一、先给三个模型分清角色
Claude 负责需求拆解和最终验收,Codex 处理后端与测试,Gemini 处理界面、交互和视觉细节。角色固定后,每个模型都能在自己的优势区间工作。
| 模型 | 工作 |
|---|---|
| Claude | 统筹、拆解、审查 |
| Codex | 后端、脚本、测试 |
| Gemini | 前端、样式、素材 |
二、从需求到任务清单
统筹模型先写验收标准和文件边界,再把后端、前端和测试拆成可以独立完成的任务。任何跨边界修改都要回到统筹模型确认。
三、用结构化交接替代复制对话
每个角色只交付结论、改动文件、运行命令和未解决风险。把这些信息放进项目内的工作记录,后续模型不必重新阅读整段聊天。
markdown
## 后端交接
- 已完成: /api/route.ts
- 验证: npm run typecheck
- 风险: 需要前端处理空状态四、哪些工作可以并行
后端接口、前端静态页面和测试样例可以并行;数据库迁移和依赖升级等会影响全局的任务应串行。每轮结束后由统筹模型合并结果。
五、成本与效果复盘
多模型不一定更贵,关键是把长上下文留给最合适的模型,并让短任务快速结束。每个迭代记录调用次数、Token 和返工原因,两三轮后就能找到最划算的分工。