几道检查先读代码，最后由一个人签字批准。
想象一下：周一早上，吉隆坡一家金融科技公司的工程主管打开 GitHub。周末期间，三个编码智能体提交了 40 个拉取请求（PR）。团队里只有两个人有权批准，而且两人手上都有自己的工作。
当智能体写代码的速度超过人阅读的速度，谁来审查 AI 代码？答案是一叠检查先完成大部分阅读，每一层抓不同类型的错误，最后由一个人签字。
下面每一层都写明负责这项工作的 Sonar 产品，以及截至 2026 年 10 月所需的方案。如果您在马来西亚或新加坡负责工程团队，包括在银行或金融科技公司，这就是我们建议的搭建顺序。
AI 生成代码审查跟不上：智能体写得比人审得快
在 Sonar 自己的 2026 年调查中，受访的 1,149 名过去一年在工作中用过 AI 的开发者表示，AI 占已提交代码的 42%。调查预计这一比例到 2027 年将达到 65%。同一调查发现，96% 的人"do not fully trust AI-generated code"（不完全信任 AI 生成的代码），而"only 48% always verify it before committing"（只有 48% 在提交前总会核查）。
工作堆积在审查环节。该调查中，38% 的人表示审查 AI 代码比审查同事的代码更费力。GitHub 在 2026 年 5 月表示："More than one in five code reviews on GitHub now involve an agent"（GitHub 上超过五分之一的代码审查现在有智能体参与）。
许多智能体提交的 PR 根本看不出被审查过。一项 2026 年针对智能体所写 PR 的研究，在热门 GitHub 仓库中发现 61.38% 的 PR "no recorded review activity"（没有任何审查记录）。在确实存在的审查评论中，71.58% 来自智能体。
GitHub 2025 年 Octoverse 报告呈现了相同的趋势。合并的 PR 一年内增长 23%，而 issue 和 PR 上的评论"essentially flat"（基本持平）。GitHub 称这些是观察性信号，并不证明因果关系。
没人读 diff 时，会漏掉什么
当代码由智能体编写时，最需要关注四类问题。
- 智能体引入的依赖。 Sonar 提醒"agents may autonomously install packages without manual vetting"（智能体可能在无人审核的情况下自行安装软件包）。一项 2025 年的研究发现，AI 模型会编造并不存在的包名：商业模型建议的包中平均至少 5.2% 是编造的，开源模型则为 21.7%。
- 注入。 Sonar 建议检查 AI 代码，以"eliminate injection vulnerabilities"（消除注入漏洞），例如把用户输入直接拼进数据库查询。智能体还面临第二种注入，即提示注入（prompt injection）。
- 密钥泄露。 GitGuardian 2025 年报告发现，使用 GitHub Copilot 的公开仓库密钥泄露率为 6.4%，比公开仓库平均水平高 40%。
- 业务逻辑和访问控制缺陷。 在 2025 年 OWASP Top 10 中，失效的访问控制（broken access control）排名第一。OWASP Top 10 是由开放全球应用安全项目（Open Worldwide Application Security Project）发布、被广泛采用的 Web 应用风险清单。在该清单背后的数据中，100% 被测试的应用都存在某种形式的此类问题。
编造的包名是真实的攻击途径。研究作者称之为"a novel form of package confusion attack"（一种新型的包混淆攻击）：谁先注册这个名字，谁就决定您的构建会安装什么。
提示注入是智能体在普通代码缺陷之上额外带来的风险。OWASP 警告，间接提示注入发生在大语言模型（LLM）"accepts input from external sources, such as websites or files"（接收来自网站或文件等外部来源的输入）时。我们认为，这意味着智能体读到一个被投毒的 issue 或 README，就可能被引导。
在我们看来，四类问题中访问控制缺陷最难发现。代码完全按写的那样运行，也能通过测试，只是让不该操作的人做了操作。
六道检查，按智能体代码经过的顺序
我们把整套审查分成六道检查。Sonar 自己的框架把产品分成三个循环：
- 智能体写代码时（智能体循环）。
- 在 PR 阶段，任何代码合并之前（CI，即持续集成验证循环）。
- 合并后，覆盖整个代码库（代码维护循环）。
部分层级也可以用其他工具完成，例如 Git 平台的分支保护可以负责批准环节。我们把六道检查都对应到 Sonar，是因为一家供应商就能覆盖全部层级，也因为我们是它的经销商。
回到那 40 个 PR。下面是每一层会怎么处理它们，以及所需的方案。
1. 智能体写代码时：Sonar Vortex
Sonar Vortex 为编码智能体提供项目上下文，"before they write a line of code, then verifies their output in real time"（在它们写下第一行代码之前提供，再实时核查输出）。它支持 Claude Code（Claude，由 Anthropic 打造）、Codex、GitHub Copilot CLI、Cursor 和 Antigravity 等。Sonar 表示它"works alongside your existing CI"（与您现有的 CI 并行运作），而不是取代 CI。
这是最早能抓到错误的地方，那 40 个 PR 都还没产生。在 Sonar 用一个编码智能体做的自测中，Vortex 让智能体产生的问题减少了 92%。这是 Sonar 自己的数据，我们没有看到独立测试。
方案。 在 SonarQube Cloud 上，Vortex 包含在 Sonar Agent Essentials 中，需要 Enterprise 方案或按年付费的 Team 方案。在 SonarQube Server 上，它是 Enterprise 版 2026.5 及以上版本的单独订阅。
2. 在 PR 上：AI 审查工具 Gitar
Gitar 是一款 AI PR 审查工具，Sonar 于 2026 年 5 月 21 日将其收购。当一个 PR 被打开时，它会"automatically reviews the code and posts inline review comments along with suggested fixes"（自动审查代码，并发布行内审查评论和修复建议）。周一早上，这意味着 40 个 PR 在有人打开之前，都已经过第一轮审查。
CI 运行失败时，Gitar 会找出原因，并"suggests a fix, which it can commit automatically or on demand"（提出修复，可自动提交或按需提交）。Sonar 的价格页面把一个"iterates until CI passes"（反复迭代直到 CI 通过）的循环列为 Pro 方案功能。
这改变了 PR 的作者身份。一旦 Gitar 提交了修改，这个变更就有两个 AI 作者：智能体和审查工具。仍然需要一个人来批准。
方案。 Gitar 是 Sonar 的独立产品，"can be purchased separately"（可单独购买）。Core 和 Pro 方案按用户计费，Enterprise 方案价格另议。Sonar 收购 Gitar 时表示，Gitar 也将可与 SonarQube 及 SonarQube Advanced Security 一起购买。
3. 合并时：质量门
AI 审查工具给出的是意见。质量门则是有书面条件的通过或不通过检查，可以阻止合并。
SonarQube AI Code Assurance 用一个专为 AI 代码设计的质量门来把关 AI 编写的项目。我们的 SonarQube AI Code Assurance 与 AI 生成代码质量门指南已解释了它的六个条件和设置方法，这里不再重复。在那 40 个 PR 中，只要质量门被设为必需检查，任何不符合条件的 PR 都可以被拦下，无法合并。
方案。 在 SonarQube Server 上，PR 分析、合并拦截和 AI Code Assurance 从 Developer 版起提供。免费的 Community Build 只分析主分支。
4. 依赖：SonarQube Advanced Security
Advanced Security 检查您代码所用的开源软件包。它会标出已知漏洞，其可达性分析（reachability analysis）会把"your code actually calls"（您的代码实际调用到的）漏洞排在前面。
它还会对照"against known malicious packages"（已知恶意软件包）检查依赖，也涵盖许可证策略。为了审计，它可导出 SBOM（软件物料清单，列出您交付的每一个组件），格式为 CycloneDX 和 SPDX 这两种常用格式。
对那 40 个 PR 来说，这一层会把智能体加入的每个软件包，与漏洞清单、恶意软件清单和您的许可证策略逐一比对。全新的恶意包可能还未进入任何清单，所以对于没人要求加入的依赖，仍应由人提出质疑。没有 Advanced Security，Sonar AI 质量门中的依赖条件会显示为灰色并被跳过。
方案。 在 SonarQube Cloud Team 和 Enterprise 方案上是单独订阅，在 SonarQube Server Enterprise 版上也是。
5. 覆盖整个代码库：SonarQube Hunter Agent
Hunter Agent 负责寻找"broken access control, business logic, and authentication flaws that traditional analysis misses"（传统分析漏掉的访问控制失效、业务逻辑和身份验证缺陷）。Sonar 的发布公告称，它在后台按计划或按需运行，因此"never blocks a pull request"（从不阻塞 PR）。
Sonar 的文档写得很清楚：它"doesn't fix the issues it finds"（不修复它发现的问题）。它扫描的是合并后的代码库，所以会在 40 个 PR 合并后把它们放在一起看。每个发现对您业务意味着什么，仍要由人来判断。
方案。 单独订阅。在 SonarQube Cloud 上需要 Enterprise 方案；在 SonarQube Server 上需要 Enterprise 版 2026.5 及以上版本。
6. 规模化修复：AI CodeFix 与 Remediation Agent
AI CodeFix 使用 LLM，为 SonarQube 发现的问题建议修复方案。开发者在 SonarQube 或编辑器中看到建议，自行决定是否采用。
SonarQube Remediation Agent 更进一步：它提出修复，并开出新的 PR 交由团队审查。它处理您的问题积压，也处理未通过质量门的 PR。
在 SonarQube Cloud 上，PR 这部分只适用于连接 GitHub 的项目。对周一的 40 个 PR 来说，被质量门拦下的 PR 可能会收到一个以新 PR 形式提出的修复，前提是其语言受支持，且修复通过 Sonar 的复查。
未通过 Sonar 复查的修复不会显示给您。而且它从不合并："Your developers do"（合并由您的开发者来做）。
对受监管团队来说，有一个细节很重要。Sonar 表示，在自己的基础设施上运行 SonarQube Server "does not keep code within your network when you use the agent"（使用该智能体时，并不能让代码留在您的网络内）。代码会发送到管理员配置的 LLM 提供商，例如 Azure AI Foundry 或 AWS Bedrock。
方案。 AI CodeFix 适用于 SonarQube Server Enterprise 版，以及 SonarQube Cloud Team 和 Enterprise 方案。在 SonarQube Cloud 上，Remediation Agent 包含在 Sonar Agent Essentials 中，需配合按年付费的 Team 方案或 Enterprise 方案。在 SonarQube Server 上，需为 Enterprise 版 2026.5 及以上版本单独购买。
哪些事仍然需要人
上面每一层都在缩小人需要阅读的范围，但没有一层能决定是否上线。
批准
截至 2026 年 10 月，GitHub 文档写明，其 Copilot cloud agent 提交的 PR "must be reviewed and merged by a human"（必须由人审查并合并）。该智能体"cannot approve or merge a pull request"（不能批准或合并 PR）。GitHub 也不允许请智能体做这项变更的人自己批准。
Anthropic 的 Claude Code GitHub Actions 文档建议："review Claude's changes before merging"（合并前审查 Claude 的修改）。我们的团队使用 Claude Code 指南介绍了这一设置。无论用哪种工具，都应把任何 AI 审查工具（包括 Gitar）视为只发表评论的审查者，而不是批准者。
同样的规则也适用于在代码之外工作的智能体。例如，ChatGPT 中全天候运行的 OpenAI dots 可以设置为先请求批准再行动；我们的 OpenAI dots 及其审批规则指南介绍了具体做法。
职责分离
把规则写下来：批准智能体 PR 的人必须是另一个人，既不是写代码的智能体，也不是提出需求的人。
对马来西亚的银行和保险公司，国家银行（BNM）的《技术风险管理政策》（RMiT）要求制定程序"to independently review and approve system changes"（独立审查和批准系统变更），并要求"appropriate segregation of duties throughout the SDLC"（在整个软件开发生命周期中进行适当的职责分离）。我们的 RMiT 源代码审查指南把这些条款对应到审计人员要求的证据。
在新加坡，金融管理局（MAS）发布了《技术风险管理指南》（2021 年 1 月），要求金融机构"adopt standards on secure coding, source code review and application security testing"（采用安全编码、源代码审查和应用安全测试标准）。指南还指出，重大问题"should be remediated before production deployment"（应在生产部署前修复）。我们的 SonarQube 新加坡页面把相关的 MAS TRM 条款对应到支持它们的 SonarQube 功能。
如果您处理银行卡支付，支付卡行业数据安全标准（PCI DSS）v4.0.1 允许以"using either manual or automated processes"（人工或自动化流程）审查代码（要求 6.2.3）。评估员是否接受 AI 审查工具作为这种自动化审查，目前尚无定论，请先询问您的评估员。本节只是给合规团队的起点，不构成法律意见。
设计审查
这套工具中没有一个知道这项变更是否本该存在。在开始大型智能体任务前，做一次简短的设计审查，回答以下问题：
- 这项变更是否符合客户的实际需求？
- 它是否为代码库中已有的功能又加了一种做法？
- 超过 RM 50,000 的退款，是否应该需要第二位批准人？
这些问题要在 40 个 PR 到来之前问，而不是之后。
从哪里开始：AI 生成代码审查的方案与清单
大多数团队第一天不需要每一层。下面是比较合理的顺序。
- 开启 PR 分析和合并拦截。 在 SonarQube Server 上需要 Developer 版或以上；我们的版本比较列出了各版本的差别。在 SonarQube Cloud 上，Team 方案会分析每个 PR。没有这一步，智能体的代码会在 SonarQube 检查之前就进入主分支。
- 给 AI 编写的项目加标签，并套用 AI 质量门。 按照我们 AI Code Assurance 指南中的设置清单操作。
- 要求人工批准，并禁止自我批准。 请智能体做变更的人，不应批准该变更的 PR。
- 如果允许智能体添加软件包，加上 Advanced Security。
- 如果审查人员被 PR 淹没，加上 Gitar，让第一轮审查和 CI 修复在人查看之前完成。
- 当问题积压足够多时，再加上 Sonar 的智能体。 截至 2026 年 10 月，它们是付费附加组件。在 SonarQube Cloud 上需要按年付费的 Team 方案或 Enterprise 方案，Hunter Agent 需要 Enterprise。在 SonarQube Server 上需要 Enterprise 版 2026.5 及以上版本。SonarQube 本身如何计价，请参阅我们的SonarQube 按代码行计价指南。
- 决定代码可以去哪里。 SonarQube Cloud 只在欧盟或美国存储数据。如果代码必须留在内部，请使用 Server，并确认 Remediation Agent 及其他基于 LLM 的功能会调用哪个 LLM 端点。
- 一个月后复盘。 按作者或标签给智能体 PR 打标记，以便统计数量。然后统计有多少 PR 在没有任何人工评论的情况下被合并。这个数字应该下降。
谁来审查 AI 代码，最终答案始终相同：工具负责缩小范围，人负责签字。
常见问题
谁应该审查 AI 生成的代码？
先由几层自动化检查，再由一个人把关。扫描工具和 AI 审查工具负责发现已知模式，质量门（quality gate）按书面规则阻止合并。最后由人批准，而且批准者不应是让智能体写这段代码的那个人。
AI 智能体写的代码，由谁负责？
实际上，由提出需求和批准变更的人共同承担。Claude Code 文档对使用者写明："You're responsible for reviewing proposed code and commands for safety before approval"（批准前，您有责任审查所提议的代码和命令是否安全）。至于版权归谁、法律责任由谁承担，是另外的问题，请咨询您的法律顾问。
审查智能体代码需要哪个 SonarQube 版本？
截至 2026 年 10 月：在 SonarQube Server 上，拉取请求分析和 AI 质量门从 Developer 版起提供。AI CodeFix 需要 Server Enterprise 版，或 Cloud 的 Team 或 Enterprise 方案。Remediation Agent 和 Hunter Agent 是单独订阅，其中 Hunter Agent 需要 Cloud Enterprise 方案，或 Server Enterprise 2026.5 及以上版本。
Gitar 是 SonarQube 的一部分吗？
截至 2026 年 10 月，Gitar 是 Sonar 旗下可单独购买的独立产品。Core 和 Pro 方案按用户计费，Enterprise 方案价格另议。Sonar 收购 Gitar 时表示，Gitar 也将可与 SonarQube 及 Advanced Security 一起购买。
Sonar 的智能体能让代码留在我们自己的服务器上吗？
不完全可以。自 2026.5 版起，Sonar 的智能体功能可在自管的 SonarQube Server 上使用。但 Sonar 表示，Remediation Agent 仍会把代码发送到您所配置的 LLM 提供商。
您的本地 Sonar 经销合作伙伴
向本地合作伙伴购买 SonarQube，以令吉或新元计价
安克极速 是马来西亚和新加坡的 Sonar 经销合作伙伴。欢迎就 SonarQube Cloud 或 Server 许可证、Advanced Security、Gitar 与 AI 智能体、续期，或免费评估团队需求与我们联系。
- 以令吉 (RM) 或新元 (SGD) 报价
- 在您的代码仓库与 CI/CD 上本地部署
- 团队培训，在马来西亚可申领 HRD Corp
资料来源
- Sonar 文档：Agent Centric Development Cycle（Vortex、Remediation Agent、Hunter Agent、AI CodeFix），2026 年 10 月 7 日查阅。
- Sonar：Sonar acquires Gitar，2026 年 5 月 21 日，以及 Gitar 方案页面。
- GitHub Docs：Copilot cloud agent risks and mitigations，2026 年 10 月 7 日查阅。
- Spracklen 等，代码生成 LLM 的包名幻觉，USENIX Security 2025。
- 马来西亚国家银行（Bank Negara Malaysia），Risk Management in Technology，2026 年 9 月 25 日发布。
另请参阅 SonarQube 马来西亚（含 Gitar 与 AI 智能体）；如在新加坡采购，请参阅 SonarQube 新加坡。