A:这个思路完全可行,而且不是你想出来的 "野路子"—— 业界管这叫 监督者 - 执行者模式(Reviewer-Worker / Architect-Editor),Claude Code 的 subagents、Aider 的双模型模式、CrewAI 的 manager-worker 都是这个套路。
最适合你现状的两条路:
- 最快上手:Aider(开源 CLI)。它原生就支持双模型分工 —— 你指定一个模型当 architect(负责拆题目、设计结构、审查 B 的产出、挑错),另一个当 editor(负责真正写代码、改文件)。底层接 Ollama 就行,你本地已经在跑 Qwen3 了,拉一个
qwen3-coder:30b当执行者、用qwen3:32b当监督者,配两行 config 就能跑。 - 最可控、最能学东西:自己写个 Python 编排循环。本质就是:你出题给 A → A 输出任务清单和接口定义 → B 写代码到文件 → 自动跑编译 / 测试 /lint,把报错喂回给 A → A 写 review 意见 → B 改 → 循环直到 A 说过。大概 100 行代码就能跑通最小闭环。
最关键的一个坑(决定这套东西能不能真出活):
千万别让 A 只靠 "读代码" 来判断 B 写得对不对。两个 AI 对着纸面代码互相审,结果一定是错的也被夸成对的 —— 这是所有双 AI demo 好看、实际产出垃圾的根本原因。必须把 "真实执行结果" 作为裁判:B 写完 → 真的去 dotnet build / npm test / 跑起来看报错 → 把 stderr 原封不动喂给 A 和 B。A 负责设计和挑逻辑毛病,编译器和测试负责挑硬错误,这样才闭环。
评论 (0)
暂无评论。
发表留言