Claude Fable 5 官方使用指北：真正会用 AI 编程的人，都要找到自己的「未知」
公众号名称：程叙架构与AI.
作者名称：AI兴观点
发布时间：2026-07-04 20:30
原文链接：https://x.com/trq212/status/2073100352921215386
✅点击上方🔺公众号🔺关注我✅
Fable 5 是 Claude 目前最强模型，但 Claude Code 团队成员 Thariq 和你我一样，每天跟它打交道时最深的感受不是「太强了」，而是「我也不知道怎么让它更强」。
他最近发了一篇长文，分享了他和 Fable 5 合作半年后的心得。不是教你写提示词，不是分享工具，而是一套关于 「未知」的框架。
这篇文章没有废话。
看完你会发现：好的 AI 编程者和普通人的差距，不在技术深度，而在 搞清楚自己不知道什么。
地图不等于疆域
这是 Thariq 整篇文章的起点。
地图（Map）是你给 Claude 的提示词、技能、上下文——你告诉它的一切。
疆域（Territory）是真正需要完成的工作——代码库、真实世界、实际约束。
地图和疆域之间的差距，就是所谓的 未知数（Unknowns）。
当 Claude 遇到未知数，它必须基于对你意图的「最佳猜测」做决策。你做的工作越多，Claude 遇到的未知数就越多。
Fable 5 是第一个让 Thariq 觉得「工作质量的瓶颈，是我自己澄清未知数的能力」的模型。
重要的是：光是提前计划远远不够。你会在实现深处发现未知数，或者未知数会告诉你——你其实应该换个方式解决这个问题。
Thariq 的经验是：和 Fable 一起工作是在实现前、实现中、实现后持续发现未知数的迭代过程。
他还做了一套示例工具来找这些未知数，但我们先建立直觉——什么时候该用它们。
你的未知数，分四种
每次跟 Claude 说一个问题，Thariq 会把它分解成 4 种类型：
| 类型 | 含义 | 对应什么 |
|---|---|---|
| 已知的已知（Known Knowns） | 你写进提示词的东西 | 你明确告诉 AI 要什么 |
| 已知的未知（Known Unknowns） | 你没想清楚、但知道自己没想清楚的部分 | 「这块我不确定」 |
| 未知的已知（Unknown Knowns） | 太理所当然以至于你永远不会写下来，但见到就能认出来 | 「看见就懂了」 |
| 未知的未知（Unknown Unknowns） | 你完全没考虑过的角度、知识盲区 | 「不知道竟然有这种解法」 |
最优秀的 AI 编程者，他们的特点是 未知数相对较少。看 Boris 或 Jarred 写提示词，你能明显感觉到他们极其清楚自己要什么——对代码库和模型行为都深度理解。
但他们也假设自己有未知数。
在某种意义上，减少和规划你的未知数，就是 AI 编程的核心技能。 而且好在——和 Claude 一起工作本身就是练习这件事。
让 Claude 真正帮到你
给 Claude 下指令是一个微妙的平衡：
- 太具体 → Claude 会严格执行你的指令，哪怕转弯可能更合适。
- 太模糊 → Claude 会按行业最佳实践做默认选择，但可能不适合你的场景。
当你没有充分考虑自己的未知数时，两项全输。
Claude 能帮你更快发现未知数。它能极其快速地搜索你的代码库和互联网，远比你对大多数主题了解得多。它也能更快地从失败中迭代。
这个过程最重要的一步是：给 Claude 你的起点上下文。 比如告诉他你在思考过程的哪个阶段、你对该问题和代码库的经验水平、让他像一个思考伙伴一样和你合作。
Thariq 之前还写过用 HTML 和 Claude 工作的文章——在几乎所有情况下，HTML 都是可视化和表达未知数的最好方式。
实现前的四种武器
🎯 盲点扫描（Blind Spot Pass）——找出你不知道自己不知道的东西
开始工作的时候，最有价值的事之一就是搞清楚你的盲点。
比如你在代码库的新模块写一个功能，或者用 Claude 帮你不熟悉的工作（比如迭代设计），你很可能有大量 未知的未知——不知道要问什么问题、不知道「好」长什么样、不知道之前做过什么、不知道有哪些坑。
做法很简单：让 Claude 帮你找到你的未知未知，解释给你听。
示例提示词：
「我在加一个新的 auth 服务商，但完全不了解这个代码库里的 auth 模块。能不能帮我做一个盲点扫描，找出我的相关未知未知，帮我更好地向你提问？」
「我不知道什么是调色，但我需要调这个视频。教我理解我在调色上的未知未知，这样我就能更好地提问了。」
🧠 头脑风暴和原型（Brainstorms & Prototypes）——发现你的未知已知
当你面对大量 未知的已知——那些你只有看到才能定义的判断标准——最好的方式就是让 Claude 和你一起头脑风暴和做原型。
在原型阶段尽早发现和表述未知的已知，比在实现阶段发现要便宜得多。一个功能或规格的小改动，可能会导致完全不同的实现方式，让 AI 回退之前的代码也会更难。
比如你只是想看看一个按钮放在某个框架里好不好看，不需要真的接上后端路由或维护前端状态。
Thariq 几乎每次编码会话都从探索或头脑风暴阶段开始。Claude 经常会找到他本会错过的高价值方案，有时也会只见树木不见森林。
示例提示词：
「我为这些数据想做仪表盘，但我没有视觉品味，也不知道有什么可能性。给我做一个 HTML 页面，包含四种截然不同的设计方向，让我来选择。」
「在接任何东西之前，先用假数据做一个单独的 HTML 文件，模拟新的编辑器工具栏。我想在你碰真实应用之前先对布局做出反应。」
「这是我的粗略问题：用户在做完 onboarding 后流失了。搜索代码库，头脑风暴 10 个我们可以干预的地方，从最便宜到最大胆排序。我会告诉你哪些让我有感觉。」
💬 访谈模式（Interviews）——让 Claude 问你问题
做完足够的头脑风暴之后，你很可能仍然有未知。
这时候，让 Claude 来采访你——它会针对任何不清楚的地方追问你。关键是要给它足够的问题上下文，让它能问出好问题。
Thariq 的做法：让 Claude 一个一个地问，优先那些回答会改变架构方向的问题。
示例提示词：
「一个一个地问我，针对任何模糊之处提问。优先问那些我的回答会改变架构的问题。」
这个步骤的价值在于：你不需要自己去想「我不知道什么」，让 Claude 帮你挖掘出来。
📎 参考驱动（References）——当你无法描述时，指给它看
有时候你就是没办法详细描述你想要什么——可能你缺少对应的术语，也可能事情复杂到要说很久。
最好的答案就是给一个参考。
你可以用图表、文档或图片，但最好的参考是源代码。如果你有一个库以某种方式实现了某个功能，或者有一个你特别喜欢的设计组件，直接把 Fable 指向那个文件夹，告诉它要关注什么——哪怕用的是不同的编程语言。
这也是 Claude Design 的工作方式。你不需要给它一个文件（当然你也可以那样做）。你可以指向一个你喜欢的网站上的模块，它会去读底层代码，而不仅仅是截图。
示例提示词：
「vendor/rate-limiter 里这个 Rust crate 实现了我想要的退避行为。读它，然后用同样的语义在我们的 TypeScript API 客户端里重新实现。」
实施计划：在动手前暴露可能的变化
当 Thariq 觉得准备充分了，他会让 Claude 整理一份实施计划，重点关注那些最可能发生变化的部分——数据模型、类型接口、UX 流程。
这能让 Claude 把那些他可能真正需要调整的东西推到表面，而不是在代码写完之后才发现。
示例提示词：
「用 HTML 写一份实施计划，但把那些我最可能调整的决策放在前面：数据模型变化、新的类型接口、任何面向用户的东西。把机械性的重构埋在底部，那部分我信得过你。」
实施笔记：捕捉过程中的未知未知
计划满意后，开一个新的会话，把相关的 artifact 传进去（比如一份 spec 文件和一个原型），让 agent 去实现。
但不管计划得多周全，总会有未知的未知潜伏着。Agent 可能在工作中发现，由于在代码里遇到了某个边缘情况，需要采取不同的策略。
Thariq 让 Claude Code 维护一个临时的 implementation-notes.md（或 .html）文件，记录过程中做的决策，这样可以从下一次尝试中学习。
示例提示词：
「维护一个 implementation-notes.md 文件。如果你遇到一个边缘情况迫使你偏离计划，选择保守方案，记录在 ‘Deviations’ 下，然后继续。」
交付物打包：加速认同与审批
把东西真正交付出去，最重要的一部分是获得认可和批准。
在最终的文档中构建展示和说明性的 artifact 有两个作用：
- 加速理解：审阅者和你出发点一样，有相同的未知数
- 加速审批：专家想看到你已经考虑了那些他们会预见的未知和常见失败点
示例提示词：
「把原型、spec 和实施笔记打包成一份文档，我可以直接丢进 Slack 获得认可。用 demo GIF 开头。」
事后测验：确保自己真正理解了变更
经过一个漫长的协作会话，Claude 可能完成了比你意识到的多得多的东西。光读代码 diff 只能让你对发生了什么有一个浅层理解。
让 Claude 在给你一堆上下文之后考你关于改动的问题。只有完美通过测验才合并代码。
示例提示词：
「我想确保我完全理解这次改动发生了什么。给我一个 HTML 报告，包括上下文、直觉、做了什么等，最后加一个我必须通过的小测验。」
真实案例：Fable 发布视频背后的故事
这套框架不是纸上谈兵——Fable 5 的发布视频本身就是 Thariq 用这套方法做出来的。
Fable 的发布视频完全由 Claude Code 剪辑完成。这是他完全不熟悉的领域。
第一步：从知道的东西开始。 他知道 Claude 可以用代码编辑视频和转录，但不确定精确度够不够。于是让 Claude 解释 Whisper 这类转录的工作原理，以及能否用 ffmpeg 精确剪掉「嗯」和长时间停顿。
第二步：试原型。 他想让 Claude 创建一个与语音同步的 UI，但不确定能否做到，所以让 Claude 用 Remotion 和转录数据做一个原型视频看看是否可行。
第三步：承认自己不知道。 视频本身色调有点发灰。他知道这和调色有关，但其实不知道调色到底是什么。他的第一反应是让 Claude 做几个变体让他选——但他意识到：他根本不知道调色的「好」是什么样。 于是他转而让 Claude 教他调色，来发现自己的未知。
这个案例完美展示了整套框架的实际运行：从已知出发 → 试原型 → 发现自己不知道 → 让 AI 帮你搞懂 → 继续推进。
让地图和疆域匹配
模型越好，你就能用正确的方法做到越多。
当一个长周期任务回来结果是错的，很可能你需要多花时间定义你的未知数，或者创造一个让 Claude 能在其中即兴发挥的实施计划。
每一个解释、头脑风暴、访谈、原型、参考——都是在修复变得昂贵之前，低成本找出你不知道的东西的方式。
所以下次开始一个新项目时，先让 Claude 帮你找到你的未知数。
你的工具箱里，目前最缺的是哪一种——已知的已知？已知的未知？未知的已知？还是未知的未知？
别急着回答——好好想想。
如果觉得这篇文章有帮助，欢迎点赞、在看、转发！有问题也可以在评论区留言，我会尽量回复！
内容效果不满意？点此反馈