原文作者：Thariq（@trq212）
1. 概括
这篇文章讲的是：当 AI 模型越来越强时，任务质量的瓶颈不再只是模型能力，而是你能否把问题里的“未知”找出来、讲清楚，并让 AI 在正确的边界内探索。
作者把和 Claude Fable 5 协作的经验总结成一个核心方法：
在实现之前、实现过程中、实现之后，持续发现 unknowns（未知项），让 AI 不只是执行你的指令，而是帮助你澄清问题本身。
2. 核心隐喻：地图不是领土
文章开头引用了一个经典说法：
The map is not the territory.
地图不是领土。
在 AI 协作语境下：
| 概念 | 对应含义 |
|---|---|
| 地图（Map） | 你给 AI 的 prompt、上下文、技能说明、任务描述、规格文档 |
| 领土（Territory） | 真实要工作的地方：代码库、产品、用户需求、历史约束、运行环境、组织流程 |
| 两者之间的差距 | unknowns，也就是你没有显式说明、AI 也必须推断的部分 |
换句话说，prompt 只是你对任务的表达，不等于任务本身。
AI 真正要面对的是复杂的现实系统：
- 代码库里已经存在的架构和风格；
- 产品里隐含的用户体验约定；
- 团队历史上做过但你没写出来的决定；
- 真实数据、边界条件、异常路径；
- 你自己“看到才知道对不对”的主观偏好。
如果你没有把这些差距显式化，AI 就只能猜。
3. 文章最重要的判断：AI 输出质量受限于“澄清未知”的能力
作者认为，使用更强的模型时，工作质量越来越取决于：
你是否能帮助模型发现并澄清 unknowns。
这和传统 prompt engineering 的区别很大。
传统思路常常是：
我把需求写清楚，AI 按照需求执行。
而作者的思路是：
我先承认需求并不完整，然后让 AI 帮我发现哪里不完整、哪里有风险、哪里需要探索、哪里需要我做选择。
因此，好的 AI 协作不是一次性“写一个完美 prompt”，而是一个迭代过程：
- 实现前：找盲点、做探索、建立参考、评审计划；
- 实现中：记录偏离、捕捉边界情况、保守决策；
- 实现后：解释成果、争取 buy-in、检验理解。
4. 四类 unknowns：理解问题不完整性的框架
作者把问题拆成四类信息状态。这是全文的方法论基础。
4.1 Known Knowns：已知的已知
这是你明确知道，并且已经告诉 AI 的内容。
例如：
- “我要新增一个认证 provider”；
- “这个页面需要一个 dashboard”；
- “我要把视频里的停顿剪掉”；
- “我希望用 TypeScript 实现某个 API client 行为”。
这部分通常会出现在 prompt、需求文档、issue、PRD 或 ticket 里。
问题在于：真实任务往往远远不止这些。
4.2 Known Unknowns：已知的未知
这是你知道自己还没想清楚的部分。
例如：
- “我不确定数据模型应该怎么改”；
- “我还没决定 toolbar 放在哪里”；
- “我不知道 onboarding 流失发生在哪一步”；
- “我不确定这个改动会不会影响现有 auth module”。
这类问题适合直接告诉 AI：
我知道这些地方还不确定，请优先帮我分析。
Known Unknowns 是最容易处理的一类，因为你至少知道它存在。
4.3 Unknown Knowns：未知的已知
这是最容易被忽略、但对 AI 协作非常关键的一类。
它指的是：
你其实知道判断标准，但你没有语言把它提前说出来；只有看到方案时，你才会意识到“对，这就是我要的”或“不，这不对”。
典型场景包括：
- 视觉设计审美；
- 交互手感；
- 文案 tone；
- 产品体验；
- “这不像我们团队的代码风格”；
- “这个实现看起来太重了”；
- “这个 layout 感觉不对，但我说不清为什么”。
作者提到，在这类情况下，最有用的方法不是直接实现，而是先让 AI 做 brainstorm / prototype，让你通过比较和反馈把隐含偏好显性化。
4.4 Unknown Unknowns：未知的未知
这是最危险的一类。
它指的是：
你不知道自己不知道什么。
例如：
- 你不知道某个代码模块有历史坑；
- 你不知道认证流程里有特殊 edge case；
- 你不知道某个设计领域里“好”的标准是什么；
- 你不知道视频转录、剪辑、调色的技术限制；
- 你不知道有更合适的解法。
作者认为，高级 AI 协作的关键能力之一，就是主动让模型帮你找 unknown unknowns。
这也是文中反复强调的 blindspot pass。
5. 为什么“只提前规划”还不够
作者特别指出：
仅仅在实现前做计划是不够的。
原因是很多 unknowns 不会在一开始出现，而是会在实现过程中浮现。
例如：
- AI 真正读代码时才发现现有架构和计划不匹配；
- 某个边界情况导致原方案不可行；
- 某个接口历史包袱比预期更重；
- 某个 UI 看起来可以，但接入真实状态后复杂度暴涨；
- 做到一半才发现你其实应该换一种解法。
所以，作者把流程分成三段：
- Pre-implementation：实现前发现未知；
- During implementation：实现中记录未知；
- Post implementation：实现后解释与验证未知。
6. 实现前：先让 AI 帮你找问题，而不是马上写代码
6.1 Blind Spot Pass：盲点扫描
适用场景：
- 你要进入一个不熟悉的代码模块；
- 你要做一个新领域任务；
- 你不知道该问什么问题；
- 你不知道“好结果”长什么样；
- 你担心有历史坑、边界条件或隐含约束。
目标不是让 AI 直接执行，而是让它告诉你：
- 哪些地方可能有坑；
- 哪些问题需要先确认；
- 哪些上下文你还没给；
- 哪些决策会显著影响架构；
- 你应该如何更好地 prompt 它。
模板 Prompt
我正在做 [任务]，但我对 [相关领域/代码模块/系统] 不熟悉。
请先做一次 blindspot pass，帮我找出可能的 unknown unknowns。
重点告诉我：
1. 我可能还不知道哪些关键问题；
2. 哪些上下文会影响实现方向；
3. 哪些历史坑或边界情况需要检查；
4. 我应该如何补充 prompt，才能让你更好地完成任务。
先不要实现代码。
6.2 Brainstorms and Prototypes：用头脑风暴和原型发现隐性偏好
适用场景：
- 你知道目标，但不知道方案；
- 你很难描述审美或体验；
- 你想先比较不同方向；
- 你不想一开始就改真实代码；
- 你担心过早实现会导致返工。
作者的建议是：先做低成本 artifact。
例如：
- 一个独立 HTML 原型；
- 几种 dashboard 视觉方向；
- 一个 fake data 的 toolbar mock；
- 10 个从低成本到高成本的产品干预点；
- 一个可视化对比页面。
这类 artifact 的价值在于：
它让你能“看见”方案，从而把原本说不清楚的偏好讲出来。
模板 Prompt
我想做 [目标]，但我还不知道什么方案最好。
请先不要接入真实系统，也不要改核心代码。
先做一个低成本原型/HTML artifact，用假数据展示 3-5 个明显不同的方向。
每个方向请说明：
- 适合什么用户/场景；
- 优点；
- 风险；
- 如果采用，后续实现成本大概在哪里。
我会根据原型反馈偏好。
6.3 Interviews：让 AI 反过来采访你
适用场景：
- 已经 brainstorm 过，但仍有不确定；
- 你不确定哪些问题真正重要；
- 你想避免 AI 自作主张；
- 你希望先做关键决策再实现。
作者强调，采访式提问应该优先关注：
会改变架构、数据模型、UX flow 或实现策略的问题。
模板 Prompt
请采访我，帮我澄清这个任务里的歧义。
一次只问一个问题。
优先问那些“我的回答会改变架构/数据模型/用户流程/实现策略”的问题。
不要问无关紧要的偏好问题。
在我回答完后，请更新你的理解和剩余不确定项。
6.4 References：用参考物替代抽象描述
当你说不清楚想要什么时，最好的办法往往不是写更多抽象描述，而是给参考。
参考可以是：
- 现有代码；
- 某个库；
- 某个组件；
- 某个网页模块；
- 设计截图；
- 文档；
- 旧版本实现；
- 竞品流程。
作者尤其强调：最好的参考是源代码。
因为源代码不仅展示结果，还展示：
- 结构；
- 边界；
- 数据流；
- 命名；
- 设计意图；
- 真实实现细节。
模板 Prompt
请阅读 [参考路径/模块/库/组件]。
我想要的不是照抄外观，而是复用它的 [行为/结构/交互/语义/约束]。
请先总结这个参考的关键设计决策，然后说明如何把同样语义迁移到当前项目。
在我确认前不要开始实现。
6.5 Implementation Plans：实现计划要突出“最可能变的部分”
作者不是让 AI 写一个机械的任务清单，而是要求实现计划重点展示那些需要人类判断的地方。
尤其包括：
- 数据模型变化；
- 类型接口；
- 用户可见行为；
- UX flow；
- 边界条件；
- 迁移策略；
- 风险和可回滚方案。
机械重构、文件移动、样板代码可以放后面。
模板 Prompt
请先写一份实现计划供我 review。
计划开头请优先列出我最可能需要调整的决策：
1. 数据模型变化；
2. 新增或修改的类型接口；
3. 用户可见行为；
4. UX flow；
5. 可能影响架构的边界条件。
机械性的重构步骤放在最后即可。
请明确标出：哪些是你确定的，哪些是你基于假设做出的选择。
7. 实现中：让 AI 留下“决策轨迹”
7.1 Implementation Notes：实现笔记
作者建议在实现阶段让 AI 维护一个临时文件，例如：
implementation-notes.md
这个文件记录：
- AI 遇到的 edge case；
- 为什么偏离原计划；
- 当时做了什么保守选择；
- 哪些地方需要后续人工 review；
- 下次迭代可以如何改进 prompt 或计划。
这非常重要，因为 AI 实现中经常会做一些“合理但隐形”的决定。
如果没有记录，你可能只看到最终 diff，却不知道它为什么这么改。
模板 Prompt
请在实现过程中维护 implementation-notes.md。
如果你遇到迫使你偏离计划的 edge case，请：
1. 选择最保守、最容易回滚的方案；
2. 在 implementation-notes.md 的 Deviations 区域记录原因；
3. 继续推进，不要在小问题上无限停顿；
4. 对需要我确认的事项标记为 Review Needed。
8. 实现后：不仅要看 diff，还要建立理解和共识
8.1 Pitches and Explainers：把成果包装成别人能理解的说明
实现完成后，真正的挑战往往不是“代码写完了”，而是：
- reviewer 能否快速理解；
- stakeholder 能否批准；
- 团队能否相信你考虑过风险；
- 其他人能否知道为什么这样做。
因此，作者建议让 AI 把以下材料整理成一个可分享文档：
- 原型；
- spec；
- implementation notes；
- demo GIF；
- 风险说明；
- 关键决策；
- reviewers 可能关心的问题。
模板 Prompt
请把这次工作的 prototype、spec 和 implementation-notes 整理成一份可以发到 Slack/飞书/PR 描述里的 explainer。
请按这个顺序组织：
1. 先展示 demo 或最终效果；
2. 解释这解决了什么问题；
3. 说明关键设计决策；
4. 列出已考虑的风险和边界情况；
5. 标出 reviewer 最应该看的文件或代码区域。
8.2 Quizzes：用测验确认自己真的理解了变更
作者提出一个很有意思的方法：
合并代码前，让 AI 给自己出测验。
原因是：
- 只看 diff 很难理解行为变化；
- 很多影响来自既有代码路径；
- AI 可能完成了很多你没有意识到的工作；
- quiz 能逼你确认自己是否真的理解。
模板 Prompt
请给我一份本次变更的学习报告，并在最后附一个 quiz。
报告需要包括：
1. 这次变更解决了什么问题；
2. 关键代码路径；
3. 重要设计决策；
4. 可能的边界情况；
5. 哪些行为没有改变；
6. reviewer 应该重点检查什么。
quiz 请覆盖真正影响行为理解的问题。
我只有全部答对后才会合并。
9. 案例：用 Claude Code 剪辑 Fable 发布视频
作者用 Fable 发布视频作为例子说明整个方法如何串起来。
他一开始知道：
- Claude 可以用代码编辑视频；
- Claude 可以转录视频；
- ffmpeg 可能能剪掉停顿和“um”等口癖。
但他不知道：
- 转录是否足够准确；
- 是否能基于语音时间点精确剪辑；
- 是否能把 UI 动画和说话内容同步；
- 什么是好的 color grading；
- 如何判断调色结果是否专业。
于是他没有直接要求 Claude “剪一个最终视频”，而是逐步发现 unknowns：
- 先让 Claude 解释 Whisper / transcription / ffmpeg 的可行性；
- 再用 Remotion 和转录结果做一个 prototype video；
- 发现画面偏 muted 后，意识到问题属于 color grading；
- 但自己不知道什么是好的调色，于是让 Claude 先教他 color grading，帮助他建立判断标准。
这个案例说明：
高质量 AI 协作不是把模糊目标一次性交给模型，而是不断把未知拆小、验证、原型化、学习，再推进实现。
11. 可直接复用的完整工作流 Prompt
我接下来要做的任务是：[任务描述]。
请不要直接开始实现。先按以下流程协作：
1. 做一次 blindspot pass：
- 找出我可能没意识到的 unknown unknowns；
- 指出哪些上下文会显著改变实现方向；
- 提醒我可能的历史坑、边界情况和风险。
2. 区分四类信息：
- Known Knowns：我已经明确告诉你的内容；
- Known Unknowns：我知道还没决定的内容；
- Unknown Knowns：我可能需要通过原型/对比才能表达的偏好；
- Unknown Unknowns：我可能完全没考虑到的问题。
3. 如果任务涉及 UX、设计或产品判断，请先做低成本原型或方案对比，不要直接改真实系统。
4. 如果存在关键歧义，请采访我：
- 一次只问一个问题；
- 优先问会影响架构、数据模型、UX flow 或实现策略的问题。
5. 在我确认后，写实现计划：
- 开头列出最可能需要我调整的关键决策；
- 明确哪些是确定事实，哪些是你的假设；
- 把机械重构放在后面。
6. 实现过程中维护 implementation-notes.md：
- 记录偏离计划的地方；
- 记录 edge cases；
- 采用保守、可回滚方案；
- 标记 Review Needed。
7. 实现后输出：
- explainer；
- reviewer checklist；
- 行为变化总结；
- quiz，帮助我确认自己理解了改动。