Fable 5 的发布历程可谓跌宕起伏，从备受瞩目的「AI 封神」到因美国政府禁令被迫下架，再到限制非美国用户访问，这款模型一直吸引着全球的关注。

随着风波平息，Fable 5 终将回归其作为生产力工具的本质。为此，Claude 的工程师 Thariq Shihipar 在一篇长篇博客中分享了使用 Fable 5 的实用技巧。

这篇文章旨在解答一个普遍存在的疑问：尽管当前模型的性能已十分强大，为何用户在使用时仍感觉无法准确完成任务？

Thariq 的博客揭示了关键原因：用户与模型之间存在“信息差”，即用户提供的提示词、技能、上下文与实际任务执行之间存在差距。

该博客的核心内容便是指导用户如何弥合这一信息差。机器之心将全文呈现，供读者参考。

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

Thariq 在与 Claude Fable 5 合作的过程中，深刻体会到“地图并非疆域”这一古老道理。这里的“地图”指的是用户为完成任务所提供的表征，包括提示词、技能和上下文，而“疆域”则是任务实际执行的场所，如代码库、现实世界及其固有的限制。

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

Fable 是首个让 Thariq 明确感受到“工作质量的瓶颈取决于我澄清其未知项的能力”的模型。

值得注意的是，充分的提前规划并非总是万全之策。在实现过程中，可能会出现新的未知项，或者发现原有的未知项表明需要采用完全不同的解决方案。

Thariq 认为，与 Fable 协作本质上是一个持续发现未知项的迭代过程，贯穿实现前、实现中和实现后。

作者还提供了一些发现“未知项”的实例，读者可参考原文链接 https://thariqs.github.io/html-effectiveness/unknowns/ 进行查看。

理解你的未知项

未知项可以从四个维度来理解：

• 已知的已知：这是用户在提示词中明确表达的需求，即告诉智能体想要什么。
• 已知的未知：用户清楚自己尚不了解某些信息，但意识到了这些信息缺失。
• 未知的已知：对用户而言显而易见，无需言明，但一旦呈现便能识别的事物。
• 未知的未知：用户完全未曾考虑过、尚未意识到自己不知道的知识，以及对事物能达到的最佳程度缺乏认知。

经验丰富的智能体式程序员通常未知项较少，他们对目标有清晰的认识，并能提供充分的细节，同时与代码库和模型行为保持高度同步。

然而，他们也会预设未知项的存在。可以说，减少并提前规划未知项是智能体式编程的核心能力，这项技能可以通过与 Claude 的协作得到不断提升。

赋能 Claude 以助己

向 Claude 下达指令需要精妙的平衡。指令过于具体，可能导致 Claude 固守原方案，即使有更优选择也难以转向。指令过于模糊，则可能导致 Claude 依据行业最佳实践进行假设和选择，而这些不一定符合特定任务的需求。

当用户未能充分考量自身未知项时，这两种情况都可能导致失败。用户可能无法预见前路障碍，也可能忽视了本应畅通的道路，并期望 Claude 在必要时进行调整。

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

在此过程中，为 Claude 提供充分的初始上下文至关重要。例如，告知其当前思考的阶段、用户对问题和代码库的熟悉程度，并将其视为一个思考伙伴进行协作。

Thariq 曾撰写过关于使用 Claude 生成 HTML 的文章，在这些场景中，HTML 工件是可视化和表达想法的理想方式。

本文将详细介绍 Thariq 用于发现未知项的模式。他并非每次都使用所有技巧，而是将它们作为一套可调用的方法储备起来。

实现前

盲点扫描

在开始工作时，理解自身的盲点是至关重要的。例如，在不熟悉的代码模块中编写功能，或让 Claude 处理不熟悉的工作（如迭代设计方案），都可能带来大量的“未知的未知”。

用户可能不知道该提问什么，何为“好”，过往已有哪些相关工作，以及需要避免哪些陷阱。

为此，可以请 Claude 识别“未知的未知”并进行解释。Thariq 倾向于直接使用“blindspot pass”和“unknown unknowns”等词语，并强调告知 Claude 自己的身份和已知信息也很重要。

示例提示词：

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

头脑风暴与原型

当面对大量“未知的已知”（即只有看到后才能明确标准的事物）时，Thariq 会邀请 Claude 进行头脑风暴和原型设计。

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

例如，可能只是想查看在某个框架中添加按钮的效果，而无需接入后端路由或在前端维护额外状态。

视觉设计对 Thariq 而言是难以清晰表达的，但他看到后会知道自己想要什么。在这种情况下，他会要求 Claude 针对一个工件提供几种不同的设计方向。

他几乎会在每次编码会话开始时都进行探索或头脑风暴。这有助于他明确项目范围，并避免 Claude 仅见树木不见森林。头脑风暴能够防止一开始就将范围设定得过窄或过宽。

示例提示词：

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

反问

在充分头脑风暴后，通常仍会存在未知项。

此时，Thariq 会让 Claude 围绕任何不明确或存在歧义的地方进行提问。在让 Claude 提问时，应尽量提供问题的上下文，以便其提出更有针对性的问题。

示例提示词：

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

参考资料

有时，用户无法详细描述自己的需求，可能因为缺乏相应的表达语言，或者描述过程过于耗时。

在这种情况下，提供参考资料是最佳选择。可以是图表、文档或图片，但源代码是更优的参考。

如果某个库以特定方式实现了某个功能，或者存在用户非常喜欢的设计组件，可以直接将 Fable 指向相关文件夹，并告知其需要查看的内容。即使参考代码是不同语言编写的也无妨。

Claude Design 的工作方式亦是如此。用户不必局限于提供文件，可以将喜欢的网站模块指向 Claude，它会读取底层代码，而非仅是截图，从而提供更丰富的细节，包括标记结构、组件组织方式以及组件的实际构建过程。

示例提示词：

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

实现计划

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

示例提示词：

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

实现中

实现笔记

在对计划满意后，会开启一个新的会话，并将相关工件传入提示词。例如，传入一份规格文件和一个原型，然后让智能体进行实现。

然而，无论规划多么周全，总会有未知的未知潜伏着。智能体在工作过程中可能会因代码中的某个边界情况而不得不改变思路。

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

示例提示词：

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

实现后

推介与解释文档

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

• 加速评审者的理解，尤其是在他们一开始带有与用户相同的未知项时。
• 加速审批过程，当专家希望确认用户已考虑到他们通常会预见的未知项和常见失败点时。

示例提示词：

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

测验

在一次漫长的会话结束后，Claude 可能已完成了比用户意识到的更多工作。仅查看代码 diff 往往只能提供对所发生情况的浅层理解，因为许多行为取决于现有的代码路径。

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

示例提示词：

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

串联方法：以发布 Fable 为例

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

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

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

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

让地图与疆域匹配

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

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

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