Claude 用来审核，Codex 用来执行：一套更顺手的 AI 编程分工

有个 Claude 老账号，我一直没怎么动。

刚才重新登录了一下，还能用。那一刻的心情，像是发现抽屉里的老门禁卡居然还没过期。

真正让我紧张的，是 Codex 账号。

它已经不只是一个工具了。用久以后，它会熟悉你的项目结构、命名习惯、提交方式，甚至知道你说“顺手改一下”到底有多大范围。

这种熟悉感，换个模型很难立刻补回来。

两个模型，别安排同一种工作

我现在的分工很明确：

• Claude：代码审核、风险排查、方案挑错
• Codex：写代码、改代码、跑流程、持续执行

这不是给模型贴永久标签，而是按实际工作状态分配任务。

Claude：适合站在旁边挑问题

Claude 做代码审核通常够用了。它擅长抓这些内容：

• 逻辑漏洞
• 边界条件遗漏
• 异常处理缺失
• 权限和安全风险
• 可维护性问题
• 测试覆盖不足

你可以把一段接口代码交给它，让它只做审查，不要直接改文件：

请审核下面这段代码，不要修改文件。
请按严重程度列出问题，并说明：
1. 触发条件
2. 可能造成的后果
3. 推荐修复方式
4. 是否需要补测试

如果没有确定问题，请明确写“未发现确定性问题”，不要为了凑数量硬找。

这个提示词很重要。

很多模型一进入“审核模式”，就开始制造问题。变量名不顺眼也算问题，函数多写两行也算问题，恨不得把整个项目重写一遍。

咱们要的是风险清单，不是审稿人的情绪。

Codex：适合把事情做完

代码真正需要落地时，我更愿意交给执行能力稳定的工具。

比如：

• 根据需求修改多个文件
• 追踪调用链
• 补测试
• 执行命令并处理报错
• 检查修改前后的差异
• 继续完成上一次没有做完的任务

执行型任务最怕什么？

不是模型能力差，而是它一直劝你别做。

你让它修一个报错，它开始分析风险；你让它补一个功能，它开始建议重构；你让它改三行配置，它能写一篇“建议暂缓实施”的报告。

这种员工，谁看了不头疼？

给执行型模型的指令，要写得像任务单

“帮我优化一下代码”太宽泛。

“把这个接口改得更好”也不够具体。

模型一旦遇到边界不清的任务，就容易停在讨论阶段。你需要把任务拆成可验收的动作。

目标：修复用户登录接口在 Redis 不可用时直接返回 500 的问题。

请执行：
- 检查登录接口、缓存封装和现有测试
- 保留当前正常登录逻辑
- Redis 读取失败时走数据库校验
- 增加对应的单元测试
- 运行相关测试
- 汇总修改文件、测试结果和未解决问题

限制：
- 不要重构无关模块
- 不要修改数据库表结构
- 不要删除现有测试
- 遇到不确定的地方，先说明具体阻塞点

这类指令有三个作用：

• 告诉模型要改什么
• 告诉模型不能碰什么
• 告诉模型什么结果才算完成

任务越具体，执行过程越少跑偏。

推荐工作流：一个负责挑刺，一个负责落地

可以按下面这套流程配合：

任务开始前：让执行模型读懂现场

把项目目标、相关目录、运行命令和限制条件交代清楚。

不要一上来就让它“全项目检查”。范围太大，模型会失焦，咱们也很难判断它改了什么。

更好的做法是指定入口：

请从 src/auth/login.ts 开始，追踪它依赖的缓存、数据库和错误处理模块。
先给出影响范围，再开始修改。

修改过程中：要求它边做边验证

不要等模型改完一大堆文件，再一次性运行测试。

让它每完成一个小步骤就验证一次：

• 修改接口后运行接口测试
• 修改缓存逻辑后运行缓存测试
• 调整配置后检查启动命令
• 完成全部变更后查看 diff

这样出了问题也容易定位，不会出现“改了二十个文件，没人知道哪里坏了”的局面。

修改完成后：交给审核模型复查

把 diff、测试结果和任务目标交给 Claude。

请审核这次变更，重点检查：
- 是否满足原始需求
- 是否引入行为回归
- 是否遗漏异常分支
- 测试是否覆盖关键路径
- 是否修改了任务范围之外的内容

请只报告可以从代码中确认的问题，并标注文件和位置。

这时 Claude 的价值就出来了。

它不用负责把项目推到终点，只需要站在旁边问几句尖锐的问题：

“这里失败了怎么办？”

“这个参数为空时呢？”

“测试只验证了成功路径，失败路径谁管？”

这些问题很烦，却很有用。

账号保活，别等登录失败才想起来

长期使用的 AI 账号，建议做一份简单的保活清单：

• 定期确认登录邮箱和恢复方式
• 保存重要项目的上下文、规则和提示词
• 不把关键知识只留在聊天记录里
• 记录常用模型、套餐和付款状态
• 为重要项目保留本地文档和代码仓库
• 定期检查是否出现异常登录提醒
• 不在多个陌生环境频繁切换账号
• 遵守平台规则，避免批量、自动化或异常操作

账号能不能一直用，谁也不能保证。

真正可靠的做法，是把工作能力放在自己的项目、文档和版本库里。模型账号丢了，麻烦会很大；资料全丢了，才是真的返工地狱。

避坑清单

别把模型当成全能员工

一个模型擅长分析，不代表它适合连续执行。

一个模型代码写得快，也不代表它能发现所有安全问题。

按任务分工，通常比争论“哪个模型更强”更有意义。

别接受没有证据的审核意见

“这里可能有问题”不算完整结论。

审核意见至少要包含触发条件、影响范围和修复建议。没有复现路径，也没有代码依据的内容，先放到低优先级。

别让执行模型无限扩大范围

“顺便优化一下”是项目失控的起点。

需求之外的重构，统一放到单独任务里。当前任务只解决当前问题。

别只看模型说了什么

模型说“已完成”，不等于真的完成。

你要看：

• git diff
• 测试输出
• 实际运行结果
• 修改文件列表
• 是否产生临时文件

代码能跑起来，才算完成了一半。变更符合需求，才算真正交付。

一句话总结

Claude 适合做那个会不断追问风险的审核者。

Codex 适合做那个接到任务后持续推进、把代码真正改完的执行者。

咱们没必要让所有模型做同一种事。把任务交给合适的工具，自己保留项目资料和决策权，工作会顺很多。