GitHub AI Scan 没有扫描结果：取消 CodeQL 前置条件后的配置与验收

给仓库启用了 AI 安全扫描，Pull Request 里却没有结果，是没开 CodeQL，还是扫描根本没触发？GitHub 在 2026 年 9 月 16 日调整了 AI Scan 的前置条件。本文把新规则、配置继承和结果验收拆开，避免把“没有告警”误当成“已经安全”。

一、这次变化：不再依赖 CodeQL default setup

按 GitHub 当天的 Changelog，PR 的 AI Scan 不再要求仓库先配置 CodeQL default setup。此前依赖这一配置；现在，只要仓库满足资格条件并启用了相应能力，就不应再把“没有默认 CodeQL 配置”单独判定为不能扫描。

但移除一个前置条件，不等于所有仓库自动拥有功能。公告仍要求启用 code scanning 与 AI Scan，并遵循仓库、组织及适用的企业层级权限。该变化处于 public preview，面向 github.com 上的组织和个人仓库的 GitHub Advanced Security 客户；此次不支持 GitHub Enterprise Server。

概念文档还写明预览期需要 GitHub Advanced Security 和 GitHub Copilot 许可，使用会消耗 AI credits。接入前应核实账号资格和用量策略，不能把“无需新配置步骤”翻译成“免费无限用”。本文不承诺具体账号一定已获得入口。

二、先区分三件事：扫描、告警、合并门禁

AI Scan 是对 CodeQL 的补充，目标包括 CodeQL 未覆盖的语言和框架；并不是把静态分析整体换成大模型。它直接分析 PR 代码并获取仓库上下文，不要求构建系统，也不使用仓库里的 copilot-instructions.md 或 CLAUDE.md 作为自定义扫描指令。

官方概念文档将 AI 发现描述为建议性质：它们本身不会阻止合并。结果出现在 PR 的 Conversation、Files changed 等位置，带有 AI 标识，而不是作为历史积压告警展示在仓库安全视图。想做强制准入，需要另外核对规则和检查项，不能从“开了扫描”推导出“合并按钮一定会锁住”。

这也不同于 Secret Scanning 的密钥泄露门禁。一个关注代码中的安全问题，一个关注凭据暴露，名称都带 security，却不能互相充当验收证据。

AI Scan 接入验收分为资格配置、PR证据、人工复核三个环节 — 图：三个验收环节彼此相关，但“未发现问题”不能证明前两个环节正常。

三、从上到下检查资格与配置

先确认仓库所在服务：github.com 还是自建 GHES。再确认许可、AI 用量策略和当前操作账号权限。随后检查企业策略（若适用）、组织安全配置、仓库实际生效状态。上级策略约束下，仓库页面上的一个开关并不一定代表可以独立修改。

不要为“修复无结果”而先关闭现有 CodeQL 工作流，也不要随手给机器人增加全组织写权限。这次公告明确说不需要额外的新设置步骤；排查重点应是原有功能是否真的启用、仓库是否符合条件，而不是凭空补一份 AI Scan YAML。

建议留下仓库、配置层级、核对时间、操作者权限范围四项记录。截图前遮住私有仓库名称和成员信息；面向团队的排查报告不需要包含访问令牌。

四、把排查绑定到一个 PR 和一次提交

选一个已获授权的测试仓库，用正常的小范围改动创建 PR。文档说明创建 PR 和追加提交是触发时点。不要故意把真实密钥或可利用的漏洞塞进生产仓库，只为了看到一个红色提示。

下面的 Bash 示例需要先安装 GitHub CLI，并完成有权限的登录；把 OWNER/REPO 与 123 替换成测试仓库和 PR 编号。命令只读取信息，不修改仓库配置：

REPO='OWNER/REPO'
PR=123
gh pr view "$PR" --repo "$REPO" \
  --json number,url,state,headRefOid,baseRefName,updatedAt
gh pr checks "$PR" --repo "$REPO"
gh pr view "$PR" --repo "$REPO" --web

记录 headRefOid，防止拿上一轮提交的结果验收新代码。checks 用来辅助了解 PR 检查状态，不是 AI Scan 专用状态查询；命令没有列出 AI 项目、返回成功或失败，都不能单独证明 AI 引擎是否完成扫描。本文命令依据 CLI 文档核对，未声称在读者的仓库执行过。

五、没有告警时，按证据分支排查

现象	优先检查	别急着下的结论
根本没有功能入口	部署形态、许可、权限及预览资格	不等于仓库代码有问题
入口可见但 PR 没结果	实际开关、上级策略、触发时间和提交 SHA	不等于一定要开启 CodeQL 默认配置
CodeQL 失败或等待	分别核对两个引擎的证据	不等于 AI Scan 必然也失败
发现 AI 告警仍可合并	建议性质与仓库既有合并规则	不等于分支保护失效
安全页没有历史 AI 告警	回到目标 PR 查看 AI 标识	不等于结果被删除

没有发现问题，至少可能对应未启用、未触发、尚未完成、未检出等不同状态。证据不足时就写“扫描状态待确认”，别替工具签安全保证书。也不建议靠不断追加无意义提交测试：那会增加噪声和用量，却未必补上缺失的配置证据。

六、收到修复建议后，仍要人工走一遍

先确认问题位置是否属于当前提交，再沿输入来源、权限判断、数据流和输出路径复核。部分发现会附修复建议，但不是每条都有。能够自动生成补丁，不代表它理解了全部业务约束。

处理时保留原发现、判断理由、修复提交和回归测试结果。若建议改变鉴权或输入校验，除了正常路径，还要测试未授权、空值、边界值和异常输入。确认误报则记录依据，不要为了把页面变绿而批量忽略。

七、官方资料冲突时，保留时间边界

本次核对发现一个值得注意的差异：9 月 16 日更新公告已明确取消 CodeQL default setup 前置条件，而读取到的概念文档仍保留旧依赖描述。本文对这一变化以有明确日期的公告为准；文档用于核对结果位置、建议性质及许可说明。

这不意味着可以随意挑喜欢的说法。应该把冲突点、来源日期和采用口径写清楚；若涉及账号是否可用，以管理页面实际能力和后续官方说明为准。也不要顺势推断其他限制一起取消。

八、上线前的验收清单与参考

已确认运行在受支持的服务形态，且账号许可与用量策略符合要求。
已记录仓库、组织、企业层级实际生效配置，不仅是一个页面开关。
已绑定目标 PR、提交 SHA 和触发时间；证据不足时明确标注未确认。
已在正确的 PR 位置检查结果，未把零告警当作安全证明。
AI 建议经过人工判断及回归测试；原有 CodeQL 和合并规则没有被误删。

参考来源：GitHub 9 月 16 日更新公告；AI-powered security detections 官方概念文档；gh pr view 手册；gh pr checks 手册。资料核对日期：2026 年 9 月 17 日。

AI 可以帮忙多看一遍代码，但验收不能只靠“页面今天挺安静”。把资格、配置、触发和结果分别查清楚，才知道安静究竟代表什么。