LiveReview

目标如下：一个被其他 40 个文件使用的函数中的 3 行修复，并且还会写入数据库，应该得到高分。一个文件中的 300 行 UI 更改，完全被测试覆盖且没有被其他任何地方使用，应该得到低分，即使它是更大的差异。为了实现这一点，LiveReview 为每个代码块给出两个分数，然后将它们合并为一个分数，并据此对差异中的每个代码块进行排序。风险分数：一个更改可以通过你的代码传播多远。有多少其他地方直接或隔几步调用此代码。它是否写入数据库或其他长期存储。这些调用者是否位于代码库的其他部分，而不仅仅是附近的文件。审查优先级：一个更改值得多少审查，基于其复杂性、微妙性以及遗漏重要细节的可能性。逻辑可以走多少条不同的路径，以及跟踪起来有多难。循环嵌套在其他循环中的深度。此代码本身调用了多少其他函数或符号。代码是否有测试。LiveReview 可能会随着时间的推移添加新的信号。它们背后的两个问题保持不变：传播多远，以及需要多少审查。

编辑器内审查帮助使用它们的人。LiveReview 为整个团队工作，在 git 层面和每个拉取请求上。– LiveReview – Cursor / Antigravity 编辑器内审查 – ；审查来源 – 提交前审查（git-lrc）、每个拉取请求、Web 上的 PR 链接、Slack、Teams 和 Discord，以及通过 MCP 的 AI 代理 – 在编辑器内；Cursor 的 Bugbot 也会评论拉取请求 – ；谁看到审查 – 整个组织，在一个仪表板上 – 只有该编辑器中的开发者 – ；对所有人强制执行 – 是。git-lrc 审查每个提交，无论每个人使用什么编辑器 – 只有当每个开发者记得运行时 – ；批准安全的拉取请求 – 是。根据你的策略批准风险最低的 30–50% 的拉取请求；有风险或不确定的交给人类 – 否 – ；如何决定风险 – 混合语义 LLM 分析、基于你的生产风险信号训练的自定义 ML 模型，以及基于静态图的代码库分析 – 仅 LLM 分析 – ；从你的生产事件和回滚中学习 – 是。你记录的每个回滚或事件都会重新训练你组织自己的模型 – 否 – ；每个更改的影响范围 – 是。整个代码库的图会评分每个更改传播多远（影响范围） – 未记录 – ；事件后的可追溯性 – 每个审查、批准和覆盖都被记录 – 没有共享记录 – ；在编写代码时继续使用编辑器内审查；LiveReview 是代码推送和合并前的团队级检查。

纯 LLM 审查进行语义分析， backed by broad common sense。这是 RADAR/LiveReview 风险分数的一部分。– LiveReview – 纯 LLM 审查 – ；审查来源 – 提交前审查（git-lrc）、每个拉取请求、Web 上的 PR 链接、Slack、Teams 和 Discord，以及通过 MCP 的 AI 代理 – 开发者运行它的任何地方：聊天、编辑器或 CLI – ；更改的语义分析 – 是 – 是 – ；基于你的生产事件和回滚训练的自定义 ML 模型 – 是。你记录的每个回滚或事件都会重新训练你组织自己的模型 – 否 – ；为你的仓库和组织定制的确定性检查 – 是 – 否 – ；整个代码库结构和影响范围 – 是。整个代码库的图会评分每个更改传播多远（影响范围） – 否，它们只看到差异和附近的文件 – ；每个拉取请求的风险分数 – 是，并且它决定哪些更改跳过人工审查 – 否 – ；用数字显示其影响 – 是。无需人工批准的拉取请求、每个阶段被阻止的内容，以及错误批准率（批准后后来被回滚或与事件相关的更改） – 否 – ；强制执行和可追溯性 – 团队范围；事件后你可以追溯审查了什么以及为什么发布 – 取决于每个人运行它；没有共享记录 – ；本地 LLM 审查仍然有用，它们补充像 LiveReview 这样的半自动批准系统。

大多数代码审查工具随着团队增长或令牌消耗波动而收费更高。LiveReview 明确了主要限制：每月审查的代码行数（LOC）。你可以免费开始，每月 30k LOC。当你需要更多时，付费阶梯是固定且公开的：100k LOC 32 美元，200k 64 美元，400k 128 美元，800k 256 美元，1.6M 512 美元，3.2M 1024 美元。付费计划保持用户无限制，所以如果你的团队增长但审查工作量保持不变，你的账单不会突然翻倍。这使得 LiveReview 可预测、以工作量为锚点，并且比基于席位或不透明的基于令牌的替代方案更容易预算。

不会。你只需为审查差异中出现的代码付费，而不是整个仓库。一个 100 万行的项目并不意味着 100 万行被计费。只有实际审查差异中的代码才会计数。

仅分析暂存的 diff。不会上传完整的仓库上下文，且审查后不会存储 diff。

git lrc hooks disable # 对当前仓库禁用git lrc hooks enable # 稍后重新启用

git lrc review --commit HEAD # 审查最后一次提交git lrc review --commit HEAD~3..HEAD # 审查一个范围

SonarQube 等工具主要是静态分析器和 linter。它们依据预定义规则检查代码，通常运行在 IDE 或 CI 流水线中。许多企业用它们在大规模代码库中强制执行质量和安全标准。git-lrc 聚焦于不同的层面：Git 本身。git-lrc 不通过规则目录分析整个代码库，而是在提交时审查实际的 diff。目标是帮助开发者理解变更内容、更早发现问题，并将审查信号直接附加到提交上。另一个关键区别是，git-lrc 将审查视为仓库状态。审查结果（已审查、已跳过、已担保）会成为 git log 的一部分，因此审查决策与代码一同进行版本管理。核心思路是将验证直接引入 Git，使审查更早发生，并成为仓库工程历史的一部分，而不是 CI 或仪表盘中的外部事物。如果你对这个更广泛的理念感兴趣：Conjecture, Criticize, Commit: Bringing Adversarial Refutation into AI-Assisted Software EngineeringShould Code Review Live Inside Git?它们解释了让审查成为 Git 原生产物、而非仅存在于 CI 或仪表盘中的思路。

是的。git-lrc 免费且开源——你可以在每次提交时运行微型 AI 代码审查，无需支付任何费用。它支持使用你自己的 AI 提供商密钥（OpenAI、Gemini、Anthropic、Ollama 等），因此使用成本取决于你的提供商收费。付费的 LiveReview 方案提供团队级仪表盘、仓库规则、摘要和组织级分析——但提交时审查工具本身保持免费。

是的。因为 git-lrc 本身在 git 内部本地运行（作为 git hook，而非托管机器人），所以它适用于任何 Git 托管服务——GitHub、GitLab、Bitbucket、Gitea、Azure DevOps 或普通的自托管 Git 服务器。无需仓库集成或机器人邀请即可开始使用。

跳过是被允许并记录的：提交信息/日志会保留已审查与跳过提交的记录，因此“我们审查了一切”是可验证的，而不是一种愿景。想要更严格强制执行的团队可以使用 LiveReview 中的 Repository Rules 和 CI/CD Gates 来阻止高风险变更被跳过。

当您运行审查时，LiveReview 只会将 diff 发送给 AI 模型——除此之外不发送任何内容。我们不存储您的代码，也从未在您的代码上训练任何 AI 模型。在安全方面，我们定期在自己的代码库上运行扫描，以在问题发生前发现漏洞。这包括 Gitleaks、OSV Scanner、Govulncheck 和 Semgrep，所有这些都通过 GitHub Actions 运行。每次发布时还会生成并发布物料清单 (BOM)，以便您确切了解其中包含的内容。LiveReview 完全透明——整个源代码都可以在 GitHub 上供您浏览。您可以在安全文档中查看完整的安全详情。

我们定期在我们的代码库上运行安全扫描，以尽早发现漏洞。这包括 Gitleaks、OSV Scanner、Govulncheck 和 Semgrep。您可以直接从我们的 GitHub Actions 页面查看完整的扫描历史和日志。

自托管模式在自托管模式下，您的团队运行整个应用程序栈和数据库，您的基础设施团队控制所有数据存储、备份、保留和网络访问。云/提供商集成在云/提供商集成模式下，LiveReview 将数据发送到配置的外部提供商端点，用于 AI 推理和 Git 提供商操作。在我们的部署模型文档中查看更多信息。

本地 Ollama 模型：使用本地 Ollama 模型时，所有推理流量都保留在您自己的基础设施内——不会发送到外部。云端 LLM：使用像 OpenAI、Anthropic 或 AWS Bedrock 这样的云端 LLM 时，审查负载会被发送到该提供商的 API 端点。模型的选择由操作员明确配置，确保完全的可见性且没有意外。

LiveReview 拥有强大的护栏来防止这种情况。在向 AI 模型发送任何数据之前，它会运行提示词注入检测，中和指令覆盖短语（如“忽略之前的指令”），去除隐藏字符，并替换已知的控制令牌。这些检查会在每次审查请求时自动运行。详细信息可在我们的 AI 风险和缓解文档中找到。

AI 建议严格仅作建议，在采取任何行动前需要人工审查。团队还可以在合并前强制执行分支保护、CI 检查和强制审查者批准。LiveReview 在返回模型输出之前也会对其进行清理，删除敏感模式并处理响应中的不安全链接或 HTML。您可以在我们的护栏验证文档中验证这一点。

是的。SBOM 会在每次发布时使用 Syft 自动生成，并发布到 GitHub 发布资源中。您可以在最新发布页面查看它。

LiveReview 目前尚未获得 SOC 2 Type II 认证。但是，完整的安全文档、扫描历史记录、SBOM 和源代码公开可供审查，使企业买家能够直接了解产品的安全态势。

是的。您可以在几分钟内连接您的 Gitea 仓库，并立即开始接收所有项目的代码审查。

是的。LiveReview 提供 VSCode 扩展。如果您正在使用 Cursor、Antigravity 或任何其他基于 VSCode 的编辑器，您可以从 OpenVSX 安装 LiveReview 扩展。了解更多信息请点击此处。

是的。当您尝试通过 VSCode 内置的 Git 界面提交时，提交最初会失败——这是预期的。git-lrc 不会允许提交通过，直到审查完成或被有意跳过。要使其工作，请暂存您的文件，然后在终端中手动运行 git lrc review，或在 VSCode 的 Git 选项卡中点击眼睛图标。完成后，您可以直接从 LiveReview 界面提交，或者修复标记的问题，再次暂存文件，再次运行审查，然后像往常一样通过 VSCode 的 Git 界面提交。

是的，您可以在 GitHub、GitLab、Bitbucket、Gitea 和 Azure DevOps 的 PR 请求中提及 Livereview 机器人；它会自动审查所有更改并提供反馈。您还可以提出进一步的问题或与 AI 进行辩论。

LiveReview 是完整的平台——它包括仪表板、组织级别的代码审查跟踪、跨 GitHub、GitLab、Bitbucket、Gitea 和 Azure DevOps 的 PR 集成，以及管理整个团队代码质量的完整功能套件。git-lrc 是一个轻量级的 git 子命令（git lrc review），它将 LiveReview 的 AI 分析直接带入您的本地 git 工作流。它在您推送之前运行在未提交的代码上，以便您尽早发现问题。它只需一个命令即可安装，无需 Git 提供商连接即可开始。点击此处了解更多关于 git-lrc 的信息。简而言之，git-lrc 是开始使用 LiveReview 的最快方式，专注于个人开发者的本地工作流，而 LiveReview 作为平台则是为整个组织构建的——跟踪审查、执行标准，并让管理者能够查看所有项目和团队的可见性。

是的。LiveReview 仪表盘让您全面查看多个项目中所有触发的代码审查——无论它们来自 GitHub、GitLab，还是通过 git-lrc 在本地触发。这为整个组织带来了团队标准化，让管理者获得组织级别的代码质量视图，同时帮助开发者在所有项目中一致地推送更好的代码到生产环境。

是的。如果您的团队或组织遵循特定的代码审查实践，您可以直接从 LiveReview 仪表盘将它们添加为指令。然后 LiveReview 将在每次代码审查时检查并验证这些标准是否得到满足。

LOC 代表代码行数（Lines of Code）。在 LiveReview 定价中，它指的是被审查差异中显示的代码，而不是您仓库的总大小。

高级计划起价为每月 100,000 LOC，费用为 32 美元。更高的付费档位包括：200,000 LOC 为 64 美元，400,000 LOC 为 128 美元，800,000 LOC 为 256 美元，1.6M LOC 为 512 美元，3.2M LOC 为 1024 美元。所有付费档位均保持用户数不限，并每月刷新。如果 100,000 LOC 不够用，您将进入下一个固定工作负载档位，而不是购买更多席位。

是的。LiveReview 由大语言模型驱动，而非针对每种语言的静态分析器，因此它不局限于固定的语言列表。它很好地支持 Python、Java、JavaScript/TypeScript、Go、C/C++、C#、Ruby、PHP、Rust、Kotlin、Swift 以及典型代码库中大多数其他主流语言和框架。如果您的团队技术栈在同一仓库中包含多种语言，LiveReview 会在同一个 PR 中审查它们，无需额外配置。

任何代码审查——无论是人工、AI 还是人工+AI——的首要目的，都是提供比竞争对手更好的用户/客户体验。因此，评估一个审查系统的诚实方式，是看它推动的生产指标：每天/每周/每月有多少生产事故（越低越好）每天/每周/每月有多少部署回滚（越低越好）一个变更要等待多久才能进入生产（越低越好）每个变更需要多少资深工程师的注意力/精力（越低越好）市场上大多数代码审查系统从不与这些指标建立反馈闭环——它们把审查和生产性能当作彼此独立的组件。RADAR 增加了什么LiveReview 用风险评分给每个 PR 打分——低、中或高——该评分源自多个信号：一个每天学习的组织专属 ML 模型LLM 语义反馈静态扫描 + 检查有了这套风险评分，你可以自动合并 40–50% 的低风险变更，无需人工干预——让你的工程师只把注意力放在高风险的重大变更上。了解自动批准如何工作。

在组织层面，它既更安全也更快。借助 LiveReview 基于 RADAR 的流水线：生产事故降至此前发生率的 1/50回滚率降低三分之一等待合并的时间减少三分之一因此生产中出问题的情况更少，而好的变更能更快合并和发布。你可以在自动批准画廊中浏览 19 个 LiveReview 处理各种场景的示例。

企业版计划专为需要更多控制、隐私和灵活性的组织而构建。它包括：多组织支持在一个订阅下管理不同的工程团队或实体。SSO 与目录同步通过 SAML 或 OIDC 连接你的内部用户目录，让你的团队无需管理单独凭据即可登录。SCIM 使该目录保持同步：当你的 IdP 停用或移除某人时，LiveReview 会立即取消其配置并撤销其活动会话，而 OIDC 反向通道注销会在 IdP 将其注销的那一刻切断会话。跳过 SCIM 的组织仍会获得针对 IdP 的定期对账检查作为后备。自托管部署完全在你自己的基础设施内运行 LiveReview，将所有代码和审查数据保留在你的网络内。自定义域名在你公司品牌的自有子域名上托管 LiveReview。完整数据隐私完全控制你的代码和审查数据存储在哪里以及谁可以访问。

支持。如果你的团队运行私有的自托管 AI 模型并希望使用它而不是 LiveReview 的默认模型，你可以选择企业版计划。我们的技术支持团队将帮助你在自己的基础设施上进行设置。

在使用 Ollama 的自托管模式下，模型完全在客户控制的基础设施上运行。运营者负责选择和管理模型。对于外部提供商，集成是显式配置的，因此运营者始终知道正在使用的是哪个模型。

企业客户享有专属 SLA，针对关键问题有保证的响应时间和解决时间，因此当出现紧急情况时，您的团队永远不会被等待。

企业版适合处理敏感代码库、出于合规要求需要 SSO、希望自托管以保护数据隐私，或需要保证支持响应时间的组织。

风险感知代码审查是一种在每次变更上运行 AI 审查的方法，并叠加风险模型——每个发现都会根据其可能造成的业务损害（安全性、正确性、架构、性能、合规性）进行评分和优先级排序，而不是让团队淹没在琐碎问题的平铺列表中。LiveReview 通过风险评分、审查优先级排名和 10 类风险分类法实现了风险感知审查，因此工程注意力会集中在风险最高的地方。

微审查是一种在 git 提交时运行的小型、快速 AI 代码审查——在代码合并前，而不是之后。您运行 git lrc review（来自 git-lrc，免费），AI 仅检查暂存的差异，您会得到发现结果以及审查、担保或跳过的选项。因为它只审查很小的差异，所以只需几秒钟，就能在代码到达您的分支之前捕获错误的逻辑、凭据泄露和静默的行为变更。

LOC（代码行数）仅指审查差异中的行数——我们按被审查的代码收费，而不是按您仓库的大小收费。一个主要稳定但只有少数活跃文件的仓库几乎不需要费用；只有当 LiveReview 实际审查了变更代码时，您才需要付费。

LiveReview 报告中的每一个发现都被归类到一个包含 10 个类别的风险分类体系中：安全性、正确性、架构、性能、可维护性、可靠性、成本、可扩展性、合规与治理以及开发者体验。这些类别加上每个变更的风险评分会输入到审查优先级排名中，以便团队使用 Repository Rules 和 CI/CD Gates 强制执行诸如“不得跳过高风险安全性发现”之类的规则。