了解合并请求的风险，以及它的位置。一个免费的开源 CLI 和 GitHub Action。在您的 AI 审查后，farol 告诉审批人合并的风险程度及哪些文件带来风险，因此风险最大的变更得到最多的关注。网站 · 实时演示 · 开始使用 · 参考代理编写代码，代理进行审核。最后的决定仍然是一个人的: 批准合并与否。该批准是稀缺部分，并且在每个合并请求中均匀分布后，它变成了一个沥干，这就是共享挂钩的一行变更使四十页崩溃的原因。farol 在 AI 审查之后引入，而不是取而代之。您的审查代理会对 diff 中的行进行评论。farol 给审批人提供代理无法可靠提供的信息：接受变更的风险，以及其位置。目标不仅是更快的审查：低风险的合并请求可以快速处理，而高风险的请求逐行阅读，从最有风险的文件开始。它从静态分析工作（编译器对您的代码的看法，而不是模型的猜测），因此相同的合并请求总是会得到相同的答案。Claude Code 团队在《Claude Code 团队如何进行代码审核》中描述了相同的原则：审查的努力跟随变更的风险。正如他们所说，“变更决定了级别，而不是作者。” farol（葡萄牙语意为灯塔）在审查员打开 diff 之前进行分流：这个变更影响了哪些内容？每个已存在的页面、API 操作、RPC 方法、运行更改代码的作业和脚本，以及到每个的调用链。合并的风险有多大？一个判决（快速通道、快速审查、仔细审查）和一个 0-100 的风险评分，依据范围、diff 覆盖率、安全发现、合同破坏和依赖关系变化。我该从哪里开始？最有风险的文件优先，内联 diff，未测试的行标记，以及手动尝试的检查清单。免费和开源（MIT）。通过 npx @winninjs/farol 将其作为 CLI 运行，或在每个合并请求上通过 GitHub Action winnin/farol/action 运行。无需账户，无需托管服务：它在您的机器或 CI 运行器上运行，评论每个 PR，永远不会阻止合并。它从不执行您的代码，也不会将其发送到任何地方。实时演示 查看 farol 在真实合并请求上的表现→演示保留了 farol 在 CI 中针对 FastAPI 全栈模板的合并请求生成的报告：一个 FastAPI 后端和一个带有 TanStack Router 的 React 前端。该合并请求为项目添加了状态和一个 Insights 页面，包含审核者应捕捉的各种问题：一个中断的 API 更改、使用 f-string 构建的 SQL、没有测试的共享组件。后端报告：⚠ 仔细审查、中断合同更改和高严重性安全发现。前端报告：⚠ 仔细审查，一个新页面和现有页面的共享组件。报告是互动的：标记文件为已审查，标记某个页面为被功能标志隐藏，打开内联 diff，遵循测试计划并从结果选项卡复制审查记录。它们是合并请求评论中链接到的相同文件（合并请求）；副本保存于 docs/demo/。 AI 审查代理 farol 阅读 diff，以及适合提示的任何上下文，整个程序的基准和头部，以及编译器（TypeScript 类型检查器，go/types，Python ast）。告诉您这些行中可能出现的问题，这些行影响哪些内容，合并的风险有多大，以及首先要查看在哪里。答案是概率性的：每次运行时措辞不同但确定性：相同的 PR 给出相同的报告，并且每个声明都有其调用链。在不确定时可能听起来很自信，能说出未知并要求仔细审查。运行一个模型，通常是本地或在您的 CI 中的托管服务：它从不执行您的代码，也不会将其发送到任何地方。两者都使用，按该顺序。代理首先审查这些行；然后 farol 告诉审批人合并需要多少关注、哪些文件值得关注、哪些页面和端点需要手动测试，以及哪些合同变更需要检查其客户端。代理的审查在小变更具有大范围时恰好不够，这就是 farol 展现的内容。为什么选择 farol 审查注意力跟随风险。一个 40 个文件的 PR 通常只有两到三个文件实际上可能造成伤害。farol 排名这些文件，使得审查者密切阅读这些文件，而有意识地略读其余部分。它跟踪代码，而不是文件名。farol 构建一个声明图，使用真实的编译器（TypeScript 类型检查器，go/types，Python 的 ast）。对 formatPrice 的更改列出了渲染它的十二个页面，而不是“1 个文件已更改”。合同破坏在客户端之前被捕获。删除的响应字段、新的必填参数、在 GraphQL、FastAPI、Go 处理程序和 gRPC 中更改的类型，以及调用每个端点的服务。审核整个 PR，或仅审核自上次查看以来的更改。每次推送获得两个报告：完整的合并请求，以及自上次推送以来的提交。