Codex 改错后,别只说“继续修”:我会先把问题分成这 5 类
2026/8/10 17:23:02 网站建设 项目流程

上一篇用四个信号判断一项错误应该继续修、局部回退,还是重新规划。

这一篇稍短一些,直接整理一张纠偏对照表。

我最想解决的问题是:验证已经告诉我“结果不对”,下一条指令应该让 Codex 做什么?

如果所有错误都只回复一句“请继续修复”,Codex 会优先处理眼前症状。它可能补条件、加兼容、修改测试或扩大公共封装,却没有回到真正出错的流程节点。

我的分类只有五类:目标、范围、契约、局部实现和环境。

一、目标错误:回到任务定义

典型信号

  • 实现的功能与用户结果不一致;

  • 改了本应保持不变的行为;

  • 把业务选择当成技术默认值;

  • 验收标准无法映射到当前实现;

  • 修复报错以后仍然没有解决原问题。

正确动作

重新确认目标、禁止范围、已知事实、未知项和验收标准,再规划实现。

不要做

  • 不要继续在现有方案上堆兼容分支;

  • 不要根据当前代码反推需求;

  • 不要把旧实现写成新的验收标准。

重新验证

先检查新计划能否逐项对应用户目标,再讨论代码是否保留。

二、范围错误:回到影响分析和差异边界

典型信号

  • 出现计划外文件;

  • 局部需求触碰公共组件或全局状态;

  • 自动修复产生大面积差异;

  • 为了一个页面修改统一请求层、路由或构建配置;

  • 无关重构掩盖了真正功能变化。

正确动作

把差异分成必须修改、必要支撑、兼容调整和无关变化;保留有依据的部分,移出越界差异,重新划定回归范围。

不要做

  • 不要因为公共代码已经改了,就继续迁移全部调用方;

  • 不要顺手修复整个仓库的历史问题;

  • 不要用整仓清理覆盖用户已有修改。

重新验证

复查完整差异、调用方和原有路径,确认修正没有再次越界。

三、契约错误:回到数据和公开边界

典型信号

  • Props、Emits、类型或函数签名与调用方不一致;

  • 前端类型与真实接口字段不一致;

  • 默认值、空值或枚举语义判断错误;

  • 状态所有权放在错误层;

  • 事件时机或负载改变了旧调用方式。

正确动作

先确认权威契约,再查直接和间接调用方,决定兼容、迁移还是恢复旧契约。契约没有确认前,不急着批量改调用方。

不要做

  • 不要只用类型断言压掉错误;

  • 不要为了让调用方编译通过而放宽成any

  • 不要让当前页面的特殊需求污染公共默认行为。

重新验证

类型检查只是起点,还要验证真实数据映射、代表调用方和保持不变的旧行为。

四、局部实现错误:留在当前批次聚焦修正

典型信号

  • 条件、顺序或字段映射错误;

  • Loading 没有在失败出口恢复;

  • 页码更新与请求先后顺序错误;

  • 关闭重开残留局部状态;

  • 某个边界分支遗漏,但目标和契约仍然正确。

正确动作

用稳定复现步骤锁定一个原因,只修改最小位置,运行最直接检查,再回归相关路径。

不要做

  • 不要借机抽公共工具;

  • 不要一次同时修多个猜测;

  • 不要只看新测试变绿,不检查完整差异。

重新验证

验证触发条件、实际结果、保持不变项以及与错误直接相关的连续操作。

五、环境错误:回到执行条件,不改业务代码

典型信号

  • 依赖未安装或版本不匹配;

  • 环境变量、服务、账号或测试数据缺失;

  • 本地脚本与 CI 入口不同;

  • 生成文件或前置步骤没有执行;

  • 修改前同一检查已经失败。

正确动作

记录实际命令、环境、失败输出和缺失条件,区分历史失败与本次新增问题。能补齐环境就补齐,不能补齐就标成无法判断。

不要做

  • 不要修改业务代码去适配错误环境;

  • 不要删除测试或降低规则只求变绿;

  • 不要把“无法运行”写成“功能应该正常”。

重新验证

在条件恢复后先重跑原始检查,确认失败是否仍与当前差异有关。

一张快速判断表

错误类型回到哪一步首选动作主要证据
目标错误任务卡与验收标准重新规划用户结果与保持不变项
范围错误调用链、影响分析、差异审查局部回退文件范围与调用方
契约错误接口、类型、组件公开面重建契约后再实施权威定义与兼容路径
局部实现错误当前修改批次聚焦修正直接测试或页面路径
环境错误检查入口与运行条件恢复环境或记录阻断命令、基线和失败输出

这里最容易混淆的是“契约错误”和“局部实现错误”。

判断方法很简单:

如果修复需要重新决定调用双方如何约定,就是契约问题;如果约定已经明确,只是当前代码没有照做,就是局部实现问题。

前者通常要重新查影响范围,后者通常可以在当前批次修正。

给 Codex 的最小纠偏指令

先不要直接修改。 ​ 根据现有任务、差异和失败证据,判断错误属于: 目标 / 范围 / 契约 / 局部实现 / 环境。 ​ 请输出: - 分类及依据; - 应回到的流程节点; - 建议保留和移除的差异; - 本轮允许修改的最小范围; - 修正后的直接检查与回归路径; - 当前不能确认的事项。 ​ 禁止为了让检查通过而修改验收标准、扩大公共范围或覆盖用户已有差异。

uniapp离线打包神器推荐

完全免费、免费、免费,忍不住了给大家分享下。

昨天发现了一款非常好用的打包安卓的工具,什么uni官方的离线打包、uni云打包全靠边站。
我开始还很怀疑这款软件是否是真实性,使用后发现简直太好用了,我再也不需要官方的离线打包了,再也不用等30分钟云打包了

工具名字就叫“uniapp 安卓快速打包”,5秒中打包,太好用了,可以uniapp离线打包安卓工具免费下载|本地快速生成签名APK。下载。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询