Fable 实战指南：发现你的未知

与 Claude Fable 5 合作，总会让我重新领会一个老道理：地图不等于实地。

地图是对待完成工作的描述，也就是我交给 Claude 的提示词、技能和上下文。实地则是工作真正发生的地方：代码库、现实世界，以及其中实际存在的约束。

地图与实地之间的差距，就是我所说的未知。当 Claude 遇到未知时，它必须根据自己对我意图的最佳猜测作出决定。要完成的工作越多，它可能遇到的未知也越多。

Fable 是第一个让我感到，工作质量会受限于我能否帮助它澄清未知的模型。

而且，仅仅提前规划并不总是足够。未知可能在深入实现之后才出现；也可能正是这些未知，让你意识到其实应该用完全不同的方式解决问题。

我发现，与 Fable 合作是一个不断迭代的过程：在实现之前、实现过程中，以及实现之后，持续发现自己尚未弄清的事情。

我在这里制作了一些帮助发现未知的示例作品，但看完后记得回来，建立判断何时使用这些方法的直觉。

认识你的未知

你的未知是什么？当我带着问题找 Claude 时，通常会从四个方面拆解：

• 已知的已知（Known Knowns）：基本上就是提示词里已有的内容。我告诉智能体，我想要什么？
• 已知的未知（Known Unknowns）：哪些事情我还没弄清，但我知道自己还没弄清？
• 未知的已知（Unknown Knowns）：哪些事情对我来说太理所当然，以至于我从不会写下来，但一看到就能认出来？
• 未知的未知（Unknown Unknowns）：哪些事情我根本没有考虑过？有哪些知识是我不知道其存在的？我知道一件事能够做到多好吗？

最擅长智能体编程的人，通常有相对较少的未知。看 Boris 或 Jarred 这样的人写提示词，我很明显地感到，他们非常清楚自己想要什么，连细节都很明确。他们既熟悉代码库，也熟悉模型的行为。

但他们同样会预设未知的存在。从许多方面来说，减少未知，并为未知做好准备，正是智能体编程的核心技能。幸运的是，你可以通过与 Claude 合作，不断提升这项技能。

帮助 Claude 更好地帮助你

向 Claude 下达指令，需要微妙的平衡。如果过于具体，即使改变方向更合适，Claude 也会照着你的指令走。如果过于模糊，Claude 往往会依据行业最佳实践作出选择和假设，而这些做法未必适合你的任务。

如果没有把未知考虑进去，两头都会出问题。你不知道何时前路会布满障碍，也不知道何时道路其实畅通，却仍希望 Claude 转向。

Claude 可以帮你更快地发现未知。它能极其迅速地搜索代码库和互联网，对大多数主题掌握的知识也比你更多。它还能更快地从失败中迭代。

在这个过程中，最重要的是向 Claude 说明你的起点。例如，告诉它你的思考进行到了哪一步，你对这个问题和代码库有多少经验，让它像思考伙伴一样与你合作。

我之前写过如何与 Claude 配合使用 HTML。在下面几乎所有场景中，HTML 作品都是将想法可视化、呈现出来的最佳方式。

本文会详细介绍我用来发现这些未知的一些方法。我不会每次都使用所有技巧，但把它们放进自己的工具箱很有帮助。

实现之前

盲点排查

开始工作时，最有用的事情之一，就是了解自己的盲点。例如，你要在代码库中一个陌生的部分开发功能，或者让 Claude 帮你完成设计迭代之类不熟悉的工作，就很可能面对大量“未知的未知”。

你可能不知道该问什么、怎样才算好、过去做过哪些工作，或应该避开哪些坑。

这时，可以让 Claude 帮你找出那些“未知的未知”，并向你解释。我喜欢直接使用“blindspot pass”（盲点排查）和“unknown unknowns”（未知的未知）这些词。告诉它你是谁、已经知道什么，通常很重要。

提示词示例：

• “我正在添加一个新的身份验证提供方，但对这个代码库中的身份验证模块一无所知。你能做一次盲点排查，帮我弄清相关的未知的未知，并帮助我更好地向你提需求吗？”
• “我不知道什么是调色，但我需要为这段视频调色。你能教我认识调色方面那些我还没意识到的未知，让我能写出更好的提示词吗？”

头脑风暴与原型

当一个领域中有大量“未知的已知”，也就是有些标准只有看到具体东西时，我才知道该如何定义，我就喜欢让 Claude 和我一起头脑风暴、制作原型。

在原型阶段尽早识别并说清这些隐含知识，非常有价值。因为等到实现阶段才发现，代价可能会相对高昂。功能或规格上的微小变化，都可能导致代码实现截然不同，而智能体要撤回之前的修改也可能更加困难。

例如，你可能只是想看看在一个界面框架里加上按钮是什么效果，并不需要为此接入后端路由，或在前端维护额外状态。

视觉设计对我来说很难用语言表达，但看到具体设计时，我就知道自己想要什么。这种情况下，我会要求针对同一个作品给出几种设计方案。

我几乎每次编程会话也都会从探索或头脑风暴开始。这让我从一开始就有意识地界定项目范围。Claude 经常能找到我可能忽略的高价值方案，但有时也会只见树木、不见森林。头脑风暴可以避免把范围定得过窄或过宽。

提示词示例：

• “我想为这些数据做一个仪表盘，但我没有视觉审美，也不知道有哪些可能性。给我做一个 HTML 页面，展示四种截然不同的设计方向，让我看看并给出反馈。”
• “在接入任何功能之前，先用虚假数据制作一个独立的 HTML 文件，模拟新的编辑器工具栏。在你改动真正的应用之前，我想先对布局给出反馈。”
• “我的问题大致是：用户完成引导流程后就流失了。搜索代码库，头脑风暴出十个可以介入的地方，从成本最低到最有野心的方案排序。我会告诉你哪些方向值得继续。”

访谈

即使已经充分头脑风暴，我很可能仍然有未知。

这时，我会让 Claude 针对未知或模糊之处采访我。让它提问时，尽量提供问题的背景，帮助它确定提问方向。

提示词示例：

• “针对所有不明确的地方采访我，一次问一个问题。优先问那些我的回答会改变架构的问题。”

参考资料

有时，你无法详细描述自己想要的东西。例如，你可能缺少相应的表达方式，或者事情太复杂，完整说清楚需要很长时间。

这种情况下，最好的办法是提供参考。你可以给出图表、文档或图片，但最好的参考其实是源代码。

如果某个库用你希望的方式实现了功能，或者有一个你特别喜欢的设计组件，只要把对应文件夹指给 Fable，告诉它该看什么就可以，即使用的是另一种编程语言也没关系。

Claude Design 也是这样工作的。你不一定要给它一个文件，当然也可以这样做。你可以指向一个自己喜欢的网站模块，它会读取底层代码，而不仅仅是截图。这能提供关于标记、结构，以及组件实际构建方式的丰富细节。

提示词示例：

• “vendor/rate-limiter 中的这个 Rust crate，恰好实现了我想要的退避行为。阅读它，并在我们的 TypeScript API 客户端中实现相同的语义。”

实现计划

当我觉得已经准备好开始实现时，通常会让 Claude 拟定一份实现计划供我审阅，重点放在最有可能调整的部分，例如数据模型、类型接口或用户体验流程。这样，Claude 就能把那些我可能确实需要改动的内容呈现出来。

提示词示例：

• “用 HTML 写一份实现计划，把我最可能调整的决策放在开头：数据模型的变化、新的类型接口，以及所有用户可见的内容。机械性的重构放到最后，那部分我相信你。”

实现过程中

实现笔记

对计划满意之后，我会新建一个会话，并把相关产物作为输入交给它。例如，提供一份规格文件和一个原型，让智能体实现它。

但事实是，无论提前做了多少规划，总有“未知的未知”潜藏着。智能体可能在工作过程中遇到代码中的边界情况，发现需要换一种做法。

我会让 Claude Code 维护一个临时的 implementation-notes.md（或 .html）文件，记录它作出的决策，供下一次尝试时参考。

提示词示例：

• “维护一个 implementation-notes.md 文件。如果遇到迫使你偏离计划的边界情况，就选择较保守的方案，把它记录在‘Deviations（偏离计划）’部分，然后继续。”

实现之后

提案与说明材料

交付一项成果时，最重要的事情之一就是获得认同和批准。在最终文档中加入提案与说明材料，有助于：

• 当评审者和你最初一样，面对相同的未知时，帮助他们更快理解。
• 当专家希望确认你考虑到了他们预见的未知和常见失败点时，加快审批。

提示词示例：

• “把原型、规格和实现笔记整理成一份文档，让我能直接发到 Slack 里争取支持。把演示 GIF 放在开头。”

测验

经过一段长时间的工作后，Claude 完成的内容可能远比我意识到的更多。阅读代码差异，只能让我对发生的变化有粗浅了解，因为很多行为取决于已有的代码路径。

先让 Claude 提供充分的背景，再让它围绕改动考考我，有助于理解实际发生了什么。只有完全通过测验后，我才会合并代码。

提示词示例：

• “我想确保自己理解这次改动中的一切。请给我一份 HTML 报告，包含背景、直观解释、做了哪些事情等，供我阅读理解，并在底部附上一份关于这些改动、我必须通过的测验。”

把这些方法串起来：Fable 的发布

Fable 的发布视频完全由 Claude Code 剪辑完成。这对我来说是个新领域，我远远算不上专家。

所以，我先从已知的事情开始。我知道 Claude 能用代码剪辑视频并转录，但不确定准确度是否足够。于是，我让 Claude 解释 Whisper 这类转录工具如何工作，以及能否使用 ffmpeg 精确剪掉“嗯”之类的语气词或较长的停顿。

我希望 Claude 创建一个与我说话的词句同步出现的界面，但不确定它能不能做到。因此，我让它使用 Remotion 和转录文本制作一段原型视频，验证这个想法是否可行。

最后，视频本身看起来有些灰淡。我知道这与调色有关，却并不真正了解什么是调色。我最初试着让 Claude 做几个版本供我挑选，但随后意识到，在调色这件事上，我根本不知道怎样才算“好”。于是，我改为让 Claude 教我调色，发现自己的未知。

你可以在这里观看更深入的讲解。

让地图与实地相符

模型越强，使用正确的方法就越能有所作为。当一项长期任务交回来的结果不对时，你很可能需要花更多时间界定自己的未知，或制定一份允许 Claude 在面对未知时灵活应变的实现计划。

每一份说明材料、每一次头脑风暴、访谈、原型制作和参考资料，都是在修正成本变高之前，低成本发现自己原本不知道的事情的方法。

所以，下次开始项目时，不妨先让 Claude 帮你找出自己的未知。

作者：Thariq
原文标题：A Field Guide to Fable: Finding Your Unknowns
原文链接：https://x.com/trq212/article/2073100352921215386