--- author: Best Partners TV date: '2026-07-22' guest: '' layout: post.njk source: https://www.youtube.com/watch?v=M-LF4bYjiBY speaker: Best Partners TV tags: - prompt-engineering - cognitive-bias - unknown-unknowns - ai-workflow - human-ai-collaboration title: 地图与领土的落差：如何用 AI 探索你的“未知量” summary: 本文基于 Anthropic 技术团队成员 Thariq Shihipar 的实战经验，系统性探讨了如何通过管理“已知与未知”的四象限信息差，来消除 AI 协同工作中的跑偏现象。文章详细介绍了在任务实施前、实施中、实施后消除认知盲区的实操方法与思维框架。 insight: '' draft: true series: '' category: ai-application area: tech-engineering project: [] people: - Thariq Shihipar companies_orgs: - Anthropic products_models: - Claude Code - Claude media_books: [] status: evergreen --- ### 地图与领土：重塑你与 AI 的认知对齐 大家好，这里是最佳拍档，我是大飞。不知道你在日常工作或者学习中使用人工智能时，有没有过这样一种令人沮丧的体验：你明明觉得自己的提示词已经写得非常详尽、面面俱到了，然而 AI 最终生成出来的产出还是货不对板，甚至完全跑偏。每当这种时候，你脑海中冒出的第一个念头，可能就是觉得当前使用的模型还不够聪明，或者开始怀疑是不是自己的提示词工程技巧还不够火候。 但是，今天我们要聊的这篇文章，可能会彻底颠覆你对“AI 为什么会跑偏”这件事的固有看法。 这篇文章的作者是**塔里克·希哈帕尔**（Thariq Shihipar），他是目前全球顶尖人工智能安全与研究公司 **Anthropic** 的核心技术团队成员，同时也是硅谷知名孵化器 Y Combinator W20 届的创业者。可以说，他是目前整个科技界对 **Claude Code** 以及大模型交互机制研究最深的人之一。 前段时间，塔里克做了一件让很多人感到惊讶甚至难以置信的事：作为一个在视频剪辑领域完全是“零经验”的门外汉，他仅凭 Claude Code 这款工具，独立完成了他们公司 Fable 整个发布视频的复杂剪辑工作。而在促成他完成这项看似不可能的任务的背后，并不是什么神乎其神的提示词黑魔法，而是他在整个协作过程中始终贯穿并践行的一个核心原则：**在每个不确定的节点，先找出自己的未知量，再动手执行**。 塔里克将这套在实战中摸索出来的方法论整理成了文章，在发布后的短短 24 小时内，就吸引了超过 190 万次的浏览。这套工作流的底层逻辑其实可以用一个非常经典的地理学隐喻来概括：**地图不等于领土**。 在这个隐喻中，你提供给 AI 的提示词、上下文背景、操作指令，就是你所绘制的**地图**；而任务实际发生、运行并接受检验的地方——比如你的代码库、项目所面临的真实约束、以及复杂的现实物理与商业环境——则是真正的**领土**。地图与领土之间天然存在的各种落差与空白，就是所谓的“未知量”。 当模型遇到这些它在你的“地图”中找不到的未知量时，它没有别的选择，只能依靠自己的概率机制去“猜”。而 AI 猜测的质量，将直接决定最终产出质量的好坏。这实际上是一个普遍存在的问题，但随着模型能力的跃升，有一件关键的事情正在发生微妙而深刻的变化。 在以前，我们使用旧一代的模型时，如果得出的结果不尽人意，我们很自然会归咎于模型本身的能力有限，认为它是智力水平不够才导致了失败。但现在，随着新一代大模型的迅猛发展，模型本身的基座能力已经强大到足以胜任绝大多数常规甚至复杂的执行任务。在这个阶段，如果最终产出的结果依然不对，大概率不是因为模型“笨”，而是因为你绘制的地图和真实的领土之间相差得太远。 简而言之，**模型越强大，你的未知量就越贵**。这正是塔里克撰写这篇文章的灵感起点。正如他在文章中所写的那样，Fable 的剪辑经历是第一个让他真正深刻意识到“产出质量的瓶颈不再是模型，而是我自己的模型”的时刻。当你在等更强的模型出现时，也许你还没有意识到，一旦模型足够强大，真正限制你发挥的，其实是你自己对问题认知的边界。 --- ### 未知量四象限：定位你的信息盲区 在开始任何一项任务之前，我们首先需要搞清楚，阻碍我们和 AI 达成完美默契的“未知量”究竟是由什么构成的。为了帮助我们建立诊断机制，塔里克将所有可能存在的未知量划分成了四个维度，形成了一个认知四象限： 首先是**已知的已知**（Known Knowns: 明确掌握并能清晰传达给 AI 的指令和背景）。这指的是那些你已经完全掌握，并且在撰写提示词时已经明确告知 AI 的内容。你非常清楚自己要什么，也把规则说得很透彻，而 AI 能够非常忠实地去执行这部分指令。 第二类是**已知的未知**（Known Unknowns: 用户意识到自己不懂并需要解决的问题）。这指的是你目前虽然还没搞清楚，但你心里很明白这里存在问题的部分。例如，某个特定功能的边界你还没完全想好，或者你不确定在两个技术方案中哪一个更合适。因为你知道这些问题的存在，所以你还有机会在动手干活之前去调研、讨论并解决它们。 真正麻烦并且容易导致项目走向崩溃的是后面两类。 第三类是**未知的已知**（Unknown Knowns: 用户自身具备的隐性偏好、直觉或未明说的标准）。这指的是那些你其实知道，但因为对你来说太理所当然，导致你根本不会把它写进提示词里的隐性偏好。你拥有某种基于长久以来的工作经验积累起来的直觉，但你并没有把这些直觉显性化。结果就是，当 AI 把东西做出来后，你扫一眼就觉得哪里怪怪的，但你一时间又说不清楚到底是哪里不对。这就是“未知的已知”在作祟，它会让你陷入不断要求 AI “再调整一下”、“感觉还不对”的无限循环中，因为你和 AI 都没有一个明确的、可量化的“对”的标准。 最后一类，也是最危险的一类，是**未知的未知**（Unknown Unknowns: 用户完全没有意识到其存在的知识盲区）。这是你完全没有想到的东西，你甚至不知道那个地方存在一个深坑，因此根本不会想到要在提示词中进行提前预防或规避。等你终于踩雷并发现问题时，AI 通常已经带着你在错误的方向上狂奔了很远，导致你面临极其昂贵的返工成本。 优秀的 AI 协同协作者，其优势往往不在于他们的提示词写得多么花哨，而在于他们在让 AI 真正动手敲代码或写文案之前，已经通过各种手段把这四个象限里的“未知量”压缩到了最少。消除未知量是一项可以通过后天刻意练习来掌握的技能，而非某种与生俱来的天赋。为了实现这一目标，塔里克将完整的 AI 协作流程重构为了三个阶段：实施前、实施中、实施后。 --- ### 实施前的降维打击：清空未知量的五种方法 在整个工作流中，最核心、却也最容易被绝大多数人忽略的阶段，就是**实施前**（Pre-implementation）。很多人习惯于拿到任务后，就迫不及待地开始写一堆长篇大论的提示词让 AI 开始干活，结果干到一半发现方向错了，只能推倒重来，浪费了大量的时间。其实，在前面多花一点时间把未知量清理干净，后面会省去无数的麻烦。以下是塔里克推荐的五种在实施前清理未知量的通用方法： #### 第一步：发起“盲点探测”以应对未知的未知 当你开始面对一个全新的任务，甚至不知道该向 AI 提什么问题时，你往往处于典型的“未知的未知”场景中。此时，塔里克建议直接使用 **盲点探测**（Blindspot Pass: 引导 AI 寻找用户认知漏洞的提问技术）这一策略。 你可以直接在对话中包含“blindspot pass”（盲点探测）和“unknown unknowns”（未知的未知）这两个关键词，同时诚实地告诉 AI 你的个人背景、你对这个领域的了解程度以及你目前已知的条件。这一步之所以至关重要，是因为只有当 AI 知道了你的认知起点，它才能真正帮你过滤掉那些你早已心知肚明的常识，精准找出对你而言真正有价值的盲点。 例如，你需要在代码库里接入一个新的第三方认证方式，但你对这部分遗留代码完全不熟悉。此时你可以直接对 Claude 说： > “我准备在项目中接入 OAuth 认证，但我对目前的认证模块代码不熟。请帮我做一次**盲点探测**，找出我可能忽略的、我自己不知道自己不知道的安全隐患或依赖冲突，以便我能给你提供更准确的后续指令。” 这种做法把发现问题的责任交给了对上下文具备更强逻辑梳理能力的 AI。 #### 第二步：通过“多向探索与原型设计”显性化未知的已知 当你脑海中有一个模糊的预期，却无法用精准的语言向 AI 描述这种感觉时（比如你想要的某种独特的视觉风格、一篇文章的细腻语感，或者一个技术方案的微妙体验），“未知的已知”就在暗中影响着你。与其让 AI 瞎猜你的心思，不如让它直接给你提供几个截然不同的方向。 你可以让 AI 快速生成几个小巧的草图或方案雏形，由你来做出直观的反馈——哪个方向是对的，哪个方向是错的。你的每一次反应，都是在为 AI 提供最真实的偏好数据。在一个简单的 HTML 草图里修改方向可能只需要几秒钟，但如果等项目深度实施后再想改动，往往就意味着毁灭性的重构。 比如，你要做一个数据分析看板，但你自己缺乏设计美感。你可以先对 AI 说： > “帮我用单文件 HTML 快速生成 4 个视觉风格截然不同的看板设计方向，分别侧重于极简科技感、传统报表风、高对比度暗黑风以及卡片式现代风。我将通过它们来确认我的审美偏好。” 通过这种快速的原型对比，你能迅速勾勒出心中那个模糊的标准。 #### 第三步：让 AI 扮演采访者角色 有时候，面对一个复杂的项目，你隐约知道里面存在很多模糊的死角，但由于千头万绪，你不知道该从何问起。这时，你可以反客为主，将提问的主动权交给 Claude，让它来对你进行“采访”。 为了防止 AI 陷入无关紧要的细枝末节，你必须在指令中给它设定一个明确的筛选标准：**优先提问那些如果答案改变，会直接影响整体架构或项目方向的核心问题**。你可以这样对它下令： > “我们现在要重新设计用户留存的数据链路。请一次只问我一个问题，帮我梳理逻辑。请优先问那些我的回答会改变整体系统设计方向的问题。” 在这种 इंटरव्यू（Interview）式的交互中，AI 凭借其对任务的全局视角来帮你梳理思路，许多你自己平时想不通的逻辑，在 AI 的引导式提问下往往能瞬间变得清晰明了。 #### 第四步：提供高质量的“参考物”以消除表达瓶颈 在人机协同中，有时候最费脑筋的不是你想不明白，而是你找不到合适的词汇来描述它。在这种情况下，最直接、最高效的办法就是给 Claude 提供一个实实在在的“参考物”。 对于软件开发者而言，最完美的参考物莫过于已经在线上运行良好的**源代码**。指向一个实现了你想要的行为的开源库，让 Claude 彻底读懂它的底层设计，然后在你当前的项目中进行重新实现，这比你用任何自然语言描述都要准确得多。同样，对于设计师或内容创作者，一张截图、一份优秀的文档、甚至一篇排版极佳的文章，都是绝佳的参考。 塔里克特别强调，像 Claude 这样的工具不仅能看懂截图，还能直接阅读网页底层的 HTML/CSS 代码。例如，你可以告诉它： > “在这个第三方 Rust crate（如 vendor/rate-limiter）中，它实现了一套非常优雅的指数退避重试逻辑。请帮我完整读懂它的代码逻辑，然后使用 TypeScript 在我们现有的 API 客户端中，按照完全相同的语义和错误处理流程重新实现一遍。” #### 第五步：制定“双层实施计划” 当你觉得所有未知量都已经被清理得差不多，准备正式开始干活时，不要急着让 AI 去改写核心代码，先让它为你拟定一份详细的实施计划。这份计划的核心价值并不在于展示项目的全貌，而在于将**必须由你拍板的关键决策**（如数据结构的设计、对外暴露的 API 接口定义，或者直接呈献给用户的 UI 界面）与**可以完全信任 AI 自主执行的细节**（如内部函数的重构、测试用例的补充等）清晰地剥离开来。 你可以让 AI 这样输出计划： > “请为我编写一份 HTML 格式的实施计划。请将所有需要我确认的决策（如核心数据结构的设计、路由定义等）放在最前面。把那些纯执行层面的底层修改放在最后，那部分我授权你可以自己决定。” 通过这种方式，你成功地将自己的注意力集中在了最关键的架构节点上，而免于被繁琐的细节吞没。 --- ### 实施中与后的闭环管理：让决策有迹可循 在实施前做足功课，是否就能保证执行阶段万无一失？答案显然是否定的。无论前期的设计多么完美，一旦开始与真实的物理领土接触，总会冒出各种意料之外的边缘情况。 #### 实施中的核心工具：维护“偏差记录” 当在实施中遇到未预料到的约束或冲突时，塔里克的核心策略不是让 AI 频繁停下来等待人类的确认，因为这会极大地破坏开发的流畅度。相反，他让 AI 遵循“**先保守处理，同步记录偏差**”的原则，在项目中专门维护一个名为 **偏差记录**（Deviation Log: 记录 AI 执行过程中偏好、假设或临时决策调整的日志）的临时文件（例如 `deviation-log.md`）。 你可以直接在提示词中如此规范 AI 的执行行为： > “请在项目根目录下维护一个 `implementation-notes.md` 偏差日志。在后续的执行过程中，如果遇到必须偏离我们既定计划的边缘情况，请优先选择最安全、最保守的临时解决方案，并在日志中记录该决策的原因，然后继续向下推进，不要中断任务。” 这样做的好处显而易见：它不仅保证了 AI 在执行复杂且漫长的任务时，能始终基于同一份决策上下文保持前后一致，避免逻辑混乱；同时，这些记录下来的偏差也成为了你审阅代码时的关键线索，并且能够作为后续迭代中完善“地图”的珍贵原材料。 #### 实施后的双重保障：说明提案与自我测验 当 AI 完成了所有的编码或内容创作后，工作流并没有结束，塔里克设计了两个非常独特的收尾步骤： 首先是**提案与说明**。让 AI 将它所做的所有改动、生成的原型以及偏差日志，打包整理成一份通俗易懂的说明文档。这不仅是为了让团队中的其他审阅者（他们开始时往往和你有同样的认知未知量）能够快速理解并批准你的改动，更是为了强迫你作为项目负责人，去重新梳理并彻底搞清楚你究竟让 AI 做了什么。 第二个步骤则更具启发性，被称为**消化测验**。在将重要产出合并或部署上线之前，让 Claude 根据这次的改动，为你出一份小测验： > “我想确保自己百分之百理解了这次对系统架构做出的所有调整。请为我提供一份总结报告，详细说明这次修改的底层逻辑。并在报告的最后，为我设计 3 个关于这次代码改动影响的理解测试题。只有当我全部答对时，我们再进行代码合并。” 这听起来似乎有些滑稽——让一个人工智能来考试人类？但仔细想想，我们很多人在用 AI 编程时，往往只是粗略地扫一眼生成的代码，觉得编译能通过、界面能跑起来就直接合入了。一旦未来这段代码出了问题，因为你从一开始就没有真正理解其中的逻辑，你根本无从下手去排查。这个测验机制，本质上是在通过主动检索，强制你消化 AI 写入你系统中的每一个知识点。 --- ### 视频剪辑实战：Thariq 的未知量消解之路 为了让我们更直观地理解这套方法论在真实世界中的威力，我们可以回顾一下塔里克自己剪辑 Fable 发布视频的整个心路历程。 作为一个从未接触过专业视频剪辑软件的开发者，塔里克在面对“剪辑一部高质量产品发布视频”的任务时，内心充满了不确定性。他没有盲目地直接导入视频素材开始乱剪，而是严格按照自己的未知量管理框架，开始了一场系统的自我认知迭代： * **识别已知的未知**：塔里克知道 Claude 可以通过编写脚本的方式来调用**音视频处理工具**（FFmpeg: 一款开源的、用于记录、转换和流化音视频的完整解决方案）进行视频剪辑，也能利用**语音转录模型**（Whisper: OpenAI 研发的开源通用语音识别模型）来做语音转录。但他不确定 Whisper 识别的精度是否足够高，是否能够精准地识别并帮他自动剪掉音轨中类似于“呃”、“啊”这样的口头填充词以及那些尴尬的无声停顿。 * **盲点探测**：他没有直接去写剪切脚本，而是先让 Claude 帮他做了一次针对 Whisper 和 FFmpeg 的盲点探测，详细了解了这套技术组合在处理音频边界时可能会遇到的时间戳对齐误差和爆音问题。这让他提前知道了在编写剪辑算法时，需要在音频切口处加上微小的淡入淡出（Crossfade）效果。 * **原型设计验证**：为了验证动态 UI 伴随人声说话节奏进行缩放的技术可行性，塔里克让 Claude 使用 **视频框架**（Remotion: 基于 React 构建视频的开源编程框架）快速制作了一个只有几秒钟的视频小样原型，并配上转录的 JSON 文本进行渲染。当他亲眼看到原型视频中 UI 能够完美跟随音频震动时，他彻底确认了这个方向的可行性。 * **应对未知的未知（调色挑战）**：在视频剪辑的后期，塔里克发现渲染出来的视频色彩显得非常黯淡、沉闷。他隐约知道这是因为没有进行“调色”（Color Grading），但他完全不懂任何关于色彩空间的专业知识，更不知道如何去调整饱和度、对比度。他一开始本能地让 Claude 尝试生成几个不同色彩风格的版本让他选择，但他随即发现自己根本无法做出判断，因为他的大脑中完全没有关于“好调色”的基准地图。他意识到这是他未知的未知。于是，他果断停止了无意义的盲目尝试，转而让 Claude 像一个耐心的导师一样，先为他讲解基本的色彩理论（如 LUT 和色彩平衡），帮他建立起最基本的审美和判断标准后，才重新动手完成了令人惊艳的视频调色。 塔里克的这段经历极其生动地向我们展示了一个道理：在应对复杂任务时，未知量并不是在项目开始前能够一次性彻底清零的，它会在执行的过程中伴随着你对领土的深入探测而源源不断地涌现。关键在于，每当你在执行中遭遇卡点时，你是否能有意识地停下脚步，问自己一句：“我现在是被哪一类未知量卡住了？”然后选择正确的策略去消解它。 --- ### 结语：做掌握“认知地图”的主动思考者 在人工智能技术日新月异的今天，我们与 AI 协作的范式已经发生了根本性的转移。AI 是一面巨大的放大器，它不仅会成倍地放大你已有的专业认知与创造力，同样也会毫不留情地放大你思维中的盲区与逻辑漏洞。 塔里克所分享的这套以“未知量”为核心的工作方法论，其价值早已超越了 Claude 或是任何一款特定工具的使用技巧。它本质上是一种在高度不确定性面前，帮助我们系统性地发现、面对并消除自身认知偏差的思维武器。 下一次，当你用 AI 做出来的东西又一次让你感到不满意时，不妨先别急着去修改提示词或者抱怨模型。试着坐下来，在纸上画出那四个象限，看一看你的“地图”和真实的“领土”之间，究竟还隔着多少未被探明的未知量。 最后，大飞也想把这个问题留给屏幕前的你们：在你们最近一次与 AI 的协作经历中，那件让你们不够满意的产出，现在回过头来看，究竟是由于哪一类未知量没有被妥善处理好而导致的呢？欢迎在评论区留下你们的真实故事和思考。 感谢大家的收看，我们下期再见。