三周前，公司有个 SaaS 项目的两个新模块要开发。原型图和 API 文档都是现成的，但排期排不出人——每个人手头都满了。
按正常估算，这两个模块一个熟手全职做，大概两周。问题是没有人能全职投入。
我说：“我来吧。”
不是逞能。是我心里有个想法想验证一下——能不能让 Claude Code 和 Codex 打配合，一个管架构，一个管执行，我一个人在中间当"指挥"。
11 天后，两个模块全部交付，测试通过。下面是我怎么做的。
不是"两个一起用"，是"一个想、一个做"
很多人以为"多 AI 协同"就是同时开两个终端，这边问完那边问。试过的都知道——这样用只会让两个 AI 互相打架，生成的代码风格不一致、规范不统一，最后你自己收拾烂摊子。
关键不是"同时用"，是分工。
我做了十六年研发，带团队最深的体会是：一个好用的团队，一定是有人想清楚、有人做出来。想的人和做的人不能是同一种思维。
Claude Code 的特点是深度推理——它会先大量读取项目文件，理解完整上下文后再动手。缺点也明显：token 消耗大，同样的任务消耗量是 Codex 的 4 倍左右。
Codex 刚好反过来——推理浅但执行快，在 Cerebras 上能跑到 1000 token/秒。适合一次性快速任务，但处理复杂重构时能力有限。
把 Claude 当架构师，把 Codex 当主力开发。Claude 想清楚"做什么、怎么做"，Codex 负责"做出来"。我当技术负责人——定方向、审结果、做决策。
11 天的三阶段实战
第一阶段：Claude 定方向（30 分钟）
进项目目录，启动 Claude Code，第一件事跑/init。
这个命令会扫描整个代码库，自动生成CLAUDE.md项目说明书——项目描述、技术栈、代码风格偏好、常见模式。根据我的经验，从/init开始能省掉 80% 的重复上下文设置。
跑完后我立刻往CLAUDE.md里追加了三条硬规范：
## 代码规范 - 使用 async/await 而非 Promise.then() - 所有 API 端点必须编写单元测试 - 错误返回格式: { error: string, code: number }然后让 Claude 根据原型图和 API 文档生成技术实现文档——API 设计、数据库 schema、中间件选型。Claude 先读完现有代码，再逐一输出，最后把文档存到/docs目录。
全程大约 30 分钟。我以前自己写这些文档，至少半天。
第二阶段：Codex 执行开发（几天）
技术文档定稿后，在同一个终端里执行/clear清理上下文，切到 Codex。
关键一步：在项目根目录创建AGENTS.md，这是 Codex 的"项目说明书"：
## 项目结构 - /src/api - API 路由层 - /src/services - 业务逻辑层 - /tests - 单元测试目录 ## 开发规范 - 使用 TypeScript 严格模式 - 所有函数必须有 JSDoc 注释 - 提交前必须通过 npm run test ## 完成标准 - 所有单元测试通过 - ESLint 零警告然后一条指令启动：
“请读取 /docs/技术文档.md，分成多个开发周期：先搭基础框架，再实现核心功能，最后完成周边功能。每个周期完成后生成对应的开发文档。”
Codex 自动拆解任务，按周期推进。我中间只做两件事——回答它遇到的模糊问题，以及跑一下单元测试看结果。一个中型模块大概 2000 行代码，从文档到可运行，Codex 大约需要 2-3 小时。
第三阶段：交叉审查（持续进行）
Codex 每完成一个周期，会把生成的implementation.md喂回 Claude：
“请对比 /docs/技术文档.md 和 /docs/implementation.md，评估差异，给出优化清单。”
Claude 逐项对比——遗漏的功能点、实现偏差、潜在的性能问题或安全漏洞。输出优化清单后交给 Codex 执行。执行完更新文档，再交回 Claude 审查。循环到没有新问题为止。
这个"对抗性审查"是整套流程里最关键的一步。两个 AI 互相检查对方的输出，比人审代码更细——人容易疲劳，AI 不会。
最后进入测试阶段：Claude 出测试清单，Codex 按清单逐项排查，输出结果给 Claude，Claude 给出下一轮。循环直到覆盖所有边界条件。
一张表总结这套工作流
| 阶段 | 谁 | 做什么 | 耗时 |
|---|---|---|---|
| 定方向 | Claude Code | 生成 CLAUDE.md + 技术文档 | 30 分钟 |
| 执行开发 | Codex | 按文档分周期编码 | 2-3 小时/模块 |
| 交叉审查 | Claude ↔ Codex | 对比文档找偏差，循环修复 | 持续进行 |
| 测试验证 | Claude → Codex | 出清单 → 排查 → 下一轮 | 直到全覆盖 |
踩过的坑
坑一：上下文膨胀。Claude 长时间会话后上下文会膨胀到影响推理质量。我的习惯是每次切换工具前执行/context检查使用量，达到 70-80% 时用/compact压缩。这个习惯帮我省了至少两次重开会话的麻烦。
坑二：两个 AI 互相覆盖改动。给 Codex 一个周期只改一个功能模块，改完锁版再交给 Claude 审查。引入冲突管理的成本，远低于让它们自由发挥后你来收拾烂摊子。
坑三：Codex 在复杂重构上翻车。遇到涉及跨模块依赖的改动，不要交给 Codex——切回 Claude，让它先分析影响范围，再决定怎么改。Codex 的定位是"执行者"不是"决策者"。
这套流程适合谁
- ✅ 一个人需要独立完成中型项目的开发者
- ✅ 需要快速迭代 MVP 的创业团队
- ✅ 想在保证质量的前提下提高效率的开发者
- ❌ 已经有多人协作、代码审查规范的成熟团队（直接用现有流程即可）
- ❌ 对 token 成本极度敏感的个人开发者
如果你也在探索多 AI 协同的工作流，我整理了一份《Claude Code + Codex 协同开发工作流模板》（含 AGENTS.md 模板 + 交叉审查清单），关注后回复"协同"发你。
人到中年，最大的变化是学会了"不急"。带团队也好，找第二曲线也好，都不必非要在某个节点交出满分答卷。每天做一点新的尝试，被年轻人带飞几次，被自己蠢哭几回，这一天就没白过。不油腻的秘诀？保持被打脸的机会，然后笑嘻嘻地爬起来。
关注我，咱们一起晒太阳、赶路。