模型越强，越得先把要什么说清楚
这几个月我干活，基本都是把事情交代给 agent 去做，自己不太动手。交代得多了，有个感受越来越明显，就是模型越强，你说不清楚自己要什么，吃的亏就越大。
你说错了，它就照着你说错的方向非常高效地干下去，又快又完整，一路做到底。它不会帮你把话补严实，你要求里含糊的地方，它全给你放大。这个问题其实一直都在，只是以前模型自己也做不好，问题暴露不出来，锅还能甩给模型。
所以这一代模型出来以后，我发现真正要升级的，是我跟它交代事情的方式。下面这套方法不复杂，也谈不上多原创，大概一半来自 Anthropic 一个工程师最近写的文章，一半是我自己踩坑踩出来的。但它确实管用，把我从反复返工里捞了出来，所以我想完整讲一遍。
先讲我自己翻车的事。上个月我废了两篇已经写完的稿子，都是 AI 写的播客反应文。单看手艺，稿子挑不出毛病，结构工整，论据齐全，中文也通顺。但我越读越不对劲，这两篇读起来太像产品软文了，跟我博客想要的方向完全不是一回事。最后整篇报废，一个字都没用上。
可 AI 一步都没做错，素材和要求它都老老实实照办了。毛病出在我给的要求里，根本就没有「别写成软文」这一条。我自己也是读到成稿那一刻才意识到，原来我心里一直有这条要求，只是它理所当然到我从来没说出口。
后来我琢磨这个事，发现它不是个案，是一类通病。你跟 agent 干活，给它的 prompt、context、规则文件、参考资料，所有这些凑起来是一张地图。而活真正要落地的地方，也就是你的 codebase、你的业务、你脑子里那些自己都没察觉的偏好，是疆域。普通语义学里有句老话，叫地图不是疆域，放在这儿正好。
拿写代码举个例子。你说「给系统加一个第三方登录」，这句话在地图上就一行。可疆域里的东西多得多，老的认证模块当年是怎么设计的，已有用户的登录状态怎么迁移，企业客户是不是还依赖某个旧行为，登录页要不要跟着改。这些你一个字都没提，但每一条都决定成品对不对。
地图和疆域之间差的那一块，Anthropic 那篇文章管它叫 unknowns。我更愿意叫它空白，就是你没画出来、agent 路过的时候只能靠猜的地方。
地图与疆域
那它撞上空白，为什么不停下来问你？这得从 agent 怎么干活说起。agent 没有跨 session 的记忆，每次开工都是从头来，你给它的地图就是它眼里的全部世界。它受的训练又是把活干完，不是把你问烦。所以走到没画的地方，它的本能是照训练里见得最多的走法接着走。这么猜，十次里大概有八次说得过去，但放到你的具体场景里对不对，全看运气。活越大，路过的空白越多，猜错的地方也就越攒越多。
想明白这个，「prompt 到底该写多细」这个老争论就好理解了。写得太死，它明明看见了更好的路，也只会闷头执行你的错误指令。写得太松，它就拿行业里通行的做法给你填空，可通行做法到你这儿往往不合身。两种写法其实栽在同一个地方，就是你不知道自己的地图哪里没画。
那空白怎么找？Anthropic 那篇给了个拆法，分四格。这四格里有三格是拉姆斯菲尔德在记者会上讲出来的，第三格是后来齐泽克补的。他那段话被群嘲了很多年。当年嘲得冤不冤我不知道，只能说放到 AI 协作上，这个框架是真的好用。
四种空白
第一格，你知道自己知道的。就是已经写进 prompt 的那些，不用管。
第二格，你知道自己不知道的。比如要做个功能，数据结构还没想好，你心里清楚这儿有个坑。
第三格，你不知道自己知道的。这格最麻烦。有些要求你从来不会写出来，因为太理所当然了，理所当然到你根本不觉得那是个要求，可成品一旦犯了，你一眼就能认出来。我那两篇报废稿就死在这格，「别写成软文」在我心里理所当然到从来没说出口。taste（品味）这类东西基本全在这格，说不出来，但看到就认得。
第四格，你不知道自己不知道的。刚进一个新领域，该问什么不知道，「好」长什么样也没概念。
四格对应四种做法，而且别用错格，这是我踩完坑以后最大的体会。下面一个一个说。
- 让 agent 反过来采访你。
治第二格。你知道有些事没想好，又懒得自己一条条捋，那就别捋了，直接跟它说：动工之前你先采访我，一次问一个，把没说清的地方都问出来。
但一定要加一条过滤，只许它问那些答案会牵动架构的问题。不加这条，它能问出二十个客气但不痛不痒的问题，把你烦死。加了这条，问出来的基本个个都扎在要害上。哪些数据要存下来，用户销号了记录怎么办，这种一答错方向就得推倒重来的问题，才值得在动工前占你的时间。
我常用的原话，可以直接抄：
动工前先别动手。你来采访我，一次问一个问题，把需求里含糊的地方问清楚。只问那些答案会牵动数据模型、接口约定、权限边界、迁移方案或用户可见行为的问题，命名和实现细节你自己定，别来问我。每答完一个，先更新你对整个方案的理解，再问下一个。
- 先打样，再开工。
治第三格，就是 taste 那格。既然说不出、只认得出，那就别逼自己说了，让它先出两三个方向完全不同的小样，你来挑。写文章，就先出三个不同角度的开头，各两百字；做界面，就先出四版路子完全不同的静态稿。挑中了，再往下做全套。跟印刷厂一个道理，先打样给客户过目，客户点头了才开印，没有人直接开印一万册。
废三个两百字的开头，成本约等于零；废两篇四千字的成稿，就是我上个月的下场。同一个问题，在小样里暴露比在成稿里暴露便宜二十倍。
这篇文章自己就是这么写的。动笔前我让 claude 出了三个开头，分别是翻车实录、概念科普和反直觉判断，各两百字。我挑了第三个，就是你现在读到的这个。
prompt 骨架长这样，照着改：
先别写全文。给我出 3 个方向差别很大的开头，每个两百字上下，各配一句话说明这个方向图什么。我挑一个，你再展开。
- 盲区扫描。
治第四格。刚进新领域，连问题都提不出来，那就先别干活，让它先给你画一张这个领域的地图：
我要做 X，这个领域我是外行。先别动手。帮我做一次盲区扫描，列出我多半没意识到的坑、我该问但不知道要问的问题，还有「好」在这行长什么样。按风险和回头成本排序，每条给出具体出处或代码位置，别给我一篮子空话。最后教我怎么给你提需求。
Anthropic 那篇文章里有个例子讲得挺好，我记到现在。作者剪视频，觉得画面发灰，知道该调色，但不懂调色。他第一反应是让 claude 调几版给他挑，结果挑不动，因为他根本不知道好的调色长什么样，打样这招直接失灵了。后来他换了个问法，让 claude 先给他讲调色的基本门道，学明白了再挑，一下就顺了。
这个例子正好戳到一个容易搞混的地方，第三格和第四格的做法不通用。你得认得出好坏，才能挑小样。认不出，就先补课，把第四格的问题变成第三格的，再按第三格的办法来。补课要花你半小时，听着亏，其实比闷头重做三遍便宜多了。
- 拿参考物说话。
这条算前面几招的补充，但我还是想单独说说。有些东西你形容半天，还不如直接指给它看。想要某个库的重试逻辑，就别形容了，把那个库的源码指给它，让它读完照着做。想抄某个网站的设计感觉，别说「高级一点」「干净一点」，把网站丢给它，让它去读底下的代码。还有一点很多人没意识到，源码比截图好用，因为源码里带着结构信息，截图只有一个样子。
vendor/rate-limiter 这个库的退避重试就是我要的行为。读它的源码，把同样的逻辑在我们的 TypeScript 客户端里照着实现一遍。
四格对症下药
那是不是把前期功课做到极致就行了？也不是。问也是有成本的，而且越往后问，收获越少。问到第五轮，它问出来的问题你自己都答不上来，再问下去就是互相折磨。
我自己什么时候收手呢？只要「做没做对」能交给一条测试、一个脚本、一次 lint 来判断，就立刻收住，开工。到了这一步，让它干完直接跑检查，比你接着用嘴形容快得多。这块我在让 Agent 自己证明它做完了里写透了，验收搭得越硬，前期要说清楚的就越少。
还有一个变化也在往这个方向推。生成越来越便宜，所以「做三个再挑」会越来越多地赢过「问清楚再做一个」。taste 类的活尤其是这样，小样反正不值钱，多打几个样，比多聊三轮天划算。
干长活还得多做一件事。前面这些招全是用在动工之前的，但有些空白要干到一半才冒出来，比如写到一半发现现成的架子装不下，或者测试跑起来才发现老逻辑里藏着没人知道的依赖。这种时候别指望 agent 停下来等你，给它立个规矩，让它一边干一边记偏航日志：
干活过程中记一本偏航日志。凡是实际代码跟计划对不上、你替我做了取舍、或者跳过了哪个边角情况，都记下来，写清发现了什么、牵扯到什么、你选了哪条路、哪里等我拍板。命名格式这类小事不用记。记完拣稳妥的路接着走，别停下来等我。
干完我翻一遍日志，五分钟就知道它在哪些地方替我拿过主意，比从头读改动快得多。真出了问题，也能查出来是从哪一步开始偏的。
最后说一条最要紧的，Anthropic 那篇没讲到，就是同一个坑别踩第二遍。你用两篇报废稿换来了「别写成软文」这条要求，接下来就看这个教训是留在你脑子里，还是写进系统里。留在脑子里的话，换个话题、换个新对话，同一个坑多半还得再踩一遍。前面说过，agent 每次开工都是从你给的地图重新认识世界，你不写下来，它就永远不知道，每个新 session 都不知道。
我的做法是当场写下来。那次报废以后，「别写成软文」就进了我博客的配置，成了一条硬规矩，每篇新稿都自动受它管。「先打样」也一样，我把它写成了写作流程里的固定步骤，新文章不出三个开头不许写全文。地图每补上一块，以后每次开工都能用上。
同一个坑只交一次学费：教训留在脑子里会再踩一遍，写进规矩以后都绕开
再往前想一步。既然差的就是疆域比地图多出来的那部分，那要缩小差距就有两条路。一条是每次干活都把地图画细一点，这篇讲的全是这个。另一条更底层，是把疆域本身修规整，让它本来就好画，codebase 的目录一看就懂，约定一搜就能搜到，规矩写在 agent 每次必读的地方。这些活干一次，以后每次都受益。这条路我单独写过一篇代码仓库是给 Agent 的 API，跟这篇正好是一体两面。
整套东西捋一遍。第二格用采访，让它一个一个问出来；第三格用打样，先挑再做；第四格先补课，补完当第三格用；形容不清楚的，直接甩参考物给它。验收一旦能交给机器判断，就收住开工。踩了坑，当场写进规矩，别留在脑子里。
反正我现在的感受是，「知道自己要什么」变成了一个要专门练的 skill。模型会放大你的含糊，也一样会放大你的清楚，你交代得越明白，它就做得越到位。至于你不知道自己要什么的那部分，前面也说了，可以让它帮你问出来。我现在踩到新的坑，第一反应就是回去把规矩补进配置里，补完这一步才算干完。