Claude工程师终于交出Fable 5焚诀，教你打破和模型之间的信息差

故事要从头说起。Fable 5 自发布那天起，命运就像它的名字一样充满玄幻色彩。从万众期待的“AI 封神时刻”，到美国政府一纸禁令强制下线，再到限制非美国用户访问——这一路走来，Fable 5 几乎吸引了全球的目光。如今，风波渐平，模型总归要落地到生产力中去。

在 AI 的世界里，有一个很形象的比喻——地图不等于疆域。

所谓“地图”，是你对待完成工作的一种表征：你的提示词、你定义的技能和上下文，总之是你交给模型的东西。而“疆域”，则是真正需要发生工作的地方——代码库、现实世界，以及其中真实存在的约束。

地图与疆域之间的差距，就是所谓的“未知项”。当模型遇到一个未知项时，它就只能根据自己对你意图的最佳猜测来做决定。工作越复杂，模型中潜伏的未知项就越多。Fable 是第一个让人明显感受到，工作质量的瓶颈取决于澄清未知项能力的模型。

关键是，仅仅提前规划并不总是够的。有时你会在执行到一半时发现未知项；有时会发现，这些未知项指向一个残酷的事实：你其实应该换一条完全不同的路径来解决问题。

说白了，与Fable协作，本质上是实现前、实现中和实现后，不断发现未知项的迭代过程。

那问题来了：明明现在的模型能力已经进化到如此强大的地步了，为什么我们在使用模型的时候，依旧感觉它做不对任务？

这里有个让人豁然开朗的答案：

也就是你提供的提示词、Skill、上下文，与实际任务执行之间的落差。下面这本“屠龙技”，教的正是如何打破这种信息差。

了解你的未知项

当带着一个问题来找Claude时，通常会从四个角度把它拆解开：

——这就是写在提示词里的内容。告诉智能体，你想要什么。

——哪些事情你还没弄清楚，但知道自己没弄清楚？

——哪些东西对你来说太显而易见了，以至于压根儿不会写下来，但一看到就能认出来？

——有没有哪些事是你完全没有考虑过的？还有什么知识是你不知道自己不知道的？

最出色的“智能体式”程序员，往往拥有相对更少的“未知项”——他们很清楚自己要什么，细节也给的足够充分，和代码库、模型行为都保持高度同步。但他们也会预设未知项的存在。从某种意义上说，

。还好，这是一项可以不断打磨的技能。

帮助Claude以帮助你自己

给Claude下指令，是一门微妙的平衡艺术。如果指令过于具体，即使转向另一个方案更合适，模型也会严格按照你的指令走。如果指令过于模糊，模型通常会基于行业最佳实践做出假设，但这些选择不一定适合你的具体任务。

当没有充分考虑自己的未知项时，两种情况都会翻车。因为你不知道前方道路何时会布满障碍，也不知道什么时候其实很顺畅，但你仍希望Claude能在必要时灵活调整。

模型本身能帮助你更快发现未知项。它可以极快搜索你的代码库和互联网，而且在大多数主题上掌握的通用知识比你更多。它也更能从失败中快速迭代。

这个过程中最重要的一点，是给Claude足够的起点上下文。比如，告诉它你目前思考到哪一步了；说明你对这个问题和代码库的熟悉程度；让它像一个思考伙伴一样与你协作。

我之前专门聊过如何用Claude生成HTML。在几乎所有这些场景中，HTML工件都是最适合用来可视化和表达想法的方式。下面，我会详细介绍一些用来发现这些未知项的模式。并不见得每次都把所有技巧用上，但把它们作为一套可调用的方法储备起来，非常有用。

实现前

盲点扫描

开始工作时，最有用的事情之一，就是摸清自己的盲点。比如，你正在代码库的一个新模块里编写功能，或者让Claude帮你处理某种不熟悉的工作——比如迭代一个设计方案——那么你很可能有大量“未知的未知”。

你可能不知道该问什么，不知道什么才算好，不知道过去已经做过哪些历史工作，也不知道有哪些坑应该避开。要做到这一点，可以直截了当地让Claude帮你找出“未知的未知”，并向你解释。直接使用“blindspot pass”和“unknown unknowns”这些字眼。通常来说，告诉它你是谁、你知道什么，也很重要。

示例提示词：

「我正在添加一个新的身份认证提供方，但我对这个代码库里的认证模块一无所知。你能不能做一次 blindspot pass，帮我找出相关的 unknown unknowns，并帮助我更好地给你写提示词？」

「我不了解调色，但我需要给这个视频做调色。你能不能教我理解自己在调色方面的 unknown unknowns，这样我就能写出更好的提示词？」

头脑风暴与原型

当我在一个有很多“未知的已知”的领域工作时——也就是那些只有看到之后才知道如何定义标准的事情——我会让Claude和我一起头脑风暴、做原型。

在原型阶段尽早识别并表达这些“未知的已知”，性价比极高。因为如果到了实现阶段才发现它们，代价往往更高。功能或规格中的小变化，可能会导致代码实现发生巨大差异，而且让智能体回退之前的修改也更困难。

一个例子：你可能只是想看看在某个框架里加一个按钮是什么效果，但并不想真正接入后端路由，也不想在前端维护额外状态。

视觉设计对我来说就是一种很难清楚表达的东西，但只要看到了就知道自己想要什么。这种情况下，我会要求Claude针对一个工件给出几种不同的设计方向。

几乎每次编码会话一开始，我都会先进行探索或头脑风暴。这能帮助我带着明确意图来定义项目范围。Claude经常会发现一些我本来会错过的高价值方案，但有时也会只见树木不见森林。头脑风暴可以防止我一开始就把范围设得过窄或过宽。

示例提示词：

「我想为这组数据做一个仪表盘，但我没有什么视觉品味，也不知道可以做到什么程度。帮我做一个 HTML 页面，给出 4 种风格差异很大的设计方向，好让我根据结果做反馈。」

「在真正接线之前，先用假数据做一个单独的 HTML 文件，模拟新的编辑器工具栏。我想先对布局做反馈，然后你再去动真实应用。」

「这是我的粗略问题：用户在完成 onboarding 后流失。搜索代码库，头脑风暴 10 个我们可以介入的地方，从最低成本到最有野心的方案都列出来。我会告诉你哪些方向更有感觉。」

反问

在完成了足够的头脑风暴之后，通常仍然会有未知项。这种情况下，我会让Claude围绕任何不明确或存在歧义的地方来采访我。让Claude采访你时，尽量提供关于问题的上下文，以便它提出更有针对性的问题。

示例提示词：

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

参考资料

有时候，你无法详细描述自己想要什么。可能你没有对应的表达语言，或者这件事太复杂，完整描述会花很长时间。这种情况下，最好的答案就是提供参考资料。

图表、文档或图片都可以，但最好的参考资料其实是源代码。如果你有一个库用某种特定方式实现了某个功能，或者有一个你非常喜欢的设计组件，直接指引模型指向对应文件夹，并告诉它该看什么。即使参考代码是另一种语言写的，也没有关系。

这也是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 剪辑完成的。这对我来说是一个全新的领域，而我绝不是这方面的专家。所以我从自己已知的部分开始。我知道 Claude 可以用代码来编辑视频并进行转录，但我不确定它的准确度是否足够。于是我让 Claude 向我解释 Whisper 这类转录技术是如何工作的，以及我是否能够用 ffmpeg 准确剪掉“嗯”这样的语气词或较长的停顿。

我希望 Claude 创建一个 UI，并让它与我说出的词语在时间上同步，但我不确定它是否能做到。于是我让 Claude 使用 Remotion 和转录文本创建一个视频原型，看看这个想法是否可行。

最后，视频本身看起来有些灰暗。我知道这是调色问题，但我并不真正了解什么是调色。我第一次尝试时，是想让 Claude 做几个版本让我来选，但我意识到，当涉及调色时，我并不知道什么才算“好”。于是，我没有继续让它盲目生成版本，而是让 Claude 教我调色，以此发现自己的未知项。

让地图与疆域匹配

当一个长周期任务返回了错误结果时，很可能说明你需要花更多时间定义自己的未知项，或者创建一份实现计划，让Claude能够在这些未知项中灵活应对。

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

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