Claude Fable 5 硬核指南：找到未知

原创 Thariq 2026-07-11 21:14 江苏

A Field Guide to Fable: Finding Your Unknowns

Claude Code 团队成员 Thariq（@trq212）在 X 上写了一篇《A Field Guide to Fable: Finding Your Unknowns》，围绕 Claude Fable 5 和 Claude Code 的长任务协作展开，重点不是某个单独 prompt，而是怎样在实现前、实现中、实现后持续发现 unknowns，以下是全文翻译。

使用 Claude Fable 5 的这段时间，一直在反复提醒我一个老道理：地图不是领土。

地图，是对要完成工作的表示，也就是我的 prompts、skills 和 context，是我交给 Claude 的东西。领土，是工作真正发生的地方：代码库、真实世界，以及它们实际存在的约束。

地图和领土之间的差距，就是我所说的 unknowns。当 Claude 遇到一个 unknown，它就需要基于自己对我意图的最佳猜测做决定。工作量越大，Claude 可能遇到的 unknowns 就越多。

Fable 是第一个让我明显感觉到：工作质量会受限于我能否把 unknowns 讲清楚的模型。

很重要的一点是，提前规划并不总是足够。你可能会在实现很深的地方才发现 unknowns；也可能是这些 unknowns 指向了一个事实：你其实应该用完全不同的方式解决这个问题。

我发现，和 Fable 一起工作，是一个在实现前、实现中、实现后不断发现自己 unknowns 的迭代过程。

我做了一些用于发现 unknowns 的示例 artifacts，但建议你看完这篇文章再回去用它们，这样更容易建立什么时候该用它们的直觉。

了解你的 unknowns

什么是你的 unknowns？当我带着一个问题来找 Claude 时，我通常会把它拆成四类：

Known Knowns：
这基本就是我写进 prompt 里的内容。我告诉 agent 我想要什么？

Known Unknowns：
有哪些事情我还没想清楚，但我知道自己还没想清楚？

Unknown Knowns：
有哪些事情明显到我根本不会写下来，但只要看到结果，我就能认出来？

Unknown Unknowns：
有哪些事情我完全没有考虑过？有哪些知识是我没有意识到自己缺乏的？我知道一件事可以好到什么程度吗？

最好的 agentic coder，unknowns 相对更少。看 Boris 或 Jarred 这类人写 prompt，我很明显能感觉到，他们非常具体地知道自己想要什么。他们和代码库、模型行为都高度同步。

但他们也会预设 unknowns 的存在。从很多意义上说，减少并规划你的 unknowns，就是 agentic coding 的一项技能。幸运的是，这项技能可以通过和 Claude 一起工作来提升。

让 Claude 帮你

给 Claude 下指令是一种微妙的平衡。如果你说得太具体，Claude 会照着你的指令做，即使此时转向另一条路可能更合适。如果你说得太模糊，Claude 又经常会基于行业最佳实践做选择和假设，而这些选择未必适合你的任务。

如果你没有考虑自己的 unknowns，两边都会失败。你不知道哪条路上布满障碍，也不知道哪条路其实很通畅，但你仍然希望 Claude 能在该转向时转向。

Claude 可以帮你更快发现 unknowns。它能非常快地搜索你的代码库和互联网，对多数普通主题也比你知道得更多。它还可以更快地从失败中迭代。

这个过程里最重要的一点，是把你的起点告诉 Claude。例如，告诉它你现在思考到哪一步；说明你对这个问题和代码库的经验；让它像一个思考伙伴一样和你一起工作。

我之前写过怎样用 HTML 和 Claude 协作。在几乎所有这类场景里，HTML artifact 都是可视化和表达问题的最佳方式。

在这篇文章里，我会详细讲一些我用来发现 unknowns 的模式。我不会每次都用到所有技巧，但把这些技巧放在手边很有用。

实现前

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 和我一起 brainstorm 并做 prototype。

在 prototyping 早期识别并说清 unknown knowns 非常有价值，因为到实现阶段再发现它们，代价会相对更高。功能或 spec 上的小变化，可能导致代码实现出现很大差异，而且 agent 回退之前的改动也可能更困难。

比如，你可能只是想看看在某个 frame 上加一个按钮是什么效果，并不想接后端 route，也不想在前端维护额外状态。

视觉设计对我来说很难用语言表达，但我看到时知道自己想要什么。在这类情况下，我会要求 Claude 给一个 artifact 做几种设计方向。

我几乎也会在每次 coding session 开始时，先做一次探索或 brainstorming。这能帮助我带着定义项目范围的意图开始。Claude 经常能找到我会错过的高价值方向，有时也会只见树木不见森林。Brainstorming 能避免我把范围定得过窄或过宽。

示例 prompts：

我想给这些数据做一个 dashboard，但我没有视觉品味，也不知道有哪些可能性。给我做一个 HTML 页面，包含 4 个完全不同的设计方向，让我可以对它们做反应。

在接任何真实逻辑之前，先做一个单独的 HTML 文件，用假数据 mock 出新的 editor toolbar。我想先对布局做反应，然后你再碰真实 app。

这是我粗略的问题：用户在 onboarding 后流失。搜索代码库，brainstorm 10 个我们可以介入的位置，从最便宜到最有野心排序。我会告诉你哪些方向有感觉。

Interviews

做完足够的 brainstorming 后，我很可能仍然还有 unknowns。

这种情况下，我会让 Claude 围绕任何 unknowns 或歧义来采访我。让 Claude 采访你时，尽量给它关于问题的上下文，用来引导它的问题。下面是一些示例。

示例 prompts：

针对所有模糊的地方，一次问我一个问题。优先问那些“我的回答会改变架构”的问题。

References

有时你无法详细描述自己想要什么。比如你可能没有相应的语言，或者它太复杂，描述起来会花很久。

这种情况下，最好的答案是 reference。你当然可以给图表、文档或图片，但最好的 reference 往往是源码。

如果你有一个库以某种方式实现了某个东西，或者你特别喜欢某个设计组件，就直接把 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 时，它能加速批准。

示例 prompts：

把 prototype、spec 和 implementation notes 打包成一个单独文档，我可以直接发到 Slack 里争取支持。开头先放 demo GIF。

Quizzes

经过一次很长的工作 session 后，Claude 可能完成了比我意识到的更多事情。阅读 code diffs 只能让我对发生了什么有一个很浅的理解，因为很多行为都依赖现有代码路径。

在给我一大段上下文后，让 Claude 围绕改动来 quiz 我，可以帮助我理解发生了什么。我只有在完美通过 quiz 后才会 merge。

示例 prompts：

我想确保自己理解了这次改动里发生的一切。给我一份 HTML report，说明这些改动，让我能带着上下文、直觉、具体做了什么等信息读懂它，并在底部放一个关于这些改动的 quiz，我必须通过它。

它们如何组合起来：launching 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

进技术交流群请添加AINLP小助手微信（id: ainlp2)

请备注具体方向+所用到的相关技术点

关于AINLP

AINLP 是一个有趣有AI的自然语言处理社区，专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。