AutoDev Studio 开源：多模型分阶段协作

一位独立开发者在 GitHub 开源了名为 AutoDev Studio 的工具，主打「让不同的大模型分别承担软件开发生命周期（SDLC）中的不同角色」。该项目以 MIT 协议发布，允许用户在规划、实现、审查、测试等阶段自由组合本地模型与托管模型，而不必被某一家供应商锁定。

核心思路：按 SDLC 阶段分配不同模型

与传统 AI 编码工具默认「一个模型包打天下」不同，AutoDev Studio 将 SDLC 拆分为若干独立阶段，每一阶段都可以独立指定模型。例如：

• 规划阶段使用本地运行的 DeepSeek-R1
• 代码实现交给 Claude Code
• 代码审查使用基于 Ollama 运行的 Qwen-Coder
• 在另一个项目中让 Gemini CLI 或 Codex 负责特定环节
• 也可以完全使用其他组合

作者在设计上特别强调，审查环节必须使用与实现环节不同的模型家族，避免「同一模型既写代码又批准自己的代码」。

流水线结构与角色分工

整个流水线按以下顺序推进：

• PM Agent：进入澄清循环，向需求方追问细节，最终产出可执行的实现工单
• 可选的 Jira 同步环节
• Dev Agent：在隔离分支上完成代码实现
• QA：直接运行仓库自身的真实测试用例
• Reviewer：针对代码 diff 进行审查
• 有界修订循环：若 QA 或审查未通过，在限定次数内返回修订
• 推送真实 Pull Request，交由人工合并

每个阶段都会独立记录 token 消耗、运行时间与成本，便于后续追溯与对比。

基准测试与局限

作者在两个大型 Python 代码库（分别约 3.5 万行与 8.2 万行）上做了对比，结果显示在六个定位明确的任务中，调优后的流水线比一次性冷启动 Claude Code 便宜 7% 到 75%，主要收益来自减少重复的仓库探索开销。

不过作者也承认，流水线并非在所有场景都占优——对一行代码级别的小改动，单次冷启动的代理通常更便宜；这些失败案例也被一并纳入了基准结果。基准仅覆盖作者自己的两个仓库，未做跨项目复现，结论仍属初步。

使用方式与许可

工具支持本地模型与托管模型混用，可接入任何 OpenAI 兼容端点，完全离线运行亦可。对于已在使用 Claude Code、Codex、Cursor、Aider 或 Gemini CLI 的用户，AutoDev Studio 可以无头方式直接驱动它们，无需额外汇总 API Key。

该项目仍处于早期阶段，作者在 Reddit 上公开征求社区反馈，鼓励用户在 GitHub 提 issue、参与讨论或测试不同的本地模型组合。