最近我把 AI 编程从「选模型」，升级成了一套协作工作流。
很多人拿到需求以后，第一反应是：Codex 和 Claude Code 到底谁更强？前端用哪个？后端用哪个？
我以前也这样。后来发现这个问题本身就问错了。
真正重要的不是「谁更强」，而是把不同模型组织成一条完整的项目流水线。
为什么需要工作流？
Codex 和 Claude Code 能力结构不一样。
Codex 适合长时间读代码库、完成功能开发、修复测试构建、执行命令并收集真实证据。偏工程化、大量连续的工作。
Claude Code 适合前期架构和方案设计、产品交互取舍、前端视觉打磨、以及第二视角审查。偏判断和体验。
两边额度也不同。我有 GPT Pro 20x 账号，额度相对充足，但即使额度充足，无脑堆给高成本模型也是浪费——因为有些工作让 Codex 干更合适，Claude 应该留给真正需要判断力的环节。
所以我的思路是：不按「谁更强」分配任务，按「谁在这个环节投入产出比最高」来分配。
我的实际工作流，分五个阶段。
第一阶段：先做任务判断。
拿到需求，先判断属于哪一类：架构决策、普通功能开发、前端视觉、测试修复构建、部署验证。任务分类以后，才决定由哪个 AI 参与。模型路由做错了，后面投入再多 token 都可能是在返工。
第二阶段：一个主 Agent 对结果负责。
我的默认主 Agent 是 Codex。它负责阅读项目规范和 Roadmap、检查代码和 Git 状态、制定可验证的开发目标、完成主要工程实现、运行测试类型检查构建、保存真实证据、汇总最终交付结果。
关键原则：可以有多个 AI 参与，但只能有一个 Agent 对最终仓库状态负责。否则很容易出现两个模型各自说「已经完成」，但代码冲突、测试没跑、部署状态没人确认。
第三阶段：Claude 用在高价值环节。
Claude 不需要从头到尾陪跑。我在三个关键节点调用它：开工前帮助检查架构和实现方案；工程基线完成后，负责一段边界明确的前端视觉实现；项目结束前，对真实 diff 做第二视角审查。
尽量复用同一个 Claude 会话。第一次让它看需求和项目结构，后面把 Codex 完成的 diff、关键文件和验证结果继续交给同一个会话。Claude 不需要每次重新理解整个项目，既省额度，上下文也保持连续。
第四阶段：并行必须有边界。
多 Agent 并行最容易把项目搞乱。我的规则是：只有彼此独立的任务才允许并行；每个任务使用独立分支或 Worktree；两个 Agent 不能同时修改同一个文件；接口还没确定时，不并行开发上下游。每次只集成一个分支，集成后重新运行测试。
第五阶段：部署必须设置人工闸门。
交付分成三个状态：本地开发完成、Preview 可以验收、Production 正式上线。AI 可以完成开发、测试和 Preview，但测试通过不等于可以推到生产。生产部署、域名修改、数据库迁移等操作，必须再次由我确认。
这套工作流真正解决了三个问题。
减少高成本模型的无效消耗。Claude 不再承担机械性的代码修改、日志读取和反复构建，而是集中处理规划、视觉和审查。
弥补单一模型的能力短板。Codex 负责把项目稳定做完，Claude 负责提升产品判断和前端质量。两者形成工程能力和产品能力的互补。
让开发过程真正可控。每次协作都留下可以核验的信息：当前处于哪个阶段、谁修改了哪些文件、运行了哪些测试、有没有出现权限等待或任务卡住。不需要相信某个 AI 说「已经完成」，直接查看代码和运行证据就好。
如果你想试试。
启动双引擎工作流很简单：
启动双引擎开发工作流。先分析需求和任务依赖，由 Codex 负责主实现；需要产品决策、前端视觉或最终审查时，再调用 Claude。不要自动部署生产环境。
前端项目：工程功能完成并通过测试后，把前端页面交给视觉模型做一次直接实现和打磨，Codex 最后负责集成、测试和真实浏览器验收。
任务比较大时：先判断哪些任务可以放进独立 Worktree 并行，存在文件重叠和接口依赖的部分必须串行。
工作流还在继续迭代，但它已经让我从「和一个 AI 聊天写代码」，逐渐变成了「调度一支小型 AI 开发团队」。
有问题群里聊，踩过的坑都可以继续分享。