三周前公司有个 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 按清单逐项排查输出结果给 ClaudeClaude 给出下一轮。循环直到覆盖所有边界条件。一张表总结这套工作流阶段谁做什么耗时定方向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 模板 交叉审查清单关注后回复协同发你。人到中年最大的变化是学会了不急。带团队也好找第二曲线也好都不必非要在某个节点交出满分答卷。每天做一点新的尝试被年轻人带飞几次被自己蠢哭几回这一天就没白过。不油腻的秘诀保持被打脸的机会然后笑嘻嘻地爬起来。关注我咱们一起晒太阳、赶路。
我一个人 11 天交付了两个模块——不是会分身，是让两个 AI 打了配合
三周前公司有个 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 按清单逐项排查输出结果给 ClaudeClaude 给出下一轮。循环直到覆盖所有边界条件。一张表总结这套工作流阶段谁做什么耗时定方向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 模板 交叉审查清单关注后回复协同发你。人到中年最大的变化是学会了不急。带团队也好找第二曲线也好都不必非要在某个节点交出满分答卷。每天做一点新的尝试被年轻人带飞几次被自己蠢哭几回这一天就没白过。不油腻的秘诀保持被打脸的机会然后笑嘻嘻地爬起来。关注我咱们一起晒太阳、赶路。
