本页目录7
- 用「地图（提示词/上下文）vs 领地（真实代码库/约束）」比喻说明：两者差距就是未知数，决定了 Claude 输出质量的上限
- 未知数分四类：known knowns、known unknowns、unknown knowns、unknown unknowns，后两类最容易被忽视
- 实施前可用 blind spot pass、头脑风暴/原型、逐题访谈、给源码做参考、写实施计划等方式提前暴露未知数
- 实施中让 Claude 维护 implementation-notes.md，记录偏离计划的决策和保守选择的理由
- 实施后可让 Claude 生成 pitch/说明文档和「必须通过的测验」，加快审查者理解和评审通过速度
- 核心原则是把 Claude 当思想合作伙伴：既不过度具体束缚它，也不过度模糊放任它套用通用最佳实践
本文是对官方文章「A field guide to Claude Fable 5: Finding your unknowns」的中文要点摘要，完整内容以原文为准：https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns
地图与领地：未知数从哪来
文章开篇用一个经典比喻切入：你给 Claude 的提示词、技能、上下文相当于一张「地图」，而实际的代码库、真实约束是「领地」。地图和领地之间总会有落差，这个落差就是所谓的「未知数（unknowns）」。作者（Anthropic 员工 Thariq Shihipar）提出一个核心判断：Claude 输出的质量上限，取决于「我澄清这些未知数的能力」，而不是模型本身的能力上限。也就是说，与 Claude Code 协作的关键技能之一，是学会主动暴露和消解未知数，而不是被动等模型「猜对」你的意图。
四类未知数框架
文章借用一个经典的知识分类矩阵，把未知数分成四类：
| 类别 | 含义 | 典型场景 |
|---|---|---|
| Known Knowns | 已知且已在提示词中说清楚 | 你写在 prompt 里的明确要求 |
| Known Unknowns | 你知道自己不懂，但还没解决 | 「我不了解这个 auth 模块」 |
| Unknown Knowns | 对你/代码库显而易见，但没写出来的隐含约定 | 代码风格、架构惯例 |
| Unknown Unknowns | 你压根没想到要考虑的领域 | 一个你从未意识到的边界情况 |
后两类是最容易被忽视、也是最容易在实施过程中带来返工成本的部分。整篇文章的方法论，基本上就是围绕如何把这四类未知数尽早显性化展开。
实施前：把未知数提前暴露出来
Blind Spot Pass（盲点通过）：直接让 Claude 帮你找 unknown unknowns。提示词示例：「我在处理新的身份认证提供者，但对代码库中的 auth 模块一无所知，能做一次 blind spot pass 吗？」关键是要在提示词里明确用「blind spot pass」「unknown unknowns」这类字眼，触发 Claude 做系统性排查而不是直接开始写代码。
头脑风暴与原型（Brainstorms and prototypes）：用来在 unknown knowns 领域尽早对齐标准，把实施中才会暴露的高成本分歧提前解决。例如：「我想要一个数据仪表盘但没有视觉品味，做 4 个完全不同设计方向的 HTML 页面让我挑」；或者「在连接任何真实逻辑之前，先用假数据做一个单文件 HTML 原型模拟新的编辑工具栏」。
访谈（Interviews）：头脑风暴之后仍然模糊的地方，可以让 Claude 反过来逐条追问你。示例提示词：「一次一个问题地采访我关于任何歧义，优先问那些答案会改变架构的问题。」
参考资料（References）：当某个行为很难用语言描述清楚时，给 Claude 源码而不是截图或口头描述效果更好。例如：「这个 Rust crate 在 vendor/rate-limiter 里实现了我想要的退避行为，读完之后在 TypeScript 客户端里重新实现相同语义。」
实施计划（Implementation Plans）：编码前先对齐理解，重点放在数据模型、类型接口、UX 流程这些「你最可能会调整」的决策上，把纯机械性重构放到文档底部，避免审查精力被稀释。
实施中：用笔记记录偏离
作者建议在新会话里让 Claude 维护一个临时文件，比如 implementation-notes.md，专门记录实施过程中遇到的边界情况、偏离原计划的决策、以及选择保守方案的理由。示例提示词：「保持一个 implementation-notes.md 文件，如果你遇到迫使你偏离计划的边界情况，选择保守选项，在 Deviations 下记录，然后继续推进。」这样做的好处是，后续复盘或交给别人审查时，决策依据是可追溯的，而不是散落在多轮对话里。
实施后：让评审者少走弯路
宣传与说明文档（Pitches and Explainers）：把原型、规格文档、implementation notes 打包成一份可以直接发到 Slack 里的文档，以演示 GIF 开头。这样审查者能从和你相同的未知数起点开始理解改动，专家也能更快看到你是否考虑到了他们预期会关心的问题，从而加快批准速度。
测验（Quizzes）：为了确保团队成员真正理解某次变更，可以让 Claude 生成一份 HTML 报告，附带阅读材料和一个「必须通过才能合并」的小测验。这是一种把「理解变更」这件事显性化、可验证化的做法。
案例：剪一支发布视频
文章用作者本人给 Fable 5 发布视频做剪辑的经历做示例，串联了上述方法：前期确认转录准确性和 ffmpeg 能力边界；用 Remotion 和转录文本做原型，搭建时间轴同步的 UI；做色彩分级时发现自己不知道「好」的标准是什么，于是要求 Claude 先教学再动手，通过多个变体反复比较，逐步建立起自己的判断标准。这个案例说明：未知数框架不只适用于写代码，也适用于任何依赖 Claude Code 完成的复杂创作任务。
核心原则：把 Claude 当思想合作伙伴
文章最后强调一个平衡点：指令过于具体，Claude 会盲目照做，即使中途该改方向也不会主动提出；指令过于模糊，Claude 只能依赖通用最佳实践去猜，未必贴合你的实际场景。更好的做法是把 Claude 当作思想合作伙伴——告诉它你当前的思考进展到哪一步、你对这个问题和代码库已有的经验判断是什么，同时留出让它能灵活发挥的空间，而不是给一份「执行清单」。