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

与 Claude Fable 5 协作的经历，一遍遍地让我重温一个老道理：地图不等于疆域（the map is not the territory）。

地图，是对待办工作的一种表征——它是我的提示词、技能（skills）和上下文，是我交给 Claude 的东西。疆域，则是工作真正发生的地方——代码库、真实世界，以及它们的实际约束。

地图与疆域之间的差距，就是我所说的未知（unknowns）。当 Claude 撞上一个未知时，它只能基于”我大概想要什么”的最佳猜测来做决定。要做的工作越多，Claude 可能遇到的未知就越多。

Fable 是第一个让我感到”工作质量的瓶颈，在于我澄清未知的能力”的模型。

重要的是，仅仅提前规划并不总是够用。你可能在实现的深处才发现新的未知；你的未知甚至可能告诉你：这个问题其实应该换一种完全不同的解法。

我发现，与 Fable 协作是一个在实现之前、之中、之后持续发现自身未知的迭代过程。

我整理了一些可以直接取用的提示词，但请务必回到本文，建立”什么时候该用哪一招”的直觉。

认识你的未知

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

• 已知的已知（Known Knowns）：基本上就是提示词里写的内容。我告诉了智能体我想要什么？
• 已知的未知（Known Unknowns）：哪些事我还没想清楚，但我自己清楚”我还没想清楚”？
• 未知的已知（Unknown Knowns）：哪些事对我来说太理所当然、根本不会写下来，但一看到就能认出来？
• 未知的未知（Unknown Unknowns）：哪些事我压根没考虑过？哪些知识我根本不知道自己缺？我知道一件事能好到什么程度吗？

最出色的智能体编程（agentic coding）高手，未知都相对较少。看 Boris Cherny 或 Jarred Sumner 这样的人写提示词，我一眼就能看出：他们对自己想要什么了如指掌，并且与代码库和模型行为都保持着深度同步。

但他们同样会为未知留出余地。从很多角度说，减少未知、为未知做规划，正是智能体编程这门手艺的核心。幸运的是，这项技能可以通过与 Claude 协作不断精进。

帮 Claude 帮你

给 Claude 下指令是一门微妙的平衡术。指令太具体，即使转向才是更合适的选择，Claude 也会死守你的指令；指令太模糊，Claude 往往会基于行业最佳实践做选择和假设——而这些未必适合你的任务。

不清点自己的未知，两头都会栽跟头：你不知道哪段路会障碍重重，也不知道哪段路其实一马平川、你却仍希望 Claude 绕道。

Claude 可以帮你更快地发现自己的未知。它检索代码库和互联网的速度极快，对一般话题的了解远超过你，从失败中迭代的速度也更快。

这个过程中最重要的一环，是把你的出发点作为上下文交给 Claude。比如：告诉它你的思考进行到了哪一步；坦白你对这个问题和这个代码库的经验深浅；让它像一位思考伙伴一样与你共事。

我之前写过如何使用 HTML 工件（artifact）——在几乎所有这类场景里，HTML 工件都是可视化和呈现问题的最佳方式。

本文将详细介绍我用来挖掘这些未知的一些模式。我并不是每次都把每个技巧用一遍，但把它们收进工具箱总是有用的。

一、实现之前

盲区排查（Blind Spot Pass）

开工之前，最有价值的事情之一就是搞清楚自己的盲区。比如，你要在代码库的陌生区域写一个新功能，或者让 Claude 帮你做设计迭代这类你不熟悉的工作，这时你大概率背着一堆”未知的未知”。

你可能不知道该问什么问题、不知道”好”长什么样、不知道前人做过哪些工作、也不知道哪里有坑要绕。

对策是：让 Claude 帮你找出”未知的未知”，并解释给你听。我喜欢在提示词里原样使用 “blindspot pass” 和 “unknown unknowns” 这两个词。同时，把”你是谁、你已经知道什么”作为上下文交代清楚，通常也很关键。

示例提示词：

• “我正在接入一个新的认证服务商（auth provider），但对这个代码库里的 auth 模块一无所知。能不能做一次 blindspot pass，帮我找出相关的 unknown unknowns，并帮我把提示词写得更好？”
• “我不懂什么是调色（color grading），但我需要给这段视频调色。能不能教我理解调色方面的 unknown unknowns，让我之后能提示得更好？”

头脑风暴与原型

当我工作的领域里有大量”未知的已知”——也就是那些”看到了才知道要什么”的标准——我喜欢让 Claude 陪我一起头脑风暴、做原型。

在原型阶段尽早识别并说出这些”未知的已知”极其划算，因为等到实现阶段才发现它们，代价（相对而言）会大得多。功能或规格上的一点小改动，可能导致代码实现天差地别，而让智能体回滚之前的修改会更加困难。

举个例子：你可能只是想看看某个框里加个按钮是什么效果，完全不必接好后端路由、也不必在前端维护额外状态。

视觉设计对我来说就是”难以言传、见了才认”的典型。这种时候，我会让它针对一个工件给出好几种设计方案。

另外，我几乎每一次编程会话都以探索或头脑风暴阶段开场。这让我带着明确的意图去圈定项目范围。Claude 经常能发现我自己会漏掉的高价值方案，偶尔也会一叶障目。头脑风暴能防止我把范围定得太窄或太宽。

示例提示词：

• “我想给这份数据做一个仪表盘，但我毫无视觉品味，也不知道有哪些可能性。给我做一个 HTML 页面，放上 4 种风格迥异的设计方向，让我逐一给出反应。”
• “先别接任何东西。用假数据做一个单文件 HTML，模拟新的编辑器工具栏。我想先对布局给出反馈，你再去动真正的应用。”
• “我的问题很模糊：用户在新手引导之后流失。搜一遍代码库，头脑风暴出 10 个我们可以介入的位置，从最省事到最有野心排列。哪些戳中我，我会告诉你。”

访谈

充分的头脑风暴之后，我手上多半还剩一些未知。

这时，我会让 Claude 就这些未知和模糊之处来”访谈”我。让 Claude 访谈你时，尽量把问题的背景交代给它，好引导它提问的方向。

示例提示词：

• “就所有模糊不清的地方，一次一个问题地访谈我。优先问那些’我的回答会改变架构’的问题。”

参考物

有时候你没法把想要的东西描述清楚——可能是找不到合适的语言，也可能是事情复杂到描述一遍就要花很久。

这种情况下，最好的答案是给一个参考物（reference）。图表、文档、图片都可以，但最好的参考物永远是源代码。

如果某个库以你想要的方式实现了某个功能，或者你特别喜欢某个设计组件，直接把 Fable 指到那个目录，告诉它看什么——哪怕它是用另一门语言写的。

Claude Design 的工作方式也是如此。你不必递给它一个文件（当然也可以）。你可以把它指向某个你喜欢的网站上的模块，它读的是底层代码，而不只是截图。这能提供丰富得多的细节：标记结构、组织方式，以及这个组件到底是怎么搭出来的。

示例提示词：

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

实现计划

当我觉得可以动手实现了，我通常会让 Claude 先拟一份实现计划给我审阅，重点放在最可能变动的部分——比如数据模型、类型接口或 UX 流程。这样 Claude 就能把我真正可能需要调整的东西摆到台面上。

示例提示词：

• “用 HTML 写一份实现计划，把我最可能微调的决策放在最前面：数据模型变更、新的类型接口、以及一切用户可感知的部分。机械性的重构埋到最后，那部分我信你。”

二、实现之中

实现笔记

对计划满意之后，我会新开一个会话，把各种工件传进提示词。比如，我可能传入一份规格文件和一个原型，然后让智能体去实现。

但事实是：无论你规划得多充分，总有”未知的未知”潜伏着。智能体可能在干活时发现，由于代码里的某个边界情况，它需要换一条路走。

我会让 Claude Code 维护一个临时的 implementation-notes.md（或 .html）文件，随手记录它做出的各项决策，供我们下一次尝试时吸取经验。

示例提示词：

• “维护一个 implementation-notes.md 文件。如果遇到迫使你偏离计划的边界情况，选保守的那条路，把它记在 ‘Deviations’（偏离）条目下，然后继续干。”

三、实现之后

提案与讲解

交付一件东西，最重要的环节之一是赢得认同与审批。在最终文档里加入提案（pitch）和讲解（explainer）类工件，好处有二：

• 当评审者和你当初抱着同样的未知入场时，帮他们更快建立理解
• 当专家想确认”你考虑到了他们预料中的未知和常见故障点”时，帮你更快拿到批准

示例提示词：

• “把原型、规格和实现笔记打包成一份文档，我可以直接丢进 Slack 争取支持。开头放演示 GIF。”

测验

一场长时间的工作会话下来，Claude 完成的东西可能远超我的预期。只读代码 diff 只能让我对发生了什么有个浅层了解，因为大量行为取决于既有的代码路径。

让 Claude 在给足我上下文之后就这次变更考考我，能帮我真正理解发生了什么。我只有满分通过测验才会合并代码。

示例提示词：

• “我想确认自己理解了这次变更里发生的一切。给我一份关于这些变更的 HTML 报告，包含背景、直觉、做了什么等等，让我阅读和理解；报告底部放一份关于变更的测验，我必须通过它。”

融会贯通：Fable 发布实战

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

所以我从自己已知的部分入手。我知道 Claude 能用代码剪视频、做转录（transcription），但不确定精度够不够。于是我让 Claude 给我讲解 Whisper 这类转录技术的原理，以及我能否用 ffmpeg 精确地剪掉”呃”之类的口头语和大段停顿。

我想让 Claude 做一个与我说的每个词精确对齐的 UI 动效，但不确定它做不做得到，于是让 Claude 用 Remotion 加一份转录先做一个原型视频，验证可行性。

最后，视频本身看起来有点发灰。我知道这是调色的问题，但我并不真的懂调色。第一次尝试时，我让 Claude 出几个版本供我挑选，随后我意识到：在调色这件事上，我根本不知道”好”长什么样。于是我换了个做法——让 Claude 教我调色，以此发现我的未知。

你可以在这条视频里看到更深入的讲解。

让地图对齐疆域

模型越强，用对方法能达成的就越多。当一个长周期任务的结果不对时，多半说明你需要花更多时间定义你的未知，或是拟一份允许 Claude 在未知中随机应变的实现计划。

每一次讲解、头脑风暴、访谈、原型和参考物，都是在”修复变得昂贵”之前，廉价地找出你所不知道的东西。

所以，下一个项目就从这句话开始：让 Claude 帮你找出你的未知。

---

附：全文技巧速查表

阶段	技巧	一句话用法
实现前	盲区排查（blindspot pass）	让 Claude 找出你的 unknown unknowns 并讲解，帮你学会更好地提问
实现前	头脑风暴与原型	用多方案 HTML 原型把”见了才认”的标准提前逼出来
实现前	访谈	让 Claude 一次一问，优先问”答案会改变架构”的问题
实现前	参考物	指向一段源代码/组件，让它照着语义重新实现
实现前	实现计划	让计划把最可能调整的决策放最前面
实现中	实现笔记	维护 implementation-notes.md，记录偏离计划的决策
实现后	提案与讲解	打包原型+规格+笔记成一份可传播的文档，加速评审
实现后	测验	让 Claude 出题考你这次变更，满分才合并

原文：A Field Guide to Fable: Finding Your Unknowns
作者：Thariq（@trq212），Anthropic 工程师
发布：2026-07-03（X 长文）
译注：核心概念首次出现时标注英文；示例提示词中 “blindspot pass”、”unknown unknowns” 等触发词按作者建议保留英文原词。文中插图为作者手绘，暂保留原图链接（英文）。

---