找出你的 Unknowns
跟 Claude Code 协作，地图是你交给它的 prompt、skill、context；地形是代码真正跑的地方。两者的差距，就是 unknowns。Thariq Shihipar 说，Fable 是第一个这样的模型：产出质量卡在你能不能把 unknowns 讲清楚，而不再卡在模型能力上。
差距有个名字，叫 unknowns
Thariq 用「地图与地形」（the map and the territory）来描述跟 Claude Code 协作的处境。地图是你交给 Claude 的东西：prompt、skill、context；地形是工作真正发生的地方，即代码库、真实世界、它实际的约束。两者之间的差距，他称为 unknowns。
Claude 撞上一个 unknown 时，只能基于「它猜你想要什么」来做决定。做的事越多，可能撞上的 unknowns 就越多。他给这套方法定的基调是一句判断：
"Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns."
在他看来，Fable 是第一个这样的模型：产出质量卡在你能不能把 unknowns 讲清楚，而不再卡在模型能力上。他同时提醒，光靠提前规划并不总够用。unknowns 可能藏在实现的深处才冒出来；也可能你挖出来的 unknown 反过来告诉你：这个问题本该换一种方式解。所以跟 Fable 协作，是一个在动手前、动手中、动手后不断发现自己 unknowns 的迭代过程。
把 unknowns 分成四类
Thariq 拿到一个问题时，习惯按四个维度拆解。右下那一格（unknown unknowns）通常最贵，因为你连要问什么都不知道。
在他的观察里，最好的 agentic coder 的 unknowns 相对很少。看 Boris 或 Jarred 这样的人 prompt，能明显感觉到他们非常清楚自己要什么的细节，跟代码库和模型行为都深度同步。但他们同样会预设存在 unknowns。由此他给出这门手艺的定义：
"In many ways, reducing and planning for your unknowns is the skill of agentic coding."
好在这是一项能靠跟 Claude 协作而练出来的技能。
给 Claude 下指令的平衡
给 Claude 下指令是个微妙的平衡：太具体，Claude 会死守你的指令，哪怕换个方向更合适也照做；太模糊，Claude 往往会按行业最佳实践去做选择和假设，而那未必贴合你的任务。不处理 unknowns，就两头都会出问题。反过来，Claude 能帮你更快地发现 unknowns：它能极快地检索你的代码库和互联网，它对大多数话题的了解比你多，也能更快地从失败里迭代。这套里最重要的一步，是给 Claude 关于你起点的 context：告诉它你在思考的哪个阶段、坦白你对这个问题和这套代码库的经验，让它像一个思考伙伴（thought partner）那样跟你一起工作。
动手前：先把 unknowns 逼出来
原文把挖 unknowns 的 pattern 分成三段：动手前、动手中、动手后。动手前这一段最厚，五个 pattern，每个都附了可照抄的 prompt。
Blind Spot Pass（盲点扫描）
进代码库里陌生的部分、或做设计迭代这类不熟悉的工作时，你很可能有大量 unknown unknowns：不知道该问什么、不知道「好」长什么样、不知道有哪些坑。让 Claude 帮你找出这些 unknown unknowns 并讲给你听。Thariq 说他喜欢直接用「blind spot pass」和「unknown unknowns」这两个字面词，并给 Claude 关于「你是谁、你懂多少」的 context。
"I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blind spot 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（头脑风暴与原型）
在满是 unknown knowns（看到才知道要不要）的领域里，让 Claude 跟你一起 brainstorm 和做原型。早点把 unknown knowns 说出来很有价值，因为等到实现阶段才发现它们代价更高：spec 的小改动可能导致代码里天差地别的实现。他几乎每个 coding session 都以一段探索或 brainstorm 开场，用来定 scope，防止定得太窄或太宽。
"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 real 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（让 Claude 反过来采访你）
brainstorm 做够之后通常还剩 unknowns。让 Claude 就任何 unknown 或含糊之处采访你，尽量给它关于你问题的 context 来引导提问。
"Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture."
References（给参照物）
有时候你没法把想要的东西描述清楚：可能没有对应的语言，也可能讲清楚要花很久。这时最好的办法是给一个参照，而最好的参照是源码。有个库实现了你要的效果、或有个你喜欢的组件，就直接把 Fable 指到那个文件夹、告诉它去看什么，哪怕是另一种语言。比起截图，源码能给 Claude 更丰富的标记和结构细节。
"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 出一份实现计划给你 review。这份计划聚焦最可能变的部分（数据模型、类型接口、UX 流程），好让 Claude 把他可能真要改的地方先摆出来。
"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."
动手中：让 agent 记下它偏离计划的地方
对计划满意后，Thariq 会开一个新 session，把之前的 artifact 传进 prompt。这样 Claude 拿到的是一个干净的 context window，但带着规划阶段编好的全部信息，比如一个 spec 文件加一个原型。
但无论规划做得多足，总有 unknown unknowns 潜伏着。agent 执行时可能发现，因为代码里的某个边界情况，它得换个打法。所以他会让 Claude Code 维护一个临时的 implementation-notes.md（或 .html）文件，把它做的决定记下来，供下一次尝试学习。
"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."
动手后：用 unknowns 反过来验收
交付和验收也绕着 unknowns 转：让别人少踩你踩过的坑，也确认自己真看懂了 agent 做了什么。
Pitches and explainers（推介与讲解）
在他看来，把成果交付出去、拿到认可与批准，是发布里最重要的环节之一。在最终文档里搭 pitch 和 explainer 类 artifact 有两个作用：当审阅者带着跟你当初一样的 unknowns 起步时，加速他们的理解；当专家想确认你已经考虑过他们本会预料到的 unknowns 和常见失败点时，加速批准。
"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（让 Claude 考你）
一段长的工作 session 之后，Claude 可能完成的东西比他意识到的多得多。光读代码 diff 只能给他一个浅层理解，因为很多行为取决于已有的代码路径。让 Claude 在给他大量 context 之后就这次改动来考他，能帮他弄清到底发生了什么。他只在测验全对之后才 merge。
"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 发布视频，就是这套的一次实跑
Fable 的发布视频，是他全程用 Claude Code 剪出来的。这对他是个全新领域，用他自己的话说，他绝不是这方面的专家。整个过程就是从已知出发、逐个把 unknown 补上。
从已知出发
他知道 Claude 能用代码剪辑、能转录，但不确定精度。于是让 Claude 讲解 Whisper 这类转录怎么工作、能不能用 ffmpeg 准确切掉「呃」这种语气词和大的停顿。
拿原型验证不确定的地方
他想要一个跟他说话的词同步的 UI，但不确定可行，于是让 Claude 用 Remotion 和一份转录做一个原型视频，看看行不行。
让 Claude 教你什么是「好」
视频看起来有点发灰，他知道是调色（color grading）的结果，但不太懂调色。第一次想让 Claude 做几个变体来挑，却意识到自己根本不知道调色里「好」长什么样，于是改成让 Claude 教他调色，来发现自己的 unknowns。
让地图对上地形
原文收尾落在一句方法论判断上：模型越好，用对方法能达成的就越多。当一个长周期任务返回的结果是错的，很可能是你需要花更多时间去定义你的 unknowns，或者做一份能让你和 Claude 在过程中随之调整的实现计划。
"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."
在他看来，每一次 explainer、brainstorm、interview、prototype 和 reference，都是在「搞清你不知道的事」还便宜的时候把它搞清，别等它变贵。所以下个项目的开头，先让 Claude 帮你找出你的 unknowns。
→ github.com/aws-samples/sample-aws-ops-skills-for-agents ·
finding-your-unknowns