GitHub AI Scan 启用状态怎么看？筛选器与 CSV 核对指南

这项状态回答的是“有没有有效启用”

可以在 GitHub 的 Security overview 中查看 AI Scan for pull requests 的启用情况。这里的 pull request 指拉取请求，即把一组代码变更提议合入仓库的协作入口；Security coverage 是安全功能覆盖视图，用来了解哪些仓库已启用相关能力。

GitHub 在 2026 年 10 月 6 日公告中加入这项可见性：汇总显示已启用与未启用的仓库数量，仓库列表显示各自状态。本文于 11 月 13 日整理这项能力，依据已核验的公告与当前官方覆盖率文档，不把旧公告写成当天新发布。

Enabled 反映的是有效配置：企业策略、组织配置、前置条件和仓库选择退出等因素都已计入。它不等于某个拉取请求已被分析，更不等于代码没有安全问题。实际执行和发现仍须另外核对。

在哪里查看，谁可以访问？

组织视图的文档访问要求是对组织中的仓库具有写入权限；企业视图列出的角色是组织所有者和安全管理员。这里说明的是查看要求，不能据此推断查看者可以修改全部企业策略或替所有仓库启用功能。

查看组织时，进入组织主页，打开 Security and quality 标签，再在侧栏选择 Coverage。先确认当前组织、团队和仓库范围，再读取页面的数量和每个仓库的状态。

查看企业范围时，进入 GitHub Enterprise Cloud，打开要查看的企业，在 Security and quality 下选择 Coverage。本文使用的是 Enterprise Cloud 官方文档，不能把这一路径直接套用到 GitHub Enterprise Server。

本次核验的两份来源没有给出 AI Scan 的完整套餐资格、逐国家可用性、具体收费和前置条件清单。能打开覆盖视图或看到一行状态，不代表该仓库已经具备所有使用条件；实际启用前需另核对应产品规则。

怎样筛选仓库并核对 CSV？

要只看有效启用的仓库，在搜索框使用 code-scanning-ai-scan-pr-scan:enabled。要整理待核查清单，使用 code-scanning-ai-scan-pr-scan:not-enabled。两个值和中间的连字符都应保留，不能把界面上的自然语言标签直接拼成另一个查询。

页面也可通过汇总中的已启用或未启用数量，以及 Teams 下拉菜单缩小范围。官方文档说明，列表与指标会随当前选择更新，因此记录数量时应同时注明所选组织、团队和筛选条件。

GitHub 的覆盖率导出 CSV 中，对应列名是 Code Scanning AI Scan for pull requests，字段值为 enabled 或 not-enabled。文档支持下载 Security coverage 显示的数据；本文不猜测尚未核验的导出按钮位置。

如果要把清单交给同事，建议保留导出时间、查看范围和原始状态值，再记录由谁核查。这个整理方法是工作建议，不是 GitHub 自动生成的资格诊断，也不代表 CSV 会替你解释每个未启用原因。

Not enabled 为什么不能直接当成配置错误？

当前官方文档明确说，not enabled 可能包含不具备 AI Scan 资格的仓库，而 Security overview 不区分为什么未启用。因此，不应只凭这一列就要求所有仓库负责人反复开关功能。

核查时可先把该仓库对应的企业策略、组织配置、适用前置条件和是否选择退出分别交给有权限的负责人确认。覆盖视图给出有效状态，具体原因仍需到对应配置与资格规则中查证；本文没有为未知条件补写启用步骤。

例如，假设一个团队筛出十个未启用仓库，这只是十个需要进一步分类的条目，不能当成十个可立即修复的故障，也不能据此计算实际扫描成功率。这是假设示例，没有执行真实组织操作。

怎样避免把覆盖率当成扫描完成证据？

把两个问题分开记录：第一，仓库目前是否有效启用 AI Scan；第二，需要分析的具体拉取请求有没有实际执行记录、输出或发现。前者可以从覆盖视图着手，后者不能由 enabled 字段代替回答。

同一份官方文档还对另一项 Pull request alerts 作出说明：只有在启用告警后，code scanning 至少分析过一个拉取请求，它才报告为已启用。这是另一项指标的定义，不应拿来推导 AI Scan 对所有拉取请求的执行情况。

交接清单可以列明仓库、观察时间、覆盖状态和待核查责任人；涉及某个拉取请求时，再补上实际执行证据。这样能把采用进度与具体扫描结果对应起来，避免把无告警、未启用或已启用解释成安全保证。