Claude Code 写需求、GPT-5.6 跑测试、Kimi K3 做 review——我这套多模型前端工作流，跑了两个月，结论是省的不是钱，是命

Claude Code 写需求、GPT-5.6 跑测试、Kimi K3 做 review——我这套多模型前端工作流，跑了两个月，结论是省的不是钱，是命。

上个月我同时用三个模型跑同一个前端项目：Claude Code 写组件和业务逻辑，GPT-5.6 生成测试用例和做回归验证，Kimi K3 做代码审查和文档生成。跑了两个月，发现这套组合比任何一个单一模型都稳。

核心逻辑：让对的模型做对的事。

Claude Code 的强项是理解复杂上下文、长程依赖和架构决策。我让它负责需要深度上下文理解的部分——组件设计、状态管理逻辑、API 接口约定。GPT-5.6 的强项是快速生成、结构化输出和边界 case 覆盖——测试用例、回归脚本、mock 数据生成。Kimi K3 的优势是中文理解和文档质量——代码 review 的中文注释、README、CHANGELOG。

token 消耗大概是这样：以前全用 Claude Code 写一个中型功能，大概花 120 万 token；现在 Claude Code 只写核心逻辑 50 万，GPT-5.6 生成测试 30 万，Kimi K3 做 review 20 万，总量差不多，但每个环节的质量都更高了。

实操中踩的坑：

第一个坑是 prompt 风格不统一。三个模型对同一件事的理解方式不一样，Claude Code 喜欢详细背景，GPT-5.6 直接给指令就能跑，Kimi K3 需要明确输出格式。解决方案是给每个模型配专属 prompt 模板，不混用。

第二个坑是上下文丢失。三个模型各自独立，没有共享上下文。解决方案是用 Git commit message 作为交接媒介，每个模型产出的 commit message 格式固定，下一个模型从 commit diff 里读上下文。

第三个坑是 latency 不一样。Claude Code 响应最慢，GPT-5.6 最快，Kimi K3 在两者之间。实际操作中我把任务分流：需要快速反馈的——语法修复、简单 refactor——全走 GPT-5.6；需要深度思考的——架构设计、复杂 bug——走 Claude Code；文档和 review 走 Kimi K3，随时可以中断。

具体怎么分工：

我给三个模型画了分工线：

Claude Code：React 组件设计、状态管理方案、API 接口定义、复杂 bug 调试、需要读多个文件的上下文理解任务。

GPT-5.6：测试用例生成、边界 case 测试、回归验证、简单函数实现、代码格式化批量处理。

Kimi K3：代码 review（中文注释）、README 和文档生成、commit message 规范化、简单的代码解释和教学。

什么不该让便宜模型做：

GPT-5.6 生成测试用例快，但生成出来的测试质量参差不齐。我后来加了一个环节：GPT-5.6 生成的测试，必须让 Claude Code 过一遍逻辑正确性，不然出现过覆盖和漏覆盖的情况。

Kimi K3 做 review 很好，但涉及到性能优化和架构层面的建议，还是得回给 Claude Code。Kimi K3 能发现问题，但解决方案的质量不如 Claude Code。

现在的日常工作流：

拿到一个需求，先让 Claude Code 做技术方案设计和核心代码实现；然后把 diff 扔给 GPT-5.6 生成测试用例；最后把完整代码加测试一起扔给 Kimi K3 做 review；review 通过后合并。全程人在 loop 里，但每个环节的 AI 质量都比单一模型高。

用了两个月，这套组合让我最大的感受是：AI 编程的下一步不是「选哪个模型最强」，而是「怎么让多个模型协同工作」。单一模型的上下文窗口再大，也有处理不了的长程依赖；多个模型分工之后，每个环节的输入输出都变得更可控。

下一步我打算把这套工作流脚本化，三个模型通过 Git 和文件系统的交接变成半自动化 pipeline。有兴趣的可以先从 prompt 模板开始试，三个模型各一套，不混用。