Fable 5 实战指南：先找到你的未知数

今天推荐一篇 Anthropic Claude Code 团队工程师发布在 X 上的长文：《A Field Guide to Fable: Finding Your Unknowns》。这篇文章今年 7 月初发出后获得了超过 60 万次阅读、7500 多次收藏，收藏量是点赞量的两倍多，属于典型的硬干货信号。

它的核心论断相当反直觉：到了 Fable 5 这个级别，真正卡住工作质量的已经不是模型能力，而是你自己澄清未知数的能力。作者甚至说，Fable 是第一个让他感到工作质量被自己澄清未知数的能力卡住的模型。这句话出自模型开发团队自己人之口，值得每个重度使用 AI 编程的人读上三遍。

一、核心隐喻：地图不是领地

作者用一个非常精准的隐喻开场：地图不是领地。

• 地图，是你对工作的描述：提示词、技能、上下文，也就是你交给 Claude 的东西。
• 领地，是工作真正发生的地方：代码库、真实世界、实际约束。

地图和领地之间的差异，就是未知数（unknowns）。Claude 每遇到一个地图上没标出来的东西，就只能基于它对你意图的猜测来做决定。任务越大，路上遇到的未知数越多，它要做的猜测也越多。

仅靠提前规划并不够。未知数可能藏在实现深处，也可能直接告诉你：应该换一种完全不同的方式来解题。与 Fable 协作，本质上是在实现之前、之中、之后不断发现未知数的过程。

二、四种未知数：先分清你不知道什么

文章借用一个经典的认知框架，把未知数分成四类：

前两类相对好处理，因为你知道它们存在，就能主动处理。真正要命的是后两类，尤其是未知的未知：这种情况下你连该问什么问题都不知道，模型也无从提醒你。

作者观察到一个规律：最好的智能体编程者，未知数相对少。看那些顶尖高手写提示，他们对想要什么了如指掌，跟代码库和模型行为深度同步。但他们同样假设未知数存在。用原文的话说：减少和规划未知数，就是智能体编程这项技能本身。好消息是，这是可以练的，下面就是具体练法。

三、太具体与太模糊之间

指导 Claude 是一件微妙的事。太具体，它会死守你的指令，即使该转向时也不转；太模糊，它会按行业最佳实践做选择，结果可能不适合你的任务。不处理未知数会两头失败：你既不知道路上满是障碍，也不知道路其实畅通、你本想让它转向。

作者的答案是：别一个人硬想，让 Claude 帮你发现未知数。它能极快地搜代码库和互联网，平均知识量比你大，也能从失败中更快迭代。前提是给它足够的起点上下文：告诉它你在思考过程的什么位置，交代你对问题和代码库的经验，让它像思维伙伴一样跟你工作。原文还提到，几乎所有这类场景，HTML artifact 都是可视化和表达的最佳载体。

四、实现前：五个把未知数捞出来的技巧

1. 盲点扫描（Blind Spot Pass）

进入陌生领域，或者在新代码库区域写功能时，你手里全是未知的未知：不知道该问什么、好的标准是什么、历史踩过哪些坑。这时直接让 Claude 帮你找出这些盲点并解释清楚。作者喜欢直接用 blindspot pass 和 unknown unknowns 这两个词。

我要加一个新的 auth provider，但完全不懂代码库里的 auth 模块。做个盲点扫描，帮我找出相关的未知的未知，让我能更好地提示你。

我不知道 color grading 是什么，但需要给视频调色。先教我理解调色上的未知的未知，让我能更好地提示。

2. 头脑风暴与原型

在标准只能看见了才认得的领域，比如视觉设计和交互手感，让 Claude 一次给出多个截然不同的方向，你来反应，而不是让它在一条路上走到黑。

我想要这个数据的 dashboard，但没视觉品味也不知道有什么可能。做一个 HTML 页面，给我 4 个截然不同的设计方向。

在接线任何东西之前，先用一个单 HTML 文件 mock 新编辑器工具栏，用假数据。我想在你碰真实应用之前对布局做出反应。

在原型阶段发现未知的已知非常便宜，在实现中才发现就昂贵得多：功能设计的小改动会导致代码实现大不相同，agent 也更难撤销之前的改动。

3. 采访（Interviews）

头脑风暴做得足够多之后还有模糊处，就让 Claude 反过来采访你。给它问题的上下文，让它一次问一个，优先问那些你的回答会改变架构的问题。

一次一个问题采访我关于任何模糊处，优先那些我的回答会改变架构的问题。

4. 参考（References）

有时候你无法详细描述想要什么，可能是缺词汇，也可能东西太复杂。这种情况下最好的答案是一个参考：图表、文档都行，但最好的参考是源代码。指给它一个实现了你要的行为的库或组件，哪怕语言不同。

vendor/rate-limiter 里这个 Rust crate 实现了我要的精确退避行为。读它，在我们的 TypeScript API 客户端里重新实现同样的语义。

原文还提到，Claude 的设计类能力也是这样工作的：不用递文件，只要指向网站上你喜欢的模块，它读的是底层代码而不是截图。

5. 实现计划（Implementation Plans）

准备动手时，让 Claude 整理一份实现计划给你审，重点放在最可能改动的部分：数据模型、类型接口、UX 流。这能让那些牵一发动全身的关键决策先浮上来，趁还便宜的时候拍板。

用 HTML 写实现计划，但先放我最可能调整的决定：数据模型改动、新类型接口、任何用户可见的东西。机械式重构埋在底部，那部分我信你。

五、实现中：留一份实现笔记

规划做得再细，未知的未知也会在实现中途冒出来，agent 可能因为代码里某个边界情况需要换方向。作者的做法是让 Claude Code 全程维护一份临时的 implementation-notes.md，记录它做的每个决定；碰到让它偏离计划的边界情况，选保守选项，记到 Deviations 下面，然后继续走。这份笔记让下一次尝试可以直接吸取教训。

六、实现后：推销文档与测验

1. 推销与解释（Pitches and Explainers）

交付一个东西最重要的部分之一，是获得认同和批准。把原型、spec、实现笔记打包成一份能直接丢进 Slack 的文档，先放 demo。审查者往往带着和你当初一样的未知数开始，这份文档既能加速他们的理解，也能让专家看到你考虑过他们预期的失败点，从而加速批准。

把原型、spec、实现笔记打包成一个我能丢进 Slack 获得认同的文档。先放 demo GIF。

2. 测验（Quizzes）

长会话之后，Claude 完成的东西可能比你意识到的多得多，只读 diff 只能得到浅层理解，因为很多行为依赖现有代码路径。让 Claude 先给你一份带上下文的报告，然后出题考你，完美通过测验才合并代码。

我想确保我理解这次改动发生的一切。给我一个 HTML 报告讲改动，让我读和理解，带上下文、直觉、做了什么等，底部带一个我必须通过的测验。

七、完整案例：剪辑 Fable 发布视频

作者用这套方法完成了 Fable 发布视频的剪辑，而视频剪辑对他完全是新领域。他的处理过程值得逐条看：

• 从已知出发问可行性：他知道 Claude 能用代码处理视频和转录，但不确定精度够不够，于是先让 Claude 解释 Whisper 这类转录工具的原理，确认能否用 ffmpeg 精确剪掉语气词和长停顿。
• 用原型验证有风险的想法：他想做一个跟台词同步的 UI，不确定能不能做，就让 Claude 用 Remotion 加转录先做一个原型视频看效果。
• 用盲点扫描补认知缺口：成片偏暗，他知道是调色的结果但不懂调色。第一反应是让 Claude 出几个变体挑一个，随即意识到自己不知道好长什么样，于是停下来让 Claude 先教他调色，把判断标准建立起来再说。

这个案例展示了一个反直觉的事实：面对陌生领域，最有效的起步不是动手做，而是先发现自己不知道什么。

八、写在最后

作者在结尾把整套方法浓缩成一句话：每个解释、头脑风暴、采访、原型、参考，都是在它变贵之前发现你不知道什么的便宜方式。在原型阶段发现需求错位，改的是几行 HTML；到上线之后才发现，代价就是灾难。

所以下次开始项目，先让 Claude 帮你找你的未知数。原文还附了一个配套的交互工具，把四种未知数和整套流程做成了可视化页面，值得点开玩一遍：https://thariqs.github.io/html-effectiveness/unknowns/