Anthropic 的 Claude Code 工程师 Thariq Shihipar 发了一篇 X 长文《A Field Guide to Fable, Finding Your Unknowns》（Fable 实战指南，找出你的未知），一天刷了两百多万阅读。

他认为，与 Fable 5 协作最重要的部分，是发现自己的未知，这样才能更好地提示它。

Fable 5 强到当前这一档，瓶颈已经从模型挪到了人脑里那些没说清楚的东西上。现在这个瓶颈也打破了，你没想清楚甚至你不知道的，Fable 5 都能帮你主动干了。

文章用一句 “the map is not the territory”（地图不等于疆域）作引子，把未知拆成四类，给出任务前中后三段打法。

地图不是疆域

你给 Claude 的 prompt、说明、上下文，是地图。真正的代码库、生产环境约束、还没想到的边界情况，是疆域。地图没画到的地方，Claude 会自己脑补一条路走下去。

放在弱模型时代不明显。那时候模型连你写清楚的事都做不好，大家拼命把 prompt 写厚来兜底。Fable 5 不一样，它是 Thariq 用过第一个让他真心觉得，产出质量取决于自己能不能把不知道的事说出来，模型听不听得懂已经不是问题。

Fable 5 的定位，专门解决过去模型处理不了的复杂、长周期、高模糊度问题，尤其擅长原本需要人花几小时、几天甚至几周才能做完的端到端工作。Thariq 也提醒，把 Fable 5 拿来只跑简单任务会严重低估它，要把它丢到最难、最没解过的问题上去试。

决定一个人用 Claude Code 成功率的不是编码能力，是 domain expertise（领域专长）。懂自己在解决什么问题的人，比懂自己在写什么代码的人，更容易把会话跑成。

当 Fable 5 遇到未知时，它需要根据对我想要什么的最佳猜测做出决定。完成的工作越多，Fable 5 做了你未知的事就越多。Fable 5 已经强到不需要你编写详细的 prompt，工作完成质量反而取决于你发现并向模型澄清你的未知。

很多复杂任务，仅仅提前计划并不总是足够的。你可以在实施过程中发现未知，或者你的未知可能会让你意识到，你实际上应该以一种完全不同的方式解决问题。

与 Fable 5 协作是一个迭代过程，在实现之前、期间和之后，不断发现自己的未知。

把未知分成四类

Thariq 把未知拆成四类。

• 已知的已知（Known Knowns）：这基本上就是提示词里写的内容。告诉智能体你想要什么？

• 已知的未知（Known Unknowns）：还没搞清楚，但知道自己没搞清楚的事。

• 未知的已知（Unknown Knowns）：那些太过明显、根本不会写下来，只要看到就能认出来的事。

• 未知的未知（Unknown Unknowns）：压根没考虑过的事。不知道自己缺少什么知识。甚至不知道某件事能做到多好。

最优秀的智能体编程者，其未知相对较少。像 Boris（Claude 之父）或 Jarred 这样的高手写提示词，很明显他们对自己的需求有非常细致的了解。他们对代码库和模型行为都深度同步。

但他们也假设存在未知。在许多方面，减少并规划你的未知，就是智能体编程这门手艺本身。幸运的是，这是一项可以通过与 Claude 协作来提升的技能。

指导 Claude 是一种微妙的平衡。如果你太具体，Claude 会死守你的指令，即便转向可能更合适；如果你太模糊，Claude 往往会根据行业最佳实践做出选择和假设，而这些可能并不适合你的任务。

当你没有考虑自己的未知时，你会两头都失败。你不知道什么时候路上会布满障碍，也不知道什么时候一路畅通，但你仍然希望 Claude 能随机应变。

Claude 能帮你更快地发现自己的未知。它能极快地搜索你的代码库和互联网，而且对大多数常见话题的了解远超你。它还能从失败中更快地迭代。

这个过程最重要的部分是给 Claude 提供关于你起点的上下文。例如，告诉它你当前思考到哪一步了；坦陈你对该问题和代码库的经验水平；让它像思考伙伴一样与你合作。

将 HTML 与 Claude 配合使用，在几乎所有这些场景中，都是可视化和表征问题的最佳方式。

任务前中后三段打法

1，实现之前

盲点扫描（Blind Spot Pass）

开始工作时，最有用的做法之一就是了解自己的盲点。例如，如果你要在代码库中陌生的部分写一个新功能，或者用 Claude 帮你做不熟悉的工作（比如迭代设计），你很可能有大量未知的未知。

你可能不知道要问什么问题、好的标准是什么、以往有哪些相关工作，或者有哪些坑要避开。

为此，你可以让 Claude 帮你找出你的未知未知，并为你解释。给它关于你是谁、你了解什么的上下文通常很重要。

提示词示例：

“我正在添加一个新的认证提供商，但我对代码库中的认证模块一无所知。你能帮我做一次盲点扫描，找出我相关的未知未知，并帮我更好地向你提问吗？”

“我不知道什么是调色，但我需要给这个视频调色。你能教我去理解我在调色上的未知未知，以便我能更好地提示你吗？”

头脑风暴与原型（Brainstorms and prototypes）

当在一个有很多未知的已知的领域工作时，和 Claude 一起做头脑风暴和原型。

在原型阶段尽早识别并表达出未知的已知非常有价值，因为在实现阶段才发现它们会（相对）代价高昂。功能或规格上的小改动可能导致代码实现上巨大的差异，而且让智能体回退之前的改动会更加困难。

例如，你可能只想看看把一个按钮加到画框里是什么效果，而不必先搭好后端路由或在前端维护额外的状态。视觉设计很难用语言描述，但我们看到时就知道想要什么。这种情况下，让 Claude 为一个工件提供几种不同的设计方向。

每次编程会话都从一个探索或头脑风暴阶段开始。这能帮助我们在一开始就带着意图去定义项目范围。Claude 经常会发现忽略的高价值方向，有时也会见木不见林。头脑风暴能防止把范围设得太窄或太宽。

提示词示例：

“我想要一个展示这些数据的仪表盘，但我没有视觉审美，也不知道有哪些可能性。给我做一个 HTML 页面，包含 4 种截然不同的设计方向，让我能对着它们给反馈。”

“在连接任何真实逻辑之前，先用单个 HTML 文件模拟新的编辑器工具栏，用假数据。我想先对布局给出反馈，再让你碰真正的应用。”

“这是我的粗略问题：用户在新手引导后流失。搜索代码库，头脑风暴出 10 个我们可以介入的地方，从成本最低到最雄心勃勃。我会告诉你哪些有共鸣。”

访谈（Interviews）

做完足够的头脑风暴后，可能仍然有未知。

这时，让 Claude 对自己进行访谈，问清楚任何未知或模糊之处。让 Claude 访谈你时，尽量给它关于你问题的上下文，以引导它提问。下面是一些例子。

提示词示例：

“一次问我一个问题，聚焦于任何模糊的地方，优先处理那些我的答案会改变架构的问题。”

参考（References）

有时候你无法详细描述你想要什么。比如，你可能没有相应的术语，或者事情太复杂，要花很长时间才能说清。

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

如果你有一个库以某种方式实现了某个功能，或者你非常喜欢某个设计组件，直接把那个文件夹指给 Fable，告诉它要看什么，即使是用不同语言写的也没关系。

这也是 Claude Design 的工作方式。你不必给它一个文件（虽然你也可以这么做）。你可以指给它一个你喜欢的网站上的模块，它会读取底层的代码，而不仅仅是截图。这能提供更丰富的信息，包括标记、结构以及组件的实际构建方式。

提示词示例：

“vendor/rate-limiter 里的这个 Rust crate 实现了我想要的确切退避行为。阅读它，并用相同的语义在我们的 TypeScript API 客户端中重新实现。”

实现计划（Implementation Plans）

当觉得可以开始实现时，请 Claude 为你整理一份实现计划让你自己审阅，重点放在最可能变动的部分，比如数据模型、类型接口或用户体验流程。这能让 Claude 提前暴露可能确实需要修改的地方。

提示词示例：

“用 HTML 写一份实现计划，但把我最可能调整的决定放在最前面：数据模型变更、新的类型接口，以及任何面向用户的部分。把机械性的重构工作埋在最底下，那部分我信任你。”

2，实现之中

实现笔记（Implementation notes）

当对计划满意后，开启一个新会话，把之前的工件都传进去。例如，传入一个规格说明文件和原型，让智能体去实现。

但事实是，无论做多少规划，总有未知的未知潜伏其中。智能体在干活时可能会发现，因为代码里找到一个边界情况，它需要换一种方式处理。

让 Claude Code 保留一个临时的 implementation-notes.md（或 .html）文件，记录它做出的决策，这样我们就能从下一次尝试中学习。

提示词示例：

“保留一个 implementation-notes.md 文件。如果你遇到一个边界情况，迫使你偏离计划，选择保守的方案，在‘偏离记录’下记一笔，然后继续推进。”

3，实现之后

推介与解说（Pitches and explainers）

交付东西最重要的环节之一，就是获得认同和批准。在最终文档中构建推介和解说工件能帮助：

• 让审阅者从你当初的未知起点开始理解，从而加速理解

• 让专家在看到你已考虑到他们可能预见的未知和常见失败点时，加速批准

提示词示例：

“把原型、规格说明和实现笔记打包成一份文档，我能直接丢到 Slack 里争取支持。最前面放演示 GIF。”

测验（Quizzes）

经过长时间的工作会话后，Claude 可能完成了比我们意识到的多得多的内容。仅阅读代码差异只能对发生的事情有表面的理解，因为大量行为取决于已有的代码路径。

让 Claude 在给你大量上下文后，就改动内容对你进行测验，能帮助你真正理解发生了什么。只有在你完美通过测验后，才合并代码。

提示词示例：

“我想确保自己完全理解这次变更中发生的一切。给我一份 HTML 报告，让我阅读并理解——包含上下文、直觉解释、做了什么等等——并在底部放一个关于这些改动的测验，我必须通过。”

拿 Fable 5 剪一支视频

Thariq 给了一个最具体的例子。

Anthropic 在 6 月 10 日发的 Fable 5 发布视频，是用 Claude Code 剪的，他没有任何视频制作经验。

他先盘自己知道什么。Claude Code 能用代码方式剪视频、能转写。然后探边界，Whisper（开源语音转写模型）转写怎么工作、ffmpeg 能不能精确切掉语气词、用 Remotion（基于 React 的视频框架）能不能做词级字幕同步。

画面发灰的时候，他第一反应让 Claude 出一堆调色方案。看到方案他意识到自己不会判断好坏，他不知道什么叫好的调色。他停下来，让 Claude 先教他一门课，再继续往下做。

上述链路就是 Thariq 框架在创意领域的应用。识别出一个 unknown unknown，把它变成 known unknown，再变成 known known，然后继续。换软件迁移、数据管道、视频剪辑都一样的逻辑。

模型越好，用对方法能实现的就越多。当一个长周期任务返回的结果不对时，很可能你需要花更多时间来定义你的未知，或者创建一份让 Claude 能即兴应对这些未知的实现计划。

每一次解说、头脑风暴、访谈、原型和参考，都是一种低成本的方式，让你在问题变得昂贵之前，发现自己不知道的东西。

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

参考资料：

https://x.com/trq212/status/2073100352921215386

https://thariqs.github.io/html-effectiveness/unknowns/