模型路由省了成本，却没解决AI代码信任问题

我花了一段时间优化 AI 代理的运行成本。

简单模型处理日常任务，更好的模型在真正需要时才启用。这样同时运行多个代理而不把所有请求都发往最贵的模型变得切实可行。

效果不错。但随后我遇到了下一个瓶颈：如何信任返回的结果。

一个代理可以声称任务完成了，展示了通过的测试，留下了看起来干净的 diff。但这都不能告诉我它是否理解了产品决策，是否改了正确的文件，是否漏掉了代码库中其他地方的假设。

更多的代理容量并没有消除这个问题，只是让我能更快地制造出这个问题。

我现在用 Sol Advisor 配合 Codex 来分离架构、实现和审查。我保留目标、架构、验证和最终验收。实现代理只做有边界的工作。全新的审查者挑战结果。

define the change
  -> choose the implementation lane
  -> delegate a bounded task
  -> inspect the diff and rerun checks
  -> get a fresh review
  -> ship, fix first, or rethink

实现报告是一份声明，不是证明。我检查实际的工作树，确认任务在范围内，并重新运行承诺的检查，然后才请求审查。

这个流程是我之前缺失的部分。模型路由回答的是"这个任务应该花多少成本？" Sol Advisor 帮助回答"这个补丁应该发布吗？"

你需要安装 Codex 和 Bun。然后添加仓库 marketplace 并安装插件：

codex plugin marketplace add DannyMac180/sol-advisor --ref main
codex plugin add sol-advisor@sol-advisor

启动一个新的 Codex 任务并调用工作流：

Use $sol-advisor:orchestration for this task. Verify the implementation and obtain the configured advisor review before reporting done.

第一次运行会引导你完成设置。 Sol Advisor 的仓库包含当前的安装说明，而编排 skill 展示了确切的路由、验证和审查者契约。

安装给了你工作流。但交接的质量仍然取决于你给了它什么。

我不会用"让这个页面更好"来委托任务。那样你只会得到一个解决了没人问的问题的精美补丁。

我把以下内容粘贴到父任务中并填写每个部分：

# Objective
[当这个任务完成时，应该存在什么可观察的结果？]

# Scope and ownership
- May change: [拥有的文件或责任]
- May inspect: [相关文件]
- Out of scope: [明确的排除项]
- 保留仓库中已存在的不相关编辑。

# Interfaces and constraints
- [必须保持不变的行为]
- [类型、API、设计规则或安全限制]

# Verification
- Run: `[精确命令]`
- Manually confirm: [行为和边界情况]

# Evidence expected
报告改动的文件、运行的检查、做出的假设以及仍不确定的事项。

这个数据包需要几分钟来编写。但它让我避免审查一个技术上正确但解决的是错误问题的方案。

按风险选择车道

代理数量不是产生合并冲突的理由。如果两个任务无法拥有各自独立的职责，我会让它们按顺序执行。

在请求审查前先验证

当实现返回时，我检查五件事：

检查完整的工作树状态和 diff。

确认只有范围内的文件被改了。

阅读代码而不是相信摘要。

搜索被改动的接口的消费者。

重新运行工作数据包中的检查。

然后我给审查者更小的数据包：

在不修改仓库的情况下审查这个实现。

Objective: [粘贴目标]
Scope: [粘贴拥有的责任]
Constraints: [粘贴相关约束]
Evidence: [粘贴检查和观察到的结果]

检查实际的 diff 和相关的周围文件。检查正确性、范围、隐藏的消费者、回归、缺失的测试，以及证据是否证明了目标。

返回一个裁定：
- ship: 没有阻塞性问题残留；
- fix-first: 列出最小的必要修正；
- rethink: 实现或底层方法是错误的。

将阻塞性发现与可选改进分开。不要实现修正。

如果裁定是 fix-first，我把修正发回实现通道，重新运行检查，并请求另一次全新审查。任何改动的 diff 都使旧裁定失效。

我不会用整个循环来重命名一个变量。当任务存在歧义、隐藏的消费者或足够大的影响范围时，开销才是合理的。

它也无法挽救模糊的产品决策。如果我无法解释结果和约束，多个代理只会产生更复杂版本的我的困惑。

真正的生产力收益

稀缺资源不再是生成的代码。而是判断那段代码是否属于产品所需的注意力。

这个工作流让我能审慎地花费注意力。我保留决策权和验收标准。实现代理得到它能完成的工作。审查者得到清晰的机会提出异议。

在一个中等规模的任务上试试上面的数据包。保持范围紧凑，自己检查 diff，并问一个全新的审查者这个实现漏掉了什么。

当代理说它完成时，你应该有一个比"摘要听起来很有说服力"更好的答案。