上一篇完成了组件调用链检查先列公开面再找直接、间接和条件性调用方最后补查状态、副作用、生命周期、样式和测试。但找到依赖并不等于所有依赖都需要修改。例如一个组件被 12 个页面使用改内部变量名12 个页面可能都不受影响改 Prop 默认值只有没有显式传值的页面受影响改事件负载监听该事件的调用方需要检查改根节点结构业务逻辑不变但外部样式和测试可能受影响改保存后的关闭时机所有调用方都可能出现用户行为变化。所以影响范围不能直接用“引用数量”代替。我会继续追问当前改动改变了哪一层可观察结果哪些位置必须同步修改哪些只需要回归哪些可以明确排除为了让 Codex 的分析不止停在文件列表我把影响范围拆成 7 层。评估开始前先写一条“变化声明”影响评估必须围绕具体变化展开。“优化弹窗组件”无法判断范围“把保存成功后的关闭责任从组件内部交给父页面”才有清楚的传播方向。我会先写四项# 变化声明 - 当前行为 - 目标行为 - 明确保持不变 - 尚未确定其中“明确保持不变”非常重要。例如目标只改变事件负载就应明确事件触发时机、失败行为、关闭规则和 Loading 归属是否保持不变。否则 Codex 可能为了让新接口更顺手同时调整一整段流程。如果目标行为仍有多种解释影响评估应该先暴露差异不急着给出修改范围。第一层用户行为影响我先看用户能观察到什么变化。包括入口是否仍然可见点击、输入、提交和取消结果是否变化Loading、禁用、错误和空状态是否变化成功后页面是否刷新、跳转或关闭连续操作和返回重入是否变化键盘、焦点和可访问行为是否变化。用户行为层决定验收主线。一个内部契约变化如果最终行为完全不变重点是兼容和回归如果用户行为本身改变就必须回到需求和验收标准不能把它伪装成内部重构。我会要求 Codex 用前后对照写清场景修改前修改后是否为需求目标正常操作当前结果目标结果是 / 否请求失败当前恢复方式目标恢复方式是 / 否关闭重开当前状态目标状态是 / 否连续操作当前顺序目标顺序是 / 否任何“不是需求目标但会发生变化”的行都是范围扩张信号。第二层公开契约影响这一层检查组件对外暴露的接口是否变化Props 名称、类型、必填和默认值Emits 名称、时机和负载v-model的值与更新规则插槽名称、作用域和默认内容暴露方法的签名与返回值属性和事件透传公开类型和统一导出。我会把契约变化分成三类。兼容变化旧调用方式仍然成立新能力只是可选增加。即便如此也要验证默认行为没有改变。需要迁移的变化调用方必须调整才能继续工作例如事件改名、必填 Prop 增加、负载结构变化。隐性破坏变化类型可能仍然通过但运行行为变了例如默认值、事件时机、透传位置或插槽包裹结构改变。隐性破坏最值得警惕因为自动检查未必会报错。第三层调用入口影响调用入口层回答变化会传播到哪些消费者。这里使用上一篇得到的调用链把消费者分为直接调用统一导出或组件库入口包装组件全局注册动态映射路由和自动扫描其他应用或本地包。我不会把所有消费者都列为“待修改”。我会进一步标注消费者是否使用变化契约是否依赖变化行为处理方式直接页面 A是是修改并验证页面 B否可能依赖默认值重点回归包装组件 C是会向上透传修改并继续查上层示例 D是不进入生产路径同步示例或记录旧版 E否已明确不在范围排除并说明依据这种分类能避免两个极端漏掉真正受影响的调用方或者因为引用多就把所有文件一起改掉。第四层数据与状态影响组件行为通常依赖数据来源和状态归属。我会沿下面几个问题检查输入数据来自父级、路由、状态模块还是请求组件内部是否保存副本是否存在计算值、缓存值或映射值修改是否改变状态唯一来源数据转换发生在哪一层成功和失败会写回哪些状态其他页面是否共享同一状态。例如事件负载从“无参数通知”变成“返回更新后的记录”看起来只是契约增强却可能让父页面从“重新请求列表”改成“直接替换当前行”。这时影响不只是事件类型还包括列表数据是否完整排序和筛选是否仍然成立服务端计算字段是否已经返回当前页总数是否变化其他共享状态是否同步。如果这些条件没有证据就不能把减少一次请求当成顺手优化。第五层副作用影响副作用包括所有会越过组件内部边界的动作网络请求路由变化全局状态写入缓存与本地存储全局事件定时器和订阅下载、打印或剪贴板日志、埋点和监控。评估副作用时我不会只问“是否调用”还会问调用次数是否变化调用时机是否变化参数和返回处理是否变化失败和取消路径是否变化谁依赖副作用产生的结果。把请求从父页面移进组件或者从组件移回父页面可能都能实现功能但责任边界、测试方式和复用条件会完全改变。副作用位置发生变化时我通常会提高风险等级并要求单独验证。第六层生命周期与时序影响前端很多问题不是“做没做”而是“什么时候做”。我会标出关键时序首次挂载打开前后输入或 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 层判断一个组件改动用户行为公开契约调用入口数据与状态副作用生命周期与时序DOM、样式与验证。然后给每个影响点标注直接、间接或条件性传播再判断它属于必须修改、必须回归、观察记录还是明确排除。这样得到的不是一张夸大的文件清单而是一份可以直接控制修改批次和验收路径的工程依据。下一篇会进入第 2 周 Day 4Codex 完成修改以后我怎样审查代码差异。我会从正确性、修改范围和副作用三个层面检查并重点说明为什么“代码看起来合理”仍然可能偏离任务目标。本系列持续更新。接下来会把今天划定的影响范围作为差异审查基线检查 AI 实际改动是否既没有漏也没有越界。参考资料OpenAI Codex 用例理解代码库时应追踪请求流、模块职责、状态转换、隐藏依赖和修改后的检查OpenAI Codex 用例复杂问题应建立评估方式聚焦修改并在有意义的变化后重新验证每日好工具推荐在这里推荐一款超好用的图片压缩工具——“图压”在线图片压缩免费压缩 JPG、PNG、WebP - 图压工具。同事安利给我的用过后真的觉得太香了支持批量压缩、调整压缩百分比最关键的是它是离线程序下载到本地就能反复用。我平时做自媒体和写前端时经常用到再也不用去网上找在线压缩工具了。它也带在线压缩功能很方便。