7 月 3 日，Anthropic Claude Code 团队工程师 Thariq Shihipar 发了一篇博客，标题是《A Field Guide to Claude Fable: Finding Your Unknowns》。三天两百万浏览。

他讲的道理不复杂：模型足够强之后，输出质量的瓶颈不再是模型能不能做，而是你有没有想清楚自己要什么。他借用了唐纳德·拉姆斯菲尔德（Donald Rumsfeld）那句著名的"已知的已知、已知的未知、未知的未知"，把"没想清楚"拆成四种情况，每种给一套对应的应对办法。这套框架这一周被到处转述，从 Every.to 的编辑部实测到 The Decoder 的技术解读，几乎每一篇都在重复同一句话：AI 编程的瓶颈，从模型转移到了你自己。这句话没错，但它默认了一个不那么显眼的前提，值得单独说一说。

地图与疆域：一个好用但不完整的框架

Thariq 用了一个经典比喻：地图（map）和疆域（territory）。地图是你给 Claude 的东西——提示词、技能、上下文，是你对"要做什么"的表述。疆域是真实发生的地方——代码库、真实世界、以及它们各自的约束。地图和疆域之间的差距，就是"未知"（unknowns）。

四种未知，Thariq 给了四种解法：

  • 已知的已知——已经写进提示词里的，直接给。
  • 已知的未知——你知道自己还没想清楚的问题，让 Claude 去查、去补。
  • 未知的已知——那种显而易见到你不会写下来、但一看就认得的东西（比如视觉设计的品味），他的办法是让模型生成几个差异很大的方案，让你去挑，而不是直接让它按感觉实现。
  • 未知的未知——你压根没想到的问题，这一类风险很高。他管这个动作叫"blindspot pass"：主动让 Claude 去找"你没想到但应该想到"的地方。

Anthropic 自己在 6 月 16 日发布的一份内部研究给这套框架找了实证支撑——分析了大约 40 万条 Claude Code 会话，发现一个稳定的分工：用户做了大约 70% 的规划决策，Claude 做了大约 80% 的执行决策。报告给出的是这个分工比例；至于它会不会随模型变强而消失，报告没说。渡之的判断是：不会，只会让后果被放大得更厉害——模型越能干，你规划阶段的每一个疏漏，被执行放大的幅度也越大。

这套框架讲的是一件真事，而且讲得清楚。但它有一个隐含假设：未知只存在于委托方这一侧——只要你，发出指令的人，把自己的脑子理清楚，剩下的事就交给执行者去兜底。

框架漏掉的另一半：受托方也可能悄悄藏着已知

但委托关系是双向的——受托方知道什么、又愿不愿意告诉你，同样是决定结果好坏的变量，而这个变量不在 Rumsfeld 的格子里。这不是四象限里漏掉的第五格，而是那张格子整个建在"只有你这侧有未知"的假设上。

就在 Thariq 这篇博客刷屏的同一周，Fable 5 自己出了一件事，能当反例。有开发者翻自己的调用日志，发现系统里有一个标记，叫 TOO_DUMB_TO_NEED_FABLE——意思是：这条请求被判定为"简单到不需要用 Fable"，静默 fallback 到成本更低、能力略逊一档的 Opus 4.8 去处理，用户不会收到任何提示。当事的 Claude Code 工程师被问到时，回应是"没想到你们会去翻日志"。

类似的判断权并非第一次出现。往前翻两个多月，Anthropic 自己也发过一篇工程复盘（4 月 23 日），讲的是 Claude Code（当时用的是上一代模型）连续几周被用户投诉"变笨了"——原因之一是团队上线时未作说明，把默认推理强度从 high 调到了 medium，事后才在复盘里交代。那次调整几周内就被撤回、也被公开解释，性质温和；但两件事共通的是：调不调整、要不要认真处理你的请求，这类判断本身可以在你完全不知情的情况下发生。

两件事放在一起看，指向同一个问题：你想清楚了自己的未知，但你没法确认受托方对自己的判断标准是不是也在悄悄变。这不是你这一侧的未知，是对方选择不主动告诉你的已知。

为什么这个盲区容易被忽略

Thariq 的框架之所以传得快，是因为它精准描述了一种真实体验——用惯 Fable 5 的人，确实会感觉到瓶颈从"它做不到"变成了"我没想清楚"。这个体验是真的，四象限也确实是提高委托质量的实用工具。

但一套框架传得越广，就越容易被当成完整答案。这周几十篇转述文章里，几乎没有一篇追问过：如果受托方本身就不透明呢？如果它的"能力"和"是否认真对待你的请求"之间，隔着一层你看不到的调度逻辑呢？

Thariq 的框架没有错，它回答的是"委托关系里我这一半该怎么办"，而不是"委托关系整体该怎么办"。这两个问题看起来很像，但不是一个问题——前者是执行技巧，后者是信任判断。技巧可以练，信任判断需要的是对方那边的透明度，而透明度这件事，你再怎么想清楚自己的未知，也换不来。

渡之说

想清楚自己的未知，是委托关系里必要的一半，但从来不是充分的一半。完整的委托框架至少要多问一句：对方是否愿意告诉你那些会实质改变结果的内部判断。这一半，Rumsfeld 的四象限里没有，Thariq 的文章里也没细讲——大概是因为这个问题不太方便由受托方自己来回答。

这不是苛责某一家公司或某一个工程师。任何足够复杂的系统——不管是 AI 模型、还是一个团队、一段外包关系——都会有类似的张力：执行方需要在不惊动委托方的前提下做各种权衡，因为每次权衡都拿出来解释一遍，成本太高。这是系统运行的常态，不是道德污点。但常态不代表可以被忽略——尤其当委托方（也就是你）以为自己已经把该想的都想清楚了的时候。

评论区想听听：如果你也在用 AI 编程工具，有没有遇到过类似"结果和你以为它在做的事不一样"的经历？

原文：Thariq Shihipar，"A Field Guide to Claude Fable: Finding Your Unknowns"，Anthropic Claude Code 团队，2026 年 7 月 3 日发布。