如果你想用 Claude Code 做安全代码审查，第一步不是让 agent 扫全仓库。Alberta 案例里最值得复制的是这条可审计链路：规则引擎先标出已知模式，Claude Code 再复核并引用文件和行号，最后由工程师批准修复。
触发点是 Anthropic 2026-07-06 发布的 Alberta 政府案例（来源：Anthropic 官方案例，本文核验于 2026-07-07）。官方称，Alberta 自 2025 年起用 Claude Code 搭配 Opus 和 Sonnet 模型审查政府系统。其技术团队在约 20 小时内评估了 4.66 亿行代码，约 50 个 agent 并行工作，覆盖其维护的政府代码库；修复发布前仍由工程师审查批准。
不要把 Alberta 的规模数字直接拿来预测你的团队 ROI。可复用的是试点顺序：先限定资产和规则，再要求可复核证据，然后让 AI 生成补丁和测试草稿，最后把合并、披露和上线留给人。
适合先试的团队
Claude Code 安全审查试点适合已经有代码负责人、测试入口和漏洞处理流程的团队。如果这些基础设施还没有，agent 会先放大误报和 review 压力。
| 团队状态 | 建议 |
|---|---|
| 有 10 个以上服务、历史技术债和安全 backlog | 可以选一个边界清楚的系统做试点 |
| 有 SAST、依赖扫描或内部安全规则，但缺少修复产能 | 可以让 Claude Code 补复核、修复草稿和测试草稿 |
| 有遗留系统，文档不完整，维护者变动大 | 可以先做安全清单和技术文档补全，不要先让它改生产代码 |
| 没有 CI、没有 owner、没有安全联系人 | 先补流程，不要启动大规模 agent 审查 |
| 仓库含生产密钥、未公开漏洞细节或敏感客户数据 | 先做隔离副本和脱敏输入，再讨论 agent 访问 |
Alberta 面对的是公共部门的大规模遗留系统。Anthropic 案例写明，其 Ministry of Technology and Innovation 维护 27 个省级部门的系统，约 1,280 个应用和 3,400 个代码仓库，其中很多系统从未做过系统性安全审查。你的团队不需要达到这个规模才值得试点，但必须先划清资产边界。
第一轮不要扫全公司
第一轮只验证一条安全审查闭环能不能跑通：候选问题能解释，补丁能测试，责任人能批准。不要一上来复刻 Alberta 的 4.66 亿行代码扫描。
选仓库时用这 6 条筛：
| 选择条件 | 通过标准 |
|---|---|
| 业务边界 | 一个服务、一个应用或一个清楚的子系统 |
| 代码负责人 | 至少 1 名 owner 能 review 结果 |
| 测试入口 | 有单元测试、集成测试或可运行的最小验证命令 |
| 风险类型 | 只选 2-3 类问题，例如鉴权、输入校验、依赖版本、日志泄露 |
| 数据边界 | 不需要暴露生产密钥、真实客户数据或未公开漏洞材料 |
| 回滚能力 | 修复失败时能回退，不会直接影响生产 |
第一轮避开支付、身份主干、生产部署脚本、云权限、DNS、密钥管理和未隔离的全量 monorepo。安全审查不是越大越好；第一轮要能算清真阳性率、修复成本和 review 负担。
按“两段式审查”组织 agent
在 Anthropic 的案例里，Alberta 没有让模型自己满仓库找风险。官方描述的关键机制是两段式：先用规则引擎标记已知模式，再让 Claude Code 审查这些标记并引用具体文件和行号，供开发者验证。
第一轮可以照这个结构跑：
- 准备规则集：从历史漏洞、SAST 规则、依赖策略和内部编码规范中选 10-30 条。
- 先跑确定性扫描：让规则引擎或脚本标出候选问题，不让 Claude 直接自由遍历所有风险。
- 让 Claude Code 复核候选：每条候选必须说明触发条件、影响范围、文件路径和行号。
- 要求修复草稿：只允许在选定目录内生成最小补丁。
- 缺测试先补测试：如果没有自动化测试能证明补丁安全，先让 Claude 写测试，再考虑改实现。
- 人工批准：owner 或安全工程师确认真阳性、严重性、补丁和测试后再合并。
按这个流程跑，每条结果都要留下可复查材料。安全团队要看到规则命中了什么、Claude 如何判断、具体哪一行受影响、补丁和测试在哪里。
给 Claude Code 的任务模板
试点提示词要把权限、输入、输出和停止条件写清楚。下面这个模板可以直接改：
你在一次受监督的 Claude Code 安全审查试点中工作。
目标：
复核 security-findings.json 中的候选问题，只处理 src/auth 和 src/api 目录。
输入：
- security-findings.json 是规则引擎产生的候选结果
- docs/threat-model.md 是本服务的威胁模型
- tests/api 是当前可运行测试
允许：
- 读取 src/auth、src/api、tests/api、docs/threat-model.md
- 为确认问题引用文件路径和行号
- 生成最小修复草稿
- 补充或修改 tests/api 中的测试
禁止：
- 扫描外部系统
- 生成利用代码、攻击载荷、规避检测、横向移动、持久化或数据外传步骤
- 修改部署、云权限、密钥、CI/CD 或生产配置
- 安装新依赖
- 自动提交、推送或发布
输出：
1. 每条候选是真阳性、误报还是无法判断
2. 判断依据，必须包含文件路径和行号
3. 最小修复建议
4. 需要补的测试
5. 必须由人决定的问题
停止条件：
- 需要访问允许范围外的文件
- 需要修改超过 5 个业务文件
- 需要新增依赖
- 发现高危漏洞或疑似未公开漏洞
不要在这个模板里要求 Claude “证明可利用”。安全审查第一轮要产出修复和复核材料，不要产出攻击复现材料。
补丁生成要先过测试门
Anthropic 案例写明，Alberta 在发现漏洞后会让 Claude Code 生成修复、测试并构建；如果系统缺少自动测试，Claude 会先写测试。试点也按这个顺序走：先补测试，再看补丁，最后构建验证。
试点中可以把补丁权限分成三档：
| 补丁类型 | 处理方式 |
|---|---|
| 低风险修复，例如输入校验、错误处理、日志脱敏 | 允许 Claude Code 出补丁草稿，但必须附测试 |
| 中风险修复，例如鉴权逻辑、权限判断、序列化边界 | Claude 只出方案和测试草稿，owner 手动改核心逻辑 |
| 高风险修复，例如身份主流程、支付、生产配置、加密、密钥处理 | Claude 只做影响分析和 review checklist，不自动改 |
不要把“Claude 能 build”当成“可以合并”。合并前至少查这几件事：
- 补丁是否只改了允许目录
- 测试是否覆盖触发条件和负例
- 是否引入新依赖或扩大权限
- 是否改变认证、授权、日志或数据保留语义
- 是否需要安全公告、CVE、客户通知或延迟披露
持续审查可以拆成多个角色
Alberta 案例还提到，他们构建了专门的 Claude review agents，在开发过程中持续运行：一个红队视角 agent 从外部检查应用，一个蓝队视角 agent 按国际安全标准评估防御并写修复计划，其他 agent 检查代码质量和面向公众的文案；每次大约检查 95 个安全控制。
团队可以借用这个结构，但第一版不要做成全自动攻防平台。先拆成这些受限角色：
| Agent 角色 | 第一版职责 | 不该做的事 |
|---|---|---|
| 候选复核 agent | 复核规则引擎结果，引用文件和行号 | 自由生成攻击路径 |
| 修复草稿 agent | 生成最小 patch 和测试草稿 | 自动合并、推送或发布 |
| 防御清单 agent | 对照内部控制项检查缺口 | 替代安全负责人判定严重性 |
| 文档 agent | 补充系统说明、风险说明和 runbook | 编造未验证的系统行为 |
| 回归 agent | 跑限定验证命令并总结失败 | 修改测试来掩盖失败 |
如果确实要做红队视角 agent，只在授权测试环境中使用，并把输出限制为风险描述、受影响组件、证据位置和修复建议。不要把可复用攻击步骤放进普通工单或代码 review 线程。
试点指标看三类
不要只报“扫描了多少行代码”。Alberta 的规模数字适合作为新闻背景，不适合作为你内部试点的成功指标。
第一轮看这三组指标：
| 指标 | 要记录什么 |
|---|---|
| 准确性 | 候选数、真阳性、误报、无法判断、重复问题 |
| 修复闭环 | 生成补丁数、带测试补丁数、通过 CI 数、合并数、回滚数 |
| 人工成本 | 每条问题的 review 时间、owner 修改时间、安全负责人介入次数 |
两周试点后，只在满足这些条件时扩大范围：
- 真阳性问题能被文件和行号复核
- 误报原因可分类，并能改进规则或提示词
- 合并补丁都带测试或明确人工验证记录
- 没有越权读取、敏感数据泄露或未批准的外部访问
- owner 认为 review 负担下降，而不是被大量低质报告淹没
常见错误
直接把 Claude Code 当 SAST 替代品
不建议。Alberta 案例把 Claude Code 放在规则引擎之后使用。确定性工具负责稳定命中已知模式，Claude 负责解释、定位、修复草稿和测试草稿。
要求 agent 给出完整攻击复现
安全修复不需要把攻击步骤写完整。对普通试点来说，足够的证据是受影响文件、触发条件、风险解释和修复测试。越接近利用、规避、外传和持久化，越要进入受控安全流程。
没有测试就让它批量修
如果系统没有测试，先让 Claude Code 补测试和文档。直接批量改遗留系统，会把安全试点变成回归风险制造器。
忽略人类批准
Anthropic 案例明确写了：patch 发布前由 Alberta 工程团队 review 和 approve。你的流程也要保留这条审批线。AI 可以加快发现、解释和修复草稿，不能替代最终安全责任。
把案例数字当承诺
4.66 亿行、20 小时、约 50 个 agent、95 个控制项，都是 Anthropic 对 Alberta 实施的官方案例描述。它们只能说明 Alberta 做过这个规模，不说明你的代码库会有同等速度、准确率或成本。
FAQ
Claude Code 可以直接用于政府或企业敏感代码吗？
不要直接上生产敏感仓库。先用隔离副本、受限路径、脱敏输入、审计日志和人工审批做试点。涉及政府、金融、医疗或客户敏感数据时，还要走组织的数据处理和供应商安全审批。
第一轮需要多少个 agent？
不需要从 50 个 agent 开始。Alberta 的约 50 个 agent 是官方案例里的规模。普通团队第一轮用 1-3 个角色就够：候选复核、修复草稿、回归总结。先证明闭环，再扩大并行度。
没有内部规则引擎怎么办？
先用现有 SAST、依赖扫描、lint 规则、历史漏洞清单或安全 checklist 产生候选。不要让 Claude Code 在没有边界的情况下自由寻找所有漏洞。
Claude Code 生成的安全补丁能自动合并吗？
不建议。安全补丁至少需要 owner review、测试、CI 和安全复核。涉及高危漏洞、披露、生产配置、身份权限或密钥处理时，必须由人批准。
这篇和 Fable 5 网络安全提示词文章有什么区别？
Fable 5 网络安全提示词文章 讲如何避免越界请求和误拦。本文讲团队如何把 Claude Code 放进安全代码审查流程，重点是资产选择、两段式审查、补丁测试和人工批准。
这篇和 OpenAI Daybreak / Codex Security 文章有什么区别？
OpenAI Daybreak 文章 讲 OpenAI 的防御方安全计划、Codex Security、GPT-5.5-Cyber 和开源补丁流程。本文只拆 Alberta 的 Claude Code 案例，适合已经决定试 Claude Code、但还没定第一轮仓库范围、agent 职责和补丁审批线的团队。