# 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 提供关于你出发点的上下文。例如，告诉它你的思考过程进行到了哪一步；说明你在这个问题和这个代码库上的经验水平；让它像一个思考伙伴一样与你协作。
我之前写过关于在 Claude 中使用 HTML 的文章，在几乎所有这些场景中，HTML 产物都是可视化和呈现的最佳方式。
在本文中，我详细介绍了我用的一些发现这些未知之处的模式。我并不是每次都用所有技巧，但这是一个值得掌握的实用技巧合集。
# 实现之前
## 盲点扫描
在开始工作时，你能做的最有用的事情之一就是了解自己的盲点。例如，如果你要在代码库的一个陌生部分编写功能，或者使用 Claude 帮助你完成不熟悉的工作（比如设计迭代），你很可能有大量未知的未知。
你可能不知道该问什么问题、好的标准是什么、过去做过哪些工作、要避开哪些坑。
为此，你可以让 Claude 帮助你找到你的未知未知并向你解释。我喜欢直接使用“盲点扫描”和“未知未知”这些字面词汇。向它提供关于你是谁、你知道什么的上下文通常很重要。
示例提示词：
- “我正在添加一个新的认证提供方，但我对这个代码库中的认证模块一无所知。你能做一次盲点扫描，帮我找出我相关的未知未知，并帮我更好地向你提问吗？”
- “我不知道什么是调色，但我需要给这个视频调色。你能教我理解关于调色的未知未知，以便我能更好地提问吗？”
## 头脑风暴与原型
当我在一个有大量未知的已知（即那些只有看到才能定义的标准）的领域工作时，我喜欢让 Claude 和我一起进行头脑风暴和制作原型。
在原型阶段尽早识别并表达出未知的已知是非常有价值的，因为在实现阶段才发现它们（相对）成本高昂。功能或规范中的微小改动可能导致截然不同的代码实现，而且你的智能体回滚之前的改动可能会更困难。
例如，你可能只是想看看添加到框架上的按钮是什么样子，而不必接入后端路由或在前端维护额外的状态。
视觉设计对我来说是难以言表的东西，但当我看到时我就知道是不是我想要的。在这些情况下，我会要求为产物提供几种设计思路。
我也几乎每次编码会话都以探索或头脑风暴阶段开始。这帮助我带着明确意图去界定项目范围。Claude 经常能发现一些我会错过的高价值方案，但有时也会只见树木不见森林。头脑风暴能防止我把范围定得过窄或过宽。
示例提示：
- “我想为这些数据做一个仪表盘，但我毫无视觉品味，也不知道有哪些可能性。做一个包含 4 种截然不同设计方向的 HTML 页面，让我可以对它们做出反馈。”
- “在连接任何东西之前，先用假数据做一个模拟新编辑器工具栏的单个 HTML 文件。我想在你动真正的应用之前先对布局做出反馈。”
- “这是我大概的问题：用户在完成新手引导后流失。搜索代码库，头脑风暴出 10 个我们可以介入的地方，从成本最低到最雄心勃勃的排序。我会告诉你哪些让我有共鸣。”
## 访谈
在我完成了充分的头脑风暴之后，可能仍然存在未知之处。
在这种情况下，我会让 Claude 就这些未知或模糊之处对我进行访谈。让 Claude 访谈你时，尽量给它提供关于你的问题的背景信息，以引导它的提问。以下是一些例子。
示例提示：
- “一次问我一个关于任何模糊之处的问题，优先问那些我的答案会改变架构的问题。”
## 参考
有时候你无法详细描述你想要的东西。例如，你可能没有合适的语言来表达，或者它太复杂，需要花很长时间才能说清楚。
在这种情况下，最好的答案是提供参考。虽然你可以提供图表、文档或图片，但绝对最好的参考是源代码。
如果你有一个以某种方式实现某功能的库，或者一个你非常喜欢的设计组件，只需让 Fable 指向那个文件夹，告诉它要找什么，即使它是用不同的语言编写的。
这也是 Claude Design 的工作方式。你不必给它一个文件（虽然你也可以这样做）。你可以让它指向你喜欢的网站上的一个模块，它会读取底层代码，而不仅仅是截图。这能提供关于标记、结构以及组件实际构建方式的更丰富的细节。
示例提示：
- vendor/rate-limiter 里的这个 Rust crate 正好实现了我想要的退避行为。读一下它，并在我们的 TypeScript API 客户端中重新实现同样的语义。
## 实施计划
当我觉得可以开始实施了，我通常会让 Claude 为我制定一个实施计划供我审查，重点放在最有可能需要变动的部分，例如审查数据模型、类型接口或 UX 流程。这让 Claude 能够呈现那些我可能真正需要修改的内容。
示例提示：
- 用 HTML 写一份实施计划，但把最有可能需要我调整的决策放在最前面：数据模型变更、新的类型接口，以及任何面向用户的内容。把机械性的重构放在最后，那部分我信任你。”
## 实施过程中
## 实施笔记
当我对计划满意后，我会开一个新的会话，把所有产出物传给提示。例如，我可能会传入一份规格说明文件和一个原型，让 agent 去实现它。
但事实是，无论你做多少规划，总会有未知的未知潜伏着。agent 在工作过程中可能会发现，由于在代码中发现了一个边缘情况，它需要采取不同的方法。
我会让 Claude Code 维护一个临时的 'implementation-notes.md'（或 .html）文件，记录它做出的决策，以便我们在下一次尝试时学习。
示例提示：
- “维护一个 implementation-notes.md 文件。如果你遇到迫使你偏离计划的边缘情况，选择保守的方案，把它记录在 'Deviations'（偏差）下，然后继续。”
# 实施之后
## 提案与说明文档
发布某个东西最重要的部分之一是获得认同和批准。在最终文档中构建提案和说明材料有助于：
- 当审查者与你当初有同样的未知时，加速他们的理解
- 当专家想看到你已经考虑到了他们预想到的未知和常见故障点时，加速审批
示例提示：
- “把原型、规格说明和实施笔记打包成一份文档，我可以直接发到 Slack 以获得认同。把演示 GIF 放在最前面。”
## 测验
在长时间的会话之后，Claude 完成的工作可能比我意识到的多得多。阅读代码差异只能让我对发生的事情有浅层的了解，因为很多行为都依赖于现有的代码路径。
在 Claude 给我提供大量背景之后，让它就这次改动对我进行测验，能帮助我理解发生了什么。只有完美通过测验后我才会合并代码。
示例提示：
- “我想确保自己理解了这次改动中发生的一切。给我一份关于这些改动的 HTML 报告，包含背景、设计直觉、做了什么等内容，让我阅读和理解，并在末尾附上一个我必须通过的关于这些改动的测验。”
## 这些如何结合在一起：发布 Fable
Fable 的发布视频完全由 Claude Code 剪辑。这对我来说是一个全新的领域，我绝不是这方面的专家。
所以我从我确实了解的东西开始。我知道 Claude 可以用代码来剪辑视频和转录它们，但我不确定它的准确性是否足够。于是我问 Claude 解释像 Whisper 这样的转录工具是如何工作的，以及我是否能用 ffmpeg 准确地剪掉诸如“嗯”之类的语气词或大段停顿。
我想让 Claude 创建一个与我所说的话时间同步的 UI，但不确定它是否能做到，所以我让 Claude 使用 Remotion 和一份转录文本创建一个原型视频，看看是否可行。
最后，视频本身看起来有点暗淡，我知道这是调色（color grading）的结果，但我并不真正了解什么是调色。我的第一反应是让 Claude 做出几个不同的版本供我挑选，但我意识到我并不知道调色的“好”标准是什么。于是，我改为让 Claude 教我调色知识，以发现自己的未知之处。
你可以在这里观看更深入的讲解。
## 让认知与实际相符
模型越好，用正确的方法能达成的成果就越多。当一个长周期任务的结果出错时，很可能你需要花更多时间来明确你的未知之处，或制定一个能让 Claude 在其中灵活应变（improvise）的实施计划。
每一个讲解、头脑风暴、访谈、原型和参考资料，都是在问题变得修复成本高昂之前，低成本发现未知之处的途径。
所以，开始你的下一个项目时，先让 Claude 帮你找出你的未知之处吧。
## 相关链接
- [Thariq](https://x.com/trq212)
- [@trq212](https://x.com/trq212)
- [2.1M](https://x.com/trq212/status/2073100352921215386/analytics)
- [查找未知之处的示例工件，点击这里](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)
- [用 Claude 做 HTML](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)
- [Fable 的发布视频](https://www.google.com/url?q=https://x.com/ClaudeDevs/status/2064399512664526853&sa=D&source=editors&ust=1783101769363678&usg=AOvVaw1MyZd5YMjjShztWHzo8N9u)
- [这里](https://x.com/trq212/status/2064826394589442448/video/1)
- [升级至高级版](https://x.com/i/premium_sign_up)
- [2026年7月4日 凌晨1:43](https://x.com/trq212/status/2073100352921215386)
- [210万次浏览](https://x.com/trq212/status/2073100352921215386/analytics)
- [查看引用](https://x.com/trq212/status/2073100352921215386/quotes)
---
*导出时间: 2026/7/5 17:16:19*
