Fable 实战指南：找到你的未知项
要点速览
- 核心比喻：地图不等于疆域（the map is not the territory）。地图是你给 Claude 的提示、技能与上下文；疆域是工作真正发生的地方——代码库、真实世界及其实际约束。两者之间的落差，作者称之为未知项 (unknowns)。
- Fable 5 是第一个让作者感到"工作质量的瓶颈在于我能否把未知项讲清楚"的模型。仅靠事前规划并不够，未知项会潜伏到实现深处，甚至会反过来提示你：这个问题本该换一种方式解决。
- 用四象限拆解未知项：已知的已知、已知的未知、未知的已知、未知的未知。减少并预留未知项，正是 Agentic Coding 的核心技能，而这项技能可以通过与 Claude 协作练出来。
- 一套贯穿"实现前 / 实现中 / 实现后"的具体手法：盲点扫描、头脑风暴与原型、访谈式提问、参考源码、实现计划、实现笔记、路演/解说物料、以及"考我一考"。多数以 HTML Artifact 承载。
- 一句话方法论：每一次解说、头脑风暴、访谈、原型与参考，都是在昂贵的返工发生之前，用低成本把"你原本不知道的事"提前挖出来。
原文链接 原文：English Original 作者：Thariq (@trq212)，Anthropic Claude Code 团队开发者，发布于 2026-07-04
Fable 实战指南：找到你的未知项
与 Claude Fable 5 协作，让我一次次重温一个老道理：地图不等于疆域（the map is not the territory）。
地图，是对"要做的工作"的一种表示——也就是我的提示 (prompt)、技能 (skill) 和上下文，是我交给 Claude 的东西。而疆域，是工作真正需要发生的地方——代码库、真实世界，以及它们实际的约束。
地图与疆域之间的落差，就是我所说的未知项 (unknowns)。当 Claude 撞上一个未知项时，它必须基于"对我想要什么的最佳猜测"来做决定。工作量越大，Claude 可能撞上的未知项就越多。
Fable 是第一个让我明确感到——工作质量的瓶颈，在于我能否把它面对的未知项讲清楚——的模型。
更关键的是，仅仅提前规划并不总是够用。你可能会在实现的深处才发现未知项；甚至你的未知项会反过来提示你：这个问题其实应该换一种完全不同的方式去解决。
我发现，与 Fable 协作是一个迭代的过程——在实现之前、之中、之后，持续地发现自己的未知项。
我在这里做了一些"寻找未知项"的示例 Artifact，但请务必回过头来，去建立"何时该用它们"的直觉。
认清你的未知项
你的未知项是什么？当我带着一个问题来找 Claude 时，我倾向于按四种方式来拆解它：
- 已知的已知 (Known Knowns)： 本质上就是我提示里写下的内容。我明确告诉 Agent 我想要什么？
- 已知的未知 (Known Unknowns)： 有哪些我还没想明白、但我清楚自己还没想明白的？
- 未知的已知 (Unknown Knowns)： 有哪些东西太过显而易见、以至于我永远不会把它写下来，可一旦看到我立刻就能认出来？
- 未知的未知 (Unknown Unknowns)： 有哪些是我压根没考虑过的？有哪些知识是我根本没意识到的？我知道一件事情"能做到多好"吗？
最厉害的 Agentic Coding 高手，未知项相对很少。看 Boris 或 Jarred 这样的人写提示，我一眼就能看出他们非常清楚自己想要什么、且细节到位。他们与代码库、与模型的行为都深度同步。
但他们同样会为未知项预留空间。在很多意义上，减少未知项、并为未知项做好规划，正是 Agentic Coding 的核心技能 (skill)。而幸运的是，这是一项你可以通过与 Claude 协作不断精进的技能。
帮 Claude 来帮你
给 Claude 下指令是一门微妙的平衡艺术。如果你太具体，Claude 会严格照着你的指令走——哪怕此时"掉头换个方向"才是更合适的选择。如果你太笼统，Claude 往往会依据行业最佳实践来做选择和假设，而这些未必契合你的任务。
当你没有把未知项考虑进去时，你会在两端同时失手：你不知道前方哪一段路会布满障碍，也不知道哪一段路其实畅通无阻——可即便畅通，你依然希望 Claude 能主动拐弯（veer）。
Claude 可以帮你更快地发现未知项。它能极快地检索你的代码库和互联网，而且在大多数话题上懂得都比你多；它也能更快地从失败中迭代。
这个过程里最重要的一环，是给 Claude 关于你出发点的上下文。比如：告诉它你目前思考到了哪一步；坦白你对这个问题和这个代码库的经验深浅；让它像一个思考伙伴 (thought partner) 那样与你协作。
我此前写过如何配合 Claude 使用 HTML——几乎在所有这些场景里，一个 HTML Artifact 都是把问题可视化、表达出来的最佳方式。
在这篇文章里，我会详细介绍一些我用来挖掘未知项的模式。我不会每次都把每种手法都用上，但把它们攒成一套工具箱是很有用的。
实现之前 (Pre-implementation)
盲点扫描 (Blind Spot Pass)
开工时，你能做的最有用的事情之一，就是搞清楚自己的盲点。举例来说，如果你要在代码库里一个陌生的部分写功能，或者用 Claude 帮你做不熟悉的活儿（比如打磨一版设计），你很可能有大量的未知的未知。
你可能都不知道该问什么问题、不知道"好"长什么样、不知道历史上做过哪些相关工作、也不知道有哪些坑要避开。
要解决这个，你可以让 Claude 帮你找出这些未知的未知、并讲给你听。我喜欢直接用"盲点扫描 (blindspot pass)"和"未知的未知 (unknown unknowns)"这两个字面词。把"你是谁、你已经知道什么"这层上下文交代给它，通常很重要。
示例提示：
- "我在做一个新的鉴权提供方 (auth provider)，但我对这个代码库里的鉴权模块一无所知。你能做一次盲点扫描，帮我理清相关的未知的未知，好让我把提示写得更好吗？"
- "我不懂什么叫调色 (color grading)，但我需要给这段视频调色。你能教我认识一下我在调色上的未知的未知，好让我把提示写得更好吗？"
头脑风暴与原型 (Brainstorms and prototypes)
当我在一个充满未知的已知的领域里工作——那些"我只有看到了才知道该怎么定义"的判断标准——我喜欢让 Claude 陪我一起头脑风暴、做原型。
在原型阶段就尽早识别并把未知的已知说出口，价值极大；因为等到实现阶段才发现它们，代价会（相对而言）高很多。功能或规格上一点小改动，可能导致代码里天差地别的实现，而让你的 Agent 回退之前的改动也会更困难。
举个例子，你可能只是想看看"往某个界面框里加个按钮长什么样"，而并不想为此接一条后端路由、或在前端多维护一份状态。
视觉设计对我来说是很难用语言讲清楚的东西，但我一看到就知道自己想要什么。这种情况下，我会让它给同一个 Artifact 出好几种设计方向。
我几乎每一次编码会话都以一段探索或头脑风暴开场。这帮我带着意图 (intent) 出发，去定义项目的范围。Claude 常常会找到一些我本会错过的高价值思路，偶尔也会"只见树木不见森林"。头脑风暴能防止我把范围设得太窄或太宽。
示例提示：
- "我想给这份数据做个仪表盘，但我毫无视觉审美、也不知道能做到什么程度。给我一个 HTML 页面，放上 4 个截然不同的设计方向，让我来挑挑看。"
- "在动手接任何东西之前，先用假数据做一个单文件 HTML，把新的编辑器工具栏 mock 出来。在你碰真正的 App 之前，我想先对布局做个反应。"
- "这是我大致的问题：用户在完成引导 (onboarding) 后就流失了。搜一遍代码库，头脑风暴出 10 个我们可以介入的地方，从最省事到最有野心排序。我来告诉你哪些让我有共鸣。"
访谈 (Interviews)
当我做完足够的头脑风暴后，很可能仍然残留着一些未知项。
这时，我会让 Claude 就任何未知或含糊之处来访谈我。让 Claude 访谈你的时候，尽量给它关于你问题的上下文，好引导它的提问。下面是一些例子。
示例提示：
- "就任何含糊的地方，一次只问我一个问题来访谈我，优先问那些'我的答案会改变架构'的问题。"
参考物 (References)
有时候你没法把想要的东西描述得很细。比如你可能缺少相应的词汇，或者它复杂到你要费好大劲才讲得清。
这种情况下，最好的答案是一个参考物 (reference)。图表、文档或图片都可以，但最顶级的参考物是源码。
如果你有一个库，它以某种方式实现了某个东西，或者有一个你特别喜欢的设计组件，那就直接把 Fable 指向那个文件夹，告诉它去找什么——哪怕它是用另一种语言写的。
Claude Design 也是这么工作的。你不必递给它一个文件（当然你也可以这么做）。你可以把它指向某个你喜欢的网站上的一个模块，它会去读底层的代码，而不只是看截图。这样就能拿到关于标记 (markup)、结构、以及组件究竟是怎么搭起来的更丰富细节。
示例提示：
- "vendor/rate-limiter 里这个 Rust crate 实现了我想要的那种退避 (backoff) 行为。读一读它，然后在我们的 TypeScript API 客户端里重新实现出同样的语义。"
实现计划 (Implementation Plans)
当我觉得自己可以动手实现了，我通常会让 Claude 先给我拟一份实现计划供我审阅，重点放在最可能发生变化的部分——比如让它梳理数据模型、类型接口 (type interface)、或 UX 流程。这样 Claude 就能把那些我可能真的需要改动的东西提前浮出来。
示例提示：
- "用 HTML 写一份实现计划，但要把我最可能去改的决策放在最前面：数据模型的变更、新增的类型接口、以及任何面向用户的东西。把机械性的重构埋到最底下，那部分我信得过你。"
实现之中 (During implementation)
实现笔记 (Implementation notes)
当我对计划满意后，我会新开一个会话，把各种 Artifact 塞进提示里。比如，我可能会传入一个规格文件和一个原型，让 Agent 去实现它。
但事实是，无论你规划得多充分，总有未知的未知潜伏着。Agent 在干活的过程中，可能会因为在代码里发现某个边界情况 (edge case)，而不得不改换思路。
我会让 Claude Code 维护一个临时的 implementation-notes.md（或 .html）文件，把它做过的决定记录下来，好让我们从下一次尝试中学习。
示例提示：
- "维护一个 implementation-notes.md 文件。如果你撞上某个边界情况、被迫偏离原计划，就选保守的那个方案，把它记在 'Deviations（偏离）' 一节下，然后继续往前推。"
实现之后 (Post implementation)
路演与解说 (Pitches and explainers)
交付一件东西时，最重要的环节之一是争取认同与审批 (buy-in and approvals)。在最终文档里搭建路演 (pitch) 和解说 (explainer) 类的 Artifact，能帮上忙：
- 当审阅者和你当初一样带着同样的未知出发时，加速他们的理解；
- 当专家们想看到"你已经考虑到了他们会预料到的那些未知项和常见失败点"时，加速审批。
示例提示：
- "把原型、规格和实现笔记打包成一份文档，让我能直接甩进 Slack 去争取认同。开头先放演示 GIF。"
考我一考 (Quizzes)
一段漫长的工作会话之后，Claude 完成的事情，可能比我意识到的要多得多。光读代码 diff 只能让我对发生了什么有个浅浅的理解，因为很多行为都依赖于既有的代码路径。
在给我铺垫一堆上下文之后，让 Claude 就这次改动来考我一考，能帮我真正搞懂到底发生了什么。我只在满分通过测验之后才合并 (merge)。
示例提示：
- "我想确保自己完全理解这次改动里发生的一切。给我一份关于这些改动的 HTML 报告，让我带着上下文、直觉去读懂：做了什么、为什么、怎么做的，等等；并在结尾附一份关于这些改动的测验，我必须通过。"
这一切如何串起来：Fable 的发布 (launching Fable)
Fable 的发布视频完全是由 Claude Code 剪辑的。这对我是个全新的领域，我绝算不上专家。
于是我从"我确实知道的东西"开始。我知道 Claude 能用代码来剪辑视频、给视频转写字幕，但我不确定它够不够准。于是我让 Claude 给我解释像 Whisper 这样的转写是怎么工作的，以及我能不能用 ffmpeg 精准地剪掉像"呃"这样的口头语或长停顿。
我想让 Claude 做一个和我说话的字词同步对齐的 UI，但不确定它做不做得到，于是我让 Claude 用 Remotion 加一份转写字幕做一个原型视频，看看行不行得通。
最后，视频本身看起来有点发闷 (muted)，我知道这是调色 (color grading) 的问题，但我并不真的懂调色是什么。我第一次尝试是想让 Claude 做几个版本给我挑，可我意识到——在调色这件事上，我根本不知道"好"是什么样子。于是我换了个做法：让 Claude 教我认识调色，好发现我的未知项。
你可以在这里看到关于那部分更深入的讲解。
让地图与疆域对齐 (Matching the Map and Territory)
模型越强，用对方法能达成的就越多。当一个长周期 (long-horizon) 任务交回来的结果是错的，很可能意味着你需要花更多时间去定义你的未知项，或者拟一份"允许 Claude 在其中随机应变 (improvise)"的实现计划。
每一次解说、头脑风暴、访谈、原型和参考，都是在"修复它变得昂贵之前"，用低成本弄清"你原本不知道的事"。
所以，开始你的下一个项目时，先让 Claude 帮你找到你的未知项吧。
Related Documents
- 用 Claude Code 制作 Playgrounds — 同作者，HTML Artifact 用法
- HTML 惊人的有效性 — 同作者，本文多次引用的 HTML 方法
- 为每个任务配一套 Harness — 同作者
- AI 技术博客索引
- 原始剪藏：Raws/A Field Guide to Fable Finding Your Unknowns.md