AI写代码+AI审代码,人在哪?去年团队从8个人扩到20人的时候，我算过一笔账：按每人每周2-3个PR算，我每周要看60个PR。一个PR认真看10分钟，就是10个小时。这意味着我如果全部自己审，周一到周五每天至少得有2小时钉死在GitLab上——还不算开会、写方案、处理线上问题的时间。更要命的是，我们是小公司，为了节省成本，很多人都是重头培养，没有资深技术大拿把关。新人来了之后，上线多了，问题频发，代码质量肉眼可见地下滑。一开始我推行代码规范，装阿里巴巴规约插件、上Sonar扫描。结果适得其反。这些工具规则太硬、太机械，扫出来的问题一堆是"形式主义"，真正该担心的业务逻辑漏洞反而报不出来。开发们被这些警告搞得很烦，为了消警告浪费时间，进度被拖慢，积极性也被打击。更麻烦的是，现在大家都用AI写代码。AI写得快，但质量参差不齐，有些代码一眼看去能跑，细看全是坑。审查这件事，比任何时候都重要。既然AI能写，那能不能让AI先审一遍，帮我们筛出重点问题，人只做最终确认？抱着这个想法，我们搭了一套流程。每天早上6点，系统自动调用GitLab接口，抓取所有仓库、所有分支的代码提交情况，把代码变更喂给AI，让它先做一轮分析。说实话，一开始只是想找个"自动化的代码审查员"，没想到运行一段时间后，AI给了我们很多代码质量之外的意外发现。我们原本有周会汇报进度，但信息的延迟最大可能有一周。实际过程中，等到周会才发现任务没完成，原因是"临时去干别的活了"或者"某个问题花了太久"，这种情况屡见不鲜。引入AI审查后，每个人提交了什么代码、做了哪些功能、在哪些功能上反复提交、花了多少时间，都清清楚楚。有没有偏离计划，一两天就能发现，不用等周五的周会。甚至某人因为代码冲突过多，花了半天时间解决冲突这种事，也能从提交记录里分析出来。传统开发里，很难对一个开发人员的工作价值做有效评估。代码行数？Bug数？都有明显缺陷。AI的引入在一定程度上解决了这个问题。比如：某人提交了500行代码，但全是规则化的接口生成和增删改查，测试零Bug；某人只提交了100行，测试过程多次修改，但解决的是一个困扰系统很久的技术债务。AI不但能看到代码量和Bug量，还能在一定程度上理解代码的价值，提供了过去完全没有的参照维度。管理者听汇报是常态，但也要接受汇报里适度的"美化"，这无可厚非。问题在于，当美化积累到一定程度，风险就不可控了。某个流程里硬编码了一个参数，要么是AI写的开发自己没看，要么是为了赶进度临时应付，后面大概率要返工。进度注水。有些开发会把明确没写完的功能算到进度里，说"已经提交了"，实际只搭了个空壳。以前测试阶段才发现，现在看提交内容就能预判。说实话，这些小聪明我也理解，毕竟都是从一线开发过来的。但如果积攒过多，明显一两天补不齐的坑，就必须提前介入。Step 1：自动采集每天早6点，脚本调用GitLab API，抓取前24小时所有仓库的提交记录、PR状态、分支合并情况。Step 2：AI分析将代码变更+提交信息喂给AI，让它输出三类结果：代码质量问题（代码漏洞、不规范写法、性能隐患、需求是否满足）异常行为分析（反复提交、冲突过多、写死值、特殊注释等）Step 3：AI的输出报告发到企业飞书。我花10-15分钟扫一遍，重点关注标红的异常项，看是否需要介入解决。这套方法跑了几个月，确实帮我们省了不少事，但也有明确的边界：AI不是万能的。它能发现规律性的问题和明显的Bug，但复杂的业务逻辑判断、架构层面的长期决策，它做不了。数据是辅助，不是判决。AI分析出来的"工作量价值"只能作为参考，不能完全替代人的判断。有的人，可能在某个难题上卡了三天只改了20行代码，这种价值AI很难量化。团队信任是基础。我们的定位很明确：不是为了监控，是为了让管理者更早发现问题、帮开发更早拿到反馈。AI是机器，是冰冷的，他永远无法理解数据背后的人，也无法为任何一个行为负责。我们的角色也更多的从做事情，转变为了做决策。
夜雨聆风