与 Claude Fable 5 协作，不断印证一个古老道理：地图并非疆域本身。所谓“地图”，是我们交给 Claude 的提示词、技能与上下文，是对待完成工作的一种表征；而“疆域”，则是真正需要工作发生的地方——代码库、现实世界及其真实的约束条件。
地图与疆域之间的差距，根源在于“未知项”。当 Claude 遭遇未知项时，它只能基于对用户意图的最佳推测来做出决策。任务越是复杂，潜在的未知项也就越多。Fable 是第一个让人清晰感受到，工作质量的瓶颈取决于澄清未知项能力的模型。
关键在于，仅靠提前规划并不总能奏效。你可能会在实现过程中发现未知项，也可能发现这些未知项指向一个事实：你本应采用完全不同的解决思路。从实践经验看，与 Fable 协作本质上是一个持续发现未知项的迭代过程——发生在实现前、实现中与实现后。
所谓“地图”，是对待完成工作的表征，也就是我交给 Claude 的提示词、技能和上下文。所谓“疆域”，则是真正需要工作发生的地方：代码库、现实世界及其真实的约束条件。
将地图与疆域之间的差距称为“未知项”。当 Claude 遇到未知项时，它必须根据对用户意图的最佳猜测来做决定。任务越复杂，Claude 可能遇到的未知项就越多。Fable 是第一个让我明显感受到工作质量瓶颈取决于我澄清未知项能力的模型。重要的是，仅靠提前规划并不总能奏效。你可能会在实现深处发现未知项，也可能发现这些未知项指向一个事实：你本应采用完全不同的解决思路。我发现，与 Fable 协作本质上是一个在实现前、实现中与实现后持续发现未知项的迭代过程。作者提供了一些发现未知项的示例，与全文一同查看效果更佳。
了解你的未知项
什么是未知项？当带着问题来找 Claude 时，可以从四个维度拆解：
- 已知的已知：写入提示词的内容——告诉了智能体你想要什么。
- 已知的未知：自己清楚尚未弄明白的事情。
- 未知的已知：对自己而言显而易见、根本不会写下来，但一旦看到就能辨认出来的东西。
- 未知的未知：完全没有考虑过的事情——不知道一件事可做到多好，也不知道自己不知道什么。
最优秀的智能体式程序员往往拥有相对更少的未知项。他们清晰了解自己的目标，细节充分，与代码库及模型行为保持高度同步。同时，他们也会预设未知项的存在——从很多意义上说，减少并提前规划未知项，正是智能体式编程的核心能力。幸运的是，这是一项可以通过与 Claude 协作不断提升的技能。
帮助 Claude 以帮助你自己
向 Claude 下达指令是一门微妙的平衡艺术。过于具体，即使转向其他方案可能更合适，Claude 也会严格照办；过于模糊，Claude 会基于行业最佳实践做出选择和假设，但这些不一定匹配你的任务。当没有充分考虑自身未知项时，两种情况都会失败——你不知道前方道路何时会布满障碍，也不知道何时道路其实很顺畅，但你仍希望 Claude 能在必要时做出调整。
Claude 可以帮助你更快发现未知项。它能够极快地搜索代码库与互联网，在大多数主题上掌握的通用知识比你更多，也能更快地从失败中迭代。这一过程中最关键的是，给 Claude 提供足够的起点上下文。例如，告诉它你目前思考到哪一步，说明你对问题和代码库的熟悉程度，让它像一位思考伙伴一样与你协作。正如之前讨论过的，使用 HTML 工件来可视化和表达想法，在几乎所有场景中都是最合适的方式。
下面详细梳理一些用于发现未知项的模式。不一定要每次全用，但把它们作为一组可调用的方法储备起来，会非常实用。
实现前
盲点扫描
开始工作时，最有价值的事情之一就是理解自己的盲点。例如，如果你在代码库中一个全新的模块里编写功能，或者让 Claude 协助处理某种你不熟悉的工作（比如迭代设计方案），那么你很可能有一堆“未知的未知”。你可能不知道要问什么问题，不知道什么才算好，不了解过去已经完成过哪些历史工作，也不知道有哪些坑需要避开。要实现这一点，可以让 Claude 帮你找出“未知的未知”并向你解释。直接使用“blindspot pass”和“unknown unknowns”这些关键词，通常来说，告诉它你是谁、你知道什么，也很重要。
示例提示词：
- 「我正在添加一个新的身份认证提供方，但对这个代码库里的认证模块一无所知。你能不能做一次 blindspot pass，帮我找出相关的 unknown unknowns，并帮助我更好地给你写提示词？」
- 「我不了解调色，但我需要给这个视频做调色。你能不能教我理解自己在调色方面的 unknown unknowns，这样我就能写出更好的提示词？」
头脑风暴与原型
当在一个有很多“未知的已知”的领域工作时——也就是那些只有看到之后才能知道如何定义标准的事情——可以让 Claude 一起头脑风暴、制作原型。在原型阶段尽早识别并表达这些“未知的已知”，价值非常高，因为如果到了实现阶段才发现它们，代价会相对更高。功能或规格中的微小变化，可能导致代码实现出现巨大差异，而且让智能体回退之前的修改也会更困难。例如，你可能只是想看看在某个框架里加一个按钮是什么效果，而不想真正接入后端路由，也不想在前端维护额外状态。视觉设计就属于难以清楚表达、但看到之后会知道自己想要什么的东西。在这种情况下，可以要求 Claude 针对一个工件给出几种不同的设计方向。
几乎每次编码会话一开始，先进行探索或头脑风暴，能帮助带着明确意图来定义项目范围。Claude 经常会发现一些高价值方案，但有时也会只见树木不见森林。头脑风暴可以防止一开始就把范围设得过窄或过宽。
示例提示词：
- 「我想为这组数据做一个仪表盘，但我没有什么视觉品味，也不知道可以做到什么程度。帮我做一个 HTML 页面，给出 4 种风格差异很大的设计方向，好让我根据结果做反馈。」
- 「在真正接线之前，先用假数据做一个单独的 HTML 文件，模拟新的编辑器工具栏。我想先对布局做反馈，然后你再去动真实应用。」
- 「这是我的粗略问题：用户在完成 onboarding 后流失。搜索代码库，头脑风暴 10 个我们可以介入的地方，从最低成本到最有野心的方案都列出来。我会告诉你哪些方向更有感觉。」
反问
在完成了足够的头脑风暴之后，通常仍然会有未知项。这种情况下，可以让 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 剪辑完成的。这是一个全新的领域，而我绝非这方面的专家。所以从自己已知的部分开始：我知道 Claude 可以用代码来编辑视频并进行转录，但不确定它的准确度是否足够。于是让 Claude 解释 Whisper 这类转录技术是如何工作的，以及是否能够用 ffmpeg 准确剪掉“嗯”这样的语气词或较长的停顿。我希望 Claude 创建一个 UI，并让它与说出的词语在时间上同步，但不确定能否做到。于是让 Claude 使用 Remotion 和转录文本创建一个视频原型，看看想法是否可行。最后，视频本身看起来有些灰暗，我知道是调色问题，但并不真正了解什么是调色。第一次尝试是让 Claude 做几个版本供选择，但意识到当涉及调色时，我并不清楚什么才算“好”。于是，我没有继续让它盲目生成版本，而是让 Claude 教自己调色，以此发现未知项。
让地图与疆域匹配
模型越强，就越能通过正确的方法完成更多事情。当一个长周期任务返回了错误结果时，很可能说明你需要花更多时间定义自己的未知项，或者创建一份实现计划，让 Claude 能够在这些未知项中灵活应对。每一份解释文档、头脑风暴、访谈、原型和参考资料，都是一种低成本的方法，可以在修复代价变高之前，先发现那些原本不知道的事情。所以，在启动下一个项目时，先让 Claude 帮你找到自己的未知项。