用 Codex 这类 AI 编程助手时经常会遇到一个让人困惑的情况它说“任务已完成”代码也确实改了但项目一启动就报错或者打开页面后功能完全不能用。这并不一定代表 Codex 没有干活。很多时候它完成的是“代码修改”而不是“完整验收”。就像写完一段代码不代表整个功能已经跑通。真正的完成应该包括代码修改、关联模块检查、测试运行和核心流程验证。改了函数调用方还在用旧逻辑这是比较常见的问题。比如 Codex 把一个函数的返回结果从return username;改成了return { username, avatar };函数本身没有语法问题但调用它的地方可能还在直接使用user.toUpperCase();这时项目运行后就会报错。类似的问题还包括参数数量发生变化返回值类型发生变化接口字段名称被修改数据结构调整后页面仍按旧结构读取类名、函数名修改后其他文件仍在引用旧名称。排查时不要只看 Codex 修改的那个文件还要全局搜索这个函数、接口或变量被哪些地方调用。可以直接告诉 Codex请检查你刚才修改的函数、接口或数据结构找出所有调用方确认它们是否仍然按照旧逻辑使用。不要只检查当前文件。只改了一个模块没有验证完整流程一个功能往往不是由一个文件独立完成的。比如“用户提交表单”这件事可能要经过页面输入 → 前端校验 → 请求接口 → 后端处理 → 数据保存 → 返回结果 → 页面提示。Codex 可能只修改了后端接口但没有确认前端传过来的字段是否一致也可能页面按钮能点击但请求失败后没有正确提示。代码看起来没问题实际操作时却会出现点击按钮没有反应页面一直加载数据提交成功但页面不更新接口返回成功页面却显示失败删除、编辑等后续操作无法继续。所以功能完成后要让 Codex 按真实使用路径走一遍而不是只检查某个函数能不能执行。可以这样要求请按照真实用户操作流程验证这个功能 1. 打开页面 2. 输入一组正常数据 3. 点击提交 4. 检查请求是否成功 5. 检查返回结果是否正确显示 6. 再测试一次错误输入和重复操作测试只覆盖了正常情况很多测试只验证“顺利完成”的情况却没有覆盖异常操作。例如登录功能可能只测试了账号密码正确却没有测试密码错误输入为空用户不存在重复点击登录请求失败后重新提交登录状态失效。代码在正常情况下可以运行不代表真实使用时不会崩。让 Codex 补测试时不要只说“帮我写测试”而要明确测试范围请为这个功能补充测试至少覆盖 1. 正常输入 2. 空值输入 3. 错误输入 4. 重复操作 5. 请求失败 6. 返回数据为空 7. 用户连续操作时的情况如果项目已经有测试文件也要确认测试是否真的执行过。测试文件存在不等于测试通过。报错修了一处却没有重新跑完整流程Codex 有时会根据第一条报错修改代码。第一处错误解决后新的问题可能才会暴露出来。如果没有重新执行完整命令就很容易出现“看起来修好了实际上只修了一半”。比较稳妥的处理方式是记录当前完整报错让 Codex 只处理一个明确问题修改后运行对应测试把最新结果再次交给 Codex测试通过后再验证核心功能。不要一次性把多个报错混在一起也不要只告诉它“还是不行”。最好把完整错误信息、触发步骤和最新修改内容一起发给它。“任务完成”不等于“验收通过”Codex 判断任务完成通常是根据需求是否已经实现、代码是否已经修改来判断。但用户真正关心的是项目能不能启动页面能不能打开核心功能能不能操作数据是否正确保存异常情况是否有提示原有功能有没有被改坏。所以给 Codex 下指令时要把“完成标准”说清楚。可以直接复制这段提示词请不要只修改代码后回复“任务完成”要按验收闭环处理 1. 查看本次所有代码改动 2. 检查被修改函数、接口和数据结构的全部调用方 3. 执行项目已有的测试、检查和构建命令 4. 按真实用户流程验证核心功能 5. 测试正常情况、错误输入和重复操作 6. 如果出现报错先定位原因再修改代码 7. 修改后重新执行相关测试 8. 只有核心流程验证通过后才能回复任务完成 请明确告诉我 - 修改了哪些文件 - 执行了哪些验证命令 - 每条命令的结果 - 还有哪些问题没有解决新手排查时可以记住这句话不要把“代码写出来”当成“功能已经完成”。看到 Codex 回复“任务已完成”后先检查改动再执行测试再按照真实操作走一遍。只要核心流程没有跑通就不能算真正验收完成。以后遇到项目跑不起来不要马上让 Codex 重写一遍。把最新报错、触发步骤和测试结果发给它让它围绕实际结果继续排查效率通常会高很多。