Anthropic技术团队成员塔里克·希哈帕尔提出的"地图与领土"框架正在改变AI使用方式。你给AI的提示词是地图，真实任务环境是领土，两者差距就是未知量，AI遇到未知量只能靠猜测。模型越强，未知量的代价越昂贵。他系统拆解了四类未知量（已知的已知、已知的未知、未知的已知、未知的未知），详解实施前、中、后三阶段的具体应对方法，包括盲点探测、快速原型、AI反向提问、参考物、实施计划、偏差记录、理解测验等可落地技巧，并以用AI从零完成视频剪辑的完整案例展示方法论实战，帮你把"AI总跑偏"的模糊感受转化为可系统解决的问题。

https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns

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

大家好，这里是最佳拍档，我是大飞 不知道你有没有过这样的体验 用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做的东西结果不满意 现在回头看 是哪一类未知量没处理好呢？ 欢迎在评论区分享你的经历 感谢收看，我们下期再见