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