Blog
我用 dev-orchestra 1.2.1 提了一个小功能的请求，测了耗时（不算等待我批准的时间，约 6 分钟），以及审查者为 1 人、2 人、4 人时提出和采纳的问题数。审查者越多，可采纳的问题也越多，但多出来的都是关于测试的问题。
我试用了 dev-orchestra 1.2.0 新增的工作单元。在计划中写下 ## Units，让 Claude 在各自独立的 git worktree 中并行实现两个工作单元，再合并回工作树，最后在原地运行负责整合的工作单元。本文用实际的命令和输出跟着走一遍。
我试用了 dev-orchestra 1.2.1 加入的 instructions。把给 implementer 和审查者的固定指示写在仓库里，它们就会进入每一次的提示词。本文用实际的输出确认它们如何显示、放在哪里，以及修改指示的变更会被如何对待。
我在 Claude Code、Codex 和 Antigravity 中，分别实际把 dev-orchestra 从 1.0.0 更新到了 1.1.1。在 Claude Code 中，只执行 claude plugin update 并不会更新，需要先更新 marketplace。本文整理了各 CLI 的更新步骤、更新之后要确认的事，以及卸载方法。
在 dev-orchestra 1.0.0 中，我从零编写了自己的适配器，把本地 LLM 加为审查者。只需一个接收提示词并返回回答的小型 CLI，加上大约 50 行的适配器即可接入。本文整理了存放位置、用 doctor 确认、能胜任和不能胜任的角色，以及注意事项。
介绍如何为 dev-orchestra 的每个角色（role）指定模型、如何选择审查者的侧重点，以及能提议领域专家角色的 config suggest-roles。我还把故意埋了 bug 的改动交给 9 位审查者，测了测增加人数会带来什么变化。
我在 3 种环境（只有 Claude Code、只有 Codex、两者都有）中实际展开了 dev-orchestra 初始设置里可选的预设 quality / standard / fast，并进行了比较。这里总结各角色的模型、审查者人数和成本削减程度有何不同，以及该选哪一个。
我也在 Antigravity 中装上了 dev-orchestra。作为对话的地方可以正常使用，但把设计和审查交给 Antigravity CLI（agy）是有限制的。这里整理了能做什么、不能做什么，以及我推荐的用法。
我把 dev-orchestra 也装到了 Codex 上。只有 Codex 也能运行，但同时安装 Claude Code 和 Codex 后，会自动变成由不同公司的 AI 来审查代码的推荐配置。文末还整理了只有 Codex 才有的功能和注意事项。
我在只有 Claude Code 的环境中装上 dev-orchestra，从初始设置到一句话的请求都试了一遍。安装只需两行命令，首次使用时只要选一个预设，审查员也只用 Claude 来组建。最后还整理了仅限 Claude Code 的功能和注意事项。
介绍可在 Claude Code / Codex / Antigravity 中运行的插件 dev-orchestra。内容包括它能做什么、与官方 codex-plugin-cc 的区别、只用 Claude Code 也值得使用的原因，以及它的缺点。
我想让一个 AI 写的代码也由其他 AI 来评审。但手工做的话，在终端之间复制粘贴再加上等待，让人精疲力尽。我把这件事做成了一套机制，发布了插件 dev-orchestra 的 1.0.0 版本，这篇文章整理了我做它的来龙去脉和用下来的感想。
没有符合条件的文章。