夜雨聆风上个月，我干了一件"多管闲事"的事——用AI给团队做了个自动代码审查工具。
没人安排，也没加班。就是code review的时候，连续三次看到同样的低级Bug，我受不了了。
上线第一天，它自动扫出了23个问题，其中3个是线上隐患。
今天把这个故事和做法分享出来。不是教程，是一个真实的前端老兵用AI解决团队问题的完整过程。
一、导火索：同一种Bug我review了三次
第一次：新人写了 0.1 + 0.2 直接算价格，我指出来，他改了。
第二次：另一个新人写了同样的，我又指出来。
第三次：同一个新人，换了个文件，又写了。
那一刻我想的不是"新人不行"，而是"我的review效率太低了"。人类reviewer会疲劳、会漏看、会重复劳动。但AI不会。
于是我决定：让AI来做第一轮code review，人类只做第二轮把关。
二、方案设计：AI审查要审什么
没有一上来就写代码。我先花了一个下午想清楚：AI到底能审查什么、不能审查什么。
核心思路：AI做"规则扫描+模式识别"，人做"业务判断+设计把关"。 各干各擅长的事。
三、实现过程：比想象的简单
我用一个周末搭了个原型。技术栈很简单：
• 触发方式：Git提交时自动运行（husky + lint-staged） • AI审查：调GPT-4 API，把diff发给它，按预设规则审查 • 结果展示：在PR评论里自动回复审查意见 • 成本控制：只审查变更的代码，不全量扫描
审查Prompt的核心结构，我设计了这么几条规则：
1. 安全类：检查用户输入是否未转义、是否有密钥硬编码 2. 性能类：检查大数组操作是否缺少优化、是否有内存泄漏风险 3. 规范类：检查命名规范、类型定义是否完整 4. 前端专项：检查响应式数据解构是否丢失、useEffect依赖是否遗漏
每条规则都配了具体的前端场景，不是泛泛而谈。
四、上线第一天的战果
周一早上打开系统，AI已经自动审查了周末的6个PR。
那3个安全隐患，有一个是用户搜索框的输入直接拼到了innerHTML里——如果被XSS攻击，整个页面都能被接管。
这个Bug人工review时漏了，AI抓到了。
五、团队的反应
上线第一周，团队反应分两派：
反对派（2个senior）：觉得AI审查意见太啰嗦，有些是误报，增加了处理成本。
支持派（3个junior + 1个senior）：觉得帮他们提前拦住了低级错误，提交PR前更有底气了。
我做了个调整：给AI审查意见加了严重等级标签，高亮的必须处理，低亮的选择性处理。同时把误报的规则调优了一遍，误报率从30%降到了8%。
第二周，反对派也不说话了。
六、成本核算
可能有人关心花了多少钱：
投入产出比：每周省下约4-6小时的人工review时间，月均成本$20。 对10人团队来说，3个月回本。
七、哪些人适合做这件事
不是所有团队都值得搞。我的判断标准：
• 团队5人以上：review量大，AI价值明显 • 有新人比例：新人写的代码问题多，AI拦截效果最好 • 有一定CI基础：至少有Git hooks和PR流程 • 愿意投入1-2天初始搭建：后续几乎零维护
如果你是个人开发者或3人小团队，直接用ESLint+TypeScript就够了，不需要上AI。
八、我的反思
做完这个工具后，我最大的感受是：前端工程师在AI时代的价值，不是写代码更快，而是用工程能力解决真实问题。
这个工具没有一行深度学习代码，没有训模型，没有搞复杂的AI架构。它就是"调API + 设计规则 + 做好产品化"。
但恰恰是这种工程化落地能力，是AI替代不了的，也是市场上最缺的。
🎁 福利时间
我把这个AI代码审查工具的核心Prompt模板、规则配置、以及部署脚本，整理成了一份开源指南。
关注【前端老兵之AI】，回复「审查」免费领取完整版。（注意：这个跟之前的干货包是不同的新资料）
💬 互动一下
你团队的code review是怎么做的？遇到过什么痛点？如果有个AI帮你自动审第一轮，你愿意用吗？评论区聊聊。