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

或许是知道大家这周末都要奋战狂战 Fable 5，Anthropic 的 Claude Code 开发者 Thariq 放出了一篇长文，分享他使用 Fable 5 模型的方法论。

Thariq 在文中表示：Fable 5 的能力上限，取决于你能发现多少自己还不知道的东西。

下为 Thariq 全文：

用 Claude Fable 5 写代码，反复教给我一个老道理：地图不是疆域。

地图，也就是对工作的描述，是我的 prompt、skills 和 context，是我交给 Claude 的东西。

疆域，则是工作真正发生的地方：代码库，现实世界，以及它真实的约束条件。

地图与疆域

地图和疆域之间的差距，就是我所说的「未知」。当 Claude 遇到一个未知时，它得根据对你意图的最佳猜测来做决策。工作量越大，Claude 可能碰到的未知也就越多。

Fable 是第一个让我觉得，工作质量的瓶颈其实在于我自己澄清「未知」的能力的模型。

这里有个关键点：光靠提前规划，往往还不够。你可能在实现过程中才挖出深层的未知，也可能发现这些未知其实指向了一个完全不同的解法。

我发现，用 Fable 工作其实是一个迭代的过程：在实现之前、之中和之后，持续地发现自己的未知。

我做了一些用于发现未知的示例 artifact [1]，不过建议先看完这篇文章，建立起直觉之后再去看。

01

四种「未知」

你的未知到底有哪些呢？当我带着一个问题来找 Claude 时，我倾向于从四个维度来拆解：

• 已知的已知（Known Knowns）：这基本就是你 prompt 里写的东西，你告诉 agent 你想要什么了。 

• 已知的未知（Known Unknowns）：你还没想清楚的部分，但你至少知道自己还没想清楚。 

• 未知的已知（Unknown Knowns）：那些你觉得太显而易见、根本不会写进 prompt 的东西，但看到了你就能认出来。 

• 未知的未知（Unknown Unknowns）：你压根没考虑过的东西。你不知道自己不知道什么，甚至不知道一个东西能好到什么程度。 

四种未知矩阵

最厉害的 agentic coding 高手，未知都相对较少。看 Boris 或者 Jarred 写 prompt，你能明显感觉到他们对自己想要什么了如指掌，和代码库、和模型行为之间高度同步。

但他们也会假设未知的存在。

某种意义上，减少和规划你的未知，就是 agentic coding 这件事的核心技能。 好消息是，这个技能通过和 Claude 一起工作就能不断提升。

02

帮它帮你

指令的平衡

给 Claude 下指令，其实是个微妙的平衡。

你太具体了，Claude 会严格执行你的指令，哪怕换条路更合适。你太模糊了，Claude 往往会基于行业最佳实践做选择，而这些选择未必适合你的场景。

如果你没处理好自己的未知，两边都会踩坑。你不知道什么时候路上全是障碍，也不知道什么时候其实一路畅通……但你还是想让 Claude 灵活调整方向。

Claude 能帮你更快地发现你的未知。 它可以飞速搜索你的代码库和互联网，它在大多数话题上知道的比你多，它还能从失败中更快地迭代。

这个过程中最重要的一件事，是给 Claude 关于你出发点的上下文。比如，告诉它你的思考进展到了哪一步，坦诚你对这个问题和代码库的熟悉程度，让它像一个思考伙伴一样跟你合作。

我之前写过一篇关于用 HTML artifact 和 Claude 协作 [2]的文章，在几乎所有的场景下，HTML artifact 都是可视化和呈现信息的最佳方式。

下面我会详细介绍我用来发现这些未知的方法。我并非每次都全部用到，但作为一个工具箱放在手边，确实挺趁手的。

技巧总览

03

盲区扫描

开始一项工作时，最有用的事情之一就是了解你的盲区。比如你要在代码库的一个陌生角落写功能，或者用 Claude 帮你做一些你不熟悉的事（比如迭代一个设计方案），那你很可能有大量「未知的未知」。

你可能不知道该问什么问题，不知道「好」的标准长什么样，不知道有哪些历史工作已经做过了，也不知道有哪些坑要避开。

这时候，你可以让 Claude 帮你找到你的「未知的未知」，然后解释给你听。我喜欢在 prompt 里直接用「blindspot pass」和「unknown unknowns」这两个词。给 Claude 关于你是谁、你已经知道什么的上下文，通常也至关重要。

示例 prompt：

我在给项目加一个新的认证提供商，但我对这个代码库里的 auth 模块一无所知。你能做一次盲区扫描（blindspot pass），帮我找到相关的「未知的未知」，让我能更好地给你写 prompt 吗？

我不知道什么是调色（color grading），但我需要给这个视频调色。你能教我理解调色领域里我的「未知的未知」，让我能写出更好的 prompt 吗？

04

先做原型

当我面对大量「未知的已知」时，也就是那些只有看到了才知道自己想要什么的东西，我喜欢让 Claude 和我一起头脑风暴、做原型。

在原型阶段就把「未知的已知」找出来并说清楚，价值不小。因为在实现阶段才发现它们，成本会高得多。规格上的一个小改动，可能导致代码实现截然不同，而让 agent 回滚已有的改动也会更费劲。

比如，你可能只是想看看在一个 frame 上加个按钮的效果，而不想去接后端路由或者在前端维护额外的状态。

视觉设计这块，对我来说是一个很难用语言描述、但看到了就知道自己想要什么的领域。这种情况下，我会让 Claude 给我做几个不同的设计方向。

我基本上每次写代码前，都会先来一轮探索或头脑风暴。这帮我在一开始就有意识地确定项目的范围。Claude 经常能找到我会错过的高价值方案，也偶尔会见树不见林。头脑风暴能防止我把范围定得太窄或太宽。

示例 prompt：

我想给这些数据做个仪表板，但我没什么视觉审美，也不知道有哪些可能性。做一个 HTML 页面，给我 4 个完全不同的设计方向，让我看看哪个感觉对。

在接任何东西之前，先做一个 HTML 文件，用假数据模拟新的编辑器工具栏。我想先感受一下布局，再动真正的应用。

我的大致问题是：用户在 onboarding 之后流失了。搜索代码库，头脑风暴 10 个我们可以介入的点，从最便宜到最大胆排列。我来告诉你哪些方向靠谱。

05

让它面试你

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

这时候，我会让 Claude 就任何模糊的地方来「面试」我。让 Claude 面试你的时候，尽量给它关于你问题的上下文，引导它提问的方向。

示例 prompt：

每次问我一个问题，问那些有歧义的地方，优先问那些「我的回答会改变架构设计」的问题。

06

给它看参考

有时候你确实难以描述清楚自己想要什么。可能你没有合适的语言来表达，也可能这东西太复杂了，描述起来得花不少时间。

这时候，最好的答案就是给一个参考。虽然你可以给图表、文档或截图，但最好的参考……其实是源代码。

如果你有一个库按照某种特定方式实现了某个行为，或者你很喜欢某个设计组件，直接把 Fable 指向那个文件夹，告诉它看什么就行，哪怕是另一种语言也没关系。

这也是 Claude Design 的工作方式。你不一定要给它一个文件（虽然你也可以这么做）。你可以把它指向一个你喜欢的网站上的某个模块，它会去读底层代码，而不只是看截图。这能提供关于标记、结构和组件实际构建方式的丰富细节。

示例 prompt：

 vendor/rate-limiter 里的这个 Rust crate 实现了我想要的退避行为。读一下它，然后在我们的 TypeScript API 客户端中重新实现相同的语义。

07

先出方案

当我觉得差不多可以开始写了，我通常会让 Claude 先给我出一个实现方案来审阅，重点放在那些最可能改动的部分，比如数据模型、类型接口或者 UX 流程。这能让 Claude 把我可能真正需要调整的东西浮上来。

示例 prompt：

写一个 HTML 版的实现方案，但把我最可能要调整的决策放在最前面：数据模型变更、新的类型接口、以及任何用户可见的东西。那些机械性的重构放到最后，那部分我信你。

08

边做边记

对方案满意之后，我会开一个新的 session，把之前的 artifact 传进去。比如，我可能会把一个 spec 文件和一个原型一起传进去，让 agent 来实现。

但事实上，不管你做了多少规划，总有「未知的未知」在暗处等着你。Agent 可能在工作过程中发现代码里的一个边界情况，需要换个思路。

我会让 Claude Code 维护一个临时的 implementation-notes.md（或 .html）文件，记录它做的决策，这样我们下次迭代的时候能从中学习。

示例 prompt：

 维护一个 implementation-notes.md 文件。如果你碰到一个边界情况迫使你偏离方案，选择保守的方案，把它记在「偏差」部分，然后继续。

09

交付说明

交付与说明

交付一个东西，很重要的一步是获得认同和审批。构建 pitch 和 explainer 类的 artifact 能帮你：

•  当审阅者和你当初有相同的「未知」时，加速他们的理解 

•  当专家想确认你考虑到了他们预期的风险和常见失败点时，加速审批 

示例 prompt：

把原型、spec 和实现笔记打包成一个文档，让我可以丢到 Slack 里争取支持。把 demo GIF 放在最前面。

10

验收考试

一个长时间的工作 session 结束后，Claude 完成的东西可能比我意识到的要多得多。光看代码 diff 只能让我对发生了什么有个粗浅的了解，毕竟很多行为取决于已有的代码路径。

让 Claude 先给我上下文，然后出一套关于这次改动的测验题，帮我真正理解到底发生了什么。

我只有把测验全做对了才会合并代码。

示例 prompt：

我想确保自己理解了这次改动的所有内容。给我做一个 HTML 报告，包含改动的上下文、直觉、做了什么等信息供我阅读理解，然后在底部出一套测验题，我必须通过。

11

一次实战

Fable 的发布视频 [3]完全是用 Claude Code 剪辑的。视频制作对我来说是一个全新的领域，我绝对算不上什么专家。

所以我从自己已知的东西开始。我知道 Claude 可以用代码来编辑视频和做转录，但精度够不够呢？于是我让 Claude 给我解释 Whisper 这类转录工具的原理，以及我能不能用 ffmpeg 准确地剪掉「嗯」和长停顿之类的东西。

我想让 Claude 做一个和我说话节奏同步的 UI，但不确定它能不能做到。那……先做个原型试试呢？我让 Claude 用 Remotion 和一段转录做了个原型视频，看看效果。

最后，视频看起来有点灰蒙蒙的。我知道这是调色的问题，但我其实不太了解调色到底是什么。第一次尝试是让 Claude 做几个版本让我挑，但后来发现一个问题：我根本不知道调色做到什么程度算「好」。于是换了个思路，让 Claude 先教我调色的基础知识，来发现我在这个领域的未知。

你可以在这里 [4]看到更详细的讲解。

12

缩小差距

模型变得越强大，用对了方法你能做到的事就越多。当一个长周期的任务结果不对时，你大概率需要花更多时间来定义你的未知，或者制定一个允许 Claude 灵活应变的实现方案。

每一次头脑风暴、面试、原型和参考，都是一次低成本的试探，相当于在问题变得昂贵之前先去探探路。

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

[1] 用于发现未知的示例 artifact: https://thariqs.github.io/html-effectiveness/unknowns/

[2] 用 HTML artifact 和 Claude 协作: https://x.com/trq212/status/2052809885763747935

[3] Fable 的发布视频: https://x.com/ClaudeDevs/status/2064399512664526853

[4] 这里: https://x.com/trq212/status/2064826394589442448/video/1

文章来自于微信公众号 “AGI Hunt”，作者 “AGI Hunt”