在一个SDLC流水线中混合本地LLM、Claude Code、Codex、Gemini等（开源）[P]

很多AI编码工具都假设一个模型应该完成所有事情：理解任务、编写代码、审查代码并判断是否正确。我最终围绕相反的想法构建了一个工具。不是让一个模型完成整个软件开发生命周期，而是每个阶段都可以使用完全不同的模型。这意味着你可以根据自己的需求混合使用本地LLM和托管模型。例如： - 本地运行DeepSeek-R1进行规划 - 使用Claude Code进行实现 - 在Ollama上运行Qwen-Coder作为审查者 - 为另一个项目使用Gemini CLI - 仅编码阶段使用Codex - 或者任何你喜欢的组合 每个阶段都是独立的，因此你永远不会被锁定在一个供应商或一个模型系列中。如果你已经使用Claude Code、Codex、Cursor、Aider或Gemini CLI等工具，编码阶段甚至不需要API密钥。AutoDev Studio只需通过它们现有的登录状态以无头方式驱动它们。同时，其他阶段可以完全通过Ollama或任何兼容OpenAI的端点使用本地模型运行。审查者的模型系列故意与作者的模型不同，这样同一个模型永远无法批准自己的代码。这是从一开始的设计目标之一。 流水线本身如下所示： - PM代理运行澄清循环并生成实现工单 - 可选的Jira同步 - 开发代理在隔离分支上实现 - QA运行仓库的实际测试 - 审查者验证差异 - 如果QA或审查失败，则进行有边界的修改循环 - 打开真实的拉取请求供人工合并 每个阶段都会记录其令牌数、运行时间和成本。我最初构建这个是因为我想尝试在真正有意义的地方使用专门的模型，而不是让一个模型做所有事情。我一直在使用的一些示例： - 本地推理模型 → 规划 - Claude Code → 实现 - 本地Qwen-Coder → 审查 - 本地嵌入模型 → 仓库索引 令我惊讶的基准测试结果是，在两个大型Python仓库（35k和82k行代码）上，调优后的流水线在所有六个局部良好的任务上都优于冷启动的Claude Code运行，成本降低了7%到75%，因为它避免了重复的仓库探索。当然，它并不总是赢。单行的小改动通常使用单个冷启动代理更便宜，我也在基准测试中包含了这些失败案例。 其他一些功能： - 同时支持本地和托管模型 - 支持兼容OpenAI的端点 - 如果你想要完全离线的流程，可以在免费本地模型上运行 - 语言无关的流水线 - 带有流式代理日志的实时仪表板 - 按阶段跟踪成本和运行时间 - MIT许可证 仓库：https://github.com/krishagarwal314/autodev-studio 这仍然是一个早期的副项目，所以我真诚地希望获得反馈——尤其是来自正在实验本地模型的人。如果你有更好的模型组合想法，想要为个别阶段尝试不同的本地LLM，或者发现流水线崩溃的地方，我非常希望看到问题或讨论。如果你觉得这个项目有趣，星星对我意义重大。