上一篇我给出了审查 Codex 前端差异的顺序先固定审查对象再把差异映射回任务目标然后沿用户路径检查正确性最后核对验证证据。这篇继续往下落整理成一份可以重复使用的清单。我把差异审查分成三层正确性目标行为有没有真正实现范围实际修改有没有遗漏或越界副作用没有写在目标里的其他行为是否被改变。这三层看起来有重叠关注点其实不同。正确性问“新行为对不对”范围问“改了该改的地方没有”副作用问“其他行为还和以前一样吗”。只有三层都能给出证据我才会接受一批 AI 生成的前端差异。审查前先准备四份基线清单不能脱离任务独立使用。开始前我会准备任务基线用户要解决的问题目标行为保持不变的行为正常、失败和边界验收标准。范围基线允许修改的位置修改前需要确认的公共位置明确禁止的目录和无关工作。影响基线直接、间接和条件性调用方必须修改、必须回归和明确排除的位置状态、副作用、生命周期和样式依赖。差异基线对比哪个分支、提交或任务开始前状态当前工作区是否包含用户已有修改新增、删除、重命名、暂存和未暂存文件怎样处理。如果其中一份基线缺失清单中的很多问题都无法作出判断。第一层正确性审查正确性不是看代码有没有明显报错而是检查实现与需求之间的对应关系。1. 目标是否被完整实现每个用户目标是否有对应差异是否只实现了可见入口没有接通数据与结果是否只覆盖正常路径是否遗漏失败、空值、权限或连续操作是否把“部分完成”写成“全部完成”。2. 数据是否正确流动输入来自正确来源吗状态是否仍有唯一可信来源页面、组件和请求之间的数据转换是否明确空值、默认值和可选字段是否保持语义保存后使用的是服务端结果、表单值还是旧列表数据刷新、排序、筛选和页码是否仍然一致。3. 组件契约是否正确Props 类型、必填和默认值是否符合需求Emits 名称、时机和负载是否匹配调用方v-model是否正确双向更新插槽作用域和默认内容是否改变暴露方法的参数、返回值和调用时机是否兼容属性和事件是否透传到正确节点。4. 异步流程是否闭合Loading 在所有出口都能恢复吗重复点击是否受到控制请求失败后状态是否可继续操作旧请求是否可能覆盖新状态关闭或卸载后异步结果会写到哪里成功、失败、取消和异常分支是否都有明确收尾。5. 生命周期是否正确初始化发生在首次挂载还是每次打开Props 变化后是否正确更新关闭时清理哪些状态重新打开是否残留旧数据和校验路由返回、页面缓存和组件重用是否恢复正确清理动作是否早于调用方需要的数据。6. 用户体验是否符合任务按钮、提示、错误和空状态是否明确禁用、隐藏和权限行为是否正确焦点、键盘和语义结构是否退化移动或窄屏场景是否与改动有关文案是否准确表达结果页面是否出现新的闪烁、跳动或状态错位。正确性层的结论写法我不会只写“逻辑有问题”而会写[优先级] 问题标题 触发条件 当前行为 期望行为 影响 代码或运行证据 建议修正边界它能让下一轮修复直接对应可验证结果。第二层修改范围审查正确实现一个需求不代表差异范围合理。1. 是否遗漏必须修改的位置调用链中的直接消费者是否全部处理包装组件是否继续透传旧契约公开类型和统一导出是否同步测试、示例和文档是否因公开行为变化而需要更新多应用或本地公共包是否存在真实消费者计划中的文件是否有未出现的部分。2. 是否出现计划外文件新文件为什么需要公共组件、请求层、路由和状态是否得到确认配置、依赖和锁文件变化是否与目标直接相关生成文件是否应该由脚本产生是否误改旧版、示例或其他应用。3. 是否夹带无关重构重命名是否为当前目标所需函数抽取是否改变职责边界是否顺手清理技术债是否把局部逻辑提前做成公共抽象是否替换项目已有写法是否改变与需求无关的注释、文案和样式。4. 是否出现大面积格式差异格式化是否覆盖整个文件导入排序是否使真实逻辑变化难以辨认行尾、编码或换行符是否变化自动修复是否修改了任务外文件能否缩小为只包含目标差异。5. 是否超出原定风险等级局部任务是否触碰公共契约单页面任务是否进入全局状态或路由守卫内部重构是否改变用户行为原计划的验证方式是否仍覆盖新范围是否需要重新规划而不是继续补代码。范围层最重要的问题我会让每个差异块完成一句话为了实现_这里必须改变 _如果不改会导致 ___。无法完成这句话的差异通常需要移出当前任务或补充更强的依据。第三层副作用审查副作用是最容易在“功能已完成”之后留下的问题。1. 原有调用方是否被破坏没有使用新能力的调用方是否保持原行为默认值变化是否影响未显式传值的位置事件时机和负载是否改变包装组件是否隐藏了破坏性变化动态或条件性入口是否回归。2. 共享状态是否产生连带影响修改是否写入更多全局状态其他页面是否观察到新值缓存、持久化和恢复逻辑是否一致状态清理是否影响并行页面新增副本是否可能与原状态分叉。3. 请求与接口行为是否变化请求次数是否增加参数是否新增、删除或改变默认值调用时机是否提前或延后失败重试是否可能重复副作用是否绕过统一封装返回数据是否被错误当成完整模型。4. 路由、权限和可见性是否变化查询参数和路由状态是否被重置返回或刷新后能否恢复权限判断是否移到错误层隐藏按钮是否替代了真正的数据权限不同角色是否出现新的入口或缺失入口。5. DOM 与样式是否发生隐性变化根节点和包裹层是否改变类名、深层选择器和外部样式是否失效属性透传位置是否变化定位、溢出和响应式是否退化测试选择器和可访问名称是否变化。6. 性能和资源是否退化是否增加重复请求和重复计算监听、订阅、定时器是否正确清理是否引入无必要的深度监听列表项是否产生过多局部状态大对象是否被反复复制或序列化新依赖是否增加构建和运行负担。这里不能凭感觉写“性能可能变差”。如果没有测量或明确机制证据应把它写成待验证风险而不是确定结论。7. 安全和数据边界是否变化用户输入是否进入新的 HTML、URL 或命令上下文敏感字段是否被展示、记录或缓存权限数据是否只在前端隐藏下载、跳转和外链是否校验错误信息是否暴露不必要细节。这部分涉及具体项目时应使用项目安全规范和真实接口要求不能凭通用清单替代专业安全审查。我怎样给问题排序审查不是找得越多越好。过多低价值意见会掩盖真正阻断交付的问题。我会按影响排序。P0必须立即阻断可能造成安全问题、数据破坏、严重权限越界或核心流程不可用。P1合入前必须修复稳定触发的功能错误、主要调用方破坏、状态错乱、错误数据提交或关键失败路径不可恢复。P2建议在当前任务修复特定条件下的行为问题、明显越界差异、维护成本较高的新模式或验证缺口。P3非阻断建议不影响当前正确性和边界的局部改进。它应该与必须修复的问题分开必要时转成后续任务。优先级必须根据触发条件和影响判断不能只根据代码写法是否喜欢。审查意见怎样写得可执行我使用下面的结构## [P1] 保存成功事件在状态清理后触发 - 位置目标文件和紧邻代码范围 - 触发条件保存成功父页面依赖当前记录完成局部刷新 - 当前结果关闭流程先清理记录事件负载缺失或读取为空 - 预期结果父页面在清理前取得本次保存对象失败和主动关闭行为保持不变 - 证据事件触发顺序、父页面监听逻辑、对应页面路径 - 建议边界只调整成功路径顺序不重构弹窗公共 API - 验证成功保存、失败保留、主动关闭和连续编辑路径这个结构要求审查者承担举证责任而不是只表达偏好。如果我不能说明触发条件、影响或证据就会把意见降为待确认问题而不是直接宣布代码有错。一份可直接使用的前端差异审查模板# 前端差异审查 ## 0. 审查范围 - 对比基线 - 包含文件 - 排除的已有修改 - 新增、删除、重命名和生成文件 ## 1. 任务与影响基线 - 目标行为 - 保持不变 - 允许范围 - 必须修改 - 必须回归 - 明确排除 ## 2. 正确性 - [ ] 目标完整实现 - [ ] 数据和状态正确 - [ ] 组件契约正确 - [ ] 异步流程闭合 - [ ] 生命周期正确 - [ ] 用户体验符合验收 ## 3. 修改范围 - [ ] 没有遗漏必要位置 - [ ] 没有未经确认的计划外文件 - [ ] 没有无关重构和抽象 - [ ] 没有大面积格式噪声 - [ ] 风险等级与验证计划仍然匹配 ## 4. 副作用 - [ ] 原调用方保持兼容 - [ ] 共享状态没有连带错误 - [ ] 请求与接口行为没有意外变化 - [ ] 路由、权限和可见性保持正确 - [ ] DOM、样式与可访问性没有退化 - [ ] 性能与资源风险有证据或明确待验证 - [ ] 安全与数据边界没有被扩大 ## 5. 验证证据 - 静态检查 - 测试 - 页面路径 - 完整差异复查 - 未验证事项 ## 6. 发现 ### P0 / P1 - 问题、触发、影响、证据、建议边界、验证 ### P2 - 问题、触发、影响、证据、建议边界、验证 ### P3 / 后续建议 - 建议及为什么不阻断当前交付 ## 7. 结论 - 可接受 / 修复后复审 / 需要重新规划 / 证据不足 - 结论依据清单不能替代哪些判断不能替代业务答案失败后保留数据还是回滚保存后刷新还是局部替换需要真实需求决定。不能替代运行验证静态差异无法完整证明焦点、动画、请求竞态和连续交互正确。不能替代安全与性能专项检查高风险场景需要更具体的项目规范、工具和专业审查。不能把所有建议都变成当前修改审查发现技术债很正常但当前差异应继续保持单一目标。非阻断改进可以记录为后续任务。最终结论不只有“通过”和“不通过”我会保留四种结论。可接受目标、范围和副作用均有足够证据未验证项不阻断当前交付。修复后复审存在明确问题修复范围可控修复后要重新检查相关差异和行为路径。需要重新规划影响范围扩大、公共契约变化或实现方向与需求冲突局部补丁已经不能安全解决。证据不足代码看起来合理但关键测试、页面路径或环境条件无法验证。此时不能把不确定性包装成通过。写在最后我给 Codex 前端改动做差异审查时会从三层检查正确性目标、状态、契约、异步和生命周期是否正确范围该改的有没有漏不该改的有没有进入差异副作用调用方、共享状态、请求、路由、DOM、性能和安全边界是否被意外改变。每条发现都要包含触发条件、影响、证据、建议修正边界和验证方式再按真正的交付风险排序。下一篇会进入第 2 周 Day 5为什么编译或构建通过仍然不等于任务完成。我会具体拆分类型检查、Lint、单元测试、构建和真实页面验证各自能证明什么、不能证明什么。本系列持续更新。后续会把今天的差异审查清单与自动检查和页面验证连接起来完成从“代码看起来对”到“结果有证据”的下一段闭环。参考资料OpenAI Codex 文档限定代码审查范围、查看优先级发现并使用行级反馈OpenAI Codex 文档在 AGENTS.md 中配置接近代码作用范围的审查规则
上一篇我给出了审查 Codex 前端差异的顺序先固定审查对象再把差异映射回任务目标然后沿用户路径检查正确性最后核对验证证据。这篇继续往下落整理成一份可以重复使用的清单。我把差异审查分成三层正确性目标行为有没有真正实现范围实际修改有没有遗漏或越界副作用没有写在目标里的其他行为是否被改变。这三层看起来有重叠关注点其实不同。正确性问“新行为对不对”范围问“改了该改的地方没有”副作用问“其他行为还和以前一样吗”。只有三层都能给出证据我才会接受一批 AI 生成的前端差异。审查前先准备四份基线清单不能脱离任务独立使用。开始前我会准备任务基线用户要解决的问题目标行为保持不变的行为正常、失败和边界验收标准。范围基线允许修改的位置修改前需要确认的公共位置明确禁止的目录和无关工作。影响基线直接、间接和条件性调用方必须修改、必须回归和明确排除的位置状态、副作用、生命周期和样式依赖。差异基线对比哪个分支、提交或任务开始前状态当前工作区是否包含用户已有修改新增、删除、重命名、暂存和未暂存文件怎样处理。如果其中一份基线缺失清单中的很多问题都无法作出判断。第一层正确性审查正确性不是看代码有没有明显报错而是检查实现与需求之间的对应关系。1. 目标是否被完整实现每个用户目标是否有对应差异是否只实现了可见入口没有接通数据与结果是否只覆盖正常路径是否遗漏失败、空值、权限或连续操作是否把“部分完成”写成“全部完成”。2. 数据是否正确流动输入来自正确来源吗状态是否仍有唯一可信来源页面、组件和请求之间的数据转换是否明确空值、默认值和可选字段是否保持语义保存后使用的是服务端结果、表单值还是旧列表数据刷新、排序、筛选和页码是否仍然一致。3. 组件契约是否正确Props 类型、必填和默认值是否符合需求Emits 名称、时机和负载是否匹配调用方v-model是否正确双向更新插槽作用域和默认内容是否改变暴露方法的参数、返回值和调用时机是否兼容属性和事件是否透传到正确节点。4. 异步流程是否闭合Loading 在所有出口都能恢复吗重复点击是否受到控制请求失败后状态是否可继续操作旧请求是否可能覆盖新状态关闭或卸载后异步结果会写到哪里成功、失败、取消和异常分支是否都有明确收尾。5. 生命周期是否正确初始化发生在首次挂载还是每次打开Props 变化后是否正确更新关闭时清理哪些状态重新打开是否残留旧数据和校验路由返回、页面缓存和组件重用是否恢复正确清理动作是否早于调用方需要的数据。6. 用户体验是否符合任务按钮、提示、错误和空状态是否明确禁用、隐藏和权限行为是否正确焦点、键盘和语义结构是否退化移动或窄屏场景是否与改动有关文案是否准确表达结果页面是否出现新的闪烁、跳动或状态错位。正确性层的结论写法我不会只写“逻辑有问题”而会写[优先级] 问题标题 触发条件 当前行为 期望行为 影响 代码或运行证据 建议修正边界它能让下一轮修复直接对应可验证结果。第二层修改范围审查正确实现一个需求不代表差异范围合理。1. 是否遗漏必须修改的位置调用链中的直接消费者是否全部处理包装组件是否继续透传旧契约公开类型和统一导出是否同步测试、示例和文档是否因公开行为变化而需要更新多应用或本地公共包是否存在真实消费者计划中的文件是否有未出现的部分。2. 是否出现计划外文件新文件为什么需要公共组件、请求层、路由和状态是否得到确认配置、依赖和锁文件变化是否与目标直接相关生成文件是否应该由脚本产生是否误改旧版、示例或其他应用。3. 是否夹带无关重构重命名是否为当前目标所需函数抽取是否改变职责边界是否顺手清理技术债是否把局部逻辑提前做成公共抽象是否替换项目已有写法是否改变与需求无关的注释、文案和样式。4. 是否出现大面积格式差异格式化是否覆盖整个文件导入排序是否使真实逻辑变化难以辨认行尾、编码或换行符是否变化自动修复是否修改了任务外文件能否缩小为只包含目标差异。5. 是否超出原定风险等级局部任务是否触碰公共契约单页面任务是否进入全局状态或路由守卫内部重构是否改变用户行为原计划的验证方式是否仍覆盖新范围是否需要重新规划而不是继续补代码。范围层最重要的问题我会让每个差异块完成一句话为了实现_这里必须改变 _如果不改会导致 ___。无法完成这句话的差异通常需要移出当前任务或补充更强的依据。第三层副作用审查副作用是最容易在“功能已完成”之后留下的问题。1. 原有调用方是否被破坏没有使用新能力的调用方是否保持原行为默认值变化是否影响未显式传值的位置事件时机和负载是否改变包装组件是否隐藏了破坏性变化动态或条件性入口是否回归。2. 共享状态是否产生连带影响修改是否写入更多全局状态其他页面是否观察到新值缓存、持久化和恢复逻辑是否一致状态清理是否影响并行页面新增副本是否可能与原状态分叉。3. 请求与接口行为是否变化请求次数是否增加参数是否新增、删除或改变默认值调用时机是否提前或延后失败重试是否可能重复副作用是否绕过统一封装返回数据是否被错误当成完整模型。4. 路由、权限和可见性是否变化查询参数和路由状态是否被重置返回或刷新后能否恢复权限判断是否移到错误层隐藏按钮是否替代了真正的数据权限不同角色是否出现新的入口或缺失入口。5. DOM 与样式是否发生隐性变化根节点和包裹层是否改变类名、深层选择器和外部样式是否失效属性透传位置是否变化定位、溢出和响应式是否退化测试选择器和可访问名称是否变化。6. 性能和资源是否退化是否增加重复请求和重复计算监听、订阅、定时器是否正确清理是否引入无必要的深度监听列表项是否产生过多局部状态大对象是否被反复复制或序列化新依赖是否增加构建和运行负担。这里不能凭感觉写“性能可能变差”。如果没有测量或明确机制证据应把它写成待验证风险而不是确定结论。7. 安全和数据边界是否变化用户输入是否进入新的 HTML、URL 或命令上下文敏感字段是否被展示、记录或缓存权限数据是否只在前端隐藏下载、跳转和外链是否校验错误信息是否暴露不必要细节。这部分涉及具体项目时应使用项目安全规范和真实接口要求不能凭通用清单替代专业安全审查。我怎样给问题排序审查不是找得越多越好。过多低价值意见会掩盖真正阻断交付的问题。我会按影响排序。P0必须立即阻断可能造成安全问题、数据破坏、严重权限越界或核心流程不可用。P1合入前必须修复稳定触发的功能错误、主要调用方破坏、状态错乱、错误数据提交或关键失败路径不可恢复。P2建议在当前任务修复特定条件下的行为问题、明显越界差异、维护成本较高的新模式或验证缺口。P3非阻断建议不影响当前正确性和边界的局部改进。它应该与必须修复的问题分开必要时转成后续任务。优先级必须根据触发条件和影响判断不能只根据代码写法是否喜欢。审查意见怎样写得可执行我使用下面的结构## [P1] 保存成功事件在状态清理后触发 - 位置目标文件和紧邻代码范围 - 触发条件保存成功父页面依赖当前记录完成局部刷新 - 当前结果关闭流程先清理记录事件负载缺失或读取为空 - 预期结果父页面在清理前取得本次保存对象失败和主动关闭行为保持不变 - 证据事件触发顺序、父页面监听逻辑、对应页面路径 - 建议边界只调整成功路径顺序不重构弹窗公共 API - 验证成功保存、失败保留、主动关闭和连续编辑路径这个结构要求审查者承担举证责任而不是只表达偏好。如果我不能说明触发条件、影响或证据就会把意见降为待确认问题而不是直接宣布代码有错。一份可直接使用的前端差异审查模板# 前端差异审查 ## 0. 审查范围 - 对比基线 - 包含文件 - 排除的已有修改 - 新增、删除、重命名和生成文件 ## 1. 任务与影响基线 - 目标行为 - 保持不变 - 允许范围 - 必须修改 - 必须回归 - 明确排除 ## 2. 正确性 - [ ] 目标完整实现 - [ ] 数据和状态正确 - [ ] 组件契约正确 - [ ] 异步流程闭合 - [ ] 生命周期正确 - [ ] 用户体验符合验收 ## 3. 修改范围 - [ ] 没有遗漏必要位置 - [ ] 没有未经确认的计划外文件 - [ ] 没有无关重构和抽象 - [ ] 没有大面积格式噪声 - [ ] 风险等级与验证计划仍然匹配 ## 4. 副作用 - [ ] 原调用方保持兼容 - [ ] 共享状态没有连带错误 - [ ] 请求与接口行为没有意外变化 - [ ] 路由、权限和可见性保持正确 - [ ] DOM、样式与可访问性没有退化 - [ ] 性能与资源风险有证据或明确待验证 - [ ] 安全与数据边界没有被扩大 ## 5. 验证证据 - 静态检查 - 测试 - 页面路径 - 完整差异复查 - 未验证事项 ## 6. 发现 ### P0 / P1 - 问题、触发、影响、证据、建议边界、验证 ### P2 - 问题、触发、影响、证据、建议边界、验证 ### P3 / 后续建议 - 建议及为什么不阻断当前交付 ## 7. 结论 - 可接受 / 修复后复审 / 需要重新规划 / 证据不足 - 结论依据清单不能替代哪些判断不能替代业务答案失败后保留数据还是回滚保存后刷新还是局部替换需要真实需求决定。不能替代运行验证静态差异无法完整证明焦点、动画、请求竞态和连续交互正确。不能替代安全与性能专项检查高风险场景需要更具体的项目规范、工具和专业审查。不能把所有建议都变成当前修改审查发现技术债很正常但当前差异应继续保持单一目标。非阻断改进可以记录为后续任务。最终结论不只有“通过”和“不通过”我会保留四种结论。可接受目标、范围和副作用均有足够证据未验证项不阻断当前交付。修复后复审存在明确问题修复范围可控修复后要重新检查相关差异和行为路径。需要重新规划影响范围扩大、公共契约变化或实现方向与需求冲突局部补丁已经不能安全解决。证据不足代码看起来合理但关键测试、页面路径或环境条件无法验证。此时不能把不确定性包装成通过。写在最后我给 Codex 前端改动做差异审查时会从三层检查正确性目标、状态、契约、异步和生命周期是否正确范围该改的有没有漏不该改的有没有进入差异副作用调用方、共享状态、请求、路由、DOM、性能和安全边界是否被意外改变。每条发现都要包含触发条件、影响、证据、建议修正边界和验证方式再按真正的交付风险排序。下一篇会进入第 2 周 Day 5为什么编译或构建通过仍然不等于任务完成。我会具体拆分类型检查、Lint、单元测试、构建和真实页面验证各自能证明什么、不能证明什么。本系列持续更新。后续会把今天的差异审查清单与自动检查和页面验证连接起来完成从“代码看起来对”到“结果有证据”的下一段闭环。参考资料OpenAI Codex 文档限定代码审查范围、查看优先级发现并使用行级反馈OpenAI Codex 文档在 AGENTS.md 中配置接近代码作用范围的审查规则
)
