上一篇用四个信号判断一项错误应该继续修、局部回退,还是重新规划。
这一篇稍短一些,直接整理一张纠偏对照表。
我最想解决的问题是:验证已经告诉我“结果不对”,下一条指令应该让 Codex 做什么?
如果所有错误都只回复一句“请继续修复”,Codex 会优先处理眼前症状。它可能补条件、加兼容、修改测试或扩大公共封装,却没有回到真正出错的流程节点。
我的分类只有五类:目标、范围、契约、局部实现和环境。
一、目标错误:回到任务定义
典型信号
实现的功能与用户结果不一致;
改了本应保持不变的行为;
把业务选择当成技术默认值;
验收标准无法映射到当前实现;
修复报错以后仍然没有解决原问题。
正确动作
重新确认目标、禁止范围、已知事实、未知项和验收标准,再规划实现。
不要做
不要继续在现有方案上堆兼容分支;
不要根据当前代码反推需求;
不要把旧实现写成新的验收标准。
重新验证
先检查新计划能否逐项对应用户目标,再讨论代码是否保留。
二、范围错误:回到影响分析和差异边界
典型信号
出现计划外文件;
局部需求触碰公共组件或全局状态;
自动修复产生大面积差异;
为了一个页面修改统一请求层、路由或构建配置;
无关重构掩盖了真正功能变化。
正确动作
把差异分成必须修改、必要支撑、兼容调整和无关变化;保留有依据的部分,移出越界差异,重新划定回归范围。
不要做
不要因为公共代码已经改了,就继续迁移全部调用方;
不要顺手修复整个仓库的历史问题;
不要用整仓清理覆盖用户已有修改。
重新验证
复查完整差异、调用方和原有路径,确认修正没有再次越界。
三、契约错误:回到数据和公开边界
典型信号
Props、Emits、类型或函数签名与调用方不一致;
前端类型与真实接口字段不一致;
默认值、空值或枚举语义判断错误;
状态所有权放在错误层;
事件时机或负载改变了旧调用方式。
正确动作
先确认权威契约,再查直接和间接调用方,决定兼容、迁移还是恢复旧契约。契约没有确认前,不急着批量改调用方。
不要做
不要只用类型断言压掉错误;
不要为了让调用方编译通过而放宽成
any;不要让当前页面的特殊需求污染公共默认行为。
重新验证
类型检查只是起点,还要验证真实数据映射、代表调用方和保持不变的旧行为。
四、局部实现错误:留在当前批次聚焦修正
典型信号
条件、顺序或字段映射错误;
Loading 没有在失败出口恢复;
页码更新与请求先后顺序错误;
关闭重开残留局部状态;
某个边界分支遗漏,但目标和契约仍然正确。
正确动作
用稳定复现步骤锁定一个原因,只修改最小位置,运行最直接检查,再回归相关路径。
不要做
不要借机抽公共工具;
不要一次同时修多个猜测;
不要只看新测试变绿,不检查完整差异。
重新验证
验证触发条件、实际结果、保持不变项以及与错误直接相关的连续操作。
五、环境错误:回到执行条件,不改业务代码
典型信号
依赖未安装或版本不匹配;
环境变量、服务、账号或测试数据缺失;
本地脚本与 CI 入口不同;
生成文件或前置步骤没有执行;
修改前同一检查已经失败。
正确动作
记录实际命令、环境、失败输出和缺失条件,区分历史失败与本次新增问题。能补齐环境就补齐,不能补齐就标成无法判断。
不要做
不要修改业务代码去适配错误环境;
不要删除测试或降低规则只求变绿;
不要把“无法运行”写成“功能应该正常”。
重新验证
在条件恢复后先重跑原始检查,确认失败是否仍与当前差异有关。
一张快速判断表
| 错误类型 | 回到哪一步 | 首选动作 | 主要证据 |
|---|---|---|---|
| 目标错误 | 任务卡与验收标准 | 重新规划 | 用户结果与保持不变项 |
| 范围错误 | 调用链、影响分析、差异审查 | 局部回退 | 文件范围与调用方 |
| 契约错误 | 接口、类型、组件公开面 | 重建契约后再实施 | 权威定义与兼容路径 |
| 局部实现错误 | 当前修改批次 | 聚焦修正 | 直接测试或页面路径 |
| 环境错误 | 检查入口与运行条件 | 恢复环境或记录阻断 | 命令、基线和失败输出 |
这里最容易混淆的是“契约错误”和“局部实现错误”。
判断方法很简单:
如果修复需要重新决定调用双方如何约定,就是契约问题;如果约定已经明确,只是当前代码没有照做,就是局部实现问题。
前者通常要重新查影响范围,后者通常可以在当前批次修正。
给 Codex 的最小纠偏指令
先不要直接修改。 根据现有任务、差异和失败证据,判断错误属于: 目标 / 范围 / 契约 / 局部实现 / 环境。 请输出: - 分类及依据; - 应回到的流程节点; - 建议保留和移除的差异; - 本轮允许修改的最小范围; - 修正后的直接检查与回归路径; - 当前不能确认的事项。 禁止为了让检查通过而修改验收标准、扩大公共范围或覆盖用户已有差异。
uniapp离线打包神器推荐
完全免费、免费、免费,忍不住了给大家分享下。
昨天发现了一款非常好用的打包安卓的工具,什么uni官方的离线打包、uni云打包全靠边站。
我开始还很怀疑这款软件是否是真实性,使用后发现简直太好用了,我再也不需要官方的离线打包了,再也不用等30分钟云打包了
工具名字就叫“uniapp 安卓快速打包”,5秒中打包,太好用了,可以uniapp离线打包安卓工具免费下载|本地快速生成签名APK。下载。