上篇文章写了9个坑，有几个老哥私信问我：「道理我都懂，但你倒是说说你到底做成了什么？」
好，这篇就交底。
我做的第一个跑通的AI项目是——AI代码审查。
为什么是代码审查？
说实话，当时手里能选的方向不少：
- 智能客服？需求不明确，先放着
- 文档生成？领导觉得不紧急，先放着
- 流程自动化？牵扯部门太多，先放着
- 知识库问答？数据治理还没做，先放着
发现规律了吗？
越是重要的事，越容易「先放着」。
后来我想明白了：不能总想着做「该做的」，得先做「能做的」。
代码审查为什么能选？
- 场景清晰：代码进去，审查意见出来，不用跟业务方扯皮
- 数据干净：GitLab里的代码，不涉及敏感信息
- 效果可量化：问题发现率、审查覆盖率、修复周期，全是能算出来的数
- 推广阻力小：开发组那帮人，对新工具接受度最高——毕竟写代码的都知道代码审查的重要性
核心逻辑就一句话：先做「能做成」的，不做「想做成」的。
技术方案：朴实无华
说实话，这套方案没什么花活儿。
开发者提交MR
→ GitLab Webhook触发
→ Jenkins拉起任务
→ 调用内网大模型API
→ 生成审查意见
→ 评论到MR
→ 企微机器人推送通知
没有消息队列，没有微服务架构，就是最朴素的调用-响应模式。
有人问我：「怎么不用LangChain？」
我说：「LangChain是给不确定的人用的，确定的场景直接调API就行。」
复杂度是效果的敌人。 能用5个步骤解决的事，不要用50个。
踩坑回忆：那几个让我失眠的夜晚
坑1：响应时间太慢
第一版跑起来的时候，审查一次要5分钟。
开发老王跟我说：「等审查意见的时间，我代码都改完了。」
我当时差点就回去优化性能了。
后来忍住了。
原因很简单：跑通才能积累数据，积累数据才能优化。停在「优化」阶段的系统，永远上不了线。
先上线，用起来，发现问题，再迭代。这才是落地的正确姿势。
坑2：连注释代码都审了
一开始没加过滤规则，所有代码都送审。
结果：
- 注释代码被审了：「注意：这里有注释」
- 配置文件被审了：「建议增加日志」
- 生成的代码被审了：「这段代码可以复用」
废话连篇，团队直接无视。
后来加了规则：.py、.java、.js文件，且行数>20行才送审。
教训：AI不是万能的，给它喂垃圾，它就输出垃圾。喂之前先过滤一下。
坑3：审查结果没人看
系统上线了，审查意见也生成了。
然后呢？
没人看。
开发老王：「我提完MR就去改下一个了，谁还等AI审完回来看？」
痛定思痛，接了企微机器人，审查完成后主动推送到开发组群。
效果立竿见影：代码审查覆盖率从30%提升到70%。
教训：不要让用户来找结果，让结果去找用户。
效果数据
这部分我没法替你填，你得自己去统计。
需要关注的核心指标：
| 指标 | 计算方式 | 建议收集周期 |
|---|---|---|
| 审查覆盖率 | AI审查MR数 ÷ 总MR数 | 上线前后对比 |
| 严重问题发现率 | AI发现问题数 ÷ 实际问题总数 | 每周抽检10%验证 |
| 误报率 | 误判数 ÷ 总报告数 | 每周统计 |
| 人工时间节省 | （原来耗时 - 现在耗时）÷ 原来耗时 | 上线前后对比 |
建议：前两周先跑着，把数据收集齐，从第三周开始正式统计。
可复制的经验
写到最后，总结几条能带走的：
-
选小场景切入：能做成一个，再复制第二个。别一上来就搞大的，贪多嚼不烂。
-
先跑通再优化：完美主义是落地的天敌。响应慢不慢？慢。但慢比不上线强。
-
让结果找人：不要指望用户主动来看，主动推过去，覆盖率能翻2-3倍。
-
用数据说话：没有数据就没有说服力，没有说服力就没有持续投入。
下篇预告
工具链整合篇——我是怎么把大模型、GitLab、Jenkins串起来，让团队效率提升的。
文末互动：你们团队在推什么AI项目？跑通了还是还在坑里？评论区聊聊。
