夜雨聆风事情是这样的。
前两天我手里有一份 agent 的设计文档，写得不算差，但我心里总有点不踏实，说不清哪儿虚。就想着找个东西帮我审一遍。我用的是 /grill-with-docs，一个专门拿来盘文档的东西，简单说就是让 AI 揪着你的设计反复追问，问到你没话说为止。
一开始我是抱着「让它挑挑毛病」的心态去的。结果 13 轮问答下来，逼出了 8 条架构决策记录，文档里那些我原本含糊过去的地方，全被摊到台面上了。
但真正让我坐那儿愣了一会儿的，不是它挑出了多少问题。
是它问问题的方式。
我做技术这些年，评审别人的设计、被别人评审，这事儿干得不少了。自认为审文档还算有点手感。可这一轮下来我发现，它组织追问的那个节奏，比我强。不是强在它比我懂，是强在它比我有章法。我审东西经常是凭直觉东戳一下西戳一下，它是一套有结构的打法，一步扣一步。
我复盘的时候把这套打法拆出来了，一共 7 步。我越拆越觉得，这玩意儿根本不绑工具。你自己审别人的设计也好，带着 AI 一起 review 也好，甚至就是拿它当个 checklist 提醒自己，这套节奏都能用。
我也不敢说这就是审查的标准答案，我自己也还在琢磨。但这 7 步确实改了我不少习惯，掏出来跟你聊聊。
我原以为它上来就会怼我第一个问题。没有。
它第一步是去翻仓库结构，读上下文文件，把目录层级从上到下扫了一遍。等它把「这个项目到底长什么样」摸清楚了，才开始动嘴。
这个顺序我以前是反着来的。
坦率的讲，大部分人做 review 的姿势都差不多，拿到一份文档，从第一行往下读，读到哪儿觉得不对就问到哪儿。问题是散的，东一个西一个，全落在局部。这么审有个隐患，你能看见每一句话对不对，但你看不见句子和句子之间、模块和模块之间的关系。
它不是这么干的。它先建全局认知，再定点打击。
有一次它问我的问题是这么个句式，你这个模块的设计，跟三个文件之外那块的假设是冲突的。我当时就想，这话逐行读文档的人根本问不出来。因为你得先在脑子里同时装下这两块东西，才看得见它们打架。它是先把整张地图铺在桌上，然后手指头点着说这儿和那儿对不上。
后面每一个问题都打在要害上，回头看，靠的全是它一开始没急着开口、先花时间把地图建起来这一步。
所以你要是想抄这一步，就一件事，别急着读第一行。 先花十分钟搞清楚这份设计所处的上下文，它依赖谁，谁依赖它，边界在哪。地图没建起来之前问出来的问题，大概率都是浮在表面的。
需要素材，它自己去翻，不问你要
聊到测试夹具那块的时候，出了个我特别欣赏的动作。
按常理，它这时候该问我一句，你有没有 ETL 相关的文件？然后等我回答。它没有。它直接就去 find 目录、cat 文件，自己一个一个读。读完了才回过头来告诉我，你这套素材缺两样东西，你设计里的那条关键路径，物理上是跑不通的。
这一下给我省了两件事。
一件是描述素材结构的来回。我要是自己解释目录里有啥，得吭哧吭哧打一大段字，还未必说全。它自己去读，这段字我一个都不用打。
另一件更要命，它替我照出了一个盲区，就是我「以为有、但其实不全」的那部分。我跟你说实话，做项目做久了，你脑子里记的那个项目状态，跟磁盘上真实的状态，经常是对不上的。你以为某个文件早加进去了，其实还躺在你另一个分支上。你以为某段逻辑写完了，其实只写了一半。
它不信我的转述。它只认自己亲眼读到的东西。
这点我觉得还是挺重要的。我们跟 AI 协作的时候，很容易图省事，用嘴告诉它「情况就是这样」，它信了，然后你俩一起在一个错误的前提上往下推。它这种「你别说了我自己看」的做法，看着有点不近人情，其实是把地基给你夯实了。
这一步能落到你自己身上的，是一个提醒。 审设计的时候，凡是能去看源头的，别听转述，包括别听你自己的记忆。你以为的和实际有的，中间那道缝，恰恰是 bug 最爱藏的地方。
发现矛盾，它把两条原文并排贴出来，逼你当场选
这是整个过程里我印象最深的一个动作。
它某一轮直接甩给我这么一段，§5.1.2 说禁止回补取证，§5.1.4 说校验失败退回取证。这两条打架了，你选哪个？
我想让你注意它的措辞。它没说「这里好像有点不一致哦」，也没自作主张替我猜「我觉得应该是前面那条对」。它干的事情特别干脆，把两处冲突的原文，一个字都不改，并排贴在一起，然后把球踢给我，你定。
这个动作狠在哪儿？
它把一个「模糊的不舒服感」，变成了一个「必须二选一的岔路口」。
你想想看，我自己读这份文档的时候，其实隐隐是感觉到有点别扭的。5.1.2 和 5.1.4 我都看过，但读的时候隔了挺远，那种别扭是一闪而过的，我当时的处理方式是「先记着，回头再说」。然后就没有然后了。这种模糊的不舒服，最后基本都不了了之。
它不给我这个含糊过去的机会。两条规则白纸黑字并排摆在那儿，你不选一个，你这系统就是自相矛盾的，跑起来一定出问题。没有模糊空间，没有「回头再看」，当场必须给个说法。
我事后想，这其实是审查里最反人性、但也最值钱的一步。因为发现矛盾不难，难的是你有没有胆子把它摊开、并且拒绝自己糊弄过去。
你带着 AI review 的时候，可以专门给它下这个指令。 不要让它给你一段温柔的「建议」，让它把冲突的原文成对贴出来，逼你二选一。含糊的措辞是共识的敌人，并排的原文才是。
它每个问题都自带一个推荐答案
聊到这儿你可能觉得，那它是不是特别咄咄逼人，一个问题接一个问题地拷问？
恰恰相反。它问得特别省我脑子。
关键在于，它从来不开放式地问我「你怎么想」。它每一个问题的结构都是一样的，我推荐 X，理由是 Y，代价是 Z，你拍板。
13 轮里，我有 12 次是直接回它「按推荐来」。
一开始我还有点不好意思，觉得自己是不是太偷懒了。后来我琢磨明白了，这压根不是偷懒，是这俩活儿的脑力成本差了一个量级。
它带着推荐来问我，我要干的事情只是判断，它这个推荐有没有硬伤。这是个校对题，我看一眼理由和代价，觉得没毛病，过。可要是它开放式地问我「你觉得这儿该怎么设计」，我就得从一张白纸开始，自己把所有选项列出来，自己权衡，自己得出结论。这是个论述题。
校对题和论述题，你自己感受一下这中间的差距。
我一直觉得，开放式提问这东西，听着特别尊重人，「我把决定权交给你」，实际上是把最重的那部分思考负担，原封不动甩回给了你。真正在帮你往前走的，是带推荐的提问。它先把 80% 的活干了，列选项、找理由、算代价，然后把最后那 20% 的拍板权留给你。
这个姿态我特别认。它没有替我做决定，决定权始终在我手里。但它也没有假模假式地把整摊活儿都推给我。
这一条是我觉得最该抄进日常的。 你以后不管是让 AI 帮你想事情，还是你自己给同事提问题，都别停在「你怎么看」。往前多走一步，「我倾向 X，因为 Y，但有 Z 这个代价，你怎么定」。就这一步，能帮对方省掉大半的力气。
我推翻它的时候，它没有硬顶，也没有秒怂
第 4 轮，我否了它的推荐。
我很好奇它会怎么反应。因为跟 AI 打交道久了，你大概会遇到两种货色。一种是秒怂型，你一说「我不同意」，它立马「好的您说得对，听您的」，然后就没下文了。另一种是嘴硬型，反复跟你解释「不不不你没理解，我这个方案其实是对的」，跟你在那儿磨。
它两种都不是。
它接受了我的决定，但接受得不是无脑的。它顺着我选的这条路，重新论证了一遍，为什么我选的反而更合理，然后把那条 ADR 的 rationale，整个重写了一版。
我当时就有点感慨。
你看啊，秒怂型的问题在哪儿？它是把决策给你留了个悬空的坑。你说选 B，它说好，可 B 为什么对、B 的代价你扛不扛得住，没人给你补这个逻辑。这个决定是站不住的，过两天你自己都会忘了当初为啥选 B。
嘴硬型就更别提了，纯粹是消耗。
它是第三种。你选了 B，那我帮你把 B 的论证补完整。它不跟你争谁对谁错，它认你的决定，然后把力气花在，让这个决定真正站得住脚上。
这个分寸我觉得太难得了。它既没有放弃自己的判断力，变成一个应声虫，又没有把自己的判断凌驾在我之上。它守住了一条线，最终拍板的是你，但我负责让你拍的这一板，有据可依。
如果你在训练自己或者调教 AI 的 review 习惯，这一条值得刻意练。 被推翻之后，别急着道歉，也别急着辩解。问自己一句，对方选的这条路，我能不能帮他把逻辑补圆？能，就补。这比「听话」和「嘴硬」都高级。
每定一条，它当场就固化下来，不攒到最后
还有个习惯，我是全程都在偷偷学它的。
第一个术语刚敲定，它就顺手建了个术语表。之后每达成一条决策，它立刻写进 ADR。不是聊完了再一把整理，是边聊边沉淀，实时归档。
好处有两个，我都实打实体会到了。
第一个是抗中断。我们聊到一半，我得去开个会，走之前我心里还有点慌，怕回来接不上。结果开完会回来一看，之前敲定的每一条结论，一条不落全在那儿摆着。我不用回忆「刚才我们聊到哪了、定了啥」，白纸黑字，直接接着往下走。
第二个好处更隐蔽，但我觉得更值钱，它防住了「决策漂移」。
什么叫决策漂移？就是你前面明明定好了一件事，聊着聊着，不知不觉就偏离了，最后你会发现后半段的讨论和前半段的结论，悄悄地对不上了。这事儿特别常见，尤其是长时间的讨论。因为你前面定的东西只存在脑子里，脑子这个缓存是会漂的。
它把每条决策实时写死在文档里。前面定的东西白纸黑字戳在那儿，后面的讨论想偏都偏不了，一偏就跟已经写下的条目打架，当场就露馅。
我以前的习惯恰恰相反，喜欢先聊个痛快，想着「等聊完了我再统一整理成文档」。这个做法看着高效，一气呵成嘛。实际上，你聊的每一轮，都在拿脑子当缓存使。聊得越久，前面的东西丢得越多，最后整理的时候，好几个当时明明想清楚了的点，怎么都想不起来了。
这一步的行动建议特别具体，达成一条，记一条。 别信自己的短期记忆，它没你以为的那么可靠。你在跟 AI review 的时候，可以要求它每定一条就更新文档，你自己开会讨论也一样，让一个人实时记，比事后追记强太多。
它知道什么时候该停
第 13 轮之后，它停了。
不是我喊停的，是它自己主动停的。它跟我说，再往下问，就是在实现计划的地盘上空转了，设计层面该逼的洞已经逼完。然后它给了我三个选项，让我挑下一步干啥。
这一下，我是真有点服气。
因为「知道什么时候停」，比「会不会问」难太多了。
会问的人不少。可我见过太多 review，问着问着就刹不住了。要么无限发散，从一个设计问题聊到人生理想；要么机械地追问「还有别的问题吗、还有吗」，为了显得认真而认真，其实早就没有新东西了，纯粹在耗时间。
它是真的做了判断。它掂量了一下，设计层面能问出价值的问题，问完了，剩下的都属于「这个要怎么实现」的活儿，那是下一个阶段该干的，不该在这儿聊。于是它收手，并且把决定权又交回给我。
我有时候觉得，一个人或者一个工具成不成熟，很大程度上看它知不知道边界在哪。差的 review 是没完没了，让你觉得永远审不完，心累。好的 review 是有始有终，该逼的时候往死里逼，该收的时候干净利落地收。
这个「停」的能力，说到底是一种判断力，判断眼前这件事的价值已经被榨干了。它稀缺，是因为大多数时候，继续问下去总比承认「问完了」显得更安全、更勤奋。可真正专业的做法，是敢在恰当的地方喊停。
这最后一步，反而是最难抄的。 它没有具体动作，全靠火候。但你至少可以把这个意识装进脑子，审查的目标不是穷尽所有问题，是逼出所有该在这一层解决的问题。够了，就停。
写在最后
这 7 步捋完，我自己最大的一个转变是，我以前一直觉得，审查这活儿的核心是「挑毛病」,谁挑出来的毛病多谁厉害。
现在我不这么想了。
好的审查不是逐行挑刺，是交叉验证系统里各个部分到底自不自洽。它厉害的地方，从来不是它比我懂多少，而是它有一套节奏，能把我心里那些「模糊的、说不清的、隐隐觉得不对但懒得深究」的东西，一步一步逼成白纸黑字的、必须当场表态的决策。
先建地图，自己翻料，把矛盾摊开，带着推荐问，被推翻了帮你补逻辑，边聊边固化，最后干净地收手。
你回头看这 7 步，会发现它们串起来其实是一件事，用节奏，把模糊的共识，逼成明确的决策。
我们老说要 AI 帮我们干活。可这一趟下来我发现，有时候更值钱的，是看它怎么干活。它把一套我隐约会、但从没系统化过的东西，完整地演示了一遍给我看。
这大概就是跟一个好工具协作最爽的地方。它不光替你把活干了，它还顺手，教了你一手。
我也还在学。下回审文档，我打算自己先按这 7 步走一遍，不开工具，看看我这颗人脑，能把这套节奏复现到几成。
