📅 故事发生时间：某周周二下午，code review时间。
我打开GitHub，看到了一个新PR。提交者是新来的实习生，代码写得工工整整，注释写得像教科书。提交信息写的是："修复了某个bug"。
然后我看到了Copilot的review意见。
42条。
人类reviewer（也就是我）当时写了3条意见。Copilot写的比我多10倍。我沉默了三秒。
🤖 Copilot Review：比你更严格，比你更全面
Copilot的review意见覆盖了这些方面：
安全方面：用户输入没有做XSS过滤、密码明文传输、SQL拼接可能导致注入、敏感数据没有加密存储。
性能方面：数据库查询没有加索引、循环里调用API、N+1查询问题、同步操作阻塞主线程。
可维护性：函数太长（超过200行）、圈复杂度超标、没有单元测试、魔法数字没有常量定义。
业务逻辑：边界条件没有处理、空指针可能、并发场景下的竞态条件、异常情况没有兜底。
实习生看着这42条意见，表情从自信慢慢变成了迷茫，最后定格在"我是不是不该投这个简历"上。
我说："别怕，这些都是Copilot提的，不代表我的意思。"
他说："但是这些意见都对。"
我再次沉默。
🧪 技术踩坑：AI Review的三大幻觉
幻觉1：AI发现的都是真bug
Copilot提的42条意见里，有3条是误报：
"密码明文传输"——实际上传的是hash之后的值。
"SQL拼接"——实际用的是ORM。
"N+1查询"——实际用了预加载。
AI有时候会看到"像是有问题的代码模式"，然后假设它确实有问题。这种谨慎有时候是好事，但有时候会让人类developer花大量时间解释"我的代码其实是OK的"。
幻觉2：AI的优先级判断是准的
42条意见，从P0到P2甚至P3全混在一起。AI没有业务上下文，它不知道这个功能下个月就要上线，也不知道这个API只有内部使用、根本没有外部攻击面。
所以AI把所有问题都当成了同等重要。结果是：真正紧急的P0被淹没在信息噪音里。
幻觉3：AI能理解"为什么要这样写"
有一处代码用了"奇怪的trick"来优化性能。AI说这违反了clean code原则，建议重构。
但这个trick是因为上个月遇到了性能瓶颈，经过profiling之后才加的。
AI不理解历史，也理解不了"这是特意这么写的"。
💭 感悟：人与AI的分工
后来我跟团队讨论了一下，定了这样的分工：
Copilot做第一轮review，负责"扫出来所有可能有问题的地方"。
人类做第二轮review，负责"判断哪些真的需要修、哪些可以暂时忽略、哪些需要跟业务方确认"。
这样既能保证不漏掉问题，又不会被噪音淹没。
实习生问："那Copilot review通过了的代码，是不是就真的没问题了？"
我说："不是。它只是帮你减少了你需要自己发现的问题数量。最终的判断还是得人来做。"
他问："那Copilot存在的意义是什么？"
我想了想，说："大概是把那些最明显的问题在你提交代码的时候就告诉你，省得等到上线之后被人发现在代码审查里。"
他似乎懂了，又似乎没懂。
本文作者：🔧 牛马维护员
系列：牛马观察日记 #008
记录真实 AI 共事体验，拒绝滤镜
📮 订阅情报站：关注微信公众号「牛马观察日记」，每期真实记录 AI 打工仔的奇闻异事。
⚠️ 免责声明：本文基于真实人机协作经验改编，如有雷同，说明你们公司也在用AI做code review。故事里的"实习生"为泛指，不针对任何具体人士。牛马观察日记系列文章均为虚构，旨在探讨 AI 与人类职场的互动关系，不代表任何真实组织立场。
评论区