Claude Code 团队成员 Thariq（@trq212）在 X 上分享了一篇题为《A Field Guide to Fable: Finding Your Unknowns》的文章，深入探讨了如何利用 Claude Fable 5 与 Claude Code 完成长任务协作。文章的核心并非某个单一提示词，而是如何在任务开始前、执行中以及完成后持续发现并处理未知因素（unknowns）。以下是全文的中文翻译。
在使用 Claude Fable 5 的过程中，一个古老真理反复被验证：地图并非领土本身。
地图，代表了你对工作内容的描述——即你提供的 prompts、skills 和 context，是你交给 Claude 的指令。而领土，则是工作实际发生的场域：代码库、真实环境及其固有的约束条件。
地图与领土之间的差距，便是 unknowns（未知因素）。当 Claude 遇到未知情况时，它必须基于对你意图的最佳推测来做出决策。任务规模越大，Claude 可能遭遇的 unknowns 就越多。
图 2：用 map 和 territory 表示 prompt/context 与真实代码库之间的差距
Fable 是第一个让我明显感受到：工作成果的质量，取决于我能否清晰传达这些未知因素的模型。
值得强调的是，提前规划并不总能解决所有问题。你可能会在实现深入阶段才发现未知因素；也可能这些未知因素揭示了一个事实：你其实应该采用完全不同的方式来解决这个问题。
与 Fable 协作，是一个在实现前、实现中、实现后不断发现自身未知因素的迭代过程。
我制作了一些用于发现未知因素的示例 artifacts，但建议你先阅读完这篇文章再回头使用它们，这样更容易建立判断何时该使用它们的直觉。
图 3：发现 unknowns 的过程
了解你的未知因素
什么是你的未知因素？当你带着问题向 Claude 求助时，通常可以将问题拆解为四类：
图 4：unknowns 分成四类
Known Knowns（已知已知）：
基本上就是写入 prompt 的内容。你告诉 agent 你具体想要什么？
Known Unknowns（已知未知）：
有哪些事情你尚未想清楚，但你知道自己还没想清楚？
Unknown Knowns（未知已知）：
有哪些事情明显到你不会特意写下来，但只要看到结果，你就能立刻识别出来？
Unknown Unknowns（未知未知）：
有哪些事情你完全未曾考虑过？有哪些知识是你没有意识到自己欠缺的？你知道一件事情可以做到多好吗？
最优秀的 agentic coder（智能编码者），其未知因素相对较少。观察 Boris 或 Jarred 这类人编写 prompt 的方式，你会明显感受到他们对自己想要什么非常明确。他们与代码库、模型行为都保持着高度同步。
但他们同样会预设未知因素的存在。从很多意义上说，减少并规划好你的未知因素，就是 agentic coding 的一项核心技能。幸运的是，这项技能可以通过与 Claude 协作来不断提升。
让 Claude 协助你
给 Claude 下达指令是一种微妙的平衡。如果你说得太具体，Claude 会严格遵循你的指令，即使此时转向另一条路径可能更合适。如果你说得太模糊，Claude 又常常基于行业最佳实践做出选择和假设，而这些选择未必适合你的具体任务。
如果你没有充分考虑自己的未知因素，两种情形都会导致失败。你不知道哪条路上布满障碍，也不知道哪条路其实畅通无阻，但你仍然期望 Claude 能在该转向时灵活转向。
Claude 可以帮助你更快地发现未知因素。它能非常迅速地搜索你的代码库和互联网，对大多数普通主题的了解也比你更深入。它还能更快地从失败中迭代学习。
这个过程中最重要的一点，是向 Claude 清晰说明你的出发点。例如，告诉它你目前思考到了哪一步；说明你对这个问题和代码库的熟悉程度；让它像一个思考伙伴一样与你协同工作。
此前我曾写过关于如何用 HTML 与 Claude 协作的文章。在几乎所有这类场景中，HTML artifact 都是可视化和表达问题的最佳方式。
在这篇文章里，我将详细讲解一些用于发现未知因素的模式。虽然每次不一定都用得上所有技巧，但将这些技巧放在手边会非常有用。
图 5：实现前、实现中、实现后工作流
实现前
盲点排查（Blind Spot Pass）
开始工作时，最有益的事情之一就是理解自己的盲点。例如，如果你要在代码库的新区域编写一个功能，或者用 Claude 协助你完成不熟悉的工作（比如迭代设计），你很可能会面临大量 unknown unknowns。
你可能不知道该问什么问题，不清楚什么标准才算好，不了解历史上做过哪些工作，也不知道有哪些常见的坑需要避开。
此时，你可以让 Claude 帮你找出这些 unknown unknowns，并向你解释清楚。直接使用“blindspot pass”和“unknown unknowns”这两个术语。通常来说，告诉它你是谁、你知道什么也至关重要。
示例 prompts：
我正在添加一个新的 auth provider，但我对这个代码库里的 auth 模块完全不了解。你能不能做一次 blindspot pass，帮我找出相关的 unknown unknowns，并帮我把后续 prompt 写得更好？
我不知道 color grading 是什么，但我需要给这个视频做调色。你能不能教我理解自己在 color grading 上的 unknown unknowns，这样我后面能更好地给你写 prompt？
头脑风暴与原型（Brainstorms and prototypes）
当在一个包含很多 unknown knowns 的领域工作时——也就是说，有些判断标准只有看到结果才能知道怎么定义——可以让 Claude 一起进行头脑风暴并制作原型。
在原型制作早期识别并说清 unknown knowns 非常有价值，因为等到实现阶段再发现它们，代价会相对更高。功能或规格上的小变化，可能导致代码实现出现很大差异，而且 agent 回退之前的改动也可能更困难。
比如，你可能只是想看看在某个 frame 上加一个按钮的效果，并不想接入后端 route，也不想在前端维护额外状态。
视觉设计很难用语言表达，但看到时就知道自己想要什么。在这类情况下，可以要求 Claude 制作一个 artifact 展示几种设计方向。
几乎每次 coding session 开始时，我都会先做一次探索或头脑风暴。这有助于带着定义项目范围的意图开始。Claude 经常能找到我可能会错过的高价值方向，有时我也会只见树木不见森林。头脑风暴能避免把范围定得过窄或过宽。
示例 prompts：
我想给这些数据做一个 dashboard，但我没有视觉品味，也不知道有哪些可能性。给我做一个 HTML 页面，包含 4 个完全不同的设计方向，让我可以对它们做出反应。
在接任何真实逻辑之前，先做一个单独的 HTML 文件，用假数据 mock 出新的 editor toolbar。我想先对布局做出反应，然后你再碰真实 app。
这是我粗略的问题：用户在 onboarding 后流失。搜索代码库，brainstorm 10 个我们可以介入的位置，从最便宜到最有野心排序。我会告诉你哪些方向有感觉。
访谈（Interviews）
做完足够的头脑风暴后，很可能仍然存在未知因素。
这种情况下，我会让 Claude 围绕任何未知因素或歧义来采访我。让 Claude 采访你时，尽量给它提供关于问题的上下文，用来引导它的问题。下面是一些示例。
示例 prompts：
针对所有模糊的地方，一次问我一个问题。优先问那些“我的回答会改变架构”的问题。
参考样例（References）
有时你无法详细描述自己想要什么。比如你可能没有相应的语言，或者它太复杂，描述起来会花费很长时间。
这种情况下，最好的答案是提供参考样例。你当然可以给图表、文档或图片，但最好的参考样例往往是源码。
如果你有一个库以某种方式实现了某个功能，或者你特别喜欢某个设计组件，就直接把 Fable 指向那个文件夹，并告诉它该看什么，哪怕它是用另一种语言编写的。
Claude Design 也是这种工作方式。你不一定要交给它一个文件，当然你也可以这么做。你可以把它指向你喜欢的网站上的某个模块，它会读取底层代码，而不只是截图。这会提供更丰富的细节，包括 markup、结构，以及组件实际是如何构建的。
示例 prompt：
vendor/rate-limiter里的这个 Rust crate 实现了我想要的 exact backoff behavior。阅读它，然后在我们的 TypeScript API client 里重新实现相同语义。
实现计划（Implementation Plans）
当觉得准备好进入实现阶段时，我通常会让 Claude 写一份 implementation plan 来 review，并且让计划重点关注那些最可能发生变化的部分，比如数据模型、类型接口或 UX flow。这样 Claude 可以提前暴露一些可能确实需要调整的地方。
示例 prompts：
用 HTML 写一份 implementation plan，但开头先写我最可能想改的决策：数据模型变化、新的类型接口，以及任何用户可见的东西。机械重构放到底部，那部分我信你。
实现中
实现笔记（Implementation notes）
一旦对计划满意，我会开一个新 session，把所有 artifacts 放进 prompt。比如，可能会放入一个 spec 文件和一个 prototype，然后让 agent 去实现它。
但事实是，不管你做了多少规划，总会有 unknown unknowns 藏在里面。Agent 可能会在工作过程中发现，由于代码里的某个 edge case，它需要换一种做法。
我会要求 Claude Code 保持一个临时的implementation-notes.md（或.html）文件，在里面记录它做出的决策，这样可以从下一次尝试中学习。
示例 prompts：
保持一个
implementation-notes.md文件。如果你遇到某个 edge case，导致你必须偏离原计划，选择保守方案，把它记录在 "Deviations" 下面，然后继续推进。
实现后
推介与说明（Pitches and explainers）
交付某个东西时，最重要的环节之一，是获得支持和批准。在最终文档里构建 pitch 和 explainer artifacts 会有帮助：
当 reviewer 一开始和你有同样的 unknowns 时，它能加速理解。
当专家想看你是否考虑到了他们本会预期的 unknowns 和常见 failure points 时，它能加速批准。
图 6：把 prototype、spec 和 implementation notes 整合成 explainer
示例 prompts：
把 prototype、spec 和 implementation notes 打包成一个单独文档，我可以直接发到 Slack 里争取支持。开头先放 demo GIF。
测验（Quizzes）
经过一次很长的工作 session 后，Claude 可能完成了比意识到的更多事情。阅读 code diffs 只能让你对发生了什么有一个很浅的理解，因为很多行为都依赖现有代码路径。
在给了一大段上下文后，让 Claude 围绕改动来 quiz 你，可以帮助理解发生了什么。只有完美通过 quiz 后我才会 merge。
示例 prompts：
我想确保自己理解了这次改动里发生的一切。给我一份 HTML report，说明这些改动，让我能带着上下文、直觉、具体做了什么等信息读懂它，并在底部放一个关于这些改动的 quiz，我必须通过它。
它们如何组合起来：发布 Fable
Fable 的 launch video 完全是用 Claude Code 剪辑的。这对我来说是一个新领域，我绝非专家。
所以我从自己知道的东西开始。我知道 Claude 可以用代码剪辑视频并转录视频，但我不确定它是否足够准确。于是我让 Claude 向我解释 Whisper 这类转录是怎么工作的，以及我能否用 ffmpeg 准确剪掉 "um" 这类口癖和较长停顿。
我想让 Claude 创建一个和我说话内容同步的 UI，但不确定它能不能做到，所以我让 Claude 用 Remotion 和转录文本创建一个 prototype video，看看它是否可行。
最后，视频本身看起来有点灰暗，我知道这是 color grading 的结果，但我不真的知道什么是 color grading。我第一次尝试时，是想让 Claude 做几个变体让我挑选，但后来意识到，在 color grading 这件事上，我并不知道什么才叫“好”。于是，我改为让 Claude 教我 color grading，从而发现我的 unknowns。
你可以在这里观看更深入的解释。
让地图匹配领土
模型越好，只要方法对，你能完成的事情就越多。当一个长程任务返回了错误结果，很可能说明你需要花更多时间定义自己的 unknowns，或者创建一份 implementation plan，让 Claude 能围绕这些 unknowns 做合理的临场调整。
每一份 explainer、brainstorm、interview、prototype 和 reference，都是一种低成本方式，用来在修复代价变高之前，发现你之前不知道的东西。
所以，开始下一个项目时，先让 Claude 帮你找到自己的 unknowns。
参考链接
原文：https://x.com/trq212/article/2073100352921215386
Finding unknowns 示例 artifacts：https://thariqs.github.io/html-effectiveness/unknowns/
HTML with Claude：https://x.com/trq212/status/2052809885763747935
Fable launch video：https://x.com/ClaudeDevs/status/2064399512664526853
Fable launch video 深入解释：https://x.com/trq212/status/2064826394589442448/video/1