别急着让 AI 写代码，先让它帮你找盲点

你肯定见过这种场景。

你对 AI 说：“帮我加一个评论功能。”半小时后，它真的交了一大坨代码：表结构有了，接口有了，前端输入框也有了，测试甚至也补了一些。

第一眼看起来很能干。但你一 review 就开始不舒服：

评论要不要审核？匿名用户能不能发？删除父评论时子评论怎么办？旧客户端看不看得到？多语言页面是共用一条评论串，还是分语言隔离？管理员删除和用户自己删除是不是同一种状态？

这些不是代码语法问题，也不是模型不会写。更麻烦的是：它替你猜了很多产品决策。

Anthropic 最近这篇 A field guide to Claude Fable 5: Finding your unknowns 打中的就是这个问题。它不是教你写更长的 prompt，而是在说：AI 越能干，人越要先弄清楚，哪些地方不能让它猜。

我觉得这是现在用 Claude Code、Codex、Cursor 这类工具最容易被低估的一件事。

Map 和 territory 的差

原文用一个很好的比喻开场：你给 Claude 的东西是 map，真实工作发生的地方是 territory。

map 是 prompt、skills、规格、上下文、参考资料。territory 是代码库、历史实现、产品约束、用户路径、团队偏好，以及那些没人写进文档但大家默认知道的规则。

两者之间的差，就是 unknowns。

这解释了很多 AI 编程里的奇怪时刻。

有时候 AI 写出来的代码没坏，但你就是觉得“不对”。它可能用了一个项目里不常用的模式，可能把本该保守处理的边界做成了自动兜底，也可能把你还没决定的产品问题直接固化进数据库结构。

它不是故意乱来。它只是遇到了 unknown，然后按自己最合理的猜测继续走。

模型越弱，这种问题越容易暴露，因为它会卡住。模型越强，反而越危险一点：它能把猜测包装成完整实现。

Fable 视频这个故事，才是重点

原文最后讲了一个 Fable 发布视频的例子，我觉得应该提前看。先把视频放在这里，后面这段才更容易理解。

Introducing Claude Fable 5

Anthropic 官方发布视频。原文里提到，这个 Fable 发布视频是用 Claude Code 端到端剪出来的。YouTube

这个视频是作者用 Claude Code 端到端剪出来的。但作者并不是视频专家，所以他没有一上来就命令 Claude：“帮我剪一个最终版发布视频。”

他先从自己知道的部分开始：Claude 可以用代码处理视频，也可以做转录。但他不知道转录够不够准，不知道能不能用 ffmpeg 精准剪掉停顿和语气词。

于是他先让 Claude 解释 transcription、Whisper 和 ffmpeg 的限制。后来他想让画面跟着词同步，但不确定能不能做，于是让 Claude 用 Remotion 和转录先做一个原型。再后来，视频看起来有点灰，他知道这可能和 color grading 有关，但不知道什么叫好，于是没有继续让 Claude 瞎调，而是先让 Claude 教他理解 color grading 里的未知。

这个故事好就好在，它不是“AI 一步到位完成复杂任务”。

它更像一个人不断承认：这里我不懂，先把不懂的地方照出来。照出来以后，再进入下一步。

这才是那篇文章真正有用的地方。它把 AI 编程从“让模型执行任务”，换成了“让模型帮你找任务里的盲点”。

四种 unknowns

原文把 unknowns 分成四类。

第一类是 known knowns：你知道，也写进 prompt 了。比如“只改这个页面”“复用现有组件”“不要引入新依赖”。

第二类是 known unknowns：你知道自己还没想清楚。比如权限边界、数据迁移、失败重试、发布策略。

第三类是 unknown knowns：你其实知道，但没说出来。比如代码风格、审美偏好、团队默认取舍。你提前说不清，但看到结果会立刻知道“不像我们项目”。

第四类是 unknown unknowns：你根本没意识到。比如旧接口依赖某个空值语义，某个测试保护的是历史兼容行为，某个老用户路径会被新逻辑打断。

我觉得这四类里，最容易被忽视的是第三类和第四类。

很多人以为 AI 写代码翻车，是因为 prompt 写得不够细。但你没法把所有 unknown knowns 都写出来，也没法提前列出所有 unknown unknowns。真正有效的做法不是把 prompt 写成十页规格书，而是用几个动作更早把这些东西逼出来。

开工前：不要急着写 plan

原文最实用的一段，是 pre-implementation。它没有上来就让 Claude 写计划，而是先用几种方式找未知。

1. Blind spot pass

如果你要进入一个不熟的模块，第一句不要说“实现这个功能”。

先让它找盲点。

我准备做 X，但我对这个模块不熟。
先做一次 blind spot pass：
找出我可能不知道、但会影响实现的 unknown unknowns。
能靠读代码确认的你自己查，需要我判断的再问我。

这句话的价值是把问题从“我不知道自己不知道什么”，推进到“我知道接下来要确认什么”。

比如你要改登录流程，它可能先告诉你：这里有旧 OAuth provider、移动端还在用某个回调参数、测试里有一个历史兼容路径、管理员登录和普通用户登录不是同一套逻辑。

这些信息一旦晚发现，返工会很贵。

2. Brainstorm / prototype

如果你说不清想要什么，就别硬写抽象形容词。

让 Claude 做几个你能反应的东西。

先不要接真实后端。
用假数据做 4 个方向不同的 HTML 原型。
每个方向说明适合什么取舍，我看完再选。

这处理的是 unknown knowns。

很多审美、交互、信息密度、产品语气，不是靠你提前写清楚的，而是靠你看见之后反应出来的。原型不是绕路，它是在用便宜的方式提前暴露判断。

3. Interview

做完探索之后，还会有一些问题必须由你拍板。

这时候再让 Claude interview 你。重点不是多问，而是问那些会改变实现路线的问题。

一次问我一个问题。
只问那些答案会改变数据模型、权限、用户流程或测试策略的问题。
每题给出你的推荐答案和原因。

这里也可以用 Grill Me 这种方式，但它只是 interview 环节的工具，不需要把它抬成另一套主线。

4. Reference

当你说不清想要什么时，给参考。

对代码任务来说，最好的参考常常不是截图，而是源代码。截图告诉 AI 长什么样，源码告诉它结构、命名、数据流、错误处理和边界语义。

如果你想把某个库里的 backoff 行为迁移到自己的 TypeScript client，别只说“做一个指数退避”。直接让 Claude 读那段实现，再要求它复刻语义。

5. Implementation plan

最后才写 implementation plan。

而且计划不要把篇幅浪费在“我会修改文件、运行测试”这种机械步骤上。你真正要 review 的是那些最可能导致返工的地方：

• 数据模型会不会变
• 类型接口怎么定
• 用户看得见的行为是什么
• 权限和异常态怎么处理
• 哪些测试能证明行为没偏

计划的作用不是让 Claude 显得有条理，而是让你在动手前看到：哪些决定还没有被真正决定。

开工中：让偏离浮出来

就算开工前做了这些，实施过程中也会撞上现实。

Claude 可能发现某个旧接口不能改，某个 edge case 会破坏原计划，某个测试保护的是历史行为而不是理想行为。这个时候它很可能会自己选一个折中，然后继续写。

问题是，如果它不记录，你最后只会看到一个 diff。你不知道哪些地方是按计划做的，哪些地方是中途临时改的。

所以原文建议让 Claude 维护 implementation notes。我觉得这是最值得立刻抄走的小习惯。

实现时维护 implementation-notes.md。
如果你发现计划和现有代码不一致，先选保守方案继续，并把偏离记录到 Deviations。
每个偏离都写清楚：发现了什么、为什么偏离、我需要 review 什么。

这会让 review 轻很多。

你不再是盯着几百行 diff 猜它脑子里发生了什么，而是能直接看它在哪些地方改变过路线。

开工后：让它解释，也让它考你

原文最后还有两个动作：explainer 和 quiz。

explainer 是给别人看的。一个好的解释文档应该把背景、原型、实现笔记、demo、风险和常见失败点放在一起。这样 reviewer 不是从零理解 diff，而是先知道你解决了什么、放弃了什么、哪些地方需要重点看。

quiz 是给自己看的。

长任务结束后，你很容易以为自己懂了，其实只是看懂了 diff 的表面。让 Claude 反过来考你，会暴露另一种 unknown：你以为自己理解了，但其实没有。

请解释这次变更影响了哪些行为和路径。
然后给我 8 个问题测试我是否真的理解。
我答不出来的地方，说明还不能合并。

这听起来有点麻烦，但很适合大改动。尤其是那种 AI 跑了很久、跨了很多文件、你已经有点不想再看的任务。

可以直接照抄的启动清单

如果只带走一个东西，我建议把下一次 AI 编程会话改成这个顺序。

第一步，不要让它马上实现：

我准备做 X。先不要写代码。
请根据当前代码库做一次 blind spot pass：
列出 known unknowns、unknown knowns、unknown unknowns。
能自己查的先查，需要我判断的再问。

第二步，如果涉及界面、交互、报告、文案、数据展示：

先做 3-4 个低成本原型，不接真实数据。
每个方向说明取舍，让我先反应。

第三步，如果涉及架构或产品决策：

一次问我一个问题。
优先问会改变数据模型、权限、用户流程、兼容性或测试策略的问题。

第四步，再让它写计划：

写 implementation plan。
先写最可能被我修改的决策，再写机械执行步骤。
标出你认为风险最高、最需要我 review 的部分。

第五步，实施时保留笔记：

维护 implementation-notes.md。
任何偏离计划的地方都记录原因和 review 点。

第六步，合并前让它考你：

写一份 explainer，并给我一组 quiz。
测试我是否真的理解了这次变更。

这套流程的好处是，它没有假设你一开始就能把需求说清楚。相反，它承认：很多需求是在看见盲点之后才变清楚的。

我读完这篇最大的感觉是：AI 编程最怕的不是模型慢，也不是模型不够聪明。

最怕的是它太聪明，聪明到可以一路替你猜下去。

你要练的不是把命令写得更漂亮，而是更早看出来：哪些地方必须问，哪些地方应该先试，哪些地方不能让它替你做决定。

知道的，写进 prompt。

说不清的，先做原型。

没想到的，让它帮你找。

还没确认的，不要让它写进代码。