跳出单模型陷阱：搭建多模型 AI 编程工作流的一些心得
我刚进上一家公司、开始大量使用 AI 编程助手时，配置非常简单：打开 Cursor Composer，几乎所有事都交给它。它写分析笔记、起草技术方案、写实现代码，还自己审自己的改动。没有第二个模型复核，也没有单独的验证环节。一开始感觉很快，但细微的缺陷很快就开始出现了。当起草技术方案、编写代码、审核结果都是同一个模型时，它会带着自己的一套假设一路走到底。如果它在方案里理解错了某个需求，就会在代码里实现同一个错误，然后在审查阶段还很开心地确认一切都没问题。这是我学到的第一课：绝不能让 AI 模型成为自己输出的唯一评估者。
拆分模型，却卡在复制粘贴上
下一步，我把职责拆给了不同的模型。我用 Codex 里的 GPT-5.6 Sol 来写深入的技术架构方案，然后把方案复制到 Cursor 里，让 Composer 照着写代码，最后请 Gemini Flash 来审查改动。分工思考确实提升了代码质量，但也带来了两个很现实的麻烦。
第一，手动复制粘贴太累了。整天在窗口之间来回切换、把终端输出复制到提示框里、在三个工具之间粘贴代码差异，很快就把我的开发节奏打乱了。如果必须靠人工在不同模型之间搬运文本，这套工作流根本没法规模化。
第二，每个方案都用 Sol 来写，成本太高。代码仓库里的任务并不都是架构级别的里程碑。用顶级推理模型的 token 去写一个五行小例程或一个无关紧要的内部目录函数，只会白白烧掉订阅额度和预算，回报却少得可怜。
在 Wira Delta Indonesia 重新设计工作流
创办自己的软件工作室 Wira Delta Indonesia 时，我决定从头重新思考我们该如何构建软件。
作为创始人，我既做开源工具，也做桌面产品，因此需要资深架构师级别的严谨性和彻底的代码审计——但不能为此烧掉几千美元的 token 费用，也不能一整天在网页界面之间来回复制粘贴。正是这番持续摸索，催生了 wdi-method 和我们目前在用的模型分配矩阵。
我们不依赖某个默认模型，而是按「一旦出错，会在生产环境造成多大破坏」把工作分成几个层级。
Tier A 模型，比如 Claude Opus 和 GPT Sol，只用于基础性决策：初期问题简报、产品需求文档（PRD）、数据库 schema、数据同步契约，以及安全不变量（一旦破坏就无法回退的安全约束）。凡是事后很难改、或者改动代价高昂的决策，都保留在最高一档的推理模型上。
Tier B 模型承担标准实现和日常开发。大多数常规功能工单、按锁定规格重构现有组件、跑日常任务，我们用的其实是 Gemini Flash 这类又快又省的模型。
独立审查则交给另外的模型，比如 Terra（GPT-5.6）、DeepSeek Pro、Composer 或 Qwen Max，具体看情况。写代码的模型不给自己批作业：审查由别的模型在流程之外完成；遇到关键组件，还会走多模型会审。
下面这张矩阵，用于对应我们的交付阶段、风险画像、模型负责人和评审人分配：
走进 Autopilot 预检环节
为了展示实际运行流程，下面是从我们的自动交付运行器（wdi-autopilot）对一个关键组件执行时得到的真实预检摘要：
============================================================
WDI AUTOPILOT PREFLIGHT SUMMARY (DOOR 1)
============================================================
Mandate ID : DEC-002
Mandate Title : Autopilot Mandate: SPEC-02 Implementation (Terra Audit Remediation)
Target Scope : SPEC-02 (5 Tickets: SPEC-02-01 to SPEC-02-05)
Component : license-client (mode: catalog, risk_accepted: low)
Validity Period : 2026-10-01 to 2026-10-08 (7 days)
Loop Interval : 10m
Run Branch : autopilot/DEC-002 (from main)
PREFLIGHT STATUS:
- Method Validator : GREEN (no findings, --baseline ok)
- Local Test Suite : GREEN (cargo test --quiet: 23 passed, 0 failed)
- Git Tree : CLEAN (main, remote up-to-date)
- Isolated Branch : autopilot/DEC-002 ready to create
PANEL DISPATCH:
- Builder / Coordinator : Gemini Flash
- Self-Review : Gemini Flash (coordinator)
- Peer Reviewer 1 : Terra (GPT-5.6 via kiro-agent)
kiro-agent chat --model gpt-5.6-terra --effort high --trust-tools=fs_read --no-interactive
- Peer Reviewer 2 : DeepSeek Pro (DeepSeek V4 Pro via opencode)
opencode run -m opencode-go/deepseek-v4-pro --agent wdi-reviewer
- Quorum Note : Satisfies 2-reviewer cross-family independent panel requirement for component risk_accepted: low (Google Flash != OpenAI Terra != DeepSeek Pro).
在让任何模型评审代码之前，这里会先做几件要紧的事：
先跑确定性检查。 方法验证器和本地 Rust 测试套件（cargo test：23 项通过）必须全部通过，才会进入下一步。单元测试一旦失败，就不会调用任何模型评审。编译器不花钱就能指出构建已经坏了，再花 API token 去诊断它毫无意义。
这次运行里的构建者是 Gemini Flash，目的是让构建过程又快又省。
因为这张工单涉及 license-client，风险容忍度低，我们的规则要求至少两名来自不同模型家族的独立审核者组成「法定人数」。审核者 1 是 Terra（OpenAI，通过 kiro-agent 以无头模式运行，只挂载只读工具）。审核者 2 是 DeepSeek Pro（通过 opencode 运行）。Google Flash 负责写代码，OpenAI 和 DeepSeek 负责审计。不同模型家族的训练架构和厂商数据集各不相同，因此它们的盲区不会重叠。Gemini Flash 在实现时忽略掉的边界情况，会被 Terra 或 DeepSeek 在审核阶段揪出来。
把 CLI 调度自动化
和我们早期复制粘贴的做法相比，最大的变化是：现在的调度是程序化完成的。协调器跑在自己的会话里，负责管理分支。当代码通过本地测试、可以进入审核阶段时，脚本会用只读参数调用审核方的 CLI，比如 kiro-agent 里的 --trust-tools=fs_read --no-interactive，或者 opencode 里的 --agent wdi-reviewer。审核者只拿到原始 git diff、目标工单的规格说明，以及一条明确指令：找出 bug 和违反契约的地方。审核者看不到构建者在聊天记录里做过的各种实现取舍，因此它能用没有偏见的新鲜视角来评估这些改动。
wdi-method 的定位
在多个不同 CLI 上跑多个模型，如果没有清晰的边界，很快会乱成一锅粥。我们把各项关卡整理成了 wdi-method —— 一个开源的交付框架，构建在 BMad 之上。它把工作划分为五个检查点：
- 问题简报（Problem Brief，G1）
- 产品 PRD（G2）
- 架构蓝图（G3）
- 组件构建（G4）
- 发布验证（G5）
模型按这套结构写代码，但任何代码合入主分支之前，都要由人来审核关卡文档。
结论
AI 编程工具确实能加快软件交付，但它们仍然依赖扎实的工程实践。如果你现在还在一个窗口里只依赖一个模型：
- 不要让同一个模型既写规格、又做功能、又审计 diff。
- 让本地编译器和测试套件先挡掉基础错误，再去叫模型审核。
日常开发用快模型，架构设计这类影响大的工作，以及独立的代码审查，留给更重的模型。模型之间的切换用终端脚本自动完成，省得一天到晚复制粘贴。
如果你想看看我们用的这套关卡结构，wdi-method 已开源，采用 MIT 许可证，可以直接从 npm 安装：
npx wdi-method install
仓库地址：github.com/wiradeltaid/wdi-method
希望这篇文章能帮你理清自己的 AI 工作流。如果有疑问，或者想交流多模型方案的经验，欢迎随时联系我。
《走出单模型陷阱：搭建多模型 AI 编程工作流后，我学到了什么》最初发表于 Medium 的 Dev Genius，目前仍有人在那边围绕这篇文章展开讨论。