GitHub 把 AI 安全检测塞进 pull request 以后，真正该先补的不是“多开一个扫描”，而是 enterprise policy、CodeQL default setup 和 AI credits 边界。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
GitHub 这次把 AI-powered security detections 直接放进 pull request，表面上看只是“多了几条提示”，实际影响的是三件事：谁能开、什么时候跑、账单怎么算。很多团队会把它当成现成福利，结果一开就遇到 enterprise policy 没放行、仓库没开 CodeQL default setup、或者开发者不知道这些 AI 标记为什么只提示不阻断。与其等第一轮 PR 出现混乱，不如先做一轮试跑，把权限、解释路径和回退点都定下来。
适用场景
- 你已经在 GitHub Advanced Security 里跑 code scanning，想补上 CodeQL 覆盖不到的语言或框架。
- 你们的 PR 流程稳定，愿意在合并前多看一层安全信号。
- 团队有人负责企业级安全策略、仓库级启用和预算监控，而不是临时谁想到谁处理。
- 你希望先在少量高价值仓库验证，再决定是否扩到整个组织。
不适用场景
- 仓库还没有 CodeQL default setup，或者 CI 与安全扫描本身都不稳定。
- 团队没有人能解释 AI 检测结果，却准备把它直接变成开发门禁。
- 预算无法接受 Copilot 相关 AI credits 消耗，也没有灰度仓库可试。
- 你想让它替代人工安全评审、依赖审查或回归测试。
先弄清 GitHub 这次的产品边界
GitHub 2026-07-14 的 changelog 给了三个关键信号。第一，AI 检测结果现在会直接显示在 pull request 里，目的是补齐 CodeQL 当前尚未原生覆盖的语言和框架。第二，这些发现会带 `AI` 标签，方便和 CodeQL 结果区分。第三，它们在 public preview 阶段是 informational，不会自动阻止合并。这个边界非常重要，因为它决定了团队的第一目标不是“挡住更多 PR”，而是先学会读懂和筛掉哪些信号真的值得追。
同时，GitHub Docs 也写明，AI-powered security detections 依赖 enterprise 层允许、organization 层启用以及仓库已经打开 CodeQL default setup。账单侧则不是“预览全免费”：运行检测会消耗组织的 AI credits。也就是说，技术前提和预算前提从第一天就是绑在一起的。
上线前准备
- 确认 enterprise owner 愿意允许此能力，并指定谁负责组织级启用。
- 列出候选仓库，优先挑高价值、活跃 PR 多、语言覆盖复杂的仓库。
- 检查这些仓库是否已经启用 CodeQL default setup，而不是只开了零散扫描。
- 准备三类样本 PR：应当通过、会触发可疑模式、以及容易被误报的边缘改动。
- 让安全负责人和开发负责人先约定：预览阶段如何解释结果、谁来复核、什么时候回退。
步骤一：先在 enterprise 和 organization 两层把门打开
这项能力不是仓库管理员单方面能拍板的。更稳的顺序是先 enterprise owner 允许，再由组织管理员只给试点组织或仓库开。这样做的好处是，即使某个仓库管理员想快速扩范围，也不会绕开企业级治理。
- 由 enterprise owner 确认是否允许 AI security detections。
- 在组织级只挑 1 到 3 个试点仓，不要一开始全开。
- 给试点仓明确负责团队，避免结果进了 PR 但没人处理。
- 记录当前启用时间、作用仓库和回退入口，后面复盘用得上。
步骤二：先确认 CodeQL default setup 真正在跑
GitHub 明确写了，AI detection engine 虽然不是 CodeQL 本身，但它依赖 CodeQL default setup 才能工作。最常见的误会是团队觉得“我们之前开过 code scanning”，就默认这次也能直接跑。实际上，如果仓库只跑过自定义或断断续续的扫描，PR 里未必会出现你预期的结果。
- 去试点仓库检查 Security 配置，确认 default setup 是启用状态。
- 查看最近一次扫描是否成功，而不是只看开关状态。
- 如果仓库语言栈复杂，先确认哪些部分是 CodeQL 本来覆盖的，哪些是这次想靠 AI 补盲。
步骤三：把预览阶段的角色定义成“提示系统”，不要急着当门禁
GitHub 的官方定位已经很清楚：public preview 阶段这些发现是 informational，不会自动 block merge。对大多数团队来说，这反而是优势，因为你有一个观察窗口，可以先看它抓到了什么，再决定值不值得进入更强流程。试点初期，最好的做法通常是把它作为 reviewer 的补充视角，而不是新的硬阻断。
- 安全负责人关注：哪些类型最常出现、哪些仓库最容易触发。
- 开发负责人关注：PR 里显示位置、解释成本、是否干扰已有评审节奏。
- 组织管理员关注：AI credits 消耗是否在预期范围内。
步骤四：单独做一轮 AI credits 预算试跑
很多团队会在“能不能用”上花很多时间，却完全没给账单做试跑。GitHub 的 billing 文档已经说明，组织和 enterprise 的 usage-based billing 需要单独看。对这项能力来说，最稳妥的做法不是等月底看总账，而是试点仓跑几天后，立刻检查 AI credits 是否按预期消耗。
- 记录试点仓每天的 PR 数量和触发次数。
- 在 billing 视图里观察 AI credits 变化，而不是只看 GHAS 总体开销。
- 若试点仓过于噪音，先缩仓库范围，再考虑缩使用者范围。
- 把安全收益和 credits 成本一起复盘，别只盯其中一边。
可复用试跑模板
仓库：
是否启用 enterprise allow：
是否启用 organization allow：
CodeQL default setup 状态：
试点开始日期：
样本 PR 数量：
出现的 AI 检测类型：
误报记录：
AI credits 观察人：
回退入口：
复盘日期：实际例子：两仓灰度而不是十仓全开
一个八人团队维护两个核心仓和六个工具仓。安全负责人原本想一口气全开，后来改成只让两个核心仓试点一周。结果发现其中一个仓的 AI detections 很有价值，另一个仓则因为改动模式特殊，误报解释成本高。团队最终只保留一个仓持续开启，把另一个仓留在观察状态。这类差异只有灰度时看得见，仓库一旦全开，反馈会被噪音淹掉。
验收清单
- enterprise 与 organization 两层权限已确认，不靠个人口头记忆。
- 试点仓库的 CodeQL default setup 已验证正常运行。
- 团队知道这些 AI 结果在预览阶段不会自动阻断合并。
- AI credits 已被纳入试跑观察，而不是等月底对账。
- 安全负责人、开发负责人和组织管理员都有明确角色。
- 回退路径可用，能快速撤回试点范围。
常见坑
- 把 AI 检测当成“自动更严的 CodeQL”，实际它的角色不同。
- 仓库没开 default setup，却以为功能失效是 GitHub 出错。
- 没做预算观察，只在 PR 页看结果，最后月底才发现 credits 超出预期。
- 试点范围过大，导致误报和真实问题混在一起，谁都不想看。
- 开发者只看到 `AI` 标签，不知道该如何判断优先级。
排错路径
- PR 里完全没有结果：先查 enterprise allow、organization enablement 和 default setup，而不是先怀疑模型。
- 结果出现但没人理解：给团队准备一页常见类型说明，先建立解释路径。
- AI credits 消耗异常：回看试点仓数量、PR 活动量和是否有人误扩范围。
- 误报太多：先缩仓灰度，再整理最常见误报模式，不要急着扩大启用面。
- 开发者反感新增信号：把它定位成安全 reviewer 的辅助层，而不是临时多加一道硬门。
后续维护建议
更新日期：2026-07-25。预览阶段最值得保留的不是“我们开过了”，而是试跑记录：哪些仓库受益、哪些信号最有用、哪些告警最容易误读。等 GitHub 后续把能力推进到更强集成时，这份记录会决定你是稳步升级，还是又重新从一轮混乱试点开始。