背景
2 个月前我从一家公司离职，这公司成立时间很长但只有一个产品，领导管得事无巨细很是难受，报备/审批流程非常多加上技术栈较为老旧，经过综合考虑决定辞职。
现象
这几年 AI 非常火爆，该公司也在追赶潮流大力推广 Cursor ，用 AI 做 Code Review ，然而不少人开发完成后提交代码卡在 AI 审查而且改了很久才通过，需求交付率很低。
AI 代码审查背后的架构问题
这个项目是用来做数据采集要对接多个接口，本应为 ETL 架构却用 MVC 强行适配导致 Model 层出现大量上帝方法，一个方法涉及许多维度的许多数据的处理逻辑，事实上应该按需采集结果做成“先采集后筛选”——数据经过一系列处理后在写入前被判定丢弃。由于上帝方法太多，AI 查出的问题改好了又查出其他问题，管理层想“渐进式重构”，然而这种几乎没有优化的空间，推倒重做才是更经济的选择，给这个项目继续打补丁要加班和值班，但同样是加班，花 3-4 个月重做等于自动完成大量积压的需求，降低运维成本的同时省去值班的煎熬，孰优孰劣非常清楚。
总结
对于 AI 我是持谨慎态度，如果推广 AI 是为了掩饰系统架构和项目管理上的错误将对组织造成更大的伤害。AI 会让原本做得好的事变得更好，也会让原本做得差的事变得更差，它治得好代码的病却治不了架构的病。
（文章仅代表个人观点）
 |
1
xuanwu 1 天前
治得好代码的病 吗？
|
 |
2
yifangtongxing28 17 小时 46 分钟前
其实现在这些功能谁做都可以，年初招人年尾裁人就行
打工者现在要么发挥个人嫡系优势，要么有税后收入，不然都是朝不保夕 |
 |
3
kaellzt777 17 小时 24 分钟前
睡后收入为 0
|
 |
4
meteora0tkvo 17 小时 3 分钟前
ai 写出来的代码压根不是给人看的，如果考虑到项目后续需要人工去维护，则要加强 Code Review 工作，不然纯靠 ai 写容易堆出一堆屎山出来
|
Select Language