- Claude Code 团队的 Thariq Shihipar 在 AI Engineer 2026 大会上发表主题演讲《A Field Guide to Fable》
- Anthropic 为 Fable 移除了 Claude Code 约 80% 的系统提示词——示例和约束会限制 Fable 的想象力，更精简的提示词反而让模型表现更好
- Shihipar 提出了"未知矩阵"框架（Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns），并给出六种实操方法来帮助开发者找到自己的盲点
- Fable 带来了"能力滞后"（Capability Overhang）的释放：模型的实际能力远超出提示词和工具框架所允许的范围，解绑 Harness 是关键
- 演讲以"Be Less Reasonable"收尾——Anthropic 认为传统工程中的取舍（Good Fast Cheap 只能选两个）已不再成立，三者可以兼得
Fable 是什么——Mythos 级模型的能力定位
Fable 是 Anthropic 自 Opus 4.5 和 Opus 4.8 之后最大的一次模型跃迁，属于全新的 Mythos 模型系列。与以往 Claude 模型"按规模分档"（Sonnet / Opus）不同，Fable 被定位为一次"地图展开"式的跃升——就像 RPG 游戏完成新手教程后踏入开放世界的瞬间。
Fable 在 2026 年 6 月 9 日首次上线，定价约为 Opus 的两倍。随后经历了一段出口管制风波（美国政府出于双重用途安全担忧实施管控），在 7 月 1 日恢复访问。AI Engineer 大会是 Fable 正式进入开发者视野的标志性节点。
Fable vs Mythos 的关系： 底层是同一个模型。Fable 是面向公众的版本，带有完整的安全护栏；Mythos 是内部版本，限制更少、能力释放更充分。Fable 在允许的范围内尽可能保留了 Mythos 级的能力。
解绑 Claude：为什么系统提示词砍掉 80% 反而更强
Shihipar 在这场演讲中最引人注目的观点是：Anthropic 为 Fable 移除了 Claude Code 约 80% 的系统提示词。
这个决定的背后是一个更深刻的模型哲学变化。他介绍，Claude 的发展经历了多个阶段：
- Sonnet 3.5 时代： 最佳实践是小型系统提示词 + 少量工具 + 大量示例
- Opus 4 时代： 模型变强后可以接受更多指令，系统提示词膨胀到包含大量示例和约束
- Fable 时代： 模型变得更富有想象力，示例反而成了束缚。Fable 不是"记不住规则"，而是觉得你的示例限制了它的发挥
Shihipar 用了**"能力滞后"**（Capability Overhang）来解释这一现象。"模型是被培育出来的，不是被设计出来的。"预训练赋予了模型远超我们认知的能力，但提示词、工具框架和 system prompt 构成了一个"缰绳"。解绑意味着：不是让模型变聪明，而是让已经聪明的模型有机会展示出来。
他给出了一个直观的例子：问大模型"哪些宝可梦的名字以 AW 结尾"，普通聊天模型答不出——尽管它知道所有宝可梦的名字。但如果你给 Claude Code 配上代码执行工具，它会列出所有宝可梦、写脚本筛选出 Croconaw 和 Drednaw。能力的飞跃不是来自推理链，而是来自工具的赋予。
同样的逻辑适用于 Fable：模型的推理深度、创造力和长期任务连贯性远超已有工具框架所能承载的。核心不是更好的提示词，而是更大的信任和更少的约束。
他在演讲中还展示了 Ask User Question 工具的演进史：
- Opus 4.5： 可以一次性问 40 个关于需求规范的问题，像在面试用户
- Opus 4.8 / Fable： 能直接生成内嵌问题的完整 HTML 报告，交互方式发生了质变
找到你的未知：Fable 时代的四种未知矩阵
Shihipar 提出的核心框架是一个决策认知矩阵：
他用了一个简洁的命题总结这一部分："当使用 Fable 时，我的上限从模型的能力变成了我匹配地图与疆域、找到未知的能力。"
地图不是疆域。 Prompt 和 spec 是你脑中的地图，真实的代码库是疆域。Fable 跑得又深又远，它会撞到很多你地图上没有标记的地形。如果你不提前找到这些未知，Fable 的探索深度反而会变成失控的风险。
六种实操技巧：从盲点扫描到事后测验
演讲中最具实操价值的部分——六种用 Fable 找到未知的具体方法，Shihipar 都给了可直接套用的 prompt 模板：
1. 盲点扫描（Blindspot Pass）
"我正在给这个代码库添加一个新的 OAuth 提供方，但我对 auth 模块一无所知。能否做一个 blindspot pass，帮我找出相关的未知未知，让我能写更好的 prompt？"
Fable 会遍历 OAuth 模块，搜索 git diff 和 Slack 记录，返回所有历史陷阱和需要注意的地方。
2. 头脑风暴与原型（Brainstorms & Prototypes）
对自己的设计品位没有自信？Shihipar 的建议是："我没有视觉审美，请你做 4 个完全不同设计方向的 HTML 页面，让我来选。" 这解决了"看到才知道"的问题——你不是要描述终极方案，而是用模型生成选项来刺激你的判断。
3. 面试用户（Interviews）
让 Fable 逐条提问，"优先问那些会影响架构的问题"。给 Fable 一些你的背景信息，让它在动手前先做一轮需求澄清。
4. 参考实现（References）
不用自己写完整 spec。直接给 Fable 一段已有实现的代码（可以是不同语言或框架），说"理解这段代码的语义，然后用同样的逻辑来做新项目"。Fable 擅长从参考中提取模式。
5. 实施日志（Implementation Notes）
让 Fable 在遇到未知决策时记录日志。在 prompt 里加一句："每当你做一个你没见过的决定时，请记录到 implementation-notes.md"。完成后可以回顾所有偏差发生的位置和原因。
6. 事后测验（Quizzes）
Fable 做完工作后，让它出题考你。"生成一个 HTML 报告，测验我对这次改动是否真正理解。" 确保你在合并 PR 前真正掌握了发生了什么。
心态的转变：悲伤与"变得不合理"
演讲中有一个意料之外的章节——"面对悲伤"（Dealing with the Grief）。
Shihipar 坦诚地谈到了自己作为一名资深程序员的体验转变。他记得创业时团队在"功能快不快"和"代码稳不稳"之间反复取舍，一个功能可能要用一周甚至一个月来实现。而如今用 Fable 回到同样的代码库，他发现过去那些痛苦的选择不复存在了——原本按周计算的事情，现在按小时完成。
"你怎么能不笑？但你又怎么能不哭？"
他享受手写代码时整个代码库在脑海中旋转的感觉，但他也无法忘记熬夜调试、项目反复失败、大多数创业项目破产的经历。这种矛盾是 Fable 时代每一位工程师都需要面对的。
他的结论是："唯一的出路是穿过去。" Fable 不会取消学习的必要，但它会改变学习的形状。
演讲的第四部分——"Be Less Reasonable"——是整场的精神高潮。Anthropic 内部有一条信条："取舍不是真的。" (Trade-offs are not real.)
Good, Fast, Cheap。传统观念里你只能选两个。但 Shihipar 认为，太多取舍是我们默认接受的限制条件，而不是真正的物理约束。如果用 Fable 强迫现实展示它的极限，而不是提前自我设限，你会发现很多看似必然的取舍其实并不必然。这既适用于产品决策，也适用于工程实现。
社区反响：为什么这场演讲引发共鸣
演讲发布后，社区反馈积极。@rajistics 称其为"当天最喜欢的演讲之一，Thariq 解释 agentic coding 非常直观"。@cedric_chee 详细整理了六种技巧的线程，称其"非常实用"。@0xwhrrari 分享了视频片段并标注"值得收藏"。
社区讨论的焦点集中在两个观察上：一是"更少的提示词，更多的模型"（Less prompt. More model.）成为 Fable 时代的操作原则；二是 Fable 在长期自主会话（long autonomous sessions）、自纠正循环、记忆验证方面的能力确实远超 Opus 4.8。
Shihipar 在 Anthropic 社区中扮演着独特角色——他被开发者评价为"Anthropic 雇来的唯一真正回应社区的人"，以极高的响应度和实操内容著称。这场演讲延续了他的风格：不讲口号，给模板代码。
AI 速览
