LiveReview：按代码风险安排评审，把人工注意力留给关键变更

产品与近期变化

LiveReview 由印度班加罗尔的 Hexmos Technology LLP 开发，定位于团队代码评审与质量管理。官方在 2026 年 11 月 7 日发布风险感知评审方案，强调先判断哪些改动值得人工投入，再安排审查顺序。产品已有更早开发记录，此次值得关注的是风险分层和自动审批路径。LiveReview 官网、11月7日官方发布说明、早期更新记录

它适合代码提交量增长、资深审查者成为瓶颈的团队，尤其是同时维护支付、权限或数据库等关键模块的项目。个人开发者也能先用免费额度试验，但工具是否有价值，应该看它能否识别团队真实关心的问题，以及反馈能否进入既有修复流程。

如何分配评审注意力

风险评分综合大模型对改动含义的分析、代码调用关系，以及团队记录的事故、回滚等生产信号。它可以把影响范围较大的代码放到前面，并按策略审批低风险改动，将不确定或高风险项交给人。默认模型、自带模型密钥、仓库规则、组织级提示和评审对话，提供了不同程度的配置空间。11月7日官方发布说明、功能说明

团队可以连接 GitHub、GitLab、Bitbucket、Gitea 或 Azure DevOps，在 PR/MR 中接收反馈；也可以用 git-lrc 在本地提交前审查暂存改动。后者是进入完整平台的一条路径，不能把免费命令行工具与企业部署、仪表盘和所有团队功能混为一谈。功能说明、git-lrc 工作流

从试点仓库落地

1. 先挑一个权限清楚、改动范围适中的仓库。从官网 Start Free 进入；使用 GitHub App 时只选择试点仓库，其他平台按对应集成文档配置权限。

2. 选择内置 LiveReview AI 或团队认可的模型，写入仓库专属规则。组织级提示只放所有项目都适用的要求，避免一个团队的特殊规则影响其他仓库。官方价格、功能说明

3. 用一个真实的小 PR 检查评审结果，在评论中追问依据。若从本地开始，按官方指南安装 git-lrc、完成 setup，暂存修改后运行 git lrc review，再修复、复审。安装会设置机器级 hooks，应先了解对其他仓库的影响。git-lrc 工作流

4. 初期保持人工把关，记录误报、漏报和审查耗时。需要自动审批时，先用过去 PR 回放策略，检查阈值，再逐步启用。保留测试和分支保护，不把模型批准直接等同于可以安全上线。11月7日官方发布说明

价格、数据与适用边界

Free 每月提供 30,000 行评审额度，最多三名成员，项目数不限；Premium 每月 32 美元起，含 100,000 行且成员不限，更大用量按固定档位升级。这里的 LOC 指被审查差异中的代码行，不是整个仓库大小。自托管、SSO 和定制控制归入 Enterprise，需询价。官方价格、常见问题

自托管不自动保证代码不出网：连接外部模型时，评审上下文仍会发送到相应服务；使用自有基础设施中的 Ollama 才能把推理留在内部。官网未列完整地区可用名单，访问、支付和模型地区支持需分别确认。官方也明确尚未取得 SOC 2 Type II 认证。安全说明、常见问题

官网引用的“事故减少50倍、回滚减少3倍”来自 Meta 的 RADAR 研究，不是 LiveReview 的客户实测成绩。官方提出的低风险自动审批比例也不应视为每个仓库的保证；更可靠的判断依据，是试点中的错误批准率、回滚和人工复核结果。11月7日官方发布说明

同类工具怎么选

三者的账单单位不同，不能仅用起步价判断谁更省钱。把同一批真实变更用于试点，同时比较有效问题、误报、修复时间和月用量，才能看清风险管理方式与团队流程是否匹配。