原文：A field guide to Claude Fable 5: Finding your unknowns。作者是 Anthropic 的 Thariq Shihipar。本文为中文译写/摘要版，图片来自原文。
作者说，与 Claude Code 协作时，他常常会想到“地图”和“真实地形”之间的区别：提示词、技能和上下文是地图；真正要改动的代码库、现实约束和具体工作环境才是“真实地形”。两者之间的差距，就是所谓的“未知”。
Claude 遇到一个未知项时，会按照它对用户意图的最佳猜测来做决定。任务越长、越复杂，未知就越多。作者认为，Claude Fable 是第一个的模型：让他清晰感觉到“工作质量的瓶颈不再主要取决于模型能力本身，而是取决于能否把这些未知项澄清清楚”。
重要的是，提前规划并不总是足够。你可能会在深入实现的过程中才发现未知项；也可能发现，某些未知项其实指向一个更根本的问题：你原本就不该用当前这种方式来解决它。
作者发现，和 Fable 一起工作，本质上是一个在实现前、实现中、实现后不断发现并澄清未知项的迭代过程。
在这里做了一些示例材料，用来帮助发现未知项。不过，最好还是回过头来继续建立一种判断力：什么时候该使用它们，什么时候不该使用。
1. 了解你的未知
你的未知项是什么？当我带着一个问题来找 Claude 时，我通常会从四个维度来拆解它
已知的已知：这基本上就是我写在提示词里的内容。也就是，我明确告诉 agent 我想要什么。已知的未知：有哪些东西我还没有想清楚，但我知道自己还没想清楚？未知的已知：有哪些东西对我来说太显而易见，以至于我根本不会写下来，但只要看到结果，我就能立刻判断它对不对？未知的未知：有哪些东西是我完全没有考虑到的？有哪些知识是我甚至不知道自己不知道的？我是否知道一件事最好可以做到什么程度？
最优秀的 agentic coder，通常未知项会比较少。看 Boris 或 Jarred 这类人写提示词时，我很明显能感觉到，他们非常清楚自己想要什么，而且细节很具体。他们既和代码库保持高度同步，也很了解模型的行为模式。
但他们也会预设未知项的存在。
从很多方面来说，减少未知项，并提前为未知项做好规划，正是 agentic coding 的核心能力。幸运的是，这是一项可以通过和 Claude 协作不断提升的技能。
2. 帮 Claude 更好地帮你
给 Claude 下指令，是一件需要拿捏分寸的事。如果你说得太具体，Claude 就会严格按照你的指令执行，即使中途其实更适合换一种思路。如果你说得太模糊，Claude 又常常会基于行业最佳实践来做选择和假设，而这些做法未必适合你当前的任务。
当你没有把未知项考虑进去时，这两种问题都会发生。你不知道什么时候前路会充满障碍，也不知道什么时候路其实是通的，但你仍然希望 Claude 能够主动转向。
Claude 可以帮你更快地发现未知项。它能非常快速地搜索你的代码库和互联网，而且在大多数普通主题上，它知道的东西比你更多。它也能更快地从失败中迭代。
这个过程中最重要的一点，是告诉 Claude 你当前的起点。比如，告诉它你现在思考到哪一步了；说明你对这个问题和代码库的熟悉程度；让它像一个思考伙伴一样和你一起推进。
在这篇文章里，我会详细介绍一些我用来发现这些未知项的模式，包括：
3. 实现前
3.1 盲点检查
在开始工作时，最有用的事情之一，就是先弄清楚自己的盲点。比如，如果你要在代码库中一个全新的部分开发功能，或者让 Claude 帮你处理一些不熟悉的工作，比如反复调整一个设计方案，那么你很可能会遇到大量“未知的未知项”。
你可能不知道该问什么问题，不知道什么样的结果才算好，也不知道过去已经做过哪些相关工作，或者有哪些坑需要避开。
要做到这一点，你可以让 Claude 帮你找出这些“未知的未知项”，并向你解释清楚。我自己喜欢直接使用 “blindspot pass” 和 “unknown unknowns” 这两个字眼。同时，告诉 Claude 你是谁、你已经知道什么，通常也很重要，因为这能帮助它更准确地判断你的盲点在哪里。
可用的提示思路：
“我正在添加一个新的认证提供方，但我完全不了解这个代码库里的认证模块。你能不能帮我做一次盲点扫描，找出和这个任务相关的未知未知项，并帮我更好地向你提问？”
“我不知道什么是色彩分级，但我现在需要给这个视频调色。你能不能教我理解自己在色彩分级方面有哪些未知的未知项，这样我就能更好地向你提问？”
3.2 头脑风暴与原型
当我在一个包含大量未知的已知项的领域工作时，也就是那些只有看到结果后我才知道该如何定义标准的情况，我喜欢让 Claude 和我一起头脑风暴、做原型。
在原型阶段尽早识别并说清楚这些未知的已知项非常有价值，因为如果等到真正实现时才发现它们，代价往往会相对更高。功能或规格上的一个小改动，可能会导致代码实现方式发生巨大变化，而且智能体要回滚之前的修改也可能更困难。
比如，你可能只是想先看看在某个框架里加一个按钮是什么效果，而不想真的去接后端路由，或者在前端维护额外的状态。
视觉设计对我来说就是一种很难用语言提前说清楚的东西，但我一看到结果，就知道自己想不想要。在这种情况下，我会让 Claude 针对一个产物给出几种不同的设计方案。
我几乎也会在每一次编码会话开始时，先进行一轮探索或头脑风暴。这能帮助我带着明确意图开始，并定义项目范围。Claude 经常能找到一些我原本会错过的高价值方案，但有时也会只见树木、不见森林。头脑风暴能避免我把范围定得太窄，或者铺得太宽。
示例提示词：
“我想为这些数据做一个仪表盘，但我没有什么视觉品味，也不知道有哪些可能性。请做一个 HTML 页面，给我 4 种风格差异很大的设计方向，让我可以根据它们做出反馈。”
“在真正接入任何逻辑之前，请先用假数据做一个单独的 HTML 文件，模拟新的编辑器工具栏。我想先看看布局效果，再让你改真实应用。”
“这是我目前粗略的问题：用户在完成 onboarding 后流失了。请搜索代码库，并头脑风暴 10 个我们可以介入的地方，从成本最低的方案到最有野心的方案都列出来。然后我会告诉你哪些方向更有感觉。”
3.3 访谈
当我完成了充分的头脑风暴之后，通常仍然会有一些未知项。
在这种情况下，我会让 Claude 围绕这些未知项或模糊之处来“采访”我。让 Claude 采访你时，尽量给它一些关于问题的背景信息，用来引导它提出更有价值的问题。下面是一些例子。
示例提示词：
- “请一次只问我一个问题，围绕所有不明确的地方来采访我。优先问那些我的回答会影响架构选择的问题。”
3.4 参考资料
有时候，你无法非常具体地描述自己想要什么。比如，你可能还没有掌握对应的表达方式，或者这件事本身太复杂，如果完整描述出来会花很长时间。
在这种情况下，最好的答案就是给参考资料。你可以提供图表、文档或图片，但最好的参考资料一定是源代码。
如果你有一个库，它用某种方式实现了你想要的东西；或者你特别喜欢某个设计组件，那就直接把 Fable 指向对应的文件夹，并告诉它应该关注什么。哪怕那个实现是用另一种语言写的，也没关系。
Claude Design 的工作方式也是如此。你不一定非要给它上传文件，当然也可以这么做。你可以把它指向某个你喜欢的网站模块，它会读取底层代码，而不只是看截图。这样能提供更丰富的细节，包括标记结构、整体组织方式，以及这个组件到底是如何被构建出来的。
示例提示词：
- “
vendor/rate-limiter里的这个 Rust crate 实现的退避行为，正是我想要的效果。请阅读它，并在我们的 TypeScript API 客户端中重新实现相同的语义。”
3.5 实现计划
当我觉得自己已经准备好开始实现时，我通常会让 Claude 先整理一份实现计划，供我审阅。这份计划会重点关注那些最可能发生变化的部分，比如数据模型、类型接口或用户体验流程。这样 Claude 就能把一些我可能确实需要调整的地方提前暴露出来。
示例提示词：
“请用 HTML 写一份实现计划，但开头先列出那些我最可能想调整的决策：数据模型变更、新的类型接口，以及所有面向用户的内容。把机械性的重构放到最下面就行，那部分我相信你能处理好。”
4. 实现中
4.1 实现笔记
一旦我对计划满意了，我会开启一个新的会话，并把相关产物一并放进提示词里。比如，我可能会提供一个规格说明文件和一个原型，然后让智能体根据它们来实现。
但事实是，无论你做了多少规划，总会有一些“未知的未知项”潜伏在那里。智能体在工作过程中可能会发现，由于代码里某个边界情况的存在，它需要换一种处理方式。
我会让 Claude Code 维护一个临时的 implementation-notes.md 文件，或者 .html 文件，用来记录它在实现过程中做出的决策，这样我们就能从下一次尝试中继续学习。
示例提示词：
“请维护一个 implementation-notes.md 文件。如果你遇到某个边界情况，导致你不得不偏离原计划，请选择更保守的方案，把它记录在 ‘Deviations’ 下面，然后继续推进。”
5. 实现后
5.1 推介和解释材料
发布一个东西时，最重要的环节之一，就是获得他人的认同和批准。在最终文档中准备好推介材料和解释材料，会很有帮助：
当审阅者一开始也和你有相同的未知项时，这能帮助他们更快理解。
当专家想确认你是否已经考虑到他们原本会预见的未知项和常见失败点时，这能加快审批过程。
示例提示词：
- “请把原型、规格说明和实现笔记打包成一份文档，我可以直接发到 Slack 里用来争取支持。开头先放演示 GIF。”
5.2 测验
在一次很长的工作会话之后，Claude 可能已经完成了比我意识到的更多的事情。只看代码 diff，往往只能让我对发生了什么有一个很浅的理解，因为很多行为都依赖于现有的代码路径。
让 Claude 在给我大量上下文之后，再围绕这次变更来考我，可以帮助我真正理解发生了什么。只有当我能完美通过这个测验时，我才会合并代码。
示例提示词：
“我想确认自己完全理解了这次变更中发生的一切。请给我一份 HTML 报告，帮助我阅读和理解这些变更，包括相关上下文、直觉解释、具体做了什么等等，并在底部附上一组关于这些变更的测验，我必须通过之后才能合并。”
6. 案例：发布 Fable
Fable 的发布视频完全是由 Claude Code 剪辑完成的。对我来说，这是一个全新的领域，而我也完全不是这方面的专家。
所以我先从自己已知的部分开始。我知道 Claude 可以通过代码来剪辑视频、转录视频内容，但我不确定它是否足够准确。于是我让 Claude 向我解释 Whisper 这类转录工具是如何工作的，以及我是否能够用 ffmpeg 准确地剪掉类似“嗯”“啊”这样的口头填充词，或者较长的停顿。
我希望 Claude 创建一个 UI，并让这个 UI 和我说话的内容在时间上对齐。但我不确定它能不能做到，所以我让 Claude 使用 Remotion 和转录文本创建一个原型视频，看看这个方案是否可行。
最后，视频本身看起来有些灰、缺少层次。我知道这和调色有关，但我其实并不了解什么是调色。我的第一反应是让 Claude 做几个不同版本，然后由我来挑选。但后来我意识到，在调色这件事上，我并不知道什么样才算“好”。所以，我转而让 Claude 教我关于调色的知识，帮助我发现自己的未知项。
你可以在这里观看更深入的解释。
7. 让地图与真实地形相匹配
模型越强，你用正确方法所能完成的事情就越多。当一个长期任务最终产出的结果不对时，很可能说明你需要花更多时间去定义自己的未知项，或者创建一份实现计划，让 Claude 能够在遇到这些未知项时进行合理的即兴调整。
每一份解释材料、每一次头脑风暴、每一轮访谈、每一个原型、每一个参考样例，都是一种低成本方式，帮助你在问题变得昂贵之前，先发现自己原本不知道的东西。
所以，在开始下一个项目时，不妨先让 Claude 帮你找出你的未知项。