使用 Codex 开发项目时经常会遇到一种很隐蔽的问题任务结束后Codex提示“修改完成”测试甚至也能通过但真正检查代码时却发现里面还留着不少半成品TODO没有处理临时 Mock 数据没有删除异常分支只返回空值测试只覆盖正常流程接口实现了一半某些函数直接写着“后续补充”临时调试代码仍然存在新功能能运行但并没有达到真正的交付标准。这类问题的核心并不是 Codex 不会写代码而是任务缺少明确的完成定义。一、“代码能运行”不等于任务完成例如要求 Codex增加用户头像上传功能。它可能完成上传按钮 → 文件选择 → 请求接口 → 页面显示头像从演示效果来看功能已经能用了。但正式项目还需要考虑文件大小限制 文件类型检查 上传失败处理 重复上传 旧头像删除 网络超时 权限验证 异常日志 自动化测试如果这些没有写进任务要求Codex很可能只完成最明显的主流程。所以不能把页面可以操作直接等同于功能已经完成。二、先定义“完成标准”在让Codex开始写代码前可以直接加入验收标准。例如当前任务 增加用户头像上传功能。 完成标准 1. 支持jpg、png 2. 最大文件5MB 3. 不支持的格式要提示 4. 上传失败不能覆盖旧头像 5. 上传成功后刷新用户信息 6. 补充相关测试 7. 不允许保留TODO 8. 不允许使用Mock数据代替真实逻辑。这样 Codex 在判断任务是否完成时就不仅仅检查“代码有没有写出来”。而是需要逐项对照验收条件。三、任务结束前强制扫描TODO一个很实用的方法是在 Codex 完成修改后要求它搜索TODO FIXME HACK TEMP mock placeholder例如rg TODO|FIXME|HACK|TEMP src如果项目没有rg也可以使用其他搜索工具。重点检查本轮新增的 TODO临时跳过的异常Mock 返回值临时账号测试中的.skip被注释掉的旧代码。尤其需要注意return null;这种代码本身不是错误但如果它只是为了暂时绕过业务实现就属于潜在半成品。四、警惕“先写个占位实现”Codex为了让项目先通过编译可能会生成async function getUserPermission() { // TODO: connect permission service return []; }从类型上看没有问题。调用方也不会立即报错。但真实业务已经被替换成所有用户都没有权限或者另一种危险情况function canAccess() { return true; }这可能直接绕过权限校验。所以遇到占位代码时要判断它是否只用于测试是否会进入生产路径是否应该阻止任务完成是否需要真正实现后才能提交。五、Mock只能存在于明确的测试范围Mock本身不是坏东西。例如单元测试中模拟外部接口const paymentClient { createPayment: vi.fn().mockResolvedValue({ status: success }) };这是合理的。但如果业务代码里出现const user { id: 1, name: test-user };只是为了让页面先跑起来那就需要特别检查。可以在AGENTS.md中加入# 临时代码规则 - 生产代码不得使用Mock数据替代真实逻辑 - TODO必须在任务结束前说明 - 不允许使用固定成功结果绕过业务流程 - 不允许通过return true跳过权限判断 - 测试Mock只能存在于测试目录 - 临时代码必须明确标记并在提交前清理六、检查有没有被跳过的测试为了让整个测试集变绿有时会出现it.skip(should reject expired token, ...)或者describe.skip(...)甚至test.todo(...)这些都不一定是错误但如果是 Codex 在本轮修改中新增的就必须检查原因。可以搜索rg \.skip|test\.todo|it\.todo .任务完成前要求请列出所有被skip、todo或暂时禁用的测试。 如果是本轮新增 说明为什么不能完成。不要把“测试没有失败”误认为“所有测试都执行了”。七、异常分支是否真正处理很多半成品隐藏在catch中。例如try { await saveUser(data); } catch (error) { console.log(error); }代码不会崩溃但调用方也不知道保存失败。更完整的处理可能需要try { await saveUser(data); } catch (error) { logger.error({ event: save_user_failed, error }); throw new UserSaveError(); }或者返回明确的错误状态。所以Code Review时需要重点检查catch fallback default return null return [] return true这些位置最容易隐藏“暂时先这样”的处理。八、检查临时日志是否还存在调试过程中常见console.log(here); console.log(data); console.log(debug user, user);问题解决后如果这些日志没有删除会慢慢污染项目。更严重的是console.log(token); console.log(request.headers);可能泄露敏感信息。可以在提交前搜索rg console\.log src当然并不是所有console.log都必须删除。关键是判断是否属于正式日志是否包含敏感内容是否只是调试残留是否应该替换为统一Logger。九、不要只问Codex“完成了吗”如果直接问任务完成了吗答案通常只会得到已完成。更有效的方式是请不要继续修改代码。 按照以下清单审查本轮结果 1. 是否存在TODO 2. 是否存在FIXME 3. 是否存在Mock业务数据 4. 是否有被skip的测试 5. 是否存在未处理异常 6. 是否保留调试日志 7. 是否有未实现接口 8. 是否有临时return 9. 是否达到所有验收标准。 最后给出 完成 / 未完成。这相当于让 Codex 做一次交付前自检。十、建立Definition of Done团队开发中经常使用一个概念Definition of DoneDoD也就是“什么情况下才算真正完成”。例如# Definition of Done 任务只有满足以下条件才能标记完成 - 功能符合需求 - 正常流程通过 - 异常流程处理完成 - 没有新增TODO/FIXME - 没有业务Mock - 没有新增skip测试 - 类型检查通过 - 自动化测试通过 - 构建通过 - Git Diff已审查 - 文档按需更新把这份规则放进AGENTS.md以后每个Codex任务都可以复用。十一、区分“完成”和“阻塞”有些任务确实无法一次完成。例如需要外部API权限数据库字段确认产品需求决定第三方账号生产环境参数。这时不要让 Codex 用临时代码假装完成。更合理的输出应该是当前状态阻塞 已完成 - 页面结构 - 类型定义 - 请求封装 未完成 - 真实接口联调 阻塞原因 缺少第三方API凭据 暂未使用Mock进入生产代码。这比留下一个TODO然后说“完成了”更加可靠。十二、一个任务结束时生成交付报告可以让 Codex固定输出任务状态 完成 修改文件 4个 新增文件 1个 TODO 0 FIXME 0 跳过测试 0 临时Mock 0 测试 通过 类型检查 通过 构建 通过 未解决风险 头像文件清理策略需要后续监控这份交付报告非常适合大型项目。后续回看时也能快速知道任务当时到底做到了什么程度。十三、提交前做一次Git Diff审查最后仍然需要git diff --stat git diff重点检查有没有超出任务范围有没有调试代码有没有临时数据有没有被删除的校验有没有测试被弱化有没有无关格式化有没有新增依赖。Codex自检可以提高效率但不能完全替代最终Diff检查。十四、Plus还是Pro如果主要使用 Codex 做单模块开发Bug修复少量测试小范围文件修改Plus通常可以覆盖多数需求。如果每天都有大型仓库任务多文件实现连续测试和修复长时间Code Review多个项目并行则可以根据真实使用强度评估Pro。对于这类场景Pro更大的价值在于让“实现—测试—审查—交付”这一整条任务链更容易连续完成。但无论使用哪种方案完成标准都必须由项目自己定义。总结Codex提示“任务完成”并不代表代码已经达到真正可交付状态。如果项目缺少明确验收标准AI很容易把“功能能运行”理解成“任务完成”从而留下TODO、Mock、跳过测试和临时异常处理。通过Definition of Done、TODO扫描、测试检查、Git Diff审查和任务交付报告可以让Codex的“完成”变得更加可验证。真正可靠的AI开发不是看到一句“已完成”就结束任务而是能够明确回答还有没有临时代码测试是否完整异常是否处理这份代码现在能不能放心提交CSDN文章描述本文介绍如何通过Definition of Done、TODO/FIXME扫描、Mock检查、测试审查和Git Diff让Codex生成的代码从“可以运行”提升到真正可交付状态减少AI开发中的半成品代码。