模型路由能省钱但解决不了信任问题，除非你得像我这样搞一套审核流

最坑的地方在于，Agent 可能会告诉你任务已完成，甚至贴出测试通过的截图和干净的 diff 记录，但它到底有没有理解产品逻辑？有没有改错文件？或者是不是在代码库其他地方留了坑？这些它都不会告诉你。能力越强的 Agent，产出速度越快，导致我每天要面对的潜在 Bug 数量也呈指数级增长。

为了解决这个信任危机，我现在用 Sol Advisor 配合 Codex 把架构设计、具体实现和最终审核彻底分开。简单说就是：给实现 Agent 划定死边界，然后找一个完全独立的 Reviewer 来挑刺。

具体的实操工作流是这样的：
定义变更 → 选择实现路径 → 分配有边界的任务 → 检查 diff 并重跑测试 → 引入独立审核 → 决定上线、修复或推倒重来。

实现报告只能算作一种“声明”，而不是“证明”。所以我必须手动检查工作区，确认它没跑出范围，并在请求审核前亲自重跑一遍检查命令。

如果你也想试这套方案，得先装好 Codex 和 Bun，然后运行下面这两条命令安装插件：

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

启动新任务时，直接输入这段指令来触发工作流：

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

不过工具只是基础，最关键的是你怎么下指令。千万别写“把这个页面优化一下”这种模糊的话，否则你会得到一个很精致但完全没解决问题的补丁。我现在每次都会写一个详细的 Work Packet 丢给它，模板如下：

# Objective
[完成后应该看到什么样的具体结果？]

# Scope and ownership
- 可修改：[具体文件或职责范围]
- 可参考：[相关文件]
- 范围外：[明确禁止修改的部分]
- 必须保留仓库中已有的无关编辑。

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

# Verification
- 运行命令：`[具体命令]`
- 手动确认：[行为及边界情况]

# Evidence expected
报告修改的文件、运行的检查、做出的假设以及任何不确定的地方。

花几分钟写这个文档，能避免我花几个小时去审核一个“技术正确但方向错误”的方案。