JetBrains给AI喂了3000次代码审查后

AI能写代码、能跑测试、能让编译器闭嘴，但PR（Pull Request，代码合并请求）照样被打回。这不是能力问题，是眼光问题。

JetBrains TeamCity团队最近公布了一组实验数据：他们让AI迁移数据库API，代码功能全对，测试全过，结果被资深工程师Pavel Sher一票否决。AI把新接口套进了旧架构，像给电动车装了个化油器——能跑，但别扭。

AI的"从众心理"：100次重复=正确？

AI写代码时有个习惯：翻遍整个代码库找例子，看到什么多就抄什么。100个旧写法摆在那，它默认这就是标准。

TeamCity的代码库有15年历史，新旧设计混杂。AI分不清哪些是团队想保留的，哪些是还没来得及删的"历史遗迹"。频率被误读为正确性，这是所有大项目都会踩的坑。

Pavel Sher在博客中打了个比方：AI像个新来的实习生，看到办公室里10个人有8个穿格子衫，就以为这是 dress code。没人告诉他，那8个人只是懒得换衣服。

第一次实验里，AI完成了从旧数据库API到新API的迁移。表面看一切正常，但Pavel发现错误处理、数据流、代码结构全是老一套。新酒装了旧瓶，技术债务一分没减。

这个问题不解决，AI越勤快， legacy code（遗留代码）越牢固。团队想淘汰的设计，被AI当成范本反复强化。

解法一：给AI看"优秀作业"

JetBrains的第一次改进很直接——不再让AI只读现有代码，而是投喂已经通过审查的迁移案例。

指令变成："Class A是这么迁的，Class B照做。"

效果立竿见影。AI开始模仿正确的模式，而不是最常见的模式。但团队很快发现天花板：案例多了，AI会混淆；案例少了，覆盖不全。人工整理这些"优秀作业"本身就是重体力活。

Pavel Sher提到，他们尝试过让AI自己总结规律，结果总结出来的"原则"经常自相矛盾。A案例说要用异常，B案例说返回错误码，AI干脆两个都写，防御性编程变成了冗余代码生成器。

解法二：让AI先问"为什么"

第二次迭代，团队换了个思路。不是给更多答案，而是让AI在动手前先理解上下文。

他们设计了一个"审查预演"环节：AI生成代码后，必须先用自然语言解释自己的设计决策——为什么选这个API、为什么保留这段逻辑、有没有考虑过替代方案。

这个步骤逼AI从"复制模式"切换到"论证模式"。Pavel发现，当AI被迫解释时，它会自己暴露矛盾。比如一边说要减少嵌套，一边生成了三层回调。

更关键的是，这些解释成了人类审查的抓手。工程师不用从头读几百行代码，先看AI的"自我检讨"，再针对性检查可疑部分。

实验数据显示，引入解释环节后，AI生成代码的首次接受率从34%提升到61%。不是代码变完美了，是沟通成本降了——人类和AI终于能聊在同一个频道。

解法三：让AI"看见"代码的社交关系

最新实验中，JetBrains给AI加了层关系图谱。不是语法树，是"谁跟谁经常一起改"的协作网络。

代码库也是社交场。某些模块被同一个人维护多年，风格高度一致；某些文件是多人接力，边界模糊容易出冲突。AI以前看不见这些，现在能根据作者信息调整策略——单人领地可以更激进，公共区域必须保守。

Pavel Sher举了个具体例子：TeamCity有个核心配置类，过去5年被17个不同的人修改过。AI以前给这个类加功能时，会模仿最近一次提交的风格——但那可能是某个实习生的一次性改动。现在AI会看整体历史，识别出真正的"主人"是谁，向那个人的风格靠拢。

这个改动让跨模块重构的冲突率下降了28%。数字不算惊艳，但在生产环境里，28%的摩擦减少意味着每周能省出几个小时的扯皮时间。

AI编程的下一步：从工具到队友

JetBrains这三轮实验，本质上在解决同一个问题：怎么让AI理解代码的隐性知识。

显性规则写进文档，隐性规则藏在审查意见里、藏在提交历史里、藏在"这个命名不太对"的模糊直觉里。人类工程师花几年才能培养这种直觉，AI需要被明确投喂。

Pavel Sher在文章结尾说了一句话：「我们教AI看大局，不是为了取代审查，而是让审查能聚焦在真正需要人类判断的地方。」

目前这套方法还在TeamCity内部迭代，尚未集成到公开的JetBrains AI工具里。但实验数据已经说明：当AI从"写代码"进化到"解释代码"再到"理解代码的社会关系"，它的产出才开始真正融入团队。

下一个问题是：如果AI能模仿Pavel Sher的审查风格，那Pavel本人会失业吗？他自己在评论区回了条：「我试过让AI审我的代码，它给我提了8条建议，其中3条是我三年前写的旧代码。它还在学习，我也在。」