使用 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 Done（DoD）

也就是“什么情况下才算真正完成”。

例如：

# 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开发中的半成品代码。