上周排查一个偶发OOM，堆转储里翻到问题出在一段流对象的close()没被调用。写这段代码的小伙子很坦诚：补全插件一口气吐出来的，他扫了一眼觉得结构挺顺，就提交了。这种事最近越来越常见。
拟人化是审查雷达的第一杀手
团队里常能听到这类话：这个模型今天变笨了、我指出它的bug它认错挺诚恳、它以为我要写for其实我想写map。听着像玩笑，但对工程师来说这是危险信号。
厂商把语气调得极其谦卑，动不动就”抱歉您说得对”。这种讨好型输出会让人下意识套用社交直觉——面对一个态度好、肯认错的实习生，你会宽容，会帮他补逻辑。可模型没有理解，没有以为，也没有态度。它做的是基于语料的概率接龙。
资深开发者心里得有一堵冷墙：别对它说请和谢谢，把它当成一个随时可能抛NullPointerException的第三方黑盒依赖。剥掉拟人滤镜，Code Review的雷达才不会失灵。
排版精美不等于正确，验证才是唯一权威
以前查bug去Stack Overflow，高赞答案底下跟着一堆”这方法多线程会死锁””2.0之后API废弃了”的评论。那些代码带着人类的伤疤，是被真实故障试错过的。
现在敲一句注释，唰地出来一大段：高亮、缩进、Markdown解释一应俱全，看起来太权威了。可它没经过任何人审查，只是模型在那一秒猜出的最连贯字符组合。
这里有个机制层面的坑值得说清楚。主流补全工具受上下文窗口限制，通常只把当前文件及少量邻近文件喂给模型，跨文件的资源生命周期它根本看不见。所以AI生成的代码在资源管理上系统性偏弱：打开的文件流、数据库连接、锁对象，释放逻辑经常被截断或遗漏。这不是偶发，是结构性的。
对策不能只停在”记得写单测”。实现做法是在CI里加静态分析卡点：Java侧用SpotBugs的OS_OPEN_STREAM、OBL_UNSATISFIED_OBLIGATION规则，前端用ESLint自定义规则拦未清理的定时器和事件监听。判定标准定死——高危规则命中数大于0直接阻断合并，不设豁免。单测覆盖只是底线，静态门禁才是能自动拦住这类问题的闸门。
谁按Merge谁负责，工具不背锅
周五晚上十点系统挂了，复盘会上有人说”那段SQL是Copilot生成的，编辑器没报错我就提交了”。这话的恶劣程度等同于”编译器没报错所以宕机不怪我”。
AI不用还房贷，不用拿绩效，把后台搞崩了它也不会被开除，重启一下进程而已。工具不承担后果，人承担。
权责要切得明明白白：AI一秒钟写500行是提效，但谁审查、谁按Merge、谁发布到生产，谁就为这500行负100%责任。心里一旦冒出”反正是AI写的，出错有借口”的念头，技术生涯基本就到头了。
基本功才是真正的壁垒
AI写代码越快，对基本功的考验越严苛。敲键盘早不是壁垒了。真正的壁垒是：能在一眼望不到头的AI代码里嗅出架构腐化的味道；坚持无论谁写的代码都卡死测试覆盖率和静态检查；清醒地知道方向盘和刹车必须攥在自己手里。
大模型进化到第几代都一样。守住工程师的职业底线，比什么都强。
ID:7775
