2026 年 9 月 10 日，GitHub Changelog 宣布：GitHub code scanning 的 AI Scan for pull request，现在可以用组织级和仓库级 REST API 管理开关。这次是公开预览，面向 github.com 上的 GitHub Advanced Security 客户，目标很具体——让团队用程序化方式，把面向 pull request 的 AI 安全检测铺到选定仓库，而不必在 GitHub 界面里逐个点设置。GitHub Enterprise Server 不在此次支持范围。
企业安全平台团队真正卡住的，往往不是“AI Scan 有没有这个功能”，而是组织里有几百个仓库时，无法把启用状态收成一条可审计的发布流水线。GitHub 这次补的是启用面的 API：组织设置决定整个组织能不能跑 PR 扫描，仓库设置再决定单个仓库开或关；并且写明，仓库设置不能覆盖组织级的关闭状态。
本文只讨论这一次发布：管理员要把 AI Scan 接到一次真实的组织滚动发布里，改的是哪一步，以及 API 仍然管不到哪里。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
启用权从界面点选，收成两条 REST 路径
Changelog 给出的入口是 /orgs/{org}/code-scanning/ai-scan 和 /repos/{owner}/{repo}/code-scanning/ai-scan，用来查看和更新选定仓库的 AI Scan 状态。GitHub REST 文档把组织接口单独成页，仓库接口写在 code scanning 端点里，两者目前都标记为公开预览，可能会改。
组织侧是 GET 和 PATCH /orgs/{org}/code-scanning/ai-scan。返回和更新的字段都是 pr_scan，取值只有 enabled 和 disabled。文档写明：读到的是组织上存储的值，组织还要遵守企业策略；更新时如果企业不允许 AI Scan，启用会被拒绝。调用者必须是组织 owner 或 security manager。classic PAT / OAuth 需要 admin:org、repo 或 write:org：owner 可用前两者，security manager 需要 write:org。
仓库侧是 GET 和 PATCH /repos/{owner}/{repo}/code-scanning/ai-scan，字段同样是 pr_scan。读取私有或公开仓库需要 security_events，只读公开仓库可用 public_repo；更新则需要 repo（或公开仓库的 public_repo）。仓库 GET 在未启用 GitHub Advanced Security 时会 403；仓库 PATCH 在仓库已归档或未启用 Advanced Security 时也会 403。请求头方面，文档建议 Accept: application/vnd.github+json，并给出 API 版本 2026-03-10。
一次组织滚动发布会怎么走到仓库
接到真实发布里，路径很短。安全平台先确认企业策略允许 AI Scan，再用组织 PATCH 把 pr_scan 设成 enabled；然后对目标仓库发仓库级 GET，确认当前是开还是关，再按名单 PATCH。官方 schema 把继承关系写死了：组织关闭时，仓库不能自己打开；组织打开时，仓库仍可以退出。Changelog 的表述是同一件事：仓库设置不能覆盖组织级的 disabled。
这改变的不是“机器人在 PR 上写了什么评论”，而是谁有权把这项检测变成组织默认。以前要让一批仓库打开 PR AI Scan，人得在界面里逐个找设置；现在可以把它写进现有的仓库开通流水线，和 Advanced Security 的启用状态一起做检查。文档给的组织更新示例就是 PATCH https://api.github.com/orgs/ORG/code-scanning/ai-scan，body 为 {"pr_scan":"enabled"}；仓库更新示例则把同一字段打到 /repos/OWNER/REPO/code-scanning/ai-scan。
它没有改扫描算法，改的是能不能规模化打开
如果只把它读成“GitHub 又上了一项 AI 扫描”，会和这次 Changelog 的范围错位。9 月 10 日这条更新讲的是 enablement API，让组织设置控制 PR 扫描能否在全组织运行，再让仓库设置做单个开关。它没有在这条 Changelog 里宣布新的漏洞类别、新的误报率，或把 AI Scan 从预览改成一般可用。对平台团队，价值是终于能用 REST 把开关收进自动化；对单个开发者，PR 上具体看到什么发现，仍取决于仓库是否真的打开、以及 Advanced Security 是否已经启用。
权限模型也说明这是治理接口而不是开发者玩具。组织读写走 owner / security manager，仓库读取走 security_events，仓库更新走 repo。也就是说，能在应用里给 Agent 发评论的人，不一定能打开这项扫描；能打开仓库扫描的人，也不一定能改组织默认。把这两层拆开，正是为了避免某个仓库管理员在企业禁用时把扫描重新打开。
回读时不要只看 HTTP 200。组织 GET 成功只说明你读到了组织上存的值，不说明企业策略已经放行，也不说明某个仓库已经开始扫 PR。仓库 GET 返回 pr_scan: enabled，在组织随后被关掉之后也不再成立，因为组织 disable 是硬边界。比较稳妥的发布脚本是：先 GET 组织，再抽查至少一个应打开和一个应关闭的仓库，确认仓库无法在组织关闭时自行启用。文档把组织更新失败标成 403、404 和 422，422 还包括被限流；脚本要把这三类和“Advanced Security 未启用”的仓库 403 分开处理，否则很容易把许可问题和参数错误混成一次失败。
还不能把它当成已经覆盖 GHES 的全量开关
先看产品边界。公开预览只在 github.com，面向 GitHub Advanced Security 客户；Changelog 写明 GitHub Enterprise Server 此次不支持。仓库接口在未启用 Advanced Security 或仓库归档时会 403，所以脚本不能把 403 简单当成“已经关闭”，而要先区分是权限、许可还是归档。
再看策略层次。组织启用仍可能被企业策略拒绝；组织启用也不等于所有仓库立刻扫描，仓库还可以 opt out。反过来，组织 disable 是硬边界，仓库 PATCH 不能把它顶掉。滚动发布时应该先读企业策略和组织当前值，再改仓库名单，并保留 GET 回读，而不是只发一条 PATCH 就当全组织已覆盖。
最后看它不是什么。它不替代 code scanning 告警处理、Secret Protection，或 9 月 9 日那条“含密钥 PR 禁止合并”的规则集。那些是另一类事件。试用时应用一个已开通 Advanced Security 的组织，先 GET 组织 pr_scan，再对两个仓库分别打开和关闭，确认组织 disable 时仓库无法启用。GitHub 还在 Changelog 里给出了社区讨论入口，方便反馈预览期的接口变化。
对 Apifox 这类要管大量仓库开关的团队，这次接口的可执行部分其实就一个字段：pr_scan。组织 PATCH 把它打开，只表示组织允许仓库使用 PR AI Scan；接着还要用仓库 PATCH 明确 enabled 或 disabled，并处理 403。公开预览期间，GitHub 允许接口改动，所以流水线里应把路径、字段和状态码写成可调整的，而不是写死成永久合同。Changelog 指向的“AI Scan security detections”文档是扫描能力本身的说明，和这次 enablement API 互补，但不能用扫描文档替代 REST 回读。
信息来源
- GitHub Changelog，2026-09-10：AI Scan for pull request APIs in public preview
- GitHub Docs：REST API endpoints for AI Scan
- GitHub Docs：Get / Update AI Scan enablement for a repository
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
