企业官网建设流程全解析

上一篇完成了组件调用链检查：先列公开面，再找直接、间接和条件性调用方，最后补查状态、副作用、生命周期、样式和测试。

但找到依赖，并不等于所有依赖都需要修改。

例如一个组件被 12 个页面使用：

• 改内部变量名，12 个页面可能都不受影响；

• 改 Prop 默认值，只有没有显式传值的页面受影响；

• 改事件负载，监听该事件的调用方需要检查；

• 改根节点结构，业务逻辑不变，但外部样式和测试可能受影响；

• 改保存后的关闭时机，所有调用方都可能出现用户行为变化。

所以影响范围不能直接用“引用数量”代替。

我会继续追问：

当前改动改变了哪一层可观察结果？哪些位置必须同步修改，哪些只需要回归，哪些可以明确排除？

为了让 Codex 的分析不止停在文件列表，我把影响范围拆成 7 层。

评估开始前，先写一条“变化声明”

影响评估必须围绕具体变化展开。

“优化弹窗组件”无法判断范围；“把保存成功后的关闭责任从组件内部交给父页面”才有清楚的传播方向。

我会先写四项：

# 变化声明 - 当前行为： - 目标行为： - 明确保持不变： - 尚未确定：

其中“明确保持不变”非常重要。

例如目标只改变事件负载，就应明确事件触发时机、失败行为、关闭规则和 Loading 归属是否保持不变。否则 Codex 可能为了让新接口更顺手，同时调整一整段流程。

如果目标行为仍有多种解释，影响评估应该先暴露差异，不急着给出修改范围。

第一层：用户行为影响

我先看用户能观察到什么变化。

包括：

• 入口是否仍然可见；

• 点击、输入、提交和取消结果是否变化；

• Loading、禁用、错误和空状态是否变化；

• 成功后页面是否刷新、跳转或关闭；

• 连续操作和返回重入是否变化；

• 键盘、焦点和可访问行为是否变化。

用户行为层决定验收主线。

一个内部契约变化，如果最终行为完全不变，重点是兼容和回归；如果用户行为本身改变，就必须回到需求和验收标准，不能把它伪装成内部重构。

我会要求 Codex 用前后对照写清：

任何“不是需求目标但会发生变化”的行，都是范围扩张信号。

第二层：公开契约影响

这一层检查组件对外暴露的接口是否变化：

• Props 名称、类型、必填和默认值；

• Emits 名称、时机和负载；

• v-model的值与更新规则；

• 插槽名称、作用域和默认内容；

• 暴露方法的签名与返回值；

• 属性和事件透传；

• 公开类型和统一导出。

我会把契约变化分成三类。

兼容变化

旧调用方式仍然成立，新能力只是可选增加。即便如此，也要验证默认行为没有改变。

需要迁移的变化

调用方必须调整才能继续工作，例如事件改名、必填 Prop 增加、负载结构变化。

隐性破坏变化

类型可能仍然通过，但运行行为变了，例如默认值、事件时机、透传位置或插槽包裹结构改变。

隐性破坏最值得警惕，因为自动检查未必会报错。

第三层：调用入口影响

调用入口层回答：变化会传播到哪些消费者。

这里使用上一篇得到的调用链，把消费者分为：

• 直接调用；

• 统一导出或组件库入口；

• 包装组件；

• 全局注册；

• 动态映射；

• 路由和自动扫描；

• 其他应用或本地包。

我不会把所有消费者都列为“待修改”。我会进一步标注：

这种分类能避免两个极端：漏掉真正受影响的调用方，或者因为引用多就把所有文件一起改掉。

第四层：数据与状态影响

组件行为通常依赖数据来源和状态归属。

我会沿下面几个问题检查：

• 输入数据来自父级、路由、状态模块还是请求；

• 组件内部是否保存副本；

• 是否存在计算值、缓存值或映射值；

• 修改是否改变状态唯一来源；

• 数据转换发生在哪一层；

• 成功和失败会写回哪些状态；

• 其他页面是否共享同一状态。

例如事件负载从“无参数通知”变成“返回更新后的记录”，看起来只是契约增强，却可能让父页面从“重新请求列表”改成“直接替换当前行”。

这时影响不只是事件类型，还包括：

• 列表数据是否完整；

• 排序和筛选是否仍然成立；

• 服务端计算字段是否已经返回；

• 当前页总数是否变化；

• 其他共享状态是否同步。

如果这些条件没有证据，就不能把减少一次请求当成顺手优化。

第五层：副作用影响

副作用包括所有会越过组件内部边界的动作：

• 网络请求；

• 路由变化；

• 全局状态写入；

• 缓存与本地存储；

• 全局事件；

• 定时器和订阅；

• 下载、打印或剪贴板；

• 日志、埋点和监控。

评估副作用时，我不会只问“是否调用”，还会问：

1. 调用次数是否变化；

2. 调用时机是否变化；

3. 参数和返回处理是否变化；

4. 失败和取消路径是否变化；

5. 谁依赖副作用产生的结果。

把请求从父页面移进组件，或者从组件移回父页面，可能都能实现功能，但责任边界、测试方式和复用条件会完全改变。

副作用位置发生变化时，我通常会提高风险等级，并要求单独验证。

第六层：生命周期与时序影响

前端很多问题不是“做没做”，而是“什么时候做”。

我会标出关键时序：

• 首次挂载；

• 打开前后；

• 输入或 Prop 变化；

• 提交开始和结束；

• 请求成功、失败和取消；

• 关闭；

• 路由离开；

• 缓存激活与失活；

• 卸载；

• 多次请求返回顺序。

一项看似兼容的修改，如果改变了事件触发时机，仍然可能破坏调用方。

例如父页面原本在saved事件中立即读取组件状态；如果事件改到清理之后触发，事件名称和类型都没变，读取结果却变了。

时序影响通常要靠场景验证，而不能只依赖静态检查。

第七层：DOM、样式与验证影响

我把这三项放在同一层，是因为它们经常不在业务调用链中，却直接影响交付。

DOM 与样式

• 根节点是否变化；

• 类名和层级是否变化；

• 外部选择器或深层样式是否依赖内部结构；

• 属性透传落在哪个元素；

• 响应式、溢出和定位是否变化；

• 语义标签、焦点顺序和可访问名称是否变化。

测试与验证

• 单元测试是否依赖旧契约；

• 页面测试是否依赖文本、选择器和触发顺序；

• 截图基线是否会变化；

• 类型检查覆盖哪些调用方；

• 哪些条件路径必须人工验证；

• 回退时能否恢复原行为。

一个影响评估如果没有验证出口，就仍然只是猜测。

我怎样给影响分级

我不喜欢给组件改动算一个看似精确的风险分数。真实项目中的权重很难统一。

我会用两组标签。

传播方式

• 直接影响：明确使用变化契约或行为；

• 间接影响：通过包装、状态、类型或副作用传播；

• 条件性影响：只在特定配置、权限、数据或操作顺序出现。

处理级别

• 必须修改：不调整就会类型失败、运行失败或行为错误；

• 必须回归：代码可能不用改，但依赖默认值、时序、DOM 或共享状态；

• 观察记录：与变化有关，但当前证据表明不进入交付路径；

• 明确排除：有依据证明不在当前应用、版本或任务范围。

每个影响点都要同时有传播方式和处理级别。

例如“包装组件 C，间接影响，必须修改”；“页面 B，条件性影响，必须回归”；“旧版示例，直接引用，但明确排除”。

这样比高、中、低三个词更容易落实到计划。

一个方法演示：修改编辑弹窗的成功事件负载

下面只用于说明评估方法，不代表真实项目案例。

假设当前弹窗保存成功后只触发通知：

saved()

现在计划改为返回更新后的记录：

saved(updatedRecord)

表面看是一次契约扩展，7 层影响可能包括：

用户行为

按目标应保持不变：仍然保存成功、关闭弹窗并刷新正确数据。

公开契约

事件负载类型变化；原来不接收参数的监听是否仍然兼容，需要结合项目类型和写法确认。

调用入口

所有监听saved的直接页面要查；包装弹窗如果透传事件，还要继续查它的上层调用方。

数据与状态

调用方是否会用返回记录直接替换列表项；记录是否包含完整展示字段；是否会破坏排序和筛选。

副作用

原本的列表刷新请求是否保留；如果删除，接口调用次数和服务端最新状态的获取方式会改变。

生命周期

事件在关闭和状态清理之前还是之后触发；父级能否读取所需上下文。

DOM 与验证

模板可能不变，但事件测试、页面刷新测试和失败路径需要回归。

这时更稳妥的结论可能不是“顺便删除刷新请求”，而是先只增加事件负载，保持刷新行为不变。等证据证明返回记录足以替代重新请求，再把优化拆成独立任务。

影响评估的价值，就是阻止一个小契约变化悄悄夹带第二个行为变化。

一份可以交给 Codex 的影响范围模板

# 组件改动影响范围 ​ ## 0. 变化声明 - 当前行为： - 目标行为： - 保持不变： - 尚未确定： ​ ## 1. 用户行为 | 场景 | 修改前 | 修改后 | 是否为目标变化 | 验证方式 | | --- | --- | --- | --- | --- | ​ ## 2. 公开契约 | 契约 | 当前定义 | 计划变化 | 兼容性 | 证据 | | --- | --- | --- | --- | --- | ​ ## 3. 调用入口 | 消费者 | 传播方式 | 依赖内容 | 处理级别 | 验证方式 | | --- | --- | --- | --- | --- | ​ ## 4. 数据与状态 - 输入来源： - 唯一状态来源： - 数据转换： - 共享消费者： - 成功与失败写回： ​ ## 5. 副作用 - 请求： - 路由： - 全局状态： - 缓存、事件和订阅： ​ ## 6. 生命周期与时序 - 关键时间点： - 连续操作： - 关闭、重入与卸载： - 异步竞态： ​ ## 7. DOM、样式与验证 - DOM 与属性透传： - 外部样式： - 自动检查： - 页面回归： - 条件性路径： ​ ## 8. 执行结论 - 必须修改： - 只需回归： - 观察记录： - 明确排除： - 暂停条件：

影响范围怎样反过来控制执行计划

影响评估完成后，我会据此调整 Codex 的修改批次。

先固定契约，再改调用方

契约尚未确定时，不让多个调用方同时迁移。

直接影响先处理，间接影响逐层展开

包装组件或共享状态会继续传播影响，不能把它们和最终页面混成一个大批次。

条件性影响单独设计验证

权限、环境、旧数据和连续操作不能用正常路径顺便带过。

“只需回归”不等于可以忽略

没有代码差异的调用方，同样可能因为默认值、时序和 DOM 变化而出问题。

明确排除要留下依据

例如旧版应用未进入当前构建、示例不参与生产、某调用方显式覆盖了变化默认值。没有依据的排除只是遗漏。

哪些信号说明影响范围还没有划清

• 只列文件，没有说明依赖行为；

• 所有引用都被标成“可能受影响”；

• 只看类型错误，没有检查默认值和事件时机；

• 修改范围与回归范围完全相同；

• 条件性调用没有触发条件；

• 公共状态和副作用没有继续向下追踪；

• DOM 变化被简单写成“不影响功能”；

• 验证项只有“运行测试”，没有说明测试覆盖什么；

• 计划改变了用户行为，却仍把任务描述成内部重构。

出现这些信号时，我不会让 Codex直接进入多文件修改。

写在最后

调用链解决“谁与组件有关”，影响范围解决“谁会因为当前变化而发生什么”。

我会从 7 层判断一个组件改动：

1. 用户行为；

2. 公开契约；

3. 调用入口；

4. 数据与状态；

5. 副作用；

6. 生命周期与时序；

7. DOM、样式与验证。

然后给每个影响点标注直接、间接或条件性传播，再判断它属于必须修改、必须回归、观察记录还是明确排除。

这样得到的不是一张夸大的文件清单，而是一份可以直接控制修改批次和验收路径的工程依据。

下一篇会进入第 2 周 Day 4：Codex 完成修改以后，我怎样审查代码差异。我会从正确性、修改范围和副作用三个层面检查，并重点说明为什么“代码看起来合理”仍然可能偏离任务目标。

本系列持续更新。接下来会把今天划定的影响范围作为差异审查基线，检查 AI 实际改动是否既没有漏，也没有越界。

参考资料

• OpenAI Codex 用例：理解代码库时应追踪请求流、模块职责、状态转换、隐藏依赖和修改后的检查

• OpenAI Codex 用例：复杂问题应建立评估方式，聚焦修改并在有意义的变化后重新验证

• 每日好工具推荐：

  在这里推荐一款超好用的图片压缩工具——“图压”在线图片压缩｜免费压缩 JPG、PNG、WebP - 图压工具。同事安利给我的，用过后真的觉得太香了！支持批量压缩、调整压缩百分比，最关键的是它是离线程序，下载到本地就能反复用。我平时做自媒体和写前端时经常用到，再也不用去网上找在线压缩工具了。它也带在线压缩功能，很方便。