上一篇把类型检查、Lint、单测、构建和页面验证的职责拆开以后任务终于有机会暴露真正的问题。接下来最容易做错的决定是Codex 已经改错了现在应该让它继续修还是让它全部重来这两个选择都很痛快。“继续修”看起来节省已有工作“全部重来”看起来能摆脱错误方案。但如果没有先判断错误发生在哪一层两种动作都可能让差异继续扩大。局部实现错了却把整个方案推倒会丢掉已经确认的调用链、契约和测试目标理解都错了却继续在现有代码上打补丁只会让错误假设越埋越深。所以我不会先选“修”还是“重来”而是先看四个信号。发现错误后的第一步不是马上改代码一项验证失败后我会先暂停当前修改把现场固定下来。至少记录下面五项# 当前错误现场 ​ - 原任务目标 - 当前差异范围 - 失败发生在哪个检查或页面路径 - 期望结果与实际结果 - 哪些结论已经由代码、测试或运行结果确认这一步的作用是把“感觉方案不对”变成可分析的错误。如果立即让 Codex“修好这个问题”它很可能根据最近一条报错局部优化而没有重新核对原始目标。错误提示会变成新的任务中心真正的需求反而退到上下文后面。我还会明确暂停几类动作不继续增加功能不顺手重构周边代码不为了让检查变绿而直接修改测试期望不用破坏性版本控制操作清理整个工作区不覆盖用户原有修改或与任务无关的差异。先保护现场再决定纠偏边界。第一个信号目标理解有没有发生偏移我先问的不是“代码错了多少”而是“现在实现的还是不是原来的问题”。目标偏移通常有这些表现实现解决了相邻问题却没有完成用户目标把业务结果理解成了技术动作把“保持不变”的行为一起改了遇到未知项时自行选择了业务规则验收标准已经与当前实现无法一一对应修改说明开始使用另一套目标语言。例如需求要求重置筛选条件后回到第一页并重新查询每页数量保持不变。如果实现把整个分页对象恢复成默认值代码可能很整洁查询也能执行但“每页数量保持不变”已经丢了。这不是某一行赋值写错而是目标被压缩成了“恢复默认分页”。目标没有偏移可以继续判断局部修复如果 Codex 仍然理解正确结果只是在条件顺序、字段映射或状态清理上出现局部错误现有方案通常还有保留价值。目标已经偏移先回到任务卡这时不应该继续围绕报错补代码而要重新写清用户最终要看到什么哪些行为必须改变哪些行为必须保持当前实现解决了什么错误问题新方案的验收证据是什么。目标层错误优先重新规划不代表删除全部代码。已有的项目阅读、调用链和真实验证结果仍然可以保留。需要重来的通常是错误假设不是整个工作区。第二个信号错误有没有穿过责任边界同一个错误影响范围可能完全不同。错误停留在局部实现例如一个条件判断方向写反一个字段映射遗漏成功与清理动作顺序错误局部组件少触发一次事件一个测试没有覆盖失败分支。如果公开契约、调用方和数据所有权都没有变化通常适合在当前方案内聚焦修正。错误已经扩散到公共边界例如为了修一个页面改变了公共组件默认值调整了共享类型多个调用方被迫跟着修改把局部状态迁移到全局 Store修改了统一请求封装或路由守卫引入新依赖、全局样式或构建配置自动修复制造了大面积无关差异。这时不能只修当前报错。要先把计划内差异与越界差异分开判断哪些变化应该保留哪些应当退出当前任务。我会画一张简单的错误扩散表差异位置原计划是否需要是否改变公开行为调用方数量处理动作目标页面局部状态是否1保留并修正公共组件默认值否是多个移出当前方案相关测试是否当前行为按新基线核对全局格式化差异否否多文件清理无关差异范围越界不等于全部重来更合适的动作通常是“局部回退到最后一个可信边界”保留已经确认的目标和证据保留与目标直接对应的正确差异移除越界公共修改重新建立允许修改与需要回归的范围从新的边界继续实施。这里的“回退”必须精确到本次任务自己的变化不能顺手覆盖用户已有工作。第三个信号已有成果能不能独立证明正确代码已经写了很多不代表应该保留代码只写了几行也不代表推倒成本低。我判断保留价值时不看工作量而看证据。可以保留的成果通常包括已由仓库事实确认的项目规则已复核的入口、调用链和影响范围仍然符合任务的类型或接口契约能单独通过检查的纯函数、适配层或局部组件能稳定暴露错误的测试已执行的失败路径和页面观察记录。不应该因为实现方案错了就丢掉能够说明“为什么错”的证据。怎样判断一块差异能否保留我会让每个候选差异回答四个问题它对应哪个仍然有效的任务目标它依赖的假设是否已经确认它能否与错误方案解耦有什么检查能够单独证明它没有改变其他行为四个问题中只要有关键一项答不上来就不该仅仅因为“已经写好了”而保留。这能避免沉没成本控制技术判断。第四个信号修复以后能不能快速证明继续修正还有一个前提修完以后能明确判断是否更接近目标。如果一个错误有稳定复现步骤、清楚断言或具体页面路径局部修正通常更安全复现失败 → 修改一个原因 → 运行直接检查 → 复查相关差异 → 回归受影响路径如果每次修正都只能靠“看起来更合理”就要谨慎。不可验证的连续补丁会产生两个问题新代码可能掩盖旧错误却没有解决根因多轮修改以后很难判断哪一轮改变了行为。适合继续修的情况目标和契约仍然正确错误位置可以限定修改范围没有继续扩大有直接检查能抓住错误修复后回归范围清楚。适合局部回退的情况某一批差异开始越界错误集中在一个尚未验证的实现分支最后一个可信检查点清楚正确部分可以与错误部分分离回退不会覆盖其他人的已有工作。适合重新规划的情况原始目标被误解公共契约或数据所有权判断错误新发现让风险等级明显上升当前方案的每一层都依赖同一个错误假设没有可靠方式证明继续补丁会收敛。“重新规划”与“清空后再生成一次”不是同一件事。真正的重新规划必须吸收本轮得到的新事实否则只是让 Codex 用同一份上下文再次走向同一个错误。我使用三种纠偏动作而不是二选一把选择限制成“继续修”或“全部重来”粒度太粗。我更常用三种动作。动作一聚焦修正适用于目标正确、范围稳定、错误局部且可验证的情况。要求是一轮只修一个已确认原因不扩大文件范围先运行最直接检查再复查完整差异与相关回归记录本轮改变了什么结论。动作二局部回退到可信边界适用于某一批实现越界或方向错误但前面的目标、调查和部分实现仍然有效。回退前要列出保留哪些差异及依据移除哪些差异及原因用户已有修改怎样保护回退后的基线是什么下一轮从哪个最小行为重新开始。不要把“局部回退”写成模糊的“恢复一下代码”。目标必须精确到文件、差异块和行为。动作三重新规划适用于目标、契约、所有权或影响范围判断已经失效。重新规划至少更新四份内容任务目标和保持不变项项目事实与未知项允许范围和暂停条件新的完成证据。原有代码是否保留要等新计划建立后逐项判断不能先凭情绪全部删除。一个方法演示列表重置行为改错以后怎样判断下面只是方法演示不代表具体项目经历。目标是重置搜索条件页码回到 1保持每页数量并用默认条件重新查询。验证发现重置后每页数量也恢复成默认值。进一步检查差异又发现 Codex 修改了公共分页组件的重置方法。这时我会这样判断目标层目标本身清楚错误是把“页码重置”扩大成“分页对象重置”。不需要重新定义整个需求。范围层任务只要求当前页面行为公共分页组件修改属于越界必须退出当前方案。可保留成果搜索表单清理、默认条件转换和相关测试如果不依赖公共组件修改可以保留。可验证性可以用请求参数断言和“查询 → 翻页 → 重置”页面路径直接验证。最终动作不是全部重来也不是在公共组件上继续补兼容逻辑而是局部回退公共分页差异在目标页面按既有分页契约修正页码再运行参数测试和页面连续路径。这个例子说明纠偏的核心不是改动多少而是错误停在哪个责任边界。我会这样给 Codex 下达纠偏任务# 本轮只做错误定位与纠偏 ​ ## 已确认目标 - 目标行为 - 保持不变 ​ ## 错误证据 - 触发步骤 - 期望结果 - 实际结果 - 对应代码或运行证据 ​ ## 先分析不立即扩大修改 请判断错误属于 - 目标理解 - 修改范围 - 局部实现 - 公共契约 - 环境或验证基线。 ​ ## 输出纠偏建议 - 建议动作聚焦修正 / 局部回退 / 重新规划 - 保留的差异及依据 - 移除的差异及依据 - 允许修改的最小范围 - 修复后的直接检查 - 需要回归的原有路径 - 仍然未知的事项 ​ 在边界确认前不修改任务外文件不清理用户已有差异。这份任务的重点是要求 Codex 先解释纠偏边界而不是立刻展示另一版代码。多轮修正必须留下最小记录如果需要两轮以上我会保存一张纠偏记录轮次错误假设本轮唯一变化直接证据结果下一动作1待确认聚焦验证一个原因检查或路径通过/失败继续/回退/重规划记录不是为了复述对话而是避免后面的修改忘记前一轮为什么失败。OpenAI 官方的复杂问题迭代用例强调在多轮改进中应先定义评估方式一次做一个聚焦变化并在每次有意义的修改后重新检查结果。放到前端纠偏里我更看重的正是这三点单一变化、直接证据、保留失败信息。写在最后AI 改错以后最危险的不是出现红色结果而是没有分类就继续行动。我会先固定错误现场再看四个信号目标有没有偏移错误有没有穿过责任边界哪些成果仍能独立证明正确修复以后能不能快速验证。目标正确、错误局部且可验证就聚焦修正某一批差异越界就局部回退到可信边界目标、契约或所有权判断已经失效就带着新证据重新规划。下一篇会把常见错误进一步压缩成一张分类表目标错误、范围错误、契约错误、局部实现错误和环境错误分别应该让 Codex 回到哪一步以及哪些动作必须禁止。本系列持续更新。下一篇会稍短一些重点提供可以快速判断和直接复用的纠偏对照表。参考资料OpenAI Codex 用例用评估方式、聚焦变化和迭代记录处理复杂问题OpenAI Codex 文档使用 AGENTS.md 提供作用范围明确的项目指引