Fable 5 的发布历程颇具戏剧性，从备受期待的“AI 封神”到被美国政府强制下线，再到限制非美国用户访问，引发了全球广泛关注。

随着风波的平息，Fable 5 最终回归其核心价值——提升生产力。为此，Claude 的工程师 Thariq Shihipar 在一篇长篇博客中分享了使用 Fable 5 的实用技巧。

这篇博客旨在解答一个普遍存在的疑问：为何即便 AI 模型能力日益强大，用户在使用时仍感觉无法准确完成任务。

Thariq 的文章揭示了关键原因：用户与模型之间存在“信息差”，即用户输入的提示词、技能、上下文与实际任务执行之间存在脱节。博客的核心内容便是指导用户如何弥合这一信息差。

博客标题为《A Field Guide to Fable: Finding Your Unknowns》，链接为：https://x.com/trq212/status/2073100352921215386

Shihipar 强调，与 Claude Fable 5 协作，让他深刻体会到“地图并非疆域”。这里的“地图”指的是用户提供的提示词、技能和上下文，而“疆域”则代表着实际需要完成工作的环境，如代码库或现实世界及其固有约束。

他将地图与疆域之间的差距称为“未知项”。当 Claude 遇到未知项时，它会根据对用户意图的最佳猜测来做出决策。任务越复杂，Claude 面临的未知项可能越多。

Fable 是第一个让 Shihipar 明显感受到工作质量瓶颈取决于其澄清未知项能力的模型。他指出，仅仅提前规划并不总是足够，因为在实施过程中可能会发现新的未知项，甚至可能需要改变解决问题的根本方式。与 Fable 协作，本质上是一个在实施前、实施中和实施后不断发现未知项的迭代过程。

作者还提供了一些发现“未知项”的示例，读者可在原文链接中查阅：https://thariqs.github.io/html-effectiveness/unknowns/

识别你的未知项

Shihipar 提出了四种类型的“未知项”：

• 已知的已知：用户在提示词中明确表达的需求。
• 已知的未知：用户知道自己尚未明确，但意识到的信息缺口。
• 未知的已知：对用户来说显而易见，以至于不会在提示词中提及，但看到后能识别出的信息。
• 未知的未知：用户完全未曾考虑过，或不知道自己不知道的知识盲点，包括对任务最佳完成度的认知缺失。

他认为，顶尖的智能体式程序员通常具有较少的未知项，他们对目标有清晰的认识并提供充分的细节，同时与代码库和模型行为保持高度同步。然而，他们也会预设未知项的存在。“减少并提前规划未知项”被认为是智能体式编程的核心能力，并且可以通过与 Claude 协作不断提升。

协助 Claude 从而更好地协助你

与 Claude 互动需要精妙的平衡。过于具体的指令可能导致 Claude 僵化执行，即使有更优方案也无法采纳；过于模糊的指令则可能让 Claude 基于通用最佳实践进行推断，而这些推断未必适合特定任务。当用户未能充分考虑自身未知项时，这两种极端情况都可能导致失败。

Claude 能够加速用户发现未知项的过程，因为它能快速检索代码库和互联网信息，并在多数领域拥有比用户更广泛的通用知识，同时也能更快地从失败中学习和迭代。

在此过程中，提供足够的起始上下文至关重要，包括告知 Claude 当前的思考阶段、用户对问题和代码库的熟悉程度，以及让它扮演一个思考伙伴的角色。Shihipar 曾撰文介绍如何使用 Claude 生成 HTML，他认为 HTML 是可视化和表达想法的理想媒介。

他将在文章中详细介绍自己发现未知项的模式，并将其作为一套可调用的方法储备。

实施前

盲点扫描

在项目初期，理解自身盲点是关键。例如，在一个新的代码模块或不熟悉的任务领域（如设计方案迭代）中工作时，很可能存在大量“未知的未知”。用户可能不知道该问什么，什么才算优质成果，过往的工作历史，以及需要避免的陷阱。

为此，用户可以要求 Claude 识别“未知的未知”并进行解释。Shihipar 建议使用“blindspot pass”和“unknown unknowns”等术语，并提供关于自身背景和已知信息。

示例提示词： “我正在添加一个新的身份验证提供方，但我对这个代码库里的认证模块一无所知。你能不能做一次 blindspot pass，帮我找出相关的 unknown unknowns，并帮助我更好地给你写提示词？” “我不了解调色，但我需要给这个视频做调色。你能不能教我理解自己在调色方面的 unknown unknowns，这样我就能写出更好的提示词？”

头脑风暴与原型

当用户在一个存在大量“未知的已知”的领域工作时，即那些只有看到后才能明确标准的领域，他会与 Claude 进行头脑风暴和原型制作。

在原型阶段尽早识别并表达这些“未知的已知”非常有价值，因为在实施阶段才发现它们，代价会更高。功能或规格的微小变动可能导致代码实现发生巨大变化，且让智能体回退修改也更困难。

例如，用户可能只是想了解在特定框架中添加一个按钮的效果，而不必立即接入后端路由或在前端维护额外状态。视觉设计通常难以清晰表达，但用户看到后会知道自己想要什么。在这种情况下，用户会要求 Claude 针对一个工件提供几种不同的设计方向。

Shihipar 几乎在每次编码会话开始时都会进行探索或头脑风暴，以明确项目范围。Claude 经常能发现用户可能忽略的高价值方案，但有时也会过于关注细节而忽略整体。头脑风暴有助于避免范围设定过窄或过宽。

示例提示词： “我想为这组数据做一个仪表盘，但我没有什么视觉品味，也不知道可以做到什么程度。帮我做一个 HTML 页面，给出 4 种风格差异很大的设计方向，好让我根据结果做反馈。” “在真正接线之前，先用假数据做一个单独的 HTML 文件，模拟新的编辑器工具栏。我想先对布局做反馈，然后你再去动真实应用。” “这是我的粗略问题：用户在完成 onboarding 后流失。搜索代码库，头脑风暴 10 个我们可以介入的地方，从最低成本到最有野心的方案都列出来。我会告诉你哪些方向更有感觉。”

反问

在充分头脑风暴后，用户可能仍有未知项。此时，他会要求 Claude 就任何不明确或存在歧义的地方进行提问。用户在让 Claude 提问时，应尽量提供问题上下文，以便 Claude 提出更有针对性的问题。

示例提示词： “请一次只问我一个问题，围绕任何存在歧义的地方采访我。优先提出那些我的回答会改变架构设计的问题。”

参考资料

有时，用户无法详细描述需求，可能因为缺乏相应的语言表达能力，或任务过于复杂。在这种情况下，提供参考资料是最佳选择。用户可以提供图表、文档或图片，但源代码是最好的参考资料。

如果某个库以特定方式实现了某个功能，或者用户有一个特别喜欢的设计组件，可以直接将 Fable 指向对应文件夹，并告知它需要查看的内容。即使参考代码是其他语言编写的，也无妨。Claude Design 的工作方式也是如此，它能读取底层代码，而不仅仅是截图，从而提供更丰富的细节，包括标记结构、组件组织方式以及组件的实际构建过程。

示例提示词： “vendor/rate-limiter 里的这个 Rust crate 实现的正是我想要的回退重试行为。请阅读它，并在我们的 TypeScript API 客户端中重新实现相同的语义。”

实施计划

当用户认为已准备好开始实施时，他通常会让 Claude 先整理一份实施计划供审阅，并重点关注最可能发生变化的部分，如数据模型、类型接口或 UX 流程。这有助于 Claude 提前暴露用户可能需要调整的地方。

示例提示词： “用 HTML 写一份实现计划，但开头先呈现我最可能会修改的决策点：数据模型变更、新的类型接口，以及任何面向用户的内容。机械性的重构放在最下面，那部分我相信你可以处理。”

实施中

实施笔记

在对计划满意后，用户会开启新的会话，并将相关工件传入提示词，例如一份规格文件和一个原型，然后让智能体进行实现。然而，无论计划多么周全，总会有未知的未知潜伏着。智能体在工作过程中可能会因为代码中的某个边界情况而不得不改变思路。

用户会要求 Claude Code 维护一个临时的 implementation-notes.md 或 .html 文件，记录它所做的决策，以便从下一次尝试中学习。

示例提示词： “请维护一个 implementation-notes.md 文件。如果你遇到某个边界情况，导致你必须偏离原计划，请选择保守方案，在 ‘Deviations’ 下面记录原因，然后继续推进。”

实施后

推介与解释文档

发布某个产品时，获得他人的理解、支持和批准至关重要。在最终文档中包含推介和解释类工件，有助于：

• 加速评审者理解，特别是当他们最初带着与用户相同的未知项时。
• 加速审批过程，当专家需要确认用户已考虑到他们预见的未知项和常见失败点时。

示例提示词： “把原型、规格说明和实现笔记打包成一个单独的文档，我可以直接发到 Slack 里争取支持。开头先放演示 GIF。”

测验

经过一次漫长的会话后，Claude 可能完成了比用户意识到的更多工作。仅看代码 diff 往往只能提供浅层理解，因为许多行为取决于既有代码路径。

让 Claude 在提供大量上下文后，围绕变更进行提问，可以帮助用户真正理解发生了什么。用户只有在完美通过测验后才会合并代码。

示例提示词： “我想确保自己理解了这次变更里发生的一切。请给我一份 HTML 报告，帮助我阅读和理解这些变更，包括上下文、直觉解释、具体做了什么等等，并在底部附上一份我必须通过的测验。”

串联方法：以发布 Fable 为例

Fable 的发布视频完全由 Claude Code 剪辑完成。对于 Shihipar 而言，这是一个全新的领域，他并非这方面的专家。

他从自己已知的部分入手：Claude 可以用代码编辑视频并进行转录，但他不确定其准确度。于是，他让 Claude 解释 Whisper 等转录技术的工作原理，以及是否能用 ffmpeg 精确剪掉语气词或长时间停顿。

他希望 Claude 创建一个 UI，并使其与他说出的词语在时间上同步，但不确定是否可行。因此，他让 Claude 使用 Remotion 和转录文本创建一个视频原型，以验证想法的可行性。

最后，视频画面显得有些灰暗。他知道这是调色问题，但并不真正了解调色。第一次尝试时，他让 Claude 生成几个版本供选择，但他意识到在调色方面，自己并不知道什么才算“好”。因此，他没有继续让 Claude 盲目生成版本，而是让 Claude 教他调色，以此发现自己的未知项。

让地图与疆域匹配

模型越强大，用户就越能通过正确的方法完成更多事情。当一个长周期的任务返回错误结果时，很可能表明用户需要花更多时间定义自己的未知项，或者创建一个实施计划，让 Claude 能够在这些未知项中灵活应对。

每一次的解释文档、头脑风暴、访谈、原型和参考资料，都是一种低成本的方式，可以在修复代价变高之前，先发现那些用户原本不知道的事情。

因此，在开始下一个项目时，不妨先让 Claude 帮助你识别自身的未知项。