你到底缺的是哪种「不知道」

作者带着一个问题来找 Claude 时，习惯先把手里的未知分成四格。越大的活儿，越容易掉进后两格：那些你压根没意识到，或者理所当然到从来不会写下来的东西。

原文配图：作者把开工前的未知拆成四类，越大的项目越容易踩进后两类。来源：X · Thariq

作者观察到，最强的那批协作者，比如 Boris Cherny 或 Jarred Sumner，未知相对很少：看他们下提示词，明显知道自己要什么、和代码库与模型行为都很同步。但他们同样会为未知留出余地。减少并预先安排好自己的未知，某种意义上就是和 Claude 协作的核心功夫，而这门功夫可以靠和 Claude 一起练出来。

教 Claude 干活，为什么太细和太糙都会翻车

给 Claude 交代任务像走钢丝。交代得太细，它会照着你写的每一步做，哪怕中途该换方向也不敢转；交代得太糙，它会按行业里通用的最佳做法去猜，未必合你的场景。当你没算好自己的未知，两头都会栽：你不知道路上哪段有坑，也不知道哪段其实很通畅，却又还是想让它该转弯时敢转弯。

好在 Claude 能帮你更快发现未知：它翻代码库、查网络都极快，对多数话题懂得也比你多，还能从失败里快速迭代。这个过程里最重要的一步，是把你的起点讲给它听：告诉它你的思考进度、你对这个问题和代码库的经验深浅，让它像思考搭档一样跟你一起做。作者也提到，几乎所有这些场景里，一个 HTML 页面都是把想法可视化、摆到眼前的最好方式。

下面这些技法，按「实现前、实现中、实现后」三个阶段排布。作者说他并不是每次都全用，但这是一套值得随手备着的工具箱。

原文配图：指导 Claude 是一种微妙的平衡，太具体和太模糊都会翻车。来源：X · Thariq

先让 Claude 帮你找「你不知道自己不知道」的地方

开工时最有用的一件事，是先搞清自己的盲区。如果你要在代码库里陌生的部分写功能，或者在做设计迭代这种不熟的活儿，你很可能有一大堆未知的未知：不知道该问什么、不知道「好」长什么样、不知道以前有人做过什么、也不知道该躲开哪些坑。

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?

原文配图：作者归纳的发现未知的技法合集。来源：X · Thariq

有些东西你说不清，但一看就知道对不对

这类未知，你说不出标准，但东西摆在面前你立刻知道对不对，这就是「未知的已知」。它们最好在早期靠头脑风暴和原型挖出来：等到写代码时才发现，代价会大得多，规格里一个小改动可能让整块实现推倒重来，而且让 Claude 回退之前的改动也更难。作者几乎每次都从探索或头脑风暴阶段开始，用它来定住项目的范围，既防止铺得太窄，也防止铺得太宽。

头脑风暴与原型

比如你只是想看看给某个界面加个按钮长什么样，并不想真的接后端路由、在前端多维护一份状态。视觉设计对作者来说尤其难用语言讲清，但东西一摆出来他就知道要哪个，这时他会一次要好几种设计方向来对比反应。

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.

让 Claude 反过来访谈你

头脑风暴之后往往还剩一些模糊点。这时让 Claude 反过来逐个问你，并且给它一点关于你这个问题的背景来引导提问，重点是优先问那些「答案会改变架构」的问题。

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

有些东西不知道怎么说，那就直接甩代码给它看

有时候你根本没有词去描述你要什么，或者它复杂到解释起来太费劲。这种时候最好的参考就是源码本身。图、文档、截图都可以给，但绝对最好的参考是源代码。手里有个库按某种方式实现了你想要的行为，或者有个你很喜欢的设计组件，直接把那个文件夹指给 Fable，告诉它看什么，哪怕代码是另一种语言也行。

Claude Design 也是这么工作的。你不必递给它一个文件（当然递也行），你可以把它指向某个网页上你喜欢的模块，它读的是底层代码，而不只是那张截图。这样它拿到的关于标记、结构、组件到底怎么搭起来的细节，要丰富得多。

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.

实现计划：把最可能改的放最前

准备动手时，作者会让 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.

开工以后，让 Claude 边做边记「临时决定」

计划做得再足，实现过程里总会冒出没预料到的未知。作者对计划满意后会新开一个会话，把规格文件、原型这些产物丢进提示词，让一个 agent 去实现。但 Claude 干着干着，可能因为代码里的某个边缘情况需要换个做法。他会让 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.

做完之后，先让 Claude 考你一遍再合并

活儿做完，收尾有两个技法。一个是把成果打包成能拿去要审批的文档，一个是最关键的：让 Claude 反过来考你一遍。

打包说服文档

交付一件东西，很重要的一步是拿到认可和批准。在最终文档里做点「说服」和「讲解」的成分，有两个好处：评审的人和你当初一样带着同样的未知开始读，能更快看懂；懂行的专家想确认你考虑过那些坑和常见失败点，也能更快点头。

原文配图：把原型、规格、实现笔记打包成一份能拿去要审批的文档。来源：X · Thariq

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.

小测验：过不了不合并

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 剪出来。这对作者是个全新领域，他自认外行。整个过程正好把前面的技法串了一遍：他从自己已经知道的东西出发，一步步把未知一个个逼出来。

作者的收尾建议是：模型越强，用对方法能做成的事越多。一个长周期任务返回来是错的，往往说明你需要花更多时间去定义自己的未知，或者写一份能让 Claude 在这些未知里自行发挥的实现计划。每一次讲解、头脑风暴、访谈、原型、参考，都是在便宜的阶段先把你不知道的东西找出来，免得到了贵的阶段再来补。所以，下一个项目，就从让 Claude 帮你找未知的那句话开始。

方法第一步不是急着写要求，而是先把「不知道」分成四种。交代太细，它不敢转弯；交代太糙，它瞎猜，先看清自己卡在哪一格，越大的活儿越容易掉进后两种你毫无察觉的盲区。

• 已知的已知：写进提示词、明说要什么（按钮放右上角）。
• 已知的未知：知道自己还没想清（列表要不要分页还没定）。
• 未知的已知：从不写下来、可一看就知道对不对（配色太刺眼，一眼否掉）。
• 未知的未知：压根没想过、连「能做多好」都不知道（原来视频能靠代码自动切掉停顿）。

找未知不是开工前做一次，而是贯穿动手前、中、后。作者给了 8 个技法分在这三段，每个都是趁便宜先把盲区挖出来。这些技法，正文都配了能直接照抄的英文提示词。

作者反复强调：每次头脑风暴、访谈、原型、参考，都是趁便宜把你不知道的挖出来，免得拖到贵的时候返工。