【译】Fable 实战指南：找出你的未知

译者推荐：让 agent 干活，结果不对，多数人第一反应是怪模型。Thariq 给了另一个解释：模型越强，瓶颈越是你自己没讲清楚的那些「未知」。这不是又一篇「prompt 技巧大全」，而是一套有框架的工作方法，每个环节都带现成 prompt，拿来就能用。

导读：作者把人和 agent 之间的鸿沟拆成四类「未知」，再给出实现前、实现中、实现后逐步挖出它们的一套做法——盲区扫描、访谈、参考物、实现笔记、小测验。文末还有一个完整案例：一个从没剪过视频的人，怎么用这套方法让 Claude Code 剪出一条官方发布视频。

原文：A Field Guide to Fable: Finding Your Unknowns，发布于 2026-07-03。

作者：Thariq Shihipar（@trq212），Anthropic Claude Code 团队工程师，Claude Code 里的 AskUserQuestion 工具就出自他手，Fable 的官方发布视频也是他用 Claude Code 剪的。加入 Anthropic 之前连续创业：办过 YC 投的游戏公司（融资 1700 万美元）、卖过一家 SaaS，在 MIT Media Lab 读过研。写过《Claude Code is All You Need》《HTML is the new markdown》。

和 Claude Fable 5 协作，反复给我上同一堂老课：地图不是疆域。

Working with Claude Fable 5 keeps re-teaching me an old lesson: the map is not the territory.

地图，是对「要做的工作」的一种表述——我的 prompt、skill 和 context，也就是我交给 Claude 的那些东西。疆域，是工作实际发生的地方——代码库、真实世界，以及它们真正的约束。

The map, a representation of the work to be done, is my prompts and skills and context, it’s what I give Claude. The territory is where the work needs to happen, the codebase, the real world, its actual constraints.

地图和疆域之间的差距，就是我说的「未知」（unknowns）。Claude 撞上一个未知时，只能基于「它猜我想要什么」来做决定。干的活越多，Claude 可能撞上的未知就越多。

The difference between the map and the territory is what I call unknowns. When Claude runs into an unknown, it needs to make a decision based on its best guess of what I want. The more work being done, the more unknowns Claude might run into

Fable 是第一个让我觉得瓶颈在自己身上的模型：工作质量卡在我能不能把它的未知讲清楚。

Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.

重要的是，光靠提前规划并不总够用。有些未知要到实现深处才会冒出来；有的未知甚至会告诉你，这个问题本身就该换一种解法。

Importantly, just planning ahead isn’t always enough. You can find unknowns deep in implementation, or your unknowns may point you to the fact that you should actually be solving the problem in a different way altogether.

我发现，和 Fable 协作就是一个在实现前、实现中、实现后不断发现自己未知的迭代过程。

I’ve found that working with Fable is an iterative process of discovering my unknowns before, during, and after implementation.

我做了一些用来找未知的示例 artifact，但记得回来这里，把「什么时候用哪个」的直觉建立起来。

I’ve made some example artifacts for finding unknowns here, but be sure to come back to build the intuition for when to use them.

认识你的未知 · Knowing your unknowns

你的未知有哪些？我带着一个问题去找 Claude 时，习惯把它拆成四类：

What are your unknowns? When I come to Claude with a problem I tend to break it down in 4 ways:

• 已知的已知（Known Knowns）：基本就是 prompt 里写的东西。我明确告诉了 agent 我要什么？
• 已知的未知（Known Unknowns）：哪些我还没想清楚，但我知道自己没想清楚？
• 未知的已知（Unknown Knowns）：哪些东西对我太理所当然、从来不会写下来，但一看到就能认出来？
• 未知的未知（Unknown Unknowns）：哪些我压根没考虑过？我意识不到自己缺哪块知识？我知道一件事能好到什么程度吗？

• Known Knowns: This is essentially what is in my prompt. What do I tell the agent that I want?
• Known Unknowns: What haven’t I figured out yet, but I’m aware that I haven’t?
• Unknown Knowns: What’s so obvious I’d never write it down, but would recognize it if I saw it?
• Unknown Unknowns: What haven’t I considered at all? What knowledge am I not aware of? Do I know how good something can be?

最好的 agentic coding 玩家，未知都相对少。看 Boris 或 Jarred 写 prompt，一眼就能看出他们对自己要什么了如指掌——他们和代码库、和模型的行为都深度同频。

The best agentic coders are good have relatively few unknowns. Watching someone like Boris or Jarred prompt, it is obvious to me that they know what they want in-detail. They are deeply in-sync with both the codebase and the model behaviors.

但他们同样会预设未知的存在。某种意义上，减少并规划你的未知，正是 agentic coding 的核心功力。好在这是能练出来的——跟 Claude 一起练。

But they also assume unknowns. In many ways, reducing and planning for your unknowns is the skill of agentic coding. But luckily, this is a skill you can improve at, by working with Claude.

帮 Claude 帮你 · Help Claude help you

指挥 Claude 是个微妙的平衡。说得太具体，即使中途转向更合适，Claude 也会照着你的指令一路走到底；说得太模糊，Claude 就会按「行业最佳实践」来做选择和假设，而那未必适合你的任务。

Instructing Claude is a delicate balance. If you are too specific, Claude will follow your instructions even when a pivot may be more appropriate. If you are too vague, Claude will often make choices and assumptions based on industry best practices that may not be a fit for your task.

不盘点自己的未知，两头都会翻车：你既料不到哪段路会布满障碍，也料不到哪段路明明畅通、你却还是希望 Claude 拐个弯。

When you don’t account for your unknowns you fail both ways. You don’t know when the path will be filled with obstacles and you don’t know when the path will be clear, but you still want Claude to veer.

Claude 能帮你更快发现未知。它搜代码库、搜互联网的速度极快，对大多数话题都比你懂得多，从失败中迭代也比你快。

Claude can help you discover your unknowns faster. It can search through your codebase and the internet extremely quickly and it knows much more about the average topic than you. It can also iterate from failure faster.

这个过程最关键的一点，是把你的出发点交代给 Claude。比如：告诉它你的思考进行到哪一步了；坦白你对这个问题和这个代码库的经验深浅；让它像思考伙伴一样和你一起干活。

The most important part of this process is to give Claude context about your starting point. For example, tell it where you are in your thought process; disclose your experience with the problem and codebase; and let it work with you like a thought partner.

我之前写过怎么和 Claude 用 HTML，上面这些场景里，HTML artifact 几乎都是可视化和表达的最佳载体。

I’ve previously written about using HTML with Claude, in almost all of these cases, a HTML artifact is the best way to visualize and represent it.

这篇文章我会展开讲一些我用来挖掘未知的套路。不是每次全用，但值得都备着。

In this article I detail some of the patterns I use to uncover these unknowns. I don’t use every technique each time, but it’s a useful collection of techniques to have.

实现前 · Pre-implementation

盲区扫描（Blind Spot Pass）

刚开工时，最有价值的事之一是搞清自己的盲区。比如要在代码库的陌生区域写功能，或者让 Claude 带你干不熟的活（比如迭代设计稿），你多半揣着一堆未知的未知。

When starting work, one of the most useful things you can do is understand your blindspots. For example, if you’re writing a feature in a new part of the codebase or using Claude to help you with unfamiliar work like iterating on a design, you’re likely to have a lot of unknown unknowns.

你可能不知道该问什么问题、不知道「好」长什么样、不知道前人做过什么，也不知道哪里有坑。

You may not know what questions to ask, what good looks like, what historical work has been done or what potholes to avoid.

这时可以让 Claude 帮你找出未知的未知，并讲给你听。我喜欢直接用「盲区扫描（blindspot pass）」「unknown unknowns」这样的字眼。把你是谁、你懂什么交代清楚，通常很重要。

To do this, you can ask Claude to help you find your unknown unknowns and explain them to you. I like to use the literal words “blindspot pass” and “unknown unknowns”. Giving it context on who you are and what you know is usually important for

示例 prompt：

• 「我要接入一个新的 auth provider，但我对这个代码库的 auth 模块一无所知。帮我做一个盲区扫描（blindspot pass），找出和这件事相关的 unknown unknowns，好让我把 prompt 写得更到位。」
• 「我不懂什么是调色（color grading），但我得给这条视频调色。教我搞懂在调色这件事上我的 unknown unknowns，让我之后能把 prompt 提得更好。」

• “I’m working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blindspot pass to help me figure out my relevant unknown unknowns and help me prompt you better.”
• “I don’t know what color grading is but I need to grade this video. Can you teach me to understand my unknown unknowns about color grading, so that I can prompt better?”

头脑风暴与原型 · Brainstorms and prototypes

当我干活的领域里有大量未知的已知——也就是那些「见了才知道要什么」的标准——我喜欢拉着 Claude 一起头脑风暴、做原型。

When I’m working in an area with a lot of unknown knowns, involving criteria I only know to define when I see it, I like to ask Claude to brainstorm and prototype with me.

在原型阶段尽早把未知的已知找出来、说出口，非常值。等到实现阶段才发现，代价（相对）就大了：功能或 spec 上的一点小改动，可能导致代码实现天差地别，而且 agent 想回滚之前的改动也会更费劲。

It’s extremely valuable to identify and verbalize unknown knowns early during prototyping, because finding them out during implementation can be (relatively) expensive. Small changes in a feature or spec can cause drastically different implementations in code and it can be more difficult for your agent to revert previous changes.

比如你可能只是想看看某个按钮放进界面里长什么样，不想为此先接好后端路由、再在前端多维护一份状态。

For example, you may just want to see how a button added to a frame looks without having to wire up a backend route or maintaining additional state in the frontend.

视觉设计对我就是典型：很难说清，但见了就认得。这种时候我会让它对一个 artifact 给出好几种设计方向。

Visual design is something that for me is difficult to articulate, but I know what I want when I see it. In these cases, I’ll ask for several design approaches to an artifact.

我几乎每个编码 session 都从探索或头脑风暴开始。这让我带着意图开场，把项目范围定下来。Claude 经常能找到我自己想不到的高价值方案，偶尔也会见树不见林。头脑风暴能防止我把范围定得过窄或过宽。

I also start almost every coding session with an exploration or brainstorming phase. This helps me start with intent to define the project’s scope. Claude often finds high-value approaches I would have missed and sometimes misses the forest through the trees. Brainstorming prevents me from setting too narrow or too wide a scope.

示例 prompt：

• 「我想给这份数据做个 dashboard，但我没什么视觉品味，也不知道能做成什么样。给我一个 HTML 页面，放 4 个风格迥异的设计方向，让我看着挑。」
• 「先别接任何东西，用一个单独的 HTML 文件、拿假数据把新的编辑器工具栏 mock 出来。我想先对布局有个反应，你再去动真实应用。」
• 「我的问题很粗糙：用户在 onboarding 之后流失。搜一遍代码库，头脑风暴 10 个我们可以介入的位置，从最省事的到最有野心的排开，我来说哪些有感觉。」

• “I want a dashboard for this data but I have no visual taste and don’t know what’s possible. Make me an HTML page with 4 wildly different design directions so I can react to them.”
• “Before wiring anything up, make a single HTML file mocking the new editor toolbar with fake data. I want to react to the layout before you touch the treal app.”
• “Here’s my rough problem: users churn after onboarding. Search the codebase and brainstorm 10 places we could intervene, from cheapest to most ambitious. I’ll tell you which ones resonate.”

访谈 · Interviews

风暴够了之后，多半还剩一些未知。

Once I’ve done sufficient brainstorming, I likely still have unknowns.

这时我会让 Claude 围绕那些含糊的地方来访谈我。让 Claude 访谈你时，尽量把问题背景交代给它，让它的提问有方向。举个例子。

In this case, I ask Claude to interview me about any unknowns or ambiguities. When asking Claude to interview you, try and give it context about your problem to guide its questions. Here are some examples.

示例 prompt：

• 「一次一个问题地访谈我，凡是含糊的都可以问；优先问那些我的回答会改变架构的问题。」

• “Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture.”

参考物（References）

有时候你就是没法把想要的东西描述清楚——可能是缺少语言，也可能它太复杂，讲清楚得花好一阵。

Sometimes you can’t describe what you want in detail. For example, you might not have the language or it might be so complicated that it would take you quite a while.

这时最好的答案是给参考。图表、文档、截图都行，但最好的参考是源码。

In this case, the best answer is a reference. While you can include diagrams, documentation or pictures, the absolute best reference is source code.

如果某个库把一样东西实现得正合你意，或者你特别喜欢某个设计组件，直接把 Fable 指到那个目录、告诉它看什么——哪怕那是另一门语言写的。

If you have a library that implements something in a certain way or a design component you really like, just point Fable at the folder and tell it what to look for, even if it’s in a different language.

Claude Design 也是这么工作的。你不用非得递文件（当然也可以），你可以把它指向某个你喜欢的网站上的模块，它读的是底层代码，而不只是截图。这样拿到的信息——标记、结构、组件实际是怎么搭的——细节要丰富得多。

This is also the way Claude Design works. You don’t have to hand it a file (although you can do that too). You can point it at a module on a website you like, and it reads the underlying code, not just the screenshot. This provides much richer detail around the markup, structure, and how the component is actually built.

示例 prompt：

• 「vendor/rate-limiter 里这个 Rust crate 实现的正是我要的 backoff 行为。读一遍，然后在我们的 TypeScript API client 里把同样的语义重新实现出来。」

• This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client.

实现计划 · Implementation Plans

当我觉得可以动手实现了，我会让 Claude 先整理一份实现计划给我审，重点放在最可能变动的部分——比如数据模型、类型接口、UX 流程。这样 Claude 能把我真正可能要改的东西先亮出来。

When I think I’m ready to implement, I tend to ask Claude to put together an implementation plan for me to review that focuses on the parts that might be most likely to change, for example to review data models, type interfaces or UX flows. This allows Claude to surface things I might actually need to alter.

示例 prompt：

• 「用 HTML 写一份实现计划，把我最可能要调整的决定放在最前面：数据模型改动、新的类型接口、所有用户可感知的部分。机械性的重构埋到最后，那部分我信你。」

• Write an implementation plan in HTML, but lead with the decisions I’m most likely to tweak with: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part.”

实现中 · During implementation

实现笔记 · Implementation notes

对计划满意之后，我会开一个新 session，把各种 artifact 传进 prompt。比如传一份 spec 文件加一个原型，让 agent 照着实现。

Once I am satisfied with my plan, I make a new session and pass any artifacts to the prompt. For example, I might pass in a spec file and a prototype and ask an agent to implement it.

但实话是：无论计划做得多足，总有未知的未知埋伏着。agent 干活时可能发现代码里某个边界情况，不得不换个打法。

But the truth is that no matter how much planning you do, there are always unknown unknowns lurking. The agent may find during its work that it needs to take a different tack due to an edge case it found in the code.

我会让 Claude Code 维护一份临时的 implementation-notes.md（或 .html），把它做的各种决定记下来，供下一次复盘学习。

I ask Claude Code to keep a temporary ‘implementation-notes.md’ (or .html) file where it keeps track of decisions it makes so we can learn from our next attempt.

示例 prompt：

• 「维护一份 implementation-notes.md。如果撞上边界情况、不得不偏离计划，选保守的那条路，记到『Deviations』下面，然后继续干。」

• “Keep an implementation-notes.md file. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under ‘Deviations’, and keep going.”

实现后 · Post-implementation

Pitch 与讲解文档 · Pitches and explainers

要把东西发出去，最重要的环节之一是拿到认同（buy-in）和审批。在最终文档里做好 pitch 和讲解类 artifact，能帮你：

One of the most important parts of shipping something is getting buy-in and approvals. Building pitch and explainer artifacts in the final document helps:

• 加速理解：审阅者上手时的未知，和你当初一模一样
• 加速审批：专家想看到，他们预料中的未知和常见翻车点你都考虑到了

• Accelerate understanding when reviewers start with the same unknowns you did
• Accelerate approvals when experts want to see you accounted for the unknowns and common failure points they would have anticipated

示例 prompt：

• 「把原型、spec、实现笔记打包成一份文档，让我能直接丢进 Slack 拉认同。开头放 demo GIF。」

• “Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in. Lead with the demo GIF.”

小测验 · Quizzes

一场长时间的工作 session 下来，Claude 干的事可能比我意识到的多得多。光读代码 diff 只能了解个大概，因为很多行为取决于既有的代码路径。

After a long working session, Claude might have accomplished a lot more than I realized. Reading the code diffs can only give me a light understanding of what happened, since much of the behavior will depend on existing code paths.

让 Claude 在给足我上下文之后，就这次改动考我一考，能帮我真正搞懂发生了什么。我只有满分通过才 merge。

Asking Claude to quiz me about the change after giving me a bunch of context helps me understand what happens. I only merge after I pass the quiz perfectly.

示例 prompt：

• 「我想确认自己完全理解这次改动发生了什么。给我一份关于这些改动的 HTML 报告——背景、直觉、都做了什么等等——最后附一份关于改动的小测验，我必须通过。」

• “I want to make sure I understand everything that’s happened in this change. Give me a HTML report on the changes for me to read and understand with context, intuition, what was done, etc. and a quiz at the bottom on the changes that I must pass.”

串起来看：Fable 发布视频是怎么剪出来的 · How this comes together: launching Fable

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

The launch video for Fable was edited entirely by Claude Code. This was a new domain for me and I’m by no means an expert.

于是我从已知的部分下手。我知道 Claude 能用代码剪视频、做转写，但不确定精度够不够。我先让 Claude 给我讲 Whisper 这类转写是怎么工作的，以及能不能用 ffmpeg 精确剪掉「嗯……」和长停顿。

So I started with what I did know. I knew that Claude could use code to edit videos and transcribe them, but I wasn’t sure if it was accurate enough. I then asked Claude to explain to me how transcription like Whisper worked, and whether I would be able to accurately cut out things like ums or large pauses using ffmpeg.

我想让 Claude 做一个跟我说的话逐词同步的 UI，但不确定它做不做得到，于是让 Claude 用 Remotion 加一份转写先做了个原型视频试试水。

I wanted Claude to create a UI that was timed with the words I was saying, but wasn’t sure if it would be able to so I asked Claude to create a prototype video using Remotion and a transcription to see if it would work.

最后，视频本身看着有点发闷。我知道这是调色（color grading）的问题，但我并不真懂调色是什么。第一反应是让 Claude 出几版让我挑，后来意识到：在调色这件事上，我根本不知道「好」长什么样。于是换了个方式——让 Claude 教我调色，去发现我的未知。

Finally, the video itself looked a bit muted, which I knew was the result of color grading but I didn’t really know what color grading was. My first pass attempt was to try and get Claude to do a few variations to pick, but I realized that I didn’t know what “good” looked like when it came to color grading. So instead, I asked Claude to teach me about color grading to discover my unknowns.

更完整的讲解可以看这里。

You can watch a more in-depth explanation on that here.

让地图对上疆域 · Matching the Map and Territory

模型越强，方法用对能做到的就越多。当一个长周期任务做回来不对头，多半说明你该花更多时间定义你的未知，或者做一份允许 Claude 在未知处随机应变的实现计划。

The better models get, the more you can achieve with the right approach. When a long-horizon task comes back wrong, it’s likely you need to spend more time defining your unknowns or creating an implementation plan that allows for Claude to improvise through them.

每一次讲解、头脑风暴、访谈、原型和参考，都是在「修起来很贵」之前，用便宜的方式买到你原本不知道的信息。

Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn’t know before it gets expensive to fix.

所以，下一个项目就这么开场吧：让 Claude 帮你找出你的未知。

So start your next project by asking Claude to help you find your unknowns.