git-lrc
HexmosTech/git-lrc加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
凌晨两点，某团队的生产告警响起——支付模块的金额校验逻辑消失了。经过两个小时的紧急回滚和审计，Root Cause 浮出水面：某次 AI 辅助重构中，模型"合理地"删除了它认为冗余的边界检查代码。没有任何告警，没有任何提示。在 PR review 之前，这个删改已经躺在 git 历史里，静静地等待着被部署到生产环境。
这不是孤例。 当 AI 编程工具以每天数千次的速度生成代码时，一个共性问题正在形成：AI agents 写得快，删得也快——删逻辑、删边界条件、删异常处理，删得"悄无声息"。等人类发现的时候，往往已经在生产环境里交了学费。
HexmosTech 团队推出的 git-lrc（LiveReview Command-Line Interface）正是为解决这个痛点而生。它的核心机制简单而精准：在每次 git commit 执行之前，自动触发 AI 代码审查，把问题拦截在进入永久 git 历史之前。
图1：BYOK 连接器管理界面，支持 Gemini、OpenAI、Claude、DeepSeek、OpenRouter 等多种 AI 提供商
git-lrc 由 HexmosTech 开发维护，这是一家专注于开发者工具（DevTools）的技术团队，旗下还有 claude-lrc（Claude Code 插件）等产品。项目采用 Sustainable Use License（SUL），源码开放可自托管，但不允许商业转售和再分发。
截至分析时，项目已获得约 1310 颗 GitHub Stars，178 个 Forks，15 个 Open Issues。技术栈为 Go 语言，主要依赖包括：
urfave/cli/v2：命令行参数解析charm.land/bubbletea/v2：TUI 界面构建modernc.org/sqlite：本地数据持久化knadh/koanf：TOML 配置文件解析项目在 CI/CD 中集成了完整的安全扫描流程：gitleaks（密钥泄露检测）、osv-scanner（依赖漏洞扫描）、govulncheck（Go 官方漏洞检查）、semgrep（静态安全分析），以及 dependabot 自动依赖更新，安全工程实践相当成熟。
git-lrc 提供两种触发模式：
自动模式（推荐）：通过 git lrc hooks install 安装全局 git hook 调度器，此后每台机器的每个 git 仓库在 git commit 时自动弹出审查窗口，无需逐项目配置。
手动模式：git lrc review 或 git lrc review --staged，在 commit 前主动调用审查。
审查流程包含三个决策选项：
审查完成后，git commit message 会追加一条状态行：LiveReview Pre-Commit Check: ran (iter:3, coverage:85%)，团队成员可以在 git log 中清晰看到哪些提交经过了 AI 审查、迭代了多少轮、覆盖率是多少。
git-lrc 设计的精妙之处在于其 **Review Cycle（审查循环）**机制。当 AI 第一次审查发现问题后，用户可以将问题列表复制并反馈给原来的 AI 编程工具进行修复，然后再次运行 git lrc review，直到问题被全部解决。这个过程可以迭代多轮，Coverage 指标会持续攀升：
用户 → AI 编程工具生成代码 → git lrc review → AI 标记问题 → 复制问题反馈给 AI → 修复 → review again
当用户认为代码质量达标时，使用 git lrc review --vouch 进行个人担保提交，跳过 AI 审查但保留覆盖率记录。这套机制将 AI 代码审查从"一次性检查"升级为"持续迭代优化"，非常适合与 AI pair programming 场景结合使用。
从源码目录结构来看，git-lrc 的架构分为以下几个核心模块：
| 模块 | 职责 |
|---|---|
cmd/ | CLI 入口，应用主命令定义（app.go） |
internal/appcore/ | 核心业务逻辑 |
internal/reviewapi/ | 与 LiveReview 云端 API 通信 |
internal/reviewdb/ | SQLite 本地数据库，存储审查记录 |
internal/reviewhtml/ | GitHub 风格 diff HTML 渲染 |
internal/reviewopts/ | 审查选项配置（超时、轮询间隔等） |
internal/selfupdate/ | 自动更新模块 |
internal/staticserve/ | 本地静态文件服务 |
network/ | HTTP 客户端封装（setup/review/selfupdate） |
ui/ | TUI 响应类型定义 |
审查流程的技术链路如下：
git lrc review 提取 staged diff，通过 network/review_client.go 发送至 LiveReview API（hexmos.com/livereview）internal/reviewhtml/ 渲染 GitHub 风格的彩色 diff 页面internal/staticserve/ 在本地启动 HTTP 服务器，浏览器打开交互式审查界面internal/reviewdb/），并追加到 git commit message默认使用 Google Gemini API（有慷慨的免费额度），同时也支持 Bring Your Own Key（BYOK）模式：
用户可通过 lrc ui 命令打开本地 UI 管理 AI 连接器，调整优先级。这是非常实用的设计：不同团队可以根据预算和合规要求选择不同的 AI 提供商。
git-lrc 明确承诺：仅上传 staged diff，不上传完整仓库上下文，diff 在审查完成后不持久化存储。这是一个值得肯定的设计决策。对于企业场景来说，这意味着不会有代码资产泄露到第三方 AI 服务商的风险。
安装方式极度简洁：
# Linux/macOS
curl -L https://hexmos.com/ipm-install | bash && ipm i HexmosTech/git-lrc
# 或
curl -fsSL https://hexmos.com/lrc-install.sh | bash
# Windows
iwr https://hexmos.com/lrc-install.ps1 | iex
配置只需两步：git lrc setup，依次在浏览器中登录 LiveReview 账号和填入 Gemini API Key。一次配置，整机所有仓库生效，无需逐项目设置。
尽管设计理念出色，git-lrc 也存在一些值得关注的局限：
1. 对 AI 编程工具的隐式依赖：git-lrc 本质上是一个"审查反馈循环"的组织者，但它并不能替代 AI 编程工具本身。如果你主要靠手写代码，这个工具的价值会大打折扣——它最擅长的是与 AI pair programming 协同工作。
2. 网络依赖：审查需要调用云端 LiveReview API，这意味着离线环境无法使用。虽然 fake_mode 存在，但实际生产场景对网络有一定要求。
3. 审查质量依赖 AI 提供商：Gemini 免费版的审查深度和准确度，与付费的 Claude/GPT-4o 相比可能存在差距。BYOK 模式虽然灵活，但需要用户自行管理 API 成本。
4. 团队协作机制缺失：目前版本主要面向个人开发者，团队层面的审查策略管理、审查历史统计等功能属于 LiveReview 云端产品（hexmos.com/livereview），不在开源 CLI 范围内。
在 CI/CD 流程中，代码审查通常发生在 PR 阶段——但此时代码已经 commit、push，进入了共享历史。git-lrc 的核心洞察是：commit 是代码进入永久历史的最后一道关卡，也是个体开发者最有主动权的审查时机。
相比 IDE 插件（依赖个人选择），commit hook 是强制性的；相比 PR review（已经太晚），commit review 成本最低、修复最快。git-lrc 找到了一个精准的切入点，将 AI 代码审查从"团队流程"下沉到"个人习惯"，这对于当前 AI pair programming 大规模普及的背景具有重要的现实意义。
总结：git-lrc 是一款定位独特、理念清晰的 AI 代码审查工具，通过 git commit hook 机制，在代码进入永久历史之前建立了一道强制性的人机协同审查关卡。它不追求替代 PR review，而是与 AI 编程工具形成互补。对于重度使用 AI 生成代码的团队和个人开发者，这是一款值得加入日常开发流程的生产力工具。