Fable 5 实战指南：知己之未知

Anthropic 发布 Fable 5 有了些时日，@Thariq 总结了一些更好使用它的经验，现将这篇文章分享出来。

Claude Fable 5 屡屡教我认清：地图纸之外，另有山河。

你交付给 Claude 的一切：prompt、skills、上下文，不过是手绘的地图。

而真实工作发生的场所：代码库的结构、工程世界的铁律、无数微妙的约束，才是寸寸都需踩过的疆域。

地图与疆域之间的那段裂隙，我称之为未知。

每当 Claude 踏入一片未知之地，它别无选择，只能依据"我大概想要什么"来决断。任务的体量越大，潜伏的未知便越多。

Fable 是第一个让我真切感受到这一点的模型：工作品质的天花板，不再取决于模型的能力，而在于我能否将自己的未知说清道明。

更重要的是，单靠提前规划远远不够。

未知会深埋在实现细节之中等你撞上，也可能你的未知本身就昭示着一件事，这条路从一开始就走错了，该换个方向。

我逐渐领悟到，与 Fable 协作的本质，是一场贯穿始终的未知发现之旅：动手之前，躬身之时，收工之后。

我整理了一些发现未知的参考范例，https://thariqs.github.io/html-effectiveness/unknowns/

但请务必回来读完这篇文章，你需要的是直觉，知道什么时候该使用哪一件工具。

你有哪些未知？

每次带着问题走向 Claude，我习惯沿四个维度，将心中的混沌拆解清楚：

已知之已知：即我写进 prompt 里的东西，我亲口告诉 agent 我要什么。

已知之未知：我尚未想透，但我心知肚明还没想透的那些事。

未知之已知：太理所当然以至于我绝不会写下来，但一看见就知道是它的东西。

未知之未知：我连想都没想过的领域。我欠缺什么知识？我甚至不知道，"好"能好到什么程度？

Image

顶尖的 agentic coding 实践者，身上的未知往往少得惊人。

看 Boris 或 Jarred 写 prompt，那种笃定感扑面而来，他们要什么，一清二楚。

他们与代码库同呼吸，与模型行为共脉搏。

但他们也在假设未知。说到底，降低未知、预判未知，就是 agentic coding 这门手艺的核心。

而令人庆幸的是，这项技能可以在与 Claude 一次次对话之中，磨练得更好。

先帮 Claude，Claude 才能帮你

给 Claude 下达指令，是一门分寸感极高的艺术。

Image

说得太死，Claude 会忠实地沿你指定的路径走到黑，即使中途明明该转向了。

说得太活，Claude 会依循行业惯例做出判断，而惯例，未必适用于你的战壕。

当你对自己的未知视而不见，两条路都会翻车：

你分辨不出何时前方荆棘密布，也辨认不了何时本该畅通无阻，但你又真切地希望 Claude 在该拐弯的时候果断拐弯。

Claude 能帮你更快地勘破未知。

它搜索代码库和互联网的速度快到你无法想象，在大多数领域的知识储备也远超于你。

更重要的是，它从失败中迭代的速度，同样快得惊人。

这整个过程中，最关键的一件事是：把你此刻的起点交给 Claude。

告诉它你思考到了哪一步，坦白你对这个问题和代码库有多少积累，让它像一位思想伙伴那样与你并肩而行。

我此前写过用 HTML 与 Claude 协作的经历，几乎在所有场景下，HTML artifact 都是将信息可视化的最优载体。

以下是我常用的未知发现工具箱。

并非每次都用得上，但有备无患。

Image

动手之前

盲区扫描

开工伊始，最有价值的一件事，是弄清你的盲区。

如果你正在代码库一个陌生的角落写功能，或是让 Claude 帮你迭代设计这种你本就不熟的事，你的未知之未知，多到你自己都想不到。

你甚至不知道该问什么问题，不知道什么叫"好"，不知道前人做过什么，更不知道哪里有坑。

此时你完全可以直截了当：让 Claude 来帮你找出你的未知之未知，然后解释给你听。

我喜欢直接就用"blindspot pass"和"unknown unknowns"这些原词。告诉它你是谁、你懂什么，这一环通常至关重要。

示例 Prompt： "我正在接入一个新的认证 provider，但对这个代码库里 auth 模块的架构一无所知。帮我做一轮盲区扫描，帮我找出那些我自己意识不到的知识盲区，好让我能更精准地写 prompt。" "我不懂什么叫调色，但我需要给这段视频校色。先教会我理解自己在调色这件事上的未知，让我有能力提出好问题。"

头脑风暴与原型

当我在未知之已知密集的领域工作，那种"看见才知道"的判断标准当道的地方，我会请 Claude 跟我一起头脑风暴，一起做原型。

在原型阶段尽早捕捉并言明你的未知之已知，极为重要。

因为等到实现阶段再撞见它们，代价可就大了。

功能和规格上的一念之差，在代码层面可能是截然不同的两条路径；而在这些路径之间让 agent 回头重来，又远比从头走一趟更艰难。

一个简单的例子：你只是想知道一个按钮放进某个框架里是什么感觉，完全没必要接上后端路由、也不需要维护任何前端状态。

视觉设计对我而言，正是一种"千言万语说不清，但一眼看去就知道"的东西。

这种时候，我会让 Claude 给同一个 artifact 出好几套风格迥异的方案。

此外，我几乎每次 coding session 都以探索或头脑风暴阶段开局。

这让我从一开始就带着明确的意图来圈定项目范围。

Claude 常常能找到我完全忽略的高价值路径，偶尔也会一头扎进树丛看不见森林。

头脑风暴恰恰能防止我把范围定得太窄——或太宽。

示例 Prompt： "我想做一个数据看板，但没什么审美，也不知道能力边界在哪儿。给我生成一个 HTML 页面，用 4 种完全不同的设计风格来做，我来逐个感受。" "先别接任何实际逻辑。用假数据做一个独立的 HTML 文件，把新版编辑器工具栏模拟出来。我想对布局有直观感受之后，再碰真实应用。" "我的问题是：用户走完新手引导就流失了。搜索代码库，头脑风暴出 10 个可以介入的节点，从最低成本的到最大胆的都列出来。你列，我来判断哪个方向有感觉。"

面试

做完充分的头脑风暴之后，我身上大概率还挂着不少未知。

这时候，我让 Claude 来面试我。

让它针对任何模棱两可的地方，一个问题一个问题地追问我。

让它面试你的时候，给它足够的问题上下文，引导它问出能撬动架构的关键问题。

示例 Prompt： "一次一个问题地采访我，但凡有模糊之处都追问。优先问那些——我的答案一旦给出，整个架构就可能会被改写的问题。"

以代码为参照

有些时候，你就是无法用语言精确描述你想要什么。

要么是缺了那个精准的词汇，要么是太复杂，讲清楚的时间成本太高。

这种时候，最佳的答案不是语言，而是参照物。

图表、文档、截图都行，但最强大的参照物，永远是源代码。

如果你手头有一个库，它用某种方式实现了某个功能；

或者有一个 UI 组件，它的质感让你念念不忘，直接把文件夹丢给 Fable，告诉它去看什么。

哪怕是用另一种语言写的，也毫无障碍。

这也正是 Claude Design 的工作方式。

你不必给它传文件（当然传也可以）。

你只需要把某个你喜欢的网站模块的地址指给它，它读的是底层代码，而不仅仅是截图。

标签结构、构建逻辑、实现细节——远比一张截图丰富得多。

示例 Prompt： "vendor/rate-limiter 这个 Rust crate 里实现了我想要的退避策略，语义精准。去读它，然后把完全相同的语义，在我们的 TypeScript API 客户端里复刻出来。"

实现计划

当我觉得时机成熟、可以开工了，我会先让 Claude 出一份实现计划供我审阅。

计划的重心，要放在那些最有可能被我改动的地方：数据模型、类型接口、交互流程。

这样 Claude 就能把那些真正需要我做判断的决策，提前摊在桌面上。

示例 Prompt： "用 HTML 写一份实现计划。把我最可能调整的决策摆在最前面：数据模型的变化、新增的类型接口、所有用户可见的部分。机械性的重构塞到底部就行，那块我信你。"

躬身之时

实现笔记

对计划满意之后，我开一个全新的 session，把积攒的产物：spec 文件、原型，一股脑交给 agent，让它放手去实现。

但真相是：无论你做了多少规划，未知之未知永远在暗处潜伏。

Agent 在工作中可能会发现，代码中的某个边界情况逼它必须改道而行。

我让 Claude Code 维护一份临时的 implementation-notes.md（或 .html），将它一路上做出的每一个决策都记录下来。

这样，下一次尝试的时候，我们就有教训可以翻看。

示例 Prompt： "维护一份 implementation-notes.md。凡是碰到边界情况逼你偏离原计划的，选最保守的路线，记在「Deviations」栏下，然后继续前进，别停。"

收工之后

路演与解说文档

Image

将东西发布出去，最难的一关往往是获得认同与审批。

把路演和解说性的 artifact 打包进最终文档，能帮两件事：

• • 加速评审者的理解——他们起步时，也和你一样挂着一身未知；
• • 加速专家审批——他们想看到的，是你已经预判了他们心中那些未知，以及那些他们一眼就能指出的常见失败点。

示例 Prompt： "把原型、spec 和实现笔记打包成一份文档，我直接丢到 Slack 里就能拉人评审。demo GIF 放在最上面。"

出题自测

一场漫长的 working session 下来，Claude 可能已经完成了远超我认知范围的工作。

光靠翻代码 diff，我只能获得浮光掠影的理解，因为大量行为藏在已有的代码路径之中，我根本看不见。

让 Claude 在给我充分上下文之后出题考我，才能真正逼我理解到底发生了什么。只有当我完美通过测验，我才会按下 merge。

示例 Prompt： "我要确保自己彻底弄懂这次改动里发生的一切。先给我一份 HTML 报告，包含上下文直觉、做了什么、为什么这么做，让我阅读消化。报告底部放一套关于这些改动的自测题，我必须全部答对。"

融会贯通：发布 Fable 的真实案例

Fable 的发布视频，从头到尾由 Claude Code 剪辑完成。

视频剪辑于我而言是全然陌生的领域，我绝非专家。

于是我从我唯一知道的事情出发：我清楚 Claude 能用代码编辑和转录视频，但不确定精度是否足够。

我让 Claude 先给我讲清楚 Whisper 这类转录引擎的工作原理，再帮我判断，用 ffmpeg 能不能精准地切掉那些"嗯""啊"和冗长的停顿。

我想让 Claude 创建一种与我口播节奏同步的动态 UI，但不确定它能不能做到。

于是我让 Claude 用 Remotion 配合一份转录稿，先出一个原型视频，验证这条路能否走通。

最后，视频本身的画面显得灰暗沉闷。

我知道这是调色的问题，但我对什么是调色其实几乎一无所知。

我的第一反应是让 Claude 给我出几个调色变体让我选，但我很快意识到，我根本不知道什么叫"好的调色"。

于是换个思路：我让 Claude 先教会我调色是什么，帮我发现我在这件事上的盲区。

你可以在这里看更完整的复盘：https://x.com/trq212/status/2064826394589442448/video/1

让地图贴近疆域

模型越是强大，用对方法便越能走向远方。

当一项长周期任务的结果不尽如人意，很可能不是模型不行，而是你还没有花够时间去打磨你的未知，或者还没给出一个能允许 Claude 在未知中灵活应变的实现计划。

每一次解释文档、每一轮头脑风暴、每一次模拟面试、每一个原型页面、每一份代码参照，都是用近乎零成本的方式，把那些你不知道你不知道的东西，在它们变得致命之前，一一揪出。

下次开启一个项目时，第一件事：让 Claude 帮你寻找你的未知。