比较 dev-orchestra 的预设 quality / standard / fast

前言

第一次使用 dev-orchestra 时，它会让你选择一个预设。 在之前的几篇（Claude Code、Codex、Antigravity）里，我都只说了“拿不准就选 standard”，这次来比较一下它们各自的内容。

先把结论写在前面。

• 拿不准就选 standard。它在质量和费用之间取得平衡，也是默认值
• quality 会增加审查者，并更多地使用强力模型
• fast 平时只用 1 位审查者，实现和修复主要交给较轻量的模型

我用 dev-orchestra 1.0.0，在只有 Claude Code、只有 Codex、两者都有这 3 种环境中实际展开了这 3 个预设，并做了确认。

dev-orchestra 已在 GitHub 上开源（MIT 许可证）。如果觉得有用，欢迎点个 Star，我会非常高兴。

→ github.com/istb16/dev-orchestra

预设就是“把钱花在哪里”的选择

预设是在费用（token）这条轴上的一次选择。选定之后，下面 4 项会一并确定。

确定的内容	含义
各角色的模型	设计、实现、修复等工作交给多强的模型来做
审查者的构成	由几个人、从哪些角度（通用、安全、测试等）进行审查
设计审查	在实现之前，是否也对计划本身进行审查
优化级别	在多大程度上削减成本，例如小改动时减少审查者

而且，它会根据那台机器上已安装的 CLI 自动调整。不会出现机器上没装 Codex，却列着 Codex 审查者、每次都失败的情况。

步骤

1. 比较各角色的模型

在装有 Claude Code 的机器上，各角色的模型如下。

角色	quality	standard	fast
指挥（orchestrator）	opus	sonnet	sonnet
设计（architect）	fable	fable	opus
实现（implementer）	fable	opus	sonnet
修复（review_fixer）	fable	opus	sonnet

standard 的分配是“设计用最强的模型，实现和修复用 opus”。设计一旦出偏差，后面的工序就会全部白费，所以把钱花在这里。

在只有 Codex 的机器上，所有角色都使用 Codex 的推荐模型（recommended-coding）。预设是在不启动 CLI 的情况下构建的，而对 Codex 来说，能够可靠指定的只有推荐模型。其他模型可以之后按角色单独指定。

2. 比较审查者的构成

差别最大的就是这里。在同时装有 Claude Code 和 Codex 的机器上，构成如下。

• quality：6 位。加入了检查设计是否合理的 architecture 角度，Codex 也占 2 个席位
• standard：4 位。两家厂商共同负责通用审查，再用较轻量的模型补上安全和测试
• fast：平时只有 1 位。安全方面的审查者只在危险改动时才运行

在任何预设中，只要装了两家厂商，面板中就会同时包含两者。不过在 fast 中，平时运行的只有 Codex 的 general，Claude 的 security 只在危险改动时运行。另外，在 standard 和 fast 中，小而低风险的改动只有 1 位审查者（general）。并不一定每次都由两家厂商一起审查。

3. 比较各环境下的审查者人数

审查者的人数也会随已安装的 CLI 而变化。

环境	quality	standard	fast
Claude Code 和 Codex	6 位	4 位	1 位（危险时＋1 位）
只有 Claude Code	4 位	4 位	1 位（危险时＋1 位）
只有 Codex	4 位	2 位	1 位（危险时＋1 位）

只有 Codex 时 standard 只有 2 位，是因为正如我在 Codex 那一篇中写的，它不会创建让同一个 AI 以同一个角色并排的席位，也不会创建面向便宜模型的席位。

只有 Claude Code 时，fast 平时运行的审查者是 opus 的 general。设计角色也是 opus，所以并不是只靠轻量模型运转。

4. 比较设计审查和优化级别

剩下的两项。

	quality	standard	fast
设计审查	自动判断	自动判断	不做
优化级别	quality	balanced	aggressive

设计审查是在开始实现之前，对计划本身进行审查的工序。“自动判断”是指只有在计划较大或有风险时才会运行。fast 会跳过这一步。

优化级别是调节审查在多大程度上削减成本的旋钮。

	aggressive	balanced	quality
测试失败	不审查	不审查	仍然审查
小而低风险的改动	1 位审查者	1 位审查者	全员
要求每人给出的问题数	4	6	10

涉及认证、密钥、支付、迁移等的改动，在任何预设中都会把优化级别提升到 quality。预设本身不会变。该预设的全部审查者（fast 则是 2 位）都会参与，问题数也会看到上限。

在任何预设中，批准计划之前都不会进入实现，这一点是一样的。

5. 该选哪一个

场景	推荐
先用起来、日常开发	standard
认证、支付等出错代价高昂的代码很多，且 token 比较充裕	quality
以小修改为主、做原型，或想节省 token	fast

拿不准的话，保持 standard 就可以。觉得不够就往上调，觉得太重就往下调，这样就够了。

6. 切换预设

对智能体说“把 dev-orchestra 的预设改成 fast”，它就会帮你切换。背后运行的是下面的命令。

dev-orchestra config setup --preset quality   # 保存预设（不询问）
dev-orchestra config set preset fast          # 保留其他设置，只切换预设

预设在全局配置中以一个键（例如 preset: fast）的形式保存。保存的只有名称，内容会在每次加载时，根据该机器的 CLI 展开。之后如果装上 Codex，从下一次运行起，Codex 就会自动加入审查。

总结

• 预设是“把钱花在哪里”的选择。它会一并决定各角色的模型、审查者、设计审查和优化级别
• 拿不准就选 standard。设计使用强力模型，审查由两家厂商共同进行
• quality 最多有 6 位审查者，fast 平时是 1 位
• 会根据已安装的 CLI 自动调整。有两家厂商时，任何预设的面板中都会同时包含两者（不过在 fast 和小改动时，平时由 1 人审查）
• 危险的改动会把优化级别提升到 quality，由该预设的全部审查者来审查（fast 则是 2 位）
• 切换只需运行 config set preset <名称>，或直接拜托智能体

预设的详细规则见配置文档。

选好预设之后，如果想根据你的仓库增加专业的审查者（数据库、前端等），config suggest-roles 会给出建议。下一篇，我会写这些审查者以及角色的重新编排方法。

本系列的文章可以在“dev-orchestra”列表中一并阅读。

GitHub: istb16/dev-orchestra（欢迎点个 Star，这会是很大的鼓励）