夜雨聆风昨晚我又看了一遍一个调研。
不是那种“AI 会不会替代程序员”的老问题，那个话题已经被嚼得没味了。真正刺眼的是另一件事：很多团队现在生成代码的速度，已经超过了他们审查代码的速度。
这句话听起来像废话。
但你把它放进真实项目里，就有点吓人了。以前一个需求从分支到 PR ，中间慢得要命，慢本身就是一道过滤器。现在不一样。 AI 编程工具一接上，分支可以一晚上长出十几个，测试还没跑完，下一坨改动已经躺在队列里。
嗯，坨。
我知道这个词不好听，但有些 AI 生成的代码，第一眼确实就是这个质感：能跑，像样，甚至注释也写得挺体面。可你往下翻两屏，会发现它把异常吞了，把权限判断挪了，把一个本来只该改三行的地方顺手“整理”了三十行。
这不是效率问题。
这是验收问题。
不对，准确说，是验收被速度甩在了后面。
第一道门：先让 AI 说清楚它改了什么
我现在越来越不喜欢那种“你直接帮我改好”的提示词。
太顺了。顺到危险。
更好的做法是让 AI 在动手前写一份很短的变更说明：目标是什么、会碰哪些文件、不碰哪些边界、验收标准是什么。别写长，长了没人看。三五行就够。
这一步看着啰嗦，其实是在给后面的审查省命。
GitHub 的 Copilot coding agent 现在也是围绕 issue 、 pull request 和检查结果来跑：它接任务、推分支、开 PR ，然后把结果交回给人和 CI 。这个设计有个很朴素的意思： AI 可以写代码，但最终应该落到可审查的变更单里。
我自己的做法更土一点。
每次让 Codex 处理稍微复杂的活，我会先让它列“预计修改清单”。如果清单里出现我没提过的模块，先停。不是说它一定错，而是这种时候最容易发生“顺手优化”。
顺手优化，四个字，很多线上事故的祖坟。
可以直接套这个小模板：
看起来很笨。
笨东西最抗幻觉。
第二道门：把项目规则写进 AGENTS.md
很多人用 AI 编程工具，最大的问题不是不会提问。
是不愿意写规则。
OpenAI Codex 支持在仓库里放 AGENTS.md ，用来告诉代理怎么理解项目、怎么运行测试、有哪些约定。 AGENTS.md 这个格式本身也已经被当成一种开放的项目说明文件在推广，目标很明确：让代码代理别每次进仓库都像新来的外包。
这事儿很小，但我建议认真做。
因为 AI 最擅长补全“它以为合理”的东西。你不告诉它这个项目的路由规则、命名习惯、测试命令、迁移边界，它就会自己猜。猜一次可能没事，猜十次就开始发烧。
一个可用的 AGENTS.md 不需要宏大。
写这几块就够：
别写成企业制度。
写成给一个新同事的便签。越像人话，越有用。
第三道门： CI 不只是跑测试，还要拦住“看起来能跑”
我见过一种很糟的 AI 工作流。
人给一句需求， AI 改完，人扫一眼 diff ，觉得没问题，合并。测试？有空再补。安全？下个版本再看。类型报错？先 any 一下。
这就不是提效了。
这是把技术债装上涡轮增压。
GitLab 今年关于 AI accountability 的研究里有一个判断很扎心：组织正在更快地生成 AI 代码，但控制和治理跟不上。你不一定要接受它的所有结论，但这个方向我很认。因为我在日常项目里看到的也是这样：写代码的瓶颈被打穿后，瓶颈会挤到 review 、测试、权限、发布那里。
所以 CI 不能只当“有没有红灯”的仪表盘。
它应该变成第二个审稿人，而且是脾气很差的那种。
至少放这几类检查：
这里有个小分支。
如果你是个人项目，别一上来搞十几个检查，搞到自己也跑不动。先把类型检查、测试、 lint 三件事跑起来。能做到这一步，已经超过很多“AI 原生团队”了。别笑，真的。
如果你是团队项目，那就别只看测试通过。要看 AI 有没有改到不该改的地方，有没有绕开旧约束，有没有把失败藏进日志里。
最恶心的 bug ，不是红灯。
是绿灯背后的假安全。
第四道门：让安全检查专门盯 AI 最爱犯的错
AI 生成代码有一类问题特别烦。
它不是完全错。它是“看起来符合常识，但把边界条件吃掉了”。
比如用户输入拼进命令；比如为了让示例跑通，把鉴权判断写得很薄；比如错误输出里带了内部细节；比如把模型返回内容直接塞进页面或后续工具调用。
这类代码最荒唐的地方在于，它通常不是一眼假的。它很礼貌，很完整，很会装。糊弄人也糊弄得体面。
OWASP 的 LLM 应用风险清单里，提示注入、不安全输出处理、敏感信息泄露这类问题一直排在很靠前的位置。放到 AI 编程里也一样：你让工具写得越快，越要盯住输入、输出、权限和密钥。
我建议把安全检查拆成四个很土的问题：
每个 PR 都问一遍。
烦吗？烦。
但比半夜起来找泄露点强。那种感觉我不想再体验第二次。屏幕很亮，人很潮湿，脑子里只剩一句话：这玩意儿怎么过的审？
说回正题。
安全门不需要一开始就自动化到极致。你可以先把这四个问题放进 PR 模板。等团队真的开始稳定执行，再把其中一部分交给脚本、 SAST 、 secret scanning 或自定义检查。
顺序别反。
先有判断，再有自动化。
第五道门：让人类只审最值钱的部分
很多团队一听“AI 生成代码要加强 review”，第一反应是所有东西都看得更仔细。
这个方向会把人拖死。
AI 的问题不是让人类回到手工作坊，而是要重新分配注意力。机器能检查格式、类型、简单测试、依赖和常见漏洞。人应该把精力放在更难自动化的地方：需求有没有理解错，抽象有没有过度，边界有没有被偷换，长期维护会不会痛。
我现在看 AI PR ，会先扫三个地方：
其它地方不重要吗？
也重要。但注意力不是无限的。你不能指望一个人下班前审完 1200 行 AI diff ，还保持灵魂干净。别折磨人。
更现实的方式是给 AI PR 打标签：
这个标签可以让 AI 先自评，人再确认。
注意，是“人再确认”。别把评分权全交出去。那就又绕回原来的坑里了。
我刚才这句话说得有点绝对。不是 AI 不能评分，是它不能给自己签放行单。这个差别很细，但线上事故最喜欢钻这种细缝。
真正该提速的不是写代码，而是验收代码
我不反对用 AI 写代码。
恰恰相反，我现在很多活都离不开它。让它改测试、查调用链、补脚手架、整理重复逻辑，确实省时间。省很多。
但我越来越觉得， AI 编程的下一阶段不该继续卷“生成得多快”。
那条路有点虚胖。
真正值得卷的是：一个团队能不能把 AI 产出的代码稳定地变成可解释、可审查、可回滚、可追责的变更。说白了，能不能让速度长在刹车片上，而不是长在油门上。
今天这五道门，你不一定全都要装。
个人项目，先装第一道、第二道、第三道。团队项目，把第四道、第五道也补上。别追求漂亮，先追求不会半夜炸。
我知道这听起来不性感。
但工程里很多真正救命的东西，本来就不性感。
凌晨两点，你看着一个绿灯全过、线上却坏掉的 PR ，会突然明白这句话。
