Claude Code 团队在 AI Engineer World’s Fair 上做了一场 Fireside Chat。
Simon Willison 是主持人。Cat Wu 和 Thariq Shihipar——两位来自 Claude Code 团队的核心工程师——给了他一个反直觉的建议。
当时 Simon 问的是：“我应该怎么让 Fable 更高效地工作？”
他期待的回答可能是关于 prompt 技巧、context 管理、或者 tool 设计。
而 Claude Code 团队的回答是：别再告诉它怎么做。让它自己判断。（“Use its own judgement."）
〇、元问题：我们为什么一直在教 AI 怎么做，而不是让它自己做决定？
先看一个具体场景。
你告诉 Fable：“只在大功能修改时写测试，小的文案或样式改动不要跑测试。”
这听起来很合理。你在帮它省钱，省 token，省时间。你是一个好"管理者”。
然后 Claude Code 团队告诉你：这条路走错了。
“你告诉 Fable 精确的测试策略，不如直接说：用你自己的判断力决定什么时候写测试。”
为什么？
因为你的规则是死的，而实际情况是活的。“小改动"的定义会变，上下文会变，测试本身的可靠性也会变。你写下的每一条规则都在限制模型在具体情境中的决策空间。
经验一：人类写的规则是静态的，而 Agent 面对的情境是动态的。规则越细，模型在边缘情况下的表现越差。
一、从"指令模式"到"判断模式”
Simon 把这个建议立刻落地了。他给 Claude Code 发了一条指令：
“For all coding tasks, use your judgement to decide an appropriate lower power model and run that in a subagent.”
翻译：所有编码任务，用你自己的判断力决定用哪个更低功耗的模型，然后在子 Agent 中执行。
Claude Code 自动生成了这样一个 Memory 文件：
name: delegate-coding-to-subagents
description: Simon wants coding tasks delegated to subagents
running an appropriately lower-power model
Stated by Simon on 2026-07-03:
"For all coding tasks use your judgement to decide an appropriate
lower power model and run that in a subagent."
Why: cost/efficiency — implementation work rarely needs the
top-tier model; judgment, review, and synthesis stay
with the main loop.
How to apply:
- Spawn an Agent with a model override
(sonnet for substantive implementation, haiku for trivial edits)
- Design, auditing, data synthesis, and anything judgment-heavy
stays in the main model.
这个 Memory 文件展示了判断模式的三个层次：
| 层次 | 职责 | 使用哪个模型 |
|---|---|---|
| 判断层 | 决定什么任务用什么模型 | Fable（主 Agent） |
| 执行层 | 写代码、修 bug、改样式 | Sonnet / Haiku（子 Agent） |
| 审查层 | Review 结果、批准合并 | Fable（主 Agent） |
经验二：最强的模型不应该用来写每一行代码。它应该用来判断哪行代码值得它亲自写。
二、为什么这个策略不仅省钱，而且效果更好？
Simon 试了几天后的反馈是：“So far it seems to be working well.”（目前看起来运行得很好。）
但细想一下，这个策略好的原因不止省钱。
第一，它解决了模型的注意力分配问题。
如果你让 Fable 写每一行代码，它会在修改一个 CSS 颜色值和设计一个数据库 schema 之间分配同样的注意力。这就像让一个架构师去贴墙纸——他能做，但这不是对他注意力资源的最优利用。
让 Fable 把低认知负载的任务下发给 Sonnet 或 Haiku，它就能把注意力集中在判断——“这个设计的 tradeoff 对了吗？““这个测试覆盖够了吗？““这个文件结构合理吗？”
第二，它给了模型充分的上下文来决策，而不是一条死规则。
“只在大功能时写测试"这条规则，在"修改了一个按钮的 CSS 类名"时是对的——不需要跑测试。但是在"只改了一行 import 路径，但这行 import 出现在被 200 个文件引用的核心模块里"时，这条规则就错了。
模型在具体上下文中判断"什么时候值得跑测试”，远比你写一条普适规则更准确。
第三，它创造了可验证的反馈闭环。
每次 Fable 调度子 Agent 执行任务后，主 Agent 需要 review 结果。如果子 Agent 的输出有问题——测试没写够、边界条件没覆盖——主 Agent 就会学到：“下次这种任务应该给更强的模型，或者应该自己来做。”
经验三：Agent 的真正优势不是「执行得快」，而是「能从自己的调度决策中学习」。
三、Jesse Vincent 的补充：在涨价前最大化 Fable 的价值
Simon 还分享了来自 Jesse Vincent 的相关建议。
Fable 的使用成本是一个现实问题。每次调用都在烧钱，而且 Anthropic 宣布 Fable 5 即将大幅调价。
Jesse 的建议和 Claude Code 团队的逻辑一脉相承：用 Fable 的判断力来保护 Fable 的预算。
具体做法：
- Fable 的 token 应该花在「判断」和「审查」上，而不是「实现细节」上
- Trivial 的机械操作——命名重构、CSS 调整、写 boilerplate——交给 Haiku
- 中等复杂度的实现——算法改写、新组件、测试编写——交给 Sonnet
- 只有架构决策、adversarial review、跨模块重构才需要 Fable 亲自出手
这本质上是人类工程师的资源分配模式，只是执行者是 AI。
你不让高级工程师写 CSS。你让他审查方案、做 code review、做架构决策。AI 工程的管理逻辑完全一样。
四、你该怎么开始用「判断模式」？
第一步：在 Claude Code 项目的 memory 里加入判断规则。
Simon 的模板可以直接用：
“For all coding tasks, use your judgement to decide an appropriate lower power model and run that in a subagent.”
Claude Code 会自动内化这条规则，并在每次任务开始时判断是否需要调度子 Agent。
第二步：调整你的 review 习惯。
当任务被下发给子 Agent 后，你需要 review 的不是"代码有没有 bug”——那是子 Agent 层面的质量控制。你需要 review 的是"决策对不对”——这个任务该不该下发给子 Agent？下次类似任务是不是该换一个模型？
第三步：记录调度日志。
每次 Fable 做调度决策时，记录下：任务类型、选择的模型、结果质量、是否需要重做。
几周后，你就能看到模式：哪些任务类型被正确调度，哪些被错误调度。这个数据是优化判断规则的基础。
总结
| 决策 | 回答的根本问题 |
|---|---|
| 判断权从人转移到 Agent | 规则 vs 判断，谁更适合动态环境？ |
| Fable 管判断，Sonnet/Haiku 管执行 | 最强模型的最佳用途是什么？ |
| 调度日志驱动规则优化 | Agent 如何从自己的决策中学习？ |
| Review 焦点从 bug 转向决策 | 人审查 Agent 时应该看什么？ |
Claude Code 团队的这个建议似乎很简单——“让 AI 自己判断”。但它的深层含义是：AI 编程的下一个阶段不是「让 AI 更好地执行人的指令」，而是「让 AI 取代人在指令层的判断」。
你不再是一个给 AI 下命令的指挥官。你是一个给 AI 设定方向、审查决策、优化系统的管理者。
从"告诉它怎么做"到"让它自己判断”，这不只是成本优化。这是人机协作关系的质变。
🎯 想了解更多 AI 编程的工程实践和模型调度技巧？
- 📬 关注「全栈之巅 - 梦兽编程」，每周获取 AI 开发深度内容
- 🔧 加入社区，与数百名 AI 开发者交流实战经验
参考来源：
- Simon Willison, Judgement , Jul 3 2026
- Claude Code Team Fireside Chat, AI Engineer World’s Fair 2026