git-lrc开源工具：实现AI代码审查，拦截问题代码于git commit之前

用AI辅助写代码现在越来越普及了：写个注释，输入几句自然语言，模型就能快速生成大段代码，效率看起来很高。

但真正将AI生成的代码用于生产环境的开发者都知道——有时候AI对代码的修改，不一定是优化，反而可能是“悄无声息的破坏”。比如，它会偷偷修改某个条件判断，或者顺手删除几行“看起来没用”的老逻辑，而单元测试又恰好没有覆盖到这些改动。等到线上出了问题，翻看日志时才发现：这段代码怎么和我预期的不一样？那一刻，真想拉上AI一起背这个锅。

为了解决这种“AI暗改代码”带来的隐患，最近发现了一个实用的开源小工具：git-lrc。

它的工作原理简单直接——在你执行 git commit 命令之前，自动触发一次AI代码审查。如果审查不通过，它就会阻止你提交代码。

这相当于在本地为你的代码设置了一道“安检门”，任何可疑的改动都会被直接拦截在commit这个环节之前，避免有问题的代码进入版本库。

git-lrc的使用体验也很符合开发者的习惯。它会启动一个Web界面，展示类似GitHub的diff对比视图，清晰列出本次提交修改了哪些文件以及每一行的具体差异。

更重要的是，在那些“可能存在问题”的代码行旁边，AI会直接给出评审意见，例如：

• 这里可能引入空指针风险
• 这一行改动会导致原来的边界条件失效
• 这段逻辑跟上面的函数重复了，可以考虑抽取复用
• 这里打印的日志可能泄露敏感信息

对于安全相关的警告，还会用醒目的标记高亮出来。

当AI建议你修改代码时，git-lrc也并非只是丢下一句“有问题，自己看着办”。你可以在Web界面中，直接根据AI的提示反复修改代码，并再次触发审查。这样经过几轮迭代，直到AI认为这次改动“合格”了，git-lrc才会允许你执行commit操作。

此外，它还会把每次审查的状态记录到Git日志里。这样，当你日后回顾提交历史时，可以一目了然地看出：这次提交是否经过了AI审查、当时是否存在警告、以及警告是否被忽略。如果未来线上真的发生问题，这些记录就是非常直观的“审计线索”。

在安装和配置方面，门槛不高。官方支持Windows、macOS和Linux三大平台，基本一条命令就能完成初始化，无需研究复杂的脚本。

其底层的审查能力依赖于Google的Gemini API。这样做的好处是，你可以绑定一个免费的API Key来体验，无需为额外的私有服务付费。这对于个人开发者或小型创业团队来说，在成本控制上比较友好。将git-lrc集成到自己的项目后，你还可以根据团队的代码规范和业务特点来调整审查的提示词（Prompt），例如，是更侧重于安全审计，还是更关注代码质量和可读性，都可以进行定制。

这个工具尤其适合重度依赖AI编程的场景：

• 日常使用AI来生成脚手架代码、CRUD逻辑或测试用例，一天内代码改动量很大。
• 团队中有成员习惯于将AI生成的大量代码直接提交到仓库。
• 项目对代码安全性、合规性或稳定性有较高要求，但缺乏人力进行细致的日常人工Code Review。

在这些情况下，git-lrc将代码审查的环节大大提前了。问题不再是在PR提交之后、代码合并之前才被发现，而是在你按下 git commit 回车键的那一刻，潜在的风险就被扼杀在本地开发环境中。说白了，它帮你挡掉了一部分因“AI幻觉”或“手误”而可能背上的锅。

你可以继续享受AI编程带来的效率红利，但至少在提交代码前，有个工具能帮你再多看一眼：“这次改动是否触及了不该修改的核心逻辑？”“是否遗漏了原本那几个不起眼但关键的边界判断？”“是不是不小心多打印了用户敏感数据？”

守住了本地这最后一道防线，代码上线的信心也会更足一些。当然，它并非万能解药。AI再强大，也无法完全理解你所有的复杂业务细节和架构设计。真正关键的架构决策、复杂的业务流程、跨系统的交互，最终仍需开发者来把控。但对于大量的日常修改、重复性逻辑和常见的低级错误而言，拥有一个24小时在线、不知疲倦的“机器人审查员”，还是挺让人放心的。

如果你已经在使用AI辅助编码，不妨试试为你的git commit流程加上这道保险。将git-lrc接入当前的项目，运行几天看看效果：观察它能揪出多少你原本可能会忽略的小问题，也看看团队里那些“AI重度用户”的代码质量，是否会因此被潜移默化地引导到更规范的轨道上。对于此类提升代码质量的开源实战工具，云栈社区 的开发者们也经常分享他们的使用心得和最佳实践。

项目GitHub地址：github.com/HexmosTech/git-lrc