大家好，这里是最佳拍档，我是大飞。不知道你有没有过这样的体验：用AI做东西，明明提示词写得很详细了，结果出来还是不对，感觉AI总是在跑偏。你可能会觉得是模型不够聪明，或者自己提示词写得不够好，但今天要聊的这篇文章，可能会彻底改变你对这件事的看法。
文章作者是塔里克·希哈帕尔（Thariq Shihipar），Anthropic的技术团队成员，也是YC W20的创业者。他可以说是目前对Claude Code研究最深的人之一。前段时间，他做了一件让很多人惊讶的事：一个完全没有视频剪辑经验的人，仅凭Claude Code，独立完成了Fable整个发布视频的剪辑工作。
让他做成这件事的，不是什么复杂的提示词技巧，而是他在整个过程中一直在做的一件事：在每个不确定的节点，先找出自己的未知量，再动手。他把这套工作方式整理成文章，发出24小时就获得了190万浏览。核心框架说起来很简单。
你给Claude的提示词、背景、指令是地图，而任务实际发生的地方，比如代码库、真实的约束、现实的环境，它们都是领土。地图和领土之间的差距，就是未知量。Claude遇到未知量只能靠猜，而猜的质量会决定产出的质量。
这其实不是什么新问题，但有一件事正在发生变化。以前用旧一代的模型，结果出来不对，你会觉得是模型不够好。但是现在模型已经强大到足够执行大多数的任务了，结果出来不对，大概率是因为你的地图和领土差得太远。
模型越强，你的未知量就越贵。这也是塔里克写这篇文章的起点。Fable是第一个让他真正感到“产出质量的瓶颈是我自己的模型”的人。这句话我第一次看到的时候挺有触动的。
我们总在等更强的模型，但是当模型真的足够强了，你会发现限制你的，其实是你自己对问题的认知边界。那具体什么是未知量呢？在开始一个任务时，塔里克把所有可能的未知量分成四类。
你写进提示词的内容，你明确告诉Claude你要什么，这部分它能忠实执行，这叫“已知的已知”。然后是你知道自己还没搞清楚的问题，比如这个功能的边界我还没想好、我不确定哪个方案更合适。你知道问题存在，还有机会在开始前解决，这叫“已知的未知”。
真正麻烦的是后两类。首先是你其实知道，但太理所当然、不会写出来的东西。你有偏好和直觉，只有看到结果才知道对不对。就好像Claude做出来你看一眼就觉得哪里不对，但说不清哪里不对，这就是“未知的已知”。
而最危险的是最后一类，你完全没想到的东西。你不知道那个坑存在，所以不会想到要提前处理，等你发现，通常已经在错误的方向走了很远，这是“未知的未知”。
未知的已知会让你不断说“再调整一下”，或者感觉还不对，因为你自己也不知道那个对的标准是什么。未知的未知更直接，那个坑从一开始就不在你的地图里。优秀的Claude使用者，不一定是提示词写得更好，更多时候，是他们开始之前的未知量更少。
不过，这是一个可以训练的技能，并不是什么天赋。塔里克把整个工作流程分成三个阶段：实施前、实施中、实施后。最重要的是实施前，也是多数人完全跳过的阶段。
很多人拿到一个任务，上来就开始写提示词让AI干活，干到一半发现不对，再返工，浪费了大量时间。其实前面多花一点时间把未知量清掉，后面会省很多事。这里说的五种方法，底层逻辑是通用的，写代码、写文章、做产品决策，甚至做视频，用的是同一套思路。
首先，你不知道要问什么，因为你不知道那个问题存在，这是最典型的“未知的未知”场景。这时候怎么办呢？直接让Claude帮你找盲点。塔里克建议直接用“blindspot pass”（也就是盲点探测）和“unknown unknowns”（也就是未知的未知）这两个词。
同时告诉Claude你的背景，比如你是谁、你对这个领域了解多少。这一步很关键，Claude知道你的起点，才能找到对你有价值的盲点，不是告诉你一堆你早就知道的东西。比如你要在代码库里接入一个新的认证方式，但是你对这部分代码完全不熟，你就可以直接说：“能做一次盲点探测，帮我找出我不知道自己不知道的东西，让我能更准确地给你指令吗？”
再比如塔里克自己遇到的情况，他不懂什么是调色，但是他要给视频调色，他就先让Claude教他理解调色里他不知道自己不知道的东西。先搞清楚问题是什么，再动手解决。
当你知道自己要什么结果，但无法精确描述的时候，比如视觉风格、文章的语感，或者一个方案对的感觉，这就是“未知的已知”在起作用。这时候与其让Claude猜你的意思，不如让Claude给出几个截然不同的方向，你来反应哪个对、哪个不对。你的反应就是信息。
你可能觉得这会浪费时间，但其实一个小需求在草图里改是几秒的事，等到深度实施后再改，可能要推翻重来。塔里克几乎每次复杂任务都从探索或头脑风暴开始，帮他在真正动手前把项目范围定清楚。
比如你要给一份数据做一个看板，但是你没有视觉品位，也不知道什么效果是可能的，就让AI帮你做一个HTML页面，给出4个风格截然不同的设计方向，你来反馈哪个对。再比如你有个还没想透的问题，用户走完新手引导就流失了，你可以让AI搜索代码库，头脑风暴10个可以介入的地方，从改动最小到最激进的排出来，你来告诉它哪些方向说到点上了。
这时候你不需要精确描述你想要什么，你只需要对AI给出的东西做出反应就行。这比你自己憋在那里想破头要高效得多。还有一种情况，你知道有模糊地带，但是不知道从哪里问起。这时候把提问的角色交给Claude，告诉它问题的背景，让它来采访你。
不过你要给它一个排序标准，优先问那些你的答案会改变整体方向的问题，否则Claude可能把时间花在无关紧要的细节上。比如你可以直接说：“一次问我一个问题，关于任何模糊的地方，优先问那些我的回答会改变整体方向的问题。”
这个做法和普通问答的区别是什么呢？你不是在问Claude，而是Claude在问你，将找问题的活，交给了对任务有全局视角的那一方。很多时候你自己想不清楚问题在哪，但是AI一问，你马上就知道自己要什么了。这是一种很奇妙的体验。
有时候你不是不知道要什么，而是没有语言描述它，或者描述起来太费劲。这时候最有效的是直接给Claude一个参考物。对开发者来说，最好的参考物是源代码，比如指向一个实现了你想要行为的库，让Claude读懂后在你的项目里重新实现。
图表、文档、截图都可以给，但是源代码的信息最丰富。这个方法对设计或内容方向的用户同样适用。你看到一篇文章的风格你很想学，或者一个网站的某个交互做得恰到好处，直接把它指给Claude，比你用语言描述快得多，Claude拿到的信息也更准确。
塔里克还提到一个点，Claude Design可以直接读网页底层代码，不只是截图，这样它拿到的是结构和实现层面的信息，比截图丰富得多。比如你看到vendor/rate-limiter里这个Rust crate实现了你要的退避逻辑，你就直接让它完整读懂，然后在你们的TypeScript API客户端里，按照同样的语义实现一遍。这比你自己描述半天要准确太多。
等你觉得准备好了之后，先让Claude拟一份实施计划。重点不在于计划的全貌，而在于把需要你拍板的决策，和Claude可以自己处理的执行，分开排列出来。前者放最前面，后者完全交出去。对开发者来说是数据结构和接口，对做内容的人可能是文章结构和论证顺序。
这样Claude在动手之前，先把它自己也不确定的东西显式化，让你在低成本阶段确认。最后剩下的未知量，你可以告诉它：“写一份HTML格式的实施计划，把我最可能需要拍板的决策放最前面，比如数据结构怎么设计、接口怎么定，以及所有用户会直接看到的部分。然后把纯执行层面的改动放最后，那部分我信任你，可以自己决定。”
这时候你就不需要再审整个计划的每一个细节了，你只需要重点关注那些你可能会改的决策点就行了。好了，实施前的工作做充分了，是不是执行的时候就不会有问题了呢？也不是。实施前做得再充分，执行中还是会冒出没预见到的情况。
这个阶段的核心不是消除未知量，而是在遇到未知量时不乱。塔里克的做法是让Claude维护一个临时的偏差记录文件，英文叫deviation log。遇到边缘情况时，不要停下来等你确认，先选保守的处理方式，记录这个决策，继续推进。
这份记录可以帮Claude在当前任务里保持一致，也能成为下次任务更好的地图的原材料。对非开发者来说，等价的做法是让Claude记录任务中的关键决策，而不只是给你最终产出。你可以直接告诉它：“维护一个implementation-notes.md文件，遇到边缘情况导致必须偏离计划时，优先选择保守的处理方式，在偏差下面记录这个决策，然后继续推进。”
这个做法看起来简单，但是其实解决了一个很大的问题。很多时候AI做着做着就前后不一致了，或者遇到点小问题就卡住等你指示。有了这个偏差记录，它就能自己往前走，同时保证所有决策都有迹可循。
任务完成后，还有两个步骤。第一个是提案与说明，把产出、原型和实施记录打包成一份别人看得懂的文件。这不只是让别人理解你做了什么，也是在强迫你自己搞清楚你让Claude做了什么。审阅者开始时往往和你有同样的未知量，因此提前在文件里回答掉，能显著加快审阅和获批的速度。
第二个步骤初看有点奇怪，测验。在重要产出落地前，让Claude先考考你，通过了再确认。逻辑其实很简单，Claude会先给你一份报告，把做了什么、背后的思路写清楚，然后出题考你。你答对了，才说明你真的理解了，而不只是扫了一遍。测验是消化机制，不是信任问题。
你可以告诉它：“我想确认自己真正理解了这次的所有改动，给我一份报告，把做了什么、背后的思路和逻辑写清楚，在最后放一个我必须通过的测验。”说实话，第一次看到这个方法的时候我愣了一下。让AI考我？
但仔细想想，确实是这样。很多时候我们让AI写了一堆代码或者改了一堆东西，扫一眼觉得没问题就合并了，但是真要问你改了什么、为什么这么改，你可能根本答不上来。这时候出问题你都不知道从哪查。
讲完了方法，我们来看一个完整的例子，就是塔里克自己剪Fable发布视频这件事。视频剪辑对他来说是全新的领域，他对这件事能不能做成没有把握。他从已知的开始，他知道Claude可以用代码编辑视频、做语音转录，但不确定转录的精度够不够用，能不能准确剪掉像“嗯啊”这样的口气词和过长的停顿。
这是已知的未知，他没有直接开始干，而是先做盲点探测，让Claude解释Whisper这个开源语音识别模型的工作原理，以及ffmpeg这个音视频处理工具能做到什么程度。先搞清楚自己的未知的未知。
然后他还想要一个动态UI，能跟着他说话的节奏动起来，他不确定这在技术上能不能实现，所以没有直接开始做，而是先让Claude用Remotion这个React视频框架做了一段原型视频，配上转录文本，看看效果。这是头脑风暴与原型，用原型回答一个他无法凭想象判断的问题。
你看，这就是聪明人的做法。遇到不确定能不能做到的事，不要上来就投入大量时间做完整版本，先花几分钟做个原型验证一下可行性。最后是调色，视频出来后他觉得颜色发闷，知道这是调色的问题，但他不知道什么是调色，也不知道好的调色长什么样。
他的第一反应是让Claude做几个版本来挑，但做完他发现自己还是不知道哪个对，因为他根本没有判断标准。他意识到这是未知的未知，于是又回到了盲点探测，先让Claude教他理解调色，建立起基本的判断标准，再回来动手。
这个过程展示了一件很重要的事：未知量不是在开始前一次性清完的，它在整个任务里持续出现。他每次遇到卡点，做的都是同一件事：先找出自己的未知量，再动手。不是说你前面做了盲点探测，后面就不会遇到问题了，而是你要有这个意识，每次卡住的时候，先停下来想一想，我现在是哪类未知量没处理好？
说到这，我们回头看，这个框架真正有价值的地方是什么？它把Claude总是跑偏这个模糊的感受，变成了一个可以系统处理的问题。以前你觉得AI跑偏，你可能会重新写提示词，或者换个模型，或者干脆自己干。但现在你有了清晰的诊断起点：到底是哪类未知量没处理好？
是你没写进提示词？是你知道问题但没解决？是你有隐性偏好但没说出来？还是你完全不知道那个坑存在呢？不同的诊断，对应着不同的处理方法。四类未知量里，未知的未知是最值得认真对待的。
你不会主动去补你不知道需要补的背景，只有这一类，需要主动设计一个机制去发现它，而不是靠任务流程自然暴露出来。这也是为什么盲点探测这个步骤这么重要，它是专门用来对付未知的未知的。
我知道有人会说，这套方法有成本啊，盲点探测、原型、让AI采访你，这些都要花时间。但是塔里克的核心主张其实很简单：前期便宜的错误，好过后期昂贵的返工。你在前面花10分钟做个原型验证，也许能避免后面花10个小时推翻重来，这笔账其实很好算。
还有一点我觉得很重要，就是你的未知量不是固定的。持续在一个领域用Claude工作，你会逐渐把未知的未知变成已知的未知，再变成已知的已知。每次任务的偏差记录，都在让你的地图更接近领土。这个技能是越用越好的。
不是说你学了这套方法就一劳永逸了，而是每做一个任务，你对这个领域的理解就深了一层，你的地图就更准确一点，下次做类似任务的时候未知量就更少了。其实我自己用AI做内容这么久，最大的感受也是这样。
一开始总觉得提示词是万能的，后来发现真正重要的是你自己对问题的理解有多深。你自己对问题理解得越清楚，你给AI的地图就越准确，出来的结果自然就越好。反过来，如果你自己都没想清楚要什么，再厉害的提示词工程师也帮不了你。AI是放大器，它会放大你已有的认知，也会放大你认知里的盲区。
那今天聊的这套方法，其实本质上就是一套帮你系统性发现自己认知盲区的方法。它不只是用Claude的技巧，更是一种工作方式，一种思考问题的方式。不管你用不用AI，做任何复杂事情的时候，先停下来想一想，我的地图和领土之间有什么差距？我有哪些未知量？这可能比你急着动手要有用得多。
最后我也想问问大家，你最近一次对用AI做的东西结果不满意，现在回头看，是哪一类未知量没处理好呢？欢迎在评论区分享你的经历。感谢收看，我们下期再见。