读懂过程更新，完成一次审查闭环

最难判断的不是它在做什么，而是你什么时候该说话

Codex 每隔一会儿发来进度。文件找到了，方案选好了，检查正在运行。你看着很忙，却发现它第二步就误解了目标。

现在打断，怕破坏节奏。继续等待，偏差会越来越贵。

Steer 不该由焦虑触发，而该由可观察偏差触发。 这节课跟着一次模拟任务，把过程更新放进审查日志，练习何时纠偏、何时排队、何时另开工作线。

为什么“它正在做什么”不是流水账

过程更新的价值是帮助你在正确时机改变方向。你不需要逐条管理命令，但要能识别四种情况：

• 新信息会使当前方案错误：立即 steer；
• 新要求属于同一结果、但不影响当前步骤：排到下一轮；
• 新要求产生独立交付物：另开任务；
• 只是想了解进度：请求状态摘要，不改目标。

下载模拟任务记录。先只看“原始 brief”和四条过程更新，不看答案。

第一步：给每条更新写“观察—影响—动作”

例如更新说：

我发现移动端溢出来自表格，准备给整个页面设置 overflow-x: hidden。

你的判断不应只是“继续”。写：

观察：根因定位到表格，但方案会隐藏整个页面的其他溢出。
影响：可能掩盖真实缺陷，并让键盘或触摸无法访问完整表格。
动作：立即 steer；要求把横向滚动限制在表格容器，并保持页面无横向溢出。

过程反馈必须指出“为什么现在改方向”，否则容易变成风格偏好。

第二步：练习 steer

对会破坏现有目标的信息，用这个结构：

我观察到：
[引用当前计划、页面或输出中的具体差异]

这会影响：
[哪一条 Goal / Constraint / Done when]

请立即调整：
[新的边界或优先级]

调整后先验证：
[最小检查]

不要只说“别这么做”。好的 steer 保留已确认目标，并让下一步可验证。

第三步：区分 queue 与新任务

模拟记录中有一条“顺便把同样设计应用到后台页面”。它不属于当前 /feed 的验收结果，会扩大文件和回归范围，应另开任务。

另一条“修完后补一段为什么表格允许内部横向滚动的注释”仍服务于当前交付，可以排到实现后，但要确认它是否真的需要代码注释，还是文档更合适。

判断表：

问题	是	否
会改变当前方案正确性吗？	steer	继续判断
属于同一个可观察结果吗？	queue	新任务
会写同一批文件吗？	同一任务更安全	可独立
只是需要解释状态吗？	请求摘要	不改任务

第四步：审查结果交接的四类证据

结果报告至少回答：

1. 改了什么：具体文件和行为；
2. 怎么验证：命令、退出结果、页面动作；
3. 哪些没做：未覆盖状态、未执行外部动作；
4. 有什么风险：假设、兼容性或仍需人工复核。

对模拟交接逐项标记“有证据 / 只有声明 / 缺失”。特别检查：

• “测试通过”是否有命令和数量；
• “移动端正常”是否有视口、路径和动作；
• “只改相关文件”是否与 diff 一致；
• “已部署”是否有生产版本和线上检查，而不是构建成功。

第五步：查看 diff，不用摘要替代

如果这是你的真实仓库任务：

1. 打开 Codex diff 面板或运行 git diff；
2. 先看文件列表，确认范围；
3. 再看高风险区域：数据、权限、错误处理、边界条件；
4. 检查是否删除了用户原有改动；
5. 运行与变化相称的检查。

可以使用 /review 审查未提交改动、某个 commit 或相对基准分支的变化。但 review 不是自动批准；你仍需判断发现是否影响本次规范。

第六步：写一次可执行的二次修正

模拟交接漏测错误态。不要说“再仔细检查一下”，写：

观察到的差异
- 报告只验证正常和空状态，Done when 还要求错误态可重试。

必须继续保留
- 当前桌面侧栏和移动表格内部滚动行为。

修正
- 用项目已有的失败注入方式触发请求错误；
- 确认错误文案、重试按钮和重试后的恢复；
- 不改变正常请求逻辑。

重新验收
- 报告触发方法、实际文案、重试动作和结果；
- 重跑相关测试、typecheck 与 build；
- 更新截图台账和残余风险。

它包含差异、保留项、修正范围和重验，不需要重新解释整个项目。

第七步：决定接受、继续还是回退

• 接受：规范已满足，证据可复查，剩余风险可接受；
• 继续：存在明确、局部、可修复的差异；
• 回退：方案方向错误、破坏关键约束或范围已不可控；
• 暂停：需要产品、数据所有者或发布授权决定。

把你的决定写进 review-log.md，并引用至少三项证据。

参考答案与自测

打开答案，比较的不是措辞，而是分类理由。若你的结论不同，回答：

1. 你引用了哪条规范；
2. 新信息是否会使当前方案错误；
3. 它是否产生独立结果；
4. 你要求重新运行了什么检查。

一次证据冲突练习

如果结果摘要写“只修改了订单页”，但 diff 同时出现共享 Button 和主题 token，不要先问“为什么”。先记录可见冲突，检查这些文件是否属于既有用户改动，再决定继续、回退或拆分。摘要是 agent 的解释，diff 才是文件状态证据；两者不一致时，必须保留原状态并把所有权查清。

如果无法确认所有权，暂停暂存和提交，把冲突文件留给用户决定。

下一次只记录三次关键判断

别把每条状态更新都抄下来。只记录目标第一次被确认、第一次出现偏差、最后一次决定接受或拒绝的证据。

如果干预理由能指向 brief、文件或检查结果，你是在 steer。如果理由只是「我有点不放心」，先观察一轮再决定。

完成检查

• 我能区分 steer、queue、状态摘要和新任务
• 过程反馈引用了具体规范或可见差异
• 我查看了 diff，而不是只读结果摘要
• 二次修正包含保留项和重验
• 接受决定由证据而不是“Codex 说完成”支撑