上个月那篇文章，正文我记住的不多，记住的是评论区一条没几个赞的回复。
大意：一个迁移文件漏了索引，审查的人再仔细也看不出来——你得在合并那一刻就知道，六个月后哪个查询会打在这张表上。
回这条的人叫 Nazar Boyko。作者认了，还往前推了一步：这东西在 review 阶段基本抓不到，失败发生得更早，在访问模式没被写下来的那一刻。
我同意。但我还想再往前推半步。
场景你一定见过。一张新表，两个外键，本地跑通，测试绿，合并。
CREATE TABLE event_rollups (
id bigserial primary key,
org_id bigint references orgs(id),
board_id bigint references boards(id),
bucket timestamptz not null,
payload jsonb
);
没有一条语句是错的。它甚至挺好看。
三个月后仪表盘上那条查询开始超时：
SELECT ... FROM event_rollups
WHERE board_id = $1 AND bucket > now() - interval '7 days';
explain 里一个大扫，前面八位数行，过滤列上什么都没有。
这两样东西——建表语句和那条查询——从来没出现在同一块屏幕上。不是审查者粗心，是信息压根不在场。你在 PR 里被问的是"关系建对了没有"，三个月后系统问你的是"访问模式是什么"。两个问题。审查的人在回答前一个，系统在问后一个。
以前那步推理是顺手做的。人写 schema 的时候脑子里会过一遍，这表以后谁查、怎么查——不一定写下来，但过了一遍。board_id 上要不要索引，是那遍过完的副产品。
AI 不过这一遍。不是它懒，是它不知道，而且它不觉得自己不知道。
补一刀：批准的人也不过这一遍。看见两个外键，脑子里蹦出来的是"关系对了"，不是"以后谁查"。
作者把用 AI 分成两种，认知辅助和认知卸载——替你打字，还是替你思考。这两样在 PR 里长得一模一样，区别要等系统出事、要有人解释它为什么这么干的时候才露出来。
这话对，但还不够狠。评论区有个人说得更准：多数团队把"PR 看起来没问题"和"有人真的理解它"当成一回事。审查这件事会慢慢从"逻辑成不成立"滑到"看起来合不合理"。
以前这是慢性的，一个季度渗一点。现在合并频率翻倍，同一套习惯就变成了洪水。
文章给了三个自检问题，第一条最狠：能不能不打开聊天记录，把这段代码讲给队友听。
这是我这几年见过最便宜的灾难探测器。不收钱，不占排期。
但作者自己反了一半，反得挺诚实——合并那一秒上下文最热，你问"今天能解释吗"，很多没消化完的 diff 都能过。下面有人提议改成三个月后再问，作者同意了。
三个月版本是好版本。可惜三个月后没人会回来问。
那时候项目上线了，季度过了，写代码的人可能调组了。真正想问的人，是半夜被 pager 叫起来的那个冤种。他不问这段代码当初怎么来的，他问这张表上为什么没有索引——然后去 slack 里 @ 一个已经不看这个项目的人。
评论区还有一条，我记到现在。大意是自己赶工周发过一些东西，三个月后讲不明白，接手的同事也讲不明白，那块就变成了没人敢碰的区域。
屎山的诞生现场。区别是这回它生得快——以前这种区域三年攒一块，现在一个大促周期就能攒一块。合并的速度上去了，理解的速度没上去。
作者还提到一件事：他们团队到现在也没把"向队友解释"变成强制步骤，怕它变成勾选框，怕赶工周被绕过去。
这担心是对的。而且我可以替他确认：它一定会变成勾选框，一定会被绕过，而且恰恰是在它最该起作用的那一周被绕过。
所有流程都这个命。
所以别去设计那种"要解释一下"的松垮流程，那是给勾选框预备的。要问就问得具体到没法敷衍：这张表以后谁会怎么查它。这个同步调用改成发队列，晚三秒会发生什么。具体的问句绕不过去——你没法对着"这张表以后谁会怎么查它"回一句"嗯，看过了"。
作者后来在回复里给了个方向：把"为什么选这个方案而不是那个"写在 PR 描述里，别写在代码注释里。这条我认。写在描述里是逼作者自己想一遍；写在注释里，三个月后没人会打开那个文件。
他团队还有个土办法我觉得也行——轮换审查人，别让同一个人总审同一个作者的 PR，不然审的是风格，不是代码。
还有条更朴素的，说白了就是把 AI 的话翻译回自己的话。翻不过去，就是缺口。
说句实话，这些办法没一个新鲜的，全是老工程师嘴里念叨了十年的东西。新鲜的是现在漏得更快。
本期教训一行：AI 生成的迁移能不能合，不看测试绿不绿，看有没有人能拿大白话把访问模式念出来。念不出来的先别合——省下的那半小时，三个月后从别人的觉里扣。