# A Field Guide to Fable: Finding Your Unknowns
**作者**: Thariq
**日期**: 2026-07-03T17:43:35.000Z
**来源**: [https://x.com/trq212/status/2073100352921215386](https://x.com/trq212/status/2073100352921215386)
---
Working with Claude Fable 5 keeps re-teaching me an old lesson: the map is not the territory.
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.
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 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.
I’ve found that working with Fable is an iterative process of discovering my unknowns before, during, and after implementation.
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
What are your unknowns? When I come to Claude with a problem I tend to break it down in 4 ways:
- 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?
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.
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.
## Help Claude help you
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.
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 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.
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.
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
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.
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
Example Prompts:
- “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
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.
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.
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.
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.
Example prompts:
- "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.
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.
Example prompts:
- "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.
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.
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.
Example prompts:
- 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
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.
Example Prompts:
- 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
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.
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.
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.
Example prompts:
- "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
## Pitches and explainers
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
Example prompts:
- "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
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.
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.
Example prompts:
- “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.”
## How this comes together: launching Fable
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.
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.
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.
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
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.
So start your next project by asking Claude to help you find your unknowns.
## 相关链接
- [Thariq](https://x.com/trq212)
- [@trq212](https://x.com/trq212)
- [2.1M](https://x.com/trq212/status/2073100352921215386/analytics)
- [example artifacts for finding unknowns here,](https://thariqs.github.io/html-effectiveness/unknowns/)
- [Boris](https://www.google.com/url?q=https://www.linkedin.com/in/bcherny&sa=D&source=editors&ust=1783101769343560&usg=AOvVaw0NSN4RLOEaJ_k7bIWfat2t)
- [Jarred](https://www.google.com/url?q=https://www.linkedin.com/in/jarred-sumner-a8772425&sa=D&source=editors&ust=1783101769343738&usg=AOvVaw1jFeuVIbBffAC5464Tk_TD)
- [HTML with Claude](https://x.com/trq212/status/2052809885763747935)
- [implementation-notes.md](https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359369&usg=AOvVaw1Iqvg51JpzkrkRtHHIjyOL)
- [implementation-notes.md](https://www.google.com/url?q=http://implementation-notes.md&sa=D&source=editors&ust=1783101769359896&usg=AOvVaw1wFqbnqbAuO_GYnGk8_1bh)
- [launch video for Fable](https://www.google.com/url?q=https://x.com/ClaudeDevs/status/2064399512664526853&sa=D&source=editors&ust=1783101769363678&usg=AOvVaw1MyZd5YMjjShztWHzo8N9u)
- [here](https://x.com/trq212/status/2064826394589442448/video/1)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:43 AM · Jul 4, 2026](https://x.com/trq212/status/2073100352921215386)
- [2.1M Views](https://x.com/trq212/status/2073100352921215386/analytics)
- [View quotes](https://x.com/trq212/status/2073100352921215386/quotes)
---
*导出时间: 2026/7/5 17:16:19*
---
## 中文翻译
# Fable 现场指南：发现你的未知
**作者**: Thariq
**日期**: 2026-07-03T17:43:35.000Z
**来源**: [https://x.com/trq212/status/2073100352921215386](https://x.com/trq212/status/2073100352921215386)
---
与 Claude Fable 5 共作不断给我重授一门旧课：地图不等于疆域。
地图，即待做工作的表征，是我的提示词、技能和上下文，也是我给 Claude 的东西。疆域则是工作实际发生的地方，即代码库、现实世界及其真实的约束。
地图与疆域之间的差异，就是我所谓的“未知”。当 Claude 遇到一个未知时，它需要根据它对我意图的最佳猜测来做出决定。工作量越大，Claude 可能遇到的未知就越多。
Fable 是第一个让我觉得工作质量受限于我阐明其未知能力的模型。
重要的是，仅仅提前规划往往是不够的。你可能会在实现深处的细节中发现未知，或者你的未知可能会指向这样一个事实：你实际上应该完全用另一种方式来解决这个问题。
我发现，与 Fable 协作是一个迭代的过程，旨在实现前、实现中和实现后发现我的未知。
我在这里制作了一些用于发现未知的示例工件，但请务必回来阅读，以建立关于何时使用它们的直觉。
## 了解你的未知
你的未知有哪些？当我带着问题去找 Claude 时，我倾向于用 4 种方式来分解它：
- **已知已知**：这本质上就是我的提示词里的内容。我告诉代理我想要什么？
- **已知未知**：我还没有弄清楚什么，但我意识到我还没弄清楚？
- **未知已知**：什么是我觉得显而易见、永远不会写下来，但如果看到就能认出来的东西？
- **未知未知**：我完全没有考虑到什么？有哪些知识是我不知道自己不知道的？我知道某件事能做到多好吗？
最好的代理型编码者的未知相对较少。看像 Boris 或 Jarred 这样的人如何编写提示词，很明显他们知道自己在细节上想要什么。他们与代码库和模型行为都保持着深度的同步。
但他们也会预设未知。在许多方面，减少并规划你的未知是代理型编码的技能。但幸运的是，这是一项你可以通过与 Claude 合作来提高的技能。
## 帮助 Claude 帮助你
指示 Claude 是一种微妙的平衡。如果你太具体，Claude 会遵循你的指示，即使做出转向可能更合适。如果你太含糊，Claude 经常会根据行业最佳实践做出选择和假设，而这些可能不适合你的任务。
当你不考虑你的未知时，你在两方面都会失败。你不知道路径何时会充满障碍，也不知道路径何时会畅通，但你仍然希望 Claude 转向。
Claude 可以帮助你更快地发现你的未知。它可以极快地搜索你的代码库和互联网，并且它对大多数话题的了解远超你。它还可以更快地从失败中迭代。
这个过程最重要的部分是给 Claude 关于你起点的上下文。例如，告诉它你在思考过程中的哪个阶段；披露你对问题和代码库的经验；让它像思考伙伴一样与你协作。
我以前写过关于使用 HTML 与 Claude 协作的文章，在几乎所有这些情况下，HTML 工件都是可视化和表征它的最佳方式。
在本文中，我详细介绍了我发现这些未知的一些模式。我每次不会使用每种技巧，但这拥有一套有用的技巧集合。
# 实现阶段之前
## 盲点排查
开始工作时，最有用的做法之一是了解你的盲点。例如，如果你要在代码库的新部分编写功能，或者使用 Claude 帮助你处理不熟悉的工作（如迭代设计），你很可能会有很多“未知未知”。
你可能不知道该问什么问题，不知道“好”是什么样，不知道做过哪些历史工作，或者有哪些坑要避免。
为此，你可以要求 Claude 帮你找到你的“未知未知”并向你解释。我喜欢使用字面上的“盲点排查”和“未知未知”这些词。给它关于你是谁以及你知道什么的上下文通常对于
**示例提示词：**
- “我正在添加一个新的认证提供商，但我对这个代码库中的认证模块一无所知。你能做一个盲点排查，帮我找出相关的未知未知，并帮我更好地给你写提示词吗？”
- “我不知道什么是调色，但我需要调色这段视频。你能教我了解我在调色方面的未知未知，以便我能更好地提示你吗？”
## 头脑风暴与原型
当我在一个有很多“未知已知”的领域工作时，涉及那些只有看到时我才知道如何定义的标准，我喜欢让 Claude 与我一起进行头脑风暴和制作原型。
在原型制作早期识别并说出“未知已知”是非常有价值的，因为在实现阶段发现它们（相对）代价昂贵。功能或规格上的微小变化可能会导致代码实现产生巨大的差异，而且你的代理可能更难回退之前的更改。
例如，你可能只是想看看添加到框架上的按钮是什么样子，而不必连接后端路由或在前端维护额外的状态。
视觉设计对我来说是难以表达的东西，但我知道当我看到它时我想要什么。在这些情况下，我会要求为工件提供几种设计方法。
我也几乎在每个编码会话开始时都有一个探索或头脑风暴阶段。这帮助我从定义项目范围的意图开始。Claude 经常发现我可能会错过的高价值方法，但有时也会见树不见林。头脑风暴防止我设定太窄或太宽的范围。
**示例提示词：**
- "我想要一个用于这些数据的仪表板，但我没有视觉品味，不知道什么是可能的。给我制作一个 HTML 页面，包含 4 种截然不同的设计方向，以便我能做出反应。"
- “在连接任何东西之前，制作一个单独的 HTML 文件，使用假数据模拟新的编辑器工具栏。我想在你在真实应用上动手之前对布局做出反应。”
- "这是我的粗略问题：用户在引导后流失。搜索代码库并头脑风暴 10 个我们可以干预的地方，从成本最低到最雄心勃勃。我会告诉你哪些能引起共鸣。"
## 访谈
一旦我做了足够的头脑风暴，我可能仍然有未知。
在这种情况下，我要求 Claude 就任何未知或歧义采访我。当要求 Claude 采访你时，尝试给它关于你问题的上下文以引导它的问题。这里有一些例子。
**示例提示词：**
- "每次问一个关于任何模棱两可之处的问题，优先考虑那些我的答案会改变架构的问题。"
## 参考资料
有时你无法详细描述你想要的东西。例如，你可能没有相应的语言，或者它可能太复杂，需要很长时间。
在这种情况下，最好的答案是参考资料。虽然你可以包括图表、文档或图片，但绝对最好的参考是源代码。
如果你有一个以某种方式实现某事的库，或者你非常喜欢的设计组件，只需将 Fable 指向该文件夹并告诉它要寻找什么，即使它是用不同的语言编写的。
这也是 Claude Design 的工作方式。你不必递给它一个文件（尽管你也可以那样做）。你可以把它指向你喜欢的网站上的一个模块，它会读取底层代码，而不仅仅是截图。这提供了关于标记、结构以及组件实际构建方式的更丰富细节。
**示例提示词：**
- vendor/rate-limiter 中的这个 Rust crate 实现了我想要的确切退避行为。阅读它并在我们的 TypeScript API 客户端中重新实现相同的语义。
## 实现计划
当我认为准备好实施时，我倾向于要求 Claude 为我制定一个实现计划供我审查，该计划侧重于最可能改变的部分，例如审查数据模型、类型接口或 UX 流程。这允许 Claude 提出我实际上可能需要更改的事情。
**示例提示词：**
- 用 HTML 编写实现计划，但以我最可能调整的决定开头：数据模型更改、新的类型接口以及任何面向用户的内容。将机械性的重构放在底部，那部分我信任你。"
## 实现过程中
## 实现笔记
一旦我对我的计划感到满意，我会创建一个新会话并将任何工件传递给提示词。例如，我可能会传入一个规范文件和一个原型，并要求代理实现它。
但真相是，无论你做多少计划，总有潜伏的“未知未知”。代理可能会在工作中发现，由于在代码中发现的边缘情况，它需要采取不同的方法。
我要求 Claude Code 保持一个临时的“implementation-notes.md”（或 .html）文件，在其中跟踪它所做的决定，以便我们可以从下一次尝试中学习。
**示例提示词：**
- "保持一个 implementation-notes.md 文件。如果你遇到边缘情况，迫使你偏离计划，选择保守的选项，将其记录在‘偏差’下，然后继续。"
# 实现之后
## 推介与解释
发布产品最重要的部分之一是获得认可和批准。在最终文档中构建推介和解释工件有助于：
- 当审阅者从与你相同的未知开始时，加速他们的理解
- 当专家希望看到你考虑到他们会预见的未知和常见故障点时，加速批准
**示例提示词：**
- "将原型、规范和实现 notes 打包成一个我可以丢进 Slack 以获得批准的文档。以演示 GIF 开头。"
## 测验
经过漫长的工作会话后，Claude 可能比我意识到的完成的要多得多。阅读代码差异只能给我对发生的事情的轻微了解，因为大部分行为将取决于现有的代码路径。
在给我一堆上下文后，要求 Claude 就更改对我进行测验有助于我理解发生了什么。只有在我通过测验后我才会合并。
**示例提示词：**
- “我想确保我理解此更改中发生的一切。给我一份关于更改的 HTML 报告供我阅读和了解，其中包含上下文、直觉、做了什么等，并在底部包含一个我必须通过的关于更改的测验。”
## 这些如何整合：发布 Fable
Fable 的发布视频完全由 Claude Code 编辑。这对我来说是一个新领域，我绝不是专家。
所以我从我所知道的开始。我知道 Claude 可以使用代码来编辑视频并转录它们，但我不确定它是否足够准确。然后我要求 Claude 向我解释像 Whisper 这样的转录是如何工作的，以及我是否能够准确地使用 ffmpeg 剪掉诸如“嗯”之类的词或长停顿。
我想让 Claude 创建一个与我说的话同步的 UI，但我不确定它是否能做到，所以我要求 Claude 使用 Remotion 和一个转录创建一个原型视频来看看它是否可行。
最后，视频本身看起来有点沉闷，我知道这是调色的结果，但我真的不知道什么是调色。我的第一次尝试是尝试让 Claude 做几个变体供选择，但我意识到我不知道调色方面的“好”是什么样。所以我改为要求 Claude 教我关于调色的知识，以发现我的未知。
你可以在这里观看更深入的解释。
## 匹配地图与疆域
模型越好，只要方法得当，你能实现的就越多。当一个长周期任务返回错误时，很可能你需要花更多时间定义你的未知，或者创建一个允许 Claude 即兴发挥的实现计划。
每一个解释器、头脑风暴、访谈、原型和参考，都是在修复成本变高之前，以低成本找出你以前不知道的东西的途径。
所以，开始你的下一个项目时，先请 Claude 帮你找出你的未知。