与 Claude Fable 5 的合作让我不断重温一个古老的教训：地图并非疆域。
地图，是对待办工作的呈现，是我的提示词、技能和上下文，是我交给 Claude 的东西。而疆域，则是工作实际发生的场所，是代码库，是真实世界，及其实际的约束条件。
地图与疆域之间的差异，就是我所谓的未知因素。当 Claude 遇到未知因素时，它需要基于其对我想法的最佳猜测来做决策。工作量越大，Claude 可能遇到的未知因素就越多。
Fable 是第一个让我觉得工作质量的瓶颈在于我理清其未知因素能力的模型。
重要的是，仅仅提前规划往往不够。你可能会在实施过程中发现深层的未知因素，或者这些未知因素会指向一个事实：你或许应该用完全不同的方式来解决这个问题。
我发现，与 Fable 合作是一个在实施前、实施中和实施后不断发现我的未知因素的迭代过程。
我制作了一些示例工件，用于在此处查找未知因素，但请务必回来建立何时使用它们的直觉。
了解你的未知因素
你的未知因素是什么？当我带着问题来找 Claude 时，我倾向于将其分解为 4 种方式：
- 已知已知： 这基本上就是我提示词里的内容。我告诉 Agent 我想要什么？
- 已知未知： 我还没弄清楚什么，但我知道自己还没弄清楚？
- 未知已知： 有什么东西如此显而易见，以至于我永远不会写下来，但看到就会认出它？
- 未知未知： 我完全没有考虑到什么？我不知道哪些知识？我知道某些事能做到多好吗？
最优秀的 Agent 编程者，其未知因素往往相对较少。观察像 Boris 或 Jarred 这样的高手编写提示词，我明显能感觉到他们知道自己想要什么，细节明确。他们与代码库和模型行为都深度同步。
但他们也会假设未知因素的存在。在许多方面，减少并规划你的未知因素，正是 Agent 编程的技能所在。但幸运的是，这是一种可以通过与 Claude 合作来提升的技能。
帮助 Claude 帮助你
指导 Claude 是一种微妙的平衡。如果你过于具体，即使转向可能更合适，Claude 也会遵循你的指示。如果你过于模糊，Claude 通常会根据行业最佳实践做出选择和假设，而这些可能并不适合你的任务。
当你没有考虑到自己的未知因素时，你会陷入上述两种失败情况。你不知道前路何时会布满障碍，也不知道何时会一片坦途，但你仍然希望 Claude 能够灵活转向。
Claude 可以帮助你更快地发现未知因素。它能够极其迅速地搜索你的代码库和互联网，并且对于大多数普通话题，它比你知道得多。它也能更快地根据失败进行迭代。
这个过程最重要的部分是让 Claude 了解你的起点。例如，告诉它你当前思路所处的阶段；说明你对问题和代码库的经验；让它像一位思想伙伴一样与你合作。
我之前写过关于与 Claude 一起使用 HTML 的文章，在几乎所有情况下，HTML 工件都是可视化和呈现内容的最佳方式。
在这篇文章中，我详细介绍了一些用于发现这些未知因素的模式。我并非每次都使用每一种技巧，但这套技巧合集在手会很有用。
实施前
盲点检查
开始工作时，你能做的最有用的事情之一就是了解自己的盲点。例如，如果你在代码库的新部分编写功能，或者使用 Claude 帮助你处理不熟悉的工作（如迭代设计），你很可能会有大量的 未知未知。
你可能不知道要问什么问题，不知道好的标准是什么，不知道以前做过哪些相关工作，也不知道要避开哪些坑。
为此，你可以让 Claude 帮你找出你的未知未知，并向你解释。我喜欢直接使用“盲点检查”和“未知未知”这些字眼。通常，向它说明你是谁以及你知道什么非常重要。
示例提示词：
- “我正在为一个新项目添加新的 auth 提供商，但我对这个代码库中的 auth 模块一无所知。你能做一个盲点检查，帮我找出我相关的未知未知，并帮助你更好地给我提示吗？”
- “我不知道什么是调色，但我需要给这个视频调色。你能教我了解我在调色方面的未知未知，以便我能更好地给出提示吗？”
头脑风暴与原型设计
当我在一个包含大量 未知已知 的领域工作时——这些标准我只能在看到时才能定义——我喜欢让 Claude 和我一起进行头脑风暴和原型设计。
在原型设计阶段尽早识别并表述出未知已知是极其有价值的，因为在实施过程中才发现它们会（相对）昂贵。功能或规范的微小更改可能导致代码实现天差地别，并且你的 Agent 可能更难撤销之前的更改。
例如，你可能只是想看看向框架添加一个按钮的效果，而无需连接后端路由或在前端维护额外的状态。
对我而言，视觉设计很难用语言描述，但我看到就知道想要什么。在这种情况下，我会要求为一个工件提供几种设计方案。
我也几乎总是以探索或头脑风暴阶段开始每次编码会话。这有助于我带着意图开始，定义项目的范围。Claude 常常能找到我可能会错过的高价值方法，但有时也会只见树木不见森林。头脑风暴可以防止我将范围设置得过于狭窄或过于宽泛。
示例提示词：
- “我想为这些数据做一个仪表盘，但我没有视觉品味，也不知道可能做到什么程度。给我做一个包含 4 种截然不同设计方向的 HTML 页面，让我可以做出反应。”
- “在连线之前，先用假数据创建一个模拟新编辑器工具栏的单一 HTML 文件。我想先对布局做出反应，然后再让你接触真正的应用。”
- “我有一个粗略的问题：用户在入门引导后流失了。搜索代码库，头脑风暴出 10 个我们可以干预的点，从成本最低到最有野心。我会告诉你哪些点可行。”
访谈
一旦我进行了足够的头脑风暴，可能仍然存在未知因素。
在这种情况下，我让 Claude 就任何未知或模糊之处对我进行访谈。当要求 Claude 访谈你时，尝试给它提供关于你问题的上下文，以引导它的问题。以下是一些示例。
示例提示词：
- “一次一个问题地访谈我，针对任何模糊之处，优先处理那些我的回答会改变架构的问题。”
参考
有时你无法详细描述你想要什么。例如，你可能缺乏相应的语言，或者问题太复杂，需要花很长时间才能说清楚。
在这种情况下，最好的答案是提供参考。虽然你可以包含图表、文档或图片，但绝对最好的参考是源代码。
如果你有一个以特定方式实现功能的库，或者一个你非常喜欢的设计组件，只需将 Fable 指向该文件夹并告诉它要寻找什么，即使它是用不同语言编写的也可以。
这也是 Claude Design 的工作方式。你不必将文件交给它（虽然你也可以这样做）。你可以将它指向你喜欢的网站上的一个模块，它不仅读取截图，还读取底层代码。这将提供关于标记、结构以及组件实际构建方式的更丰富细节。
示例提示词：
- “这个在 vendor/rate-limiter 中的 Rust crate 实现了我想要的精确退避行为。阅读它，并在我们的 TypeScript API 客户端中重新实现相同的逻辑。”
实施计划
当我认为准备好实施时，我倾向于让 Claude 制定一个实施计划供我审查，重点放在最可能变更的部分，例如审查数据模型、类型接口或用户体验流程。这能让 Claude 揭示出我可能实际需要更改的内容。
示例提示词：
- “用 HTML 写一个实施计划，但以我最可能调整的决策开头：数据模型更改、新的类型接口，以及任何面向用户的内容。把机械性的重构放在最后，这部分我信任你。”
实施过程中
实施记录
一旦我对计划满意，我会开启一个新的会话，并将所有工件传递到提示中。例如，我可能会传入一个规范文件和一个原型，然后让 Agent 去实现它。
但事实是，无论你做多少规划，总会有隐藏的未知未知。Agent 可能在工作中发现，由于在代码中找到了某个边缘情况，它需要采取不同的策略。
我要求 Claude Code 保留一个临时的 ' implementation-notes.md' （或 .html）文件，在其中记录其做出的决策，以便我们能在下一次尝试中学习。
示例提示词：
- “保留一个 implementation-notes.md 文件。如果你遇到了迫使你偏离计划的边缘情况，选择保守的方案，在‘偏离记录’下记录，然后继续。”
实施后
提案与说明
交付某个成果最重要的部分之一是获得支持和批准。在最终文档中构建提案和说明工件有助于：
- 当评审者与你有相同的起点未知因素时，加速他们的理解
- 当专家希望看到你考虑了他们可能预见的未知因素和常见失败点时，加速批准流程
示例提示词：
- “将原型、规范和实施记录打包成一个文档，我可以丢到 Slack 里争取支持。以演示 GIF 开头。”
测验
在经过长时间的工作会话后，Claude 可能完成了比我意识到的多得多的内容。阅读代码差异只能让我对发生的事情有肤浅的了解，因为许多行为都取决于现有的代码路径。
在提供大量上下文后，让 Claude 就变更内容对我进行测验，有助于我理解发生了什么。只有在我完美通过测验后，我才会合并代码。
示例提示词：
- “我想确保我完全理解这次变更中发生的一切。给我一个关于变更的 HTML 报告，包含上下文、直觉、做了什么等内容，让我阅读和理解，并在底部附上一个关于变更的测验，我必须通过。”
如何整合这些方法：发布 Fable
Fable 的发布视频 完全由 Claude Code 剪辑完成。这对我是一个全新的领域，我绝不是专家。
所以，我从我知道的事情开始。我知道 Claude 可以使用代码来编辑视频和转录，但我不确定它是否足够精确。然后我让 Claude 向我解释像 Whisper 这样的转录是如何工作的，以及我能否使用 ffmpeg 精确地剪掉类似“嗯”这样的 filler words 或较长的停顿。
我希望 Claude 创建一个与我说话时间同步的 UI，但不确定它能否做到，所以我让 Claude 使用 Remotion 和一个转录文件制作一个原型视频，看看是否可行。
最后，视频本身看起来有点黯淡，我知道这是调色的结果，但我确实不知道调色是什么。我的第一次尝试是让 Claude 做几个变体供我选择，但我意识到我不知道调色“好”的标准是什么。所以，我转而让 Claude 教我关于调色的知识，以发现我的未知因素。
你可以在此处观看更深入的讲解 视频。
让地图与疆域匹配
模型越强大，采用正确的方法就能实现越多成就。当一个长期任务的结果出错时，很可能你需要花更多时间定义你的未知因素，或者制定一个允许 Claude 在未知因素中即兴发挥的实施计划。
每一个说明、头脑风暴、访谈、原型和参考，都是一种低成本的方式，让你在修正代价变得高昂之前，发现自己不知道的东西。
所以，开始你的下一个项目吧，让 Claude 帮你找到你的未知因素。
