发现你的未知：Agentic Coding 的地图与疆域
先交代实践背景：这套方法论来自 Anthropic 一位工程师（@trq212）的总结，我照着用了两周，这篇一半是转述，一半是我自己的实践笔记。先说结论——值得用，而且它改变的主要不是技巧，是心态。
地图与疆域
框架的核心是一个隐喻。你给 Agent 的 prompt、上下文、配置，是地图；代码库、真实约束、你脑子里的真实意图，是疆域。两者的差集就是 unknowns——Agent 每撞上一块地图没标注的疆域，只能按「对你意图的最佳猜测」行动。任务越大，撞上的未知越多，猜错的累积越可观。
这个隐喻一下子解开了我用 Agent 时的一个长期困惑：为什么指令写详细也不对、写简略也不对？写太细，它该转向时也死守指令；写太粗，它按「业界最佳实践」补空——而最佳实践未必是你的场景。原来两头难受的根源是同一个：没有管理未知。指令的粗细只是在未知面前换姿势，未知本身一点没少。
提出者有个判断我认同：新一代模型已经强到「工作质量的瓶颈不在模型，而在人能否把自己的不懂讲清楚」。顶级的 agentic coder 未知少——他们对代码库和模型行为都深度同步——但更关键的是,他们主动假设未知存在，把发现未知当成显式的工作项。
那个 2×2
把「知道/不知道」和「意识到/没意识到」交叉，四个象限：
| 我知道 | 我不知道 | |
|---|---|---|
| 意识到 | 写进 prompt 的 | 明确还没想清楚的 |
| 没意识到 | 看到才认得的标准 | 完全没考虑到的 |
右下角（unknown unknowns）名声最大，但两周实践下来，我被坑最多的是左下角——unknown knowns：那些「显然到不会写下来、但看到成品立刻知道不对」的标准。
给个真实例子。让 Agent 做一个内部报表页面，需求我自认写得很细。成品出来，功能全对，但我看了一眼就知道不行——数字没有千分位、表格能横向滚动但列没有冻结、导出按钮放在了左上角。这些要求我一条都没写，因为我不知道自己有这些要求，直到看见违反它们的东西。这就是 unknown knowns：你的品味和习惯里藏着大量从未显式化的验收标准。
两周里最好用的三招
方法论原文给了七种技巧，覆盖实现前中后。我全试了，按实用度说说体感最好的三个。
第一名：先出方向，再反向采访。做有模糊空间的需求时，先让 Agent 出几个差异极大的方案方向（视觉类的就出几版风格迥异的原型），我挑一个，然后让它一次一个问题地采访我，优先问「答案会改变架构」的问题。上面那个报表页面的教训之后，我用这套流程重做了一次：它出的第二个问题就是「表格预期最大多少列？需要冻结列吗？」——你看，我自己想不起来的标准，被问出来了。两轮下来大概二十分钟，unknown knowns 被逼出来一串。这二十分钟省下的返工以天计。
第二名：给源码当参照物。说不清楚的需求，别憋形容词，直接指认：「交互参考这个库的这个组件」，最好直接给源码路径。实测源码远胜截图，截图又远胜形容词——「像 X 那样的丝滑滚动」这种话对模型是噪声，一个能读的实现才是信号。语言不同都没关系，语义能平移。
第三名：merge 前让它出题考我。实现完成后，让 Agent 出一套关于「这次改动实际行为」的小测验，我来答，答满分才 merge。听起来像行为艺术,直到它真抓住一条漏网之鱼：一次改动里它调整了某个接口的空值处理逻辑（计划里没有,是实现中撞到边界情况后的合理决策，也记进了变更说明——但我没细看）。quiz 里它问「传入空列表时接口现在返回什么」，我答错了。diff 我看过,行为我没懂——这条如果带着我的错误理解上线,排查时会非常酸爽。现在重要变更我都走这道工序，成本五分钟。
顺便说没那么惊艳的：盲区扫描（让模型帮你找 unknown unknowns）在我熟悉的领域收益一般，多数「盲区」我确实知道；但在陌生领域（比如我最近碰的一点前端动画）确实有用，它列出的注意事项里有一半我真不知道。技巧的收益和你在该领域的未知存量成正比,很合理。
实现中：决策日志接住计划外的一切
前中后三个阶段里，「实现中」的技巧只有一个,但值得单独说，因为它解决的是最烦人的问题：计划再好，实现时总会撞上计划没覆盖的边界情况，这时候 Agent 怎么办？
默认行为是两个极端：要么每撞上一个就停下来问你（你被打断十次,烦死）,要么自作主张选一个（选错了你还不知道）。这套方法给了第三条路,写进任务说明：
撞到计划未覆盖的情况时：
1. 选择保守方案（改动最小、最容易回滚的那个）
2. 把「撞到什么、选了什么、为什么」记入 implementation-notes
的 Deviations 一节
3. 继续推进，不要停下来等确认
然后你在方便的时候批量审查 Deviations。这个设计的精妙在于它同时优化了三方：Agent 不被阻塞、你不被打断、决策留痕可回溯。我用下来，一个中型任务通常积累三到七条偏差记录，批量审一遍五分钟，其中大概一两条我会要求改——也就是说它的保守猜测七成以上是对的，但剩下三成如果没有日志，就是三成的暗雷。
补一个细节：「保守」要在任务说明里定义,不能让它自由发挥。我的定义是「优先选不改变对外行为的方案；必须改变时，选影响面最小的」。没这句的时候，它对「保守」的理解偏向「功能最全」——给边界情况加一堆防御性处理——那不是保守，是画蛇添足。
心态的变化
说回开头那句「改变的是心态」。具体讲，是归因方式变了。
以前 Agent 产出不对，我的第一反应是「它没理解」，改进动作是换个说法重试——本质是撞运气。现在的第一反应是「我的地图哪里漏了」，改进动作是定位那块缺失（是 unknown known 没逼出来？还是约束没写进 spec？），然后补上——补的地图是累积的，下次任务直接受益。前者是消耗，后者是投资，长期差距会很大。
再往大了说，把这个系列的文章串起来看有条线：控盘规则管「边界内的自主」，RPI 管「阶段的顺序」，而 unknowns 方法管的是最上游——边界本身画得对不对。地图错了，下游纪律执行得越好，错得越远。
模型每强一代，「它做不到」这个借口就少一分，剩下的差距全是「我没说清」。这话对工程师不算坏消息——把自己的不懂讲清楚，本来就是我们这行最古老的核心技能，从写需求文档的年代就是。工具换了，功夫没换。