“让 AI 写，人来 review”是一句听起来无懈可击的话。问题是它在实践中不成立。
AI 一次能产出几百行代码，如果你逐行读完再决定要不要用，那你的速度和自己写差不多——甚至更慢，因为读别人的代码比写自己的慢。
但完全不看也不行。问题不是”要不要看”，是”看哪里”。
下面是我们实际的做法，以及它是被哪几次错误逼出来的。
人的注意力是有限的，要花在刀刃上
先承认一个事实：人读代码的注意力衰减很快。读到第一百行的时候，你已经在扫而不是在读；到第三百行，读和不读差别不大。
所以”全部读一遍”实际上是”前面读了，后面装作读了”，而错误往往藏在后面——因为前面通常是主逻辑，后面是边界处理。
与其假装全读，不如明确挑几类地方认真看，其余的靠别的手段兜住。
必须认真看的四类
一、任何”批量”的操作。
循环、批量替换、正则表达式。AI 在这里最容易写出”大部分正确”的代码——对九成的输入是对的，剩下一成悄悄出错。
我们踩过一次：一段处理字符串的代码，本意是去掉结尾多余的引号，写成了”把结尾的字母 u 连同引号一起替换掉”。结果所有以字母 u 结尾的名称都被截断了一个字符。
语法完全正确，运行没有任何报错，生成的文件看起来也正常——除非你恰好检查了那几条以 u 结尾的数据。
怎么看：不是读代码，是拿三五个真实数据跑一遍看输出。读代码很难发现这种问题，跑一遍立刻就看见了。
二、任何不会报错的地方。
这一类最危险，因为它没有反馈。SEO 标签写错了不报错、缓存规则漏了不报错、页面少了一个不报错、结构化数据里的价格是旧的也不报错。
AI 是靠反馈修正的。没有反馈的地方，它只能靠训练里学到的惯例，而惯例在具体项目里经常不成立。
这类地方必须主动去验证，因为它们不会来找你。
三、任何”共用”的东西。
改一个站自己的文件，坏了影响一个站。改一份被几十个站共用的配置，坏了影响全部。
这两件事的谨慎程度应该差一个数量级。我们的规矩是：共用的东西，改之前先备份，改完先只对一个目标生效，验证之后再放开。
四、任何不可逆的操作。
删除、迁移、改域名、动数据库。AI 执行这些和改个颜色一样顺手，但后果完全不同。
这类操作我们的做法是停下来，先把”如果这一步做错了怎么退回去”想清楚再执行。多花五分钟，换的是不用花一整天。
其余的靠机制，不靠眼睛
剩下那些不属于上面四类的代码，我们不逐行读。用三道机制兜住：
落地之前先验证语法。所有文件先同步到临时目录，逐个做语法检查，全部通过才覆盖到生产环境。有一个不通过就整批不动。
这一道是被一次真实事故逼出来的：一个文件括号数量不对，直接传上去，全站白屏两分钟。那次的完整经过我们写过。
装完之后自动验证。部署完自动请求一批关键页面，逐个检查返回码。任何一个不是 200，报错并给出回滚命令。
后来又加了一条：生成静态页面之后，检查关键页面的文件是不是都在。因为缺页面不报错，只会安静地变慢。
一切都能撤回。所有改动在版本控制里，回滚是一条命令，而且能精确回到某一次改动之前。
这三道的共同点是：它们不依赖人记得。而任何依赖人记得的环节，迟早会被忘掉——尤其是在赶时间的时候，而赶时间的时候恰恰最容易出错。
一个反直觉的经验
用 AI 之后，值得投入的不是”更仔细地检查代码”，而是”让错误更快暴露”。
因为出错的概率不会降到零，人也不会。真正决定损失大小的是：错误从产生到被发现，隔了多久。
两分钟发现，代价是两分钟。三个月后发现，代价是三个月里所有受影响的访客。
所以同样的时间，花在”部署后自动验证”上，比花在”部署前多读两遍”上回报高得多。前者是确定性的，后者取决于你今天的状态。
那客户买的是什么
如果 AI 能写代码，人只是配了几道检查，那这个服务的价值在哪？
就在那几道检查，以及知道该把它们放在哪。
会用 AI 现在不构成门槛，你下午就能开始用。难的是知道哪些地方它会安静地出错，以及在那些地方提前放一道拦截。这些知识不是读文档得来的，是每一次踩坑之后加一道防护，慢慢攒出来的。
我们交付的项目用的是同一套流程，包括上面写的三道机制。这些配置本身没有秘密——这篇写的就是全部要点——区别在于有没有人真的把它们建起来，并且在出事之后真的去加下一道。