用 Claude Fable 5 干活，反复给我上同一堂老课：地图不是地盘。

地图，是对「要做的活」的一种描述——就是我的 prompt、skill 和 context，是我喂给 Claude 的东西。地盘，是活真正要落地的地方——代码库、真实世界，还有它们实打实的限制。

地图和地盘之间的差距，我管它叫「未知项」（unknowns）。Claude 撞上一个未知项时，它只能靠猜——猜我到底想要什么，然后做决定。活越多，它可能撞上的未知项就越多。

Fable 是第一个让我觉得「活干得好不好，卡在我能不能把它的未知项讲清楚」的模型。

关键是，光提前规划并不总够用。你可能在实现的深处才发现某个未知项，也可能某个未知项直接告诉你：这问题其实该换一种完全不同的做法。

我发现，跟 Fable 协作是一个反复的过程——在实现之前、之中、之后，不断发现自己的未知项。

我在这里做了一些找未知项的示例，但记得回来培养直觉，搞清楚什么时候该用它们。

认识你的未知项

你的未知项是什么？我带着一个问题去找 Claude 时，习惯把它拆成 4 类：

• 已知的已知（Known Knowns）： 基本就是我 prompt 里写的东西。我告诉 agent 我想要什么？
• 已知的未知（Known Unknowns）： 有哪些我还没想明白，但我清楚自己没想明白？
• 未知的已知（Unknown Knowns）： 有哪些我压根不会写下来、觉得太理所当然，但一看见就认得出来？
• 未知的未知（Unknown Unknowns）： 有哪些我根本没考虑过？有哪些知识我压根不知道自己不知道？我知道一件事最好能好到什么程度吗？

最厉害的 agentic 程序员，共同点是未知项相对很少。看 Boris 或 Jarred 写 prompt，我一眼就能看出：他们非常清楚自己要什么，细到每个点。他们跟代码库、跟模型的脾性都深度同步。

但他们同样会预设未知项的存在。某种意义上，减少未知项、为未知项做准备，就是 agentic 编程这门手艺。好在，这门手艺是可以练的——就在你跟 Claude 协作的过程里。

帮 Claude 帮你

给 Claude 下指令是个微妙的平衡。说得太细，就算换个方向更合适，Claude 也会死磕你的指令。说得太泛，Claude 往往会按行业「最佳实践」自己拿主意、自己假设，而那些未必适合你这个活。

你不为未知项做打算，就两头挨打：你不知道哪段路上全是坑，也不知道哪段路其实很好走——可你又希望 Claude 该拐弯的时候拐弯。

Claude 能帮你更快找到未知项。它翻代码库、翻网络都极快，而且对绝大多数话题懂得都比你多。它从失败里迭代也更快。

这个过程里最重要的一步，是把你的「起点」讲给 Claude 听。比如：告诉它你现在想到哪一步了；坦白你对这个问题和这套代码库有多少经验；让它像一个「一起想问题的伙伴」那样跟你配合。

我之前写过怎么拿 HTML 跟 Claude 配合——几乎所有这类情况，HTML artifact 都是把东西可视化、呈现出来的最好方式。

这篇文章里，我会讲一些我用来挖未知项的套路。我不是每次都全用一遍，但攒着这么一套方法很有用。

实现之前

盲点扫描（Blind Spot Pass）

刚开工时，最有用的事之一，就是搞清楚自己的盲点。比如你要在代码库里一个陌生的部分写功能，或者拿 Claude 帮你干不熟的活（像调设计），那你大概率有一堆未知的未知。

你可能连该问什么都不知道，不知道「好」长什么样，不知道以前有人做过哪些相关的活，也不知道有哪些坑要绕开。

要解决这个，你可以让 Claude 帮你找出你的「未知的未知」，再讲给你听。我喜欢直接用「盲点扫描（blindspot pass）」和「未知的未知（unknown unknowns）」这几个字。把「你是谁、你懂什么」的背景告诉它，通常很重要。

示例 prompt：

• 「我要加一个新的 auth provider，但这套代码库里的 auth 模块我一无所知。你能不能做一次盲点扫描，帮我理清相关的『未知的未知』，好让我能更好地给你写 prompt？」
• 「我不知道什么叫调色（color grading），但我得给这段视频调色。你能不能教我搞懂关于调色的『未知的未知』，好让我 prompt 写得更好？」

头脑风暴和原型

如果我干的活里有一堆未知的已知——那种「我只有看见了才知道怎么定义」的标准——我喜欢让 Claude 陪我一起头脑风暴、做原型。

在做原型阶段就早早把这些「未知的已知」找出来、说清楚，非常值。因为等到实现阶段才发现它们，代价（相对）就大了。功能或规格上一点小改动，落到代码里可能是天差地别的实现，而且让你的 agent 回退之前的改动会更麻烦。

比如，你可能只是想看看在一个框里加个按钮长啥样，而不想先接好后端路由、或在前端多维护一堆状态。

视觉设计对我来说就是很难用嘴讲清的东西，但一看见我就知道自己要不要。这种情况我会让它给一个 artifact 做几套不同的设计方向。

我几乎每次写代码都以一个「探索或头脑风暴」阶段开场。这帮我带着「意图」起步，去定项目的范围。Claude 经常能找到我会漏掉的高价值方案，有时也会「只见树木不见森林」。头脑风暴让我不至于把范围定得太窄或太宽。

示例 prompt：

• 「我想给这份数据做个 dashboard，但我毫无审美，也不知道能做成什么样。给我做一个 HTML 页面，里面放 4 个差异极大的设计方向，让我挨个看着反应一下。」
• 「先别接任何东西。用假数据做一个单独的 HTML 文件，把新的编辑器工具栏拉出来。你动真正的 app 之前，我想先对着布局提意见。」
• 「我的问题大概是这样：用户过完 onboarding 就流失。搜一下代码库，头脑风暴出 10 个我们能下手干预的地方，从最省事到最有野心排一下。我告诉你哪几个戳中我了。」

访谈

等我风暴得差不多了，多半还是留着一些未知项。

这时我会让 Claude 就任何未知项或含糊之处「访谈」我。让 Claude 访谈你的时候，尽量把你问题的背景给它，好引导它提问。下面是几个例子。

示例 prompt：

• 「一次问我一个问题，围绕任何含糊的地方来问；优先问那些『我一旦回答就会改变架构』的问题。」

参考物

有时候你就是没法把想要的东西描述清楚。比如你没有那套词汇，或者它复杂到让你讲清楚得花上老半天。

这种情况，最好的答案是一个参考物。图、文档、图片都行，但绝对最好的参考物是源代码。

如果有个库用某种方式实现了某个东西，或者有个你特别喜欢的设计组件，直接把 Fable 指向那个文件夹，告诉它去看什么就行——哪怕是另一种编程语言写的也没关系。

Claude Design 也是这么工作的。你不用非得递给它一个文件（虽然你也可以）。你可以把它指向某个你喜欢的网站上的一个模块，它读的是背后的代码，而不只是截图。这样它对标记、结构、以及这个组件到底怎么搭起来的，就能拿到丰富得多的细节。

示例 prompt：

• 「vendor/rate-limiter 里这个 Rust crate，实现的正是我想要的退避（backoff）行为。读一下它，然后在我们的 TypeScript API 客户端里用同样的语义重新实现一遍。」

实现计划

等我觉得可以开始实现了，我一般会让 Claude 先整一份实现计划给我审——重点放在那些最可能会变的部分，比如让我先看数据模型、类型接口或 UX 流程。这样 Claude 能把那些「我可能真得改」的地方先端出来。

示例 prompt：

• 「用 HTML 写一份实现计划，但开头先放那些我最可能会动的决定：数据模型改动、新的类型接口、以及任何面向用户的东西。把那些机械性的重构塞到最底下，那部分我信你。」

实现之中

实现笔记

计划一旦让我满意，我就开一个新 session，把各种 artifact 一起塞进 prompt。比如我可能塞进去一个 spec 文件和一个原型，让 agent 去实现它。

但事实是，不管你规划得多充分，总有「未知的未知」潜伏着。agent 干活途中可能发现：因为它在代码里撞见了某个边界情况，得换个打法。

我会让 Claude Code 临时维护一个 implementation-notes.md（或 .html）文件，把它做的各种决定记下来，好让我们下一次尝试时能从中学习。

示例 prompt：

• 「维护一个 implementation-notes.md 文件。如果你撞上一个边界情况、被迫偏离计划，就选保守的那个选项，把它记在『Deviations（偏离）』下面，然后继续往下走。」

实现之后

方案陈述和讲解

交付一个东西，最重要的一环是拿到支持和拍板。在最终文档里做上「方案陈述」和「讲解」这类 artifact，能帮你：

• 加速理解——当审阅者和你当初一样，起点也是一堆未知项时。
• 加速拍板——当专家们想确认，你已经把那些他们会预料到的未知项和常见坑点都考虑到了时。

示例 prompt：

• 「把原型、spec、实现笔记打包成一份文档，我好直接丢进 Slack 争取支持。开头先放 demo 的 GIF。」

小测验

一段长时间的工作后，Claude 完成的东西可能比我意识到的多得多。光读 code diff 只能让我浅浅地看懂发生了什么，因为很多行为都依赖已有的代码路径。

先让 Claude 给我一堆背景，再让它就这次改动出题考我，这能帮我真正搞懂发生了什么。我只有把测验答满分了才 merge。

示例 prompt：

• 「我想确保自己彻底搞懂这次改动里发生的一切。给我一份关于这些改动的 HTML 报告，让我带着背景去读懂——包括直觉、做了什么等等，末尾附一个关于这些改动的小测验，我必须答对才行。」

这些是怎么串起来的：发布 Fable

Fable 的发布视频完全是用 Claude Code 剪的。这对我是个全新领域，我绝对算不上专家。

所以我从自己已经知道的开始。我知道 Claude 能用代码剪视频、能转录，但我不确定它够不够准。于是我让 Claude 给我讲讲像 Whisper 这样的转录是怎么工作的，以及我能不能用 ffmpeg 精准地把「嗯」这种口头语和大段停顿剪掉。

我想让 Claude 做一个「跟我说的话对上时间点」的 UI，但不确定它能不能做到，就让 Claude 用 Remotion 加一份转录做了个原型视频，看看行不行。

最后，视频本身看着有点发闷——我知道这是调色（color grading）的问题，但我其实不太懂调色是啥。我第一次尝试是想让 Claude 做几个变体让我挑，但我意识到：在调色这件事上，我根本不知道「好」长什么样。所以我换了个法子，让 Claude 教我调色，来发现我的未知项。

关于这一段更深入的讲解，你可以看这里。

让地图和地盘对上

模型越强，只要方法对，你能干成的事就越多。当一个长周期的任务结果不对，多半是你得多花点时间去定义你的未知项，或者做一份「允许 Claude 在其中随机应变」的实现计划。

每一次讲解、头脑风暴、访谈、原型、参考物，都是一种便宜的方式——趁着修起来还不贵，先搞清楚你原先不知道的东西。

所以，下个项目开工时，就从「让 Claude 帮你找未知项」开始吧。