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

原文：Thariq（@trq212）的 A Field Guide to Fable: Finding Your Unknowns。中文翻译与配图本地化：Yaqin Hei —— 译文按中文阅读习惯做了本地化，图中文字一并译为中文（非原创）。

和 Claude Fable 5 一起工作，反复让我重新学到一个老道理：地图不是疆域。

所谓地图，是对「要做的工作」的一种表征——它就是我的 prompt、skill 和 context，是我交给 Claude 的东西。而疆域，则是工作真正发生的地方——代码库、真实世界，以及它们实实在在的约束。

地图与疆域之间的落差，就是我所说的未知（unknowns）。当 Claude 撞上一个未知时，它必须基于对「我到底想要什么」的最佳猜测来做决策。要做的工作越多，Claude 可能撞上的未知就越多。

Fable 是第一个让我觉得——工作质量的瓶颈在于我澄清它未知的能力——的模型。

重要的是，光靠提前规划并不总是够用。你可能在实现的深处才发现某个未知，或者这些未知反过来提示你：其实应该换一种完全不同的方式来解决问题。

我发现，和 Fable 一起工作是一个迭代的过程——在实现之前、之中、之后，不断发现自己的未知。

我在这里做了一些用于「发现未知」的示例 artifact，但一定要回到本文，建立起「何时该用它们」的直觉。

认清你的未知

你的未知是什么？当我带着一个问题来找 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 关于你「起点」的 context。比如：告诉它你现在处在思考的哪个阶段；坦白你对这个问题和这个代码库的经验有多少；让它像一个思考伙伴（thought partner）那样和你协作。

我此前写过如何用 HTML 配合 Claude——在几乎所有这些场景里，一个 HTML artifact 都是把想法可视化、具象化的最佳方式。

在本文中，我会详细讲讲自己用来挖掘这些未知的一些套路。我不会每次都用上每一种，但把它们收进工具箱很有用。

实现之前

盲点扫描（Blind Spot Pass）

开始动手时，最有用的事情之一，就是搞清楚自己的盲点。举个例子，如果你要在代码库的一个陌生区域写功能，或者用 Claude 帮你做不熟悉的工作（比如迭代一版设计），那你大概率有大量的未知的未知。

你可能不知道该问什么问题、不知道「好」长什么样、不知道历史上做过哪些工作、也不知道该避开哪些坑。

要解决这个，你可以让 Claude 帮你找出这些未知的未知并讲给你听。我喜欢直接用「盲点扫描」（blindspot pass）和「未知的未知」（unknown unknowns）这两个字面词。把「你是谁、你已知什么」的 context 给它，通常很重要。

示例 prompt：

• 「我要给这个代码库加一个新的 auth provider，但我对里面的 auth 模块一无所知。你能做一次盲点扫描，帮我理清相关的未知的未知，好让我更好地给你写 prompt 吗？」
• 「我不知道什么是调色（color grading），但我需要给这段视频调色。你能教我认清自己关于调色的未知的未知，好让我写出更好的 prompt 吗？」

头脑风暴与原型

当我在一个充满未知的已知的领域里工作时——那些「见到才知道该怎么定义」的标准——我喜欢让 Claude 和我一起头脑风暴、一起做原型。

在做原型的早期就识别并说出这些未知的已知，价值极高，因为拖到实现阶段才发现它们，代价（相对而言）会大得多。功能或规格上的小改动，可能导致代码实现天差地别，而让你的 agent 回滚之前的改动也会更困难。

举个例子，你可能只是想看看一个按钮加到某个界面框里长什么样，而完全不必去接后端路由，也不必在前端维护额外的状态。

视觉设计对我来说就是那种很难用语言讲清、但一见到就知道要不要的东西。这种情况下，我会让它给一个 artifact 提供好几种设计方向。

我几乎每次编程会话都以一段探索或头脑风暴阶段开场。这帮我带着「意图」出发，去界定项目的范围。Claude 常常能找到我原本会错过的高价值方案，但有时也会「只见树木不见森林」。头脑风暴能防止我把范围划得过窄或过宽。

示例 prompt：

• 「我想给这份数据做一个 dashboard，但我毫无审美，也不知道有哪些可能。给我做一个 HTML 页面，放 4 个风格迥异的设计方向，让我对着它们做反应。」
• 「先别接任何东西，用假数据做一个单独的 HTML 文件，把新的编辑器工具栏模拟出来。我想在你动真实 app 之前先对布局做反应。」
• 「这是我大致的问题：用户在 onboarding 之后就流失了。检索代码库，头脑风暴出 10 个我们可以介入的地方，从最省事的到最有野心的排列。我会告诉你哪些戳中了我。」

访谈（Interviews）

一旦我做了足够的头脑风暴，通常仍然会残留一些未知。

这种时候，我会让 Claude 就任何未知或含糊之处来「访谈」我。让 Claude 访谈你时，尽量给它关于你问题的 context，好引导它提问。下面是一些例子。

示例 prompt：

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

参照物（References）

有时候你没法把想要的东西描述得很细。比如，你可能缺少那套词汇，或者它复杂到你要花好一阵子才能讲明白。

这种情况下，最好的答案是给一个参照物。虽然你可以放图表、文档或图片，但绝对最好的参照物是源代码。

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

Claude Design 也是这么工作的。你不必递给它一个文件（当然你也可以这么做）。你可以把它指向某个你喜欢的网站上的某个模块，它会去读底层代码，而不只是截图。这能提供关于标记（markup）、结构、以及组件实际是怎么搭出来的更丰富细节。

示例 prompt：

• 「vendor/rate-limiter 里的这个 Rust crate，实现了我想要的那种 backoff 行为。把它读一遍，然后在我们的 TypeScript API 客户端里重新实现同样的语义。」

实现计划（Implementation Plans）

当我觉得自己准备好动手时，我倾向于让 Claude 拼出一份实现计划供我审阅，重点放在最可能会变的部分——比如让我审一下数据模型、类型接口或 UX 流程。这样 Claude 就能把那些我其实可能需要改动的东西浮出水面。

示例 prompt：

• 「用 HTML 写一份实现计划，但把我最可能会调整的决策放在最前面：数据模型的改动、新的类型接口，以及一切面向用户的东西。把机械性的重构埋到最底下，那部分我信你。」

实现之中

实现笔记（Implementation notes）

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

但事实是，无论你规划得多充分，总有未知的未知潜伏着。agent 可能在工作过程中发现，由于代码里的某个 edge case，它需要改换策略。

我会让 Claude Code 维护一个临时的 implementation-notes.md（或 .html）文件，让它把自己做的决策记录下来，好让我们从下一次尝试中吸取教训。

示例 prompt：

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

实现之后

推介与讲解（Pitches and explainers）

把一个东西真正交付出去，最重要的环节之一就是拿到认同和批准。在最终文档里搭建推介（pitch）和讲解（explainer）类的 artifact，能帮上忙：

• 当审阅者和你当初一样、带着同样的未知起步时，加速他们的理解
• 当专家想看到你已经把那些未知、以及他们本会预见到的常见失败点都考虑进去时，加速他们的批准

示例 prompt：

• 「把原型、spec 和实现笔记打包成一份文档，我可以直接扔进 Slack 去争取认同。开头先放 demo 的 GIF。」

小测验（Quizzes）

一段长时间的工作会话之后，Claude 完成的可能比我意识到的多得多。光读代码 diff 只能给我一个粗浅的理解，因为很多行为都依赖既有的代码路径。

在给我一堆 context 之后，让 Claude 就这次改动来考我，能帮我搞懂到底发生了什么。我只有完全通过测验之后才会合并。

示例 prompt：

• 「我想确保自己完全理解这次改动里发生的一切。给我一份关于这些改动的 HTML 报告，让我带着 context、直觉、做了什么等等去读、去懂，并在最底下附一个关于这些改动的小测验，我必须通过。」

这些是如何串起来的：发布 Fable

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

于是我从自己确实知道的东西出发。我知道 Claude 能用代码来剪辑视频、给视频转录，但我不确定它是否足够准确。接着我让 Claude 给我讲讲像 Whisper 这样的转录是怎么工作的，以及我能不能用 ffmpeg 精确地剪掉「嗯」这类语气词或大段停顿。

我想让 Claude 做一个和我说的每个词同步的 UI，但不确定它能不能做到，于是我让 Claude 用 Remotion 加一份转录做一个原型视频，看看行不行得通。

最后，视频本身看起来有点发灰，我知道这是调色的结果，但我并不真的懂调色是什么。我第一次尝试是想让 Claude 做几个变体让我挑，但我意识到，在调色这件事上，我根本不知道「好」长什么样。所以我改了做法，让 Claude 来教我调色，从而发现我的未知。

你可以在这里看一段更深入的讲解。

让地图与疆域对上

模型越强，用对方法能达成的事情就越多。当一个长周期（long-horizon）任务的结果不对时，很可能你需要花更多时间去界定你的未知，或者写一份能让 Claude 在其中即兴发挥、绕过这些未知的实现计划。

每一次讲解、头脑风暴、访谈、原型和参照，都是一种廉价的方式——趁着修复代价还没变高之前，先弄清你原本不知道的事。

所以，下一个项目，就从让 Claude 帮你找到你的未知开始吧。

---

原文：Thariq（@trq212）·《A Field Guide to Fable: Finding Your Unknowns》。中文翻译与配图本地化：Yaqin Hei。