背景

2 个月前我从一家公司离职，这公司成立时间很长但只有一个产品，领导管得事无巨细很是难受，报备/审批流程非常多加上技术栈较为老旧，经过综合考虑决定辞职。

现象

这几年 AI 非常火爆，该公司也在追赶潮流大力推广 Cursor ，用 AI 做 Code Review ，然而不少人开发完成后提交代码卡在 AI 审查而且改了很久才通过，需求交付率很低。

AI 代码审查背后的架构问题

这个项目是用来做数据采集要对接多个接口，本应为 ETL 架构却用 MVC 强行适配导致 Model 层出现大量上帝方法，一个方法涉及许多维度的许多数据的处理逻辑，事实上应该按需采集结果做成“先采集后筛选”——数据经过一系列处理后在写入前被判定丢弃。由于上帝方法太多，AI 查出的问题改好了又查出其他问题，管理层想“渐进式重构”，然而这种几乎没有优化的空间，推倒重做才是更经济的选择，给这个项目继续打补丁要加班和值班，但同样是加班，花 3-4 个月重做等于自动完成大量积压的需求，降低运维成本的同时省去值班的煎熬，孰优孰劣非常清楚。

总结

对于 AI 我是持谨慎态度，如果推广 AI 是为了掩饰系统架构和项目管理上的错误将对组织造成更大的伤害。AI 会让原本做得好的事变得更好，也会让原本做得差的事变得更差，它治得好代码的病却治不了架构的病。

（文章仅代表个人观点）