AI 编程助手已经不只是补全代码而是直接参与生成模块、安装依赖、从开源仓库复制方案。技术圈因此开始认真追问一个问题AI 生成的代码有没有被审查过在 Open Source Ingestion开源代码摄入越来越常见的今天这个问题的核心不是“AI 能不能写出好代码”而是“一个仓库每天可能摄入几十个开源来源的代码片段人如何确定这些代码是安全、合规、可维护的”。这篇文章想讨论的是作为一个开发团队如何把“AI 写了什么、从哪来、能不能进主干”变成一套可执行、可自动化的审查流程。先说明一个基本判断开源代码摄入本身不是新问题。包管理器、复制粘贴、开源组件依赖一直是软件供应链的一部分。AI 编程工具真正改变的是规模和粒度。过去一个依赖引入可能是版本更新现在 AI 可能会在一条提示词的驱动下从多个代码片段中生成一个完整函数同时自动修改依赖清单。整个过程可能只花几分钟但引入的代码来源却比一次人工引入复杂得多。团队如果仍然只靠“多找两个人 review”很快就会跟不上代码进入仓库的速度。更现实的做法是把审查拆成机器可执行的部分和人类判断的部分先让机器把规模问题处理掉再让人做真正的设计判断。1. 先理清“AI 写的代码”和“从开源摄入的代码”为什么难审查讨论解决方案之前需要先承认问题具有结构性。AI 生成的代码和传统的手写代码在审查难度上并不完全相同。理解差异才能设计出针对性的审查机制。1.1 开源代码摄入为什么是新的风险入口Open Source Ingestion 可以理解为一个软件项目主动或被动地把外部开源代码放入自身代码库的过程。常见形式包括通过 Maven、npm、pip、Go Modules 等包管理器安装开源依赖。从 GitHub、Gitee、极狐等平台复制代码片段。把某个开源仓库打成子模块或 vendor 目录。由 AI 编程工具根据训练数据间接复现开源项目中的实现思路。每一种形式都会把外部代码引入到内部工程中。过去引入一个依赖通常会经过依赖选型、版本评估、兼容性测试等环节。但 AI 工具让这个节奏发生了改变开发者在自然语言对话中提出需求AI 可能直接建议安装某个包甚至修改package.json或go.mod。如果审查流程没有同步跟上这些外部代码就会在较少的人工关注下进入生产环境。对很多业务系统来说开源代码摄入的主要风险并不是代码写得好不好而是来源是否可信、许可证是否允许、依赖是否携带已知漏洞、是否包含恶意代码。这些风险不依赖“代码是否由 AI 生成”但当 AI 让摄入次数和摄入量上升后单点风险被放大成了规模化问题。1.2 AI 编程工具如何把摄入规模推到人工无法跟踪的粒度以 Claude Code、Cursor、GitHub Copilot 等工具为例子它们有一个共同特点可以把“实现 XX 功能”翻译成多文件改动。在一次会话中AI 可能做这些事情读取当前项目结构。根据提示词生成新模块代码。自动安装运行时依赖。调整配置文件。引用第三方库中的工具函数。在这个过程里AI 训练数据中的开源代码会以“改写后”的形式出现。这已经不只是“引入依赖”这种显式摄入而是把开源代码的片段混入业务代码形成一种隐式摄入。隐式摄入的问题是代码审查者很难辨认某段逻辑究竟是开发者的原创设计还是来自某个许可证严格的仓库。如果从规模角度观察一次人工代码变更可能只涉及一个模块而一次 AI 辅助变更可能修改十几个文件、引入多个依赖。代码量变大的同时审查时间没有成比例增加。一个 PR 里出现 800 行 AI 生成代码时人类 reviewer 实际上很难判断其中是否存在隐蔽的逻辑错误、安全边界问题或第三方代码合规问题。这也是“Who Vets AIs Code”这个问题的直接来源AI 在编写代码但没有人能对它写的每一行负责。1.3 人工 review 为什么失效盲点、疲劳与责任模糊人工审查面对 AI 生成代码时会碰到三个现实问题。第一个是盲点。如果 AI 从某个不熟悉的开源库里借鉴了算法实现reviewer 在不了解该库的前提下很难发现代码其实是“不完全正确的移植版本”。尤其是一些涉及密码学、并发控制、时间处理的功能错误非常隐蔽。第二个是疲劳。AI 生成代码通常卷幅较大。人持续阅读大量结构相似、注释较少、命名风格略有差异的代码时注意力会迅速下降。结果是前面的 bug 容易被发现后面的代码容易放行。第三个是责任模糊。团队里经常无法回答“这段代码到底是谁写的”。严格来说提交人是开发者但如果开发者只是把 AI 生成结果原样提交他没有真正理解实现后续一旦出现问题排查和修复都更困难。人工 review 不能解决责任模糊只能靠流程和规范去界定。所以让机器先完成可枚举、可重复的检查是应对规模挑战的必然选择。机器可以做依赖扫描、许可证检查、漏洞比对、异常变更检测人只需要在机器输出结果的基础上做业务判断。2. 建立“可追踪”的 AI 代码审查管线审查 AI 生成代码的第一步不是读代码而是让代码“可追踪”。只有记录代码的来源、生成方式和关联依赖后续的检查才能有据可查。2.1 先给代码增加来源元数据不做无法审查的变更如果 AI 辅助产生的代码和普通提交没有任何区别审查者就失去了判断起点。可以在团队内部约定一套元数据规范在提交信息或独立 manifest 文件中记录变更是否由 AI 生成。使用了哪个 AI 工具。触发 AI 生成的提示词摘要。本次变更引用的开源仓库、依赖包和版本。生成后是否经过人工修改。一个示例提交信息可以这样写feat: 增加接口限流模块 AI-Generated: true AI-Tool: claude-code AI-Prompt: 用一个令牌桶实现接口级限流支持 Redis 分布式模式 Source-Refs: | go.mod: golang.org/x/time/rate v0.3.0 pkg/ratelimit/token_bucket.go: 参考 github.com/example/rate-limit/blob/main/bucket.go这段信息并不是用来追责而是让后续审查者知道“这段代码从哪里来”。如果之后发现许可证问题、漏洞问题或者设计问题可以通过Source-Refs快速定位到源头。如果 AI 工具会修改依赖清单提交信息里也应该明确标注。对文件级的追踪还可以使用文件头注释。例如// AI-Generated: true // AI-Tool: claude-code // Source: https://github.com/example/snippet/blob/main/foo.go package main func main() { }这种方式在脚本扫描时非常方便。但需要注意文件头注释不应过度使用否则会产生大量噪音。建议只在以下情况添加生成逻辑超过 30 行。代码来自某个明确引用的开源片段。涉及依赖或安全敏感的算法。2.2 用提交检查和 CI 门槛拦住“不知道从哪来的代码”本地 Git Hook 可以第一时间提醒开发者补充来源信息但本地 Hook 容易被绕过所以 CI 是更强的门禁。建议在 CI 中增加一个“代码摄入审查”阶段该阶段负责收集依赖清单、检查元数据、执行静态扫描。一个 GitHub Actions 的最小示例name: vet-ingested-code on: pull_request: paths: - **/*.go - **/*.py - **/*.js - **/go.mod - **/package.json jobs: vet: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: 生成 SBOM run: syft packages . --output spdx-json sbom.spdx.json - name: 扫描漏洞 run: trivy fs --format json --exit-code 0 . trivy-report.json - name: 检查来源与许可证 run: | python scripts/check_ingestion.py \ --sbom sbom.spdx.json \ --trivy trivy-report.json这个配置演示了三个步骤先生成 SBOM 来枚举依赖再用漏洞扫描器找出已知漏洞最后用脚本判断许可证和阻断条件。注意syft和trivy的安装方式需要根据实际平台调整上面的命令只用于说明流程。CI 门禁的价值在于它不会因为开发者忘记检查而失效。只要 PR 触发了该路径机器就会执行同样的规则。团队的审查文化可以从“靠自觉”变成“靠流程”。2.3 机器负责枚举人负责判断机器审查和人工审查不应该做同样的事。分工可以按这张表来设计审查内容谁来负责原因依赖是否来自允许的仓库机器可以配置 allowlist / denylist是否存在已知 CVE 漏洞机器数据库比对比人脑可靠许可证是否兼容当前项目机器基于 SPDX 匹配规则新增依赖数量是否异常机器可通过 diff 统计算法设计是否满足业务需求人需要业务上下文并发控制是否正确人需要理解执行模型是否引入不必要的复杂度人需要架构判断安全边界是否被绕过人需要结合威胁模型机器检查负责筛选“明显有问题的变更”人工检查负责判断“设计上是否正确”。当两类任务不混在一起时人工审查的负担会明显降低。3. 用依赖预检解决摄入的漏洞与许可证问题开源代码摄入最容易被自动化覆盖的部分就是依赖审查。一个依赖进入项目后它的许可证、漏洞和维护状态都是可以查证的。把这三项做成 CI 中的自动检查是成本最低、收益最明显的起步动作。3.1 SBOM 是审查的起点先让依赖可见SBOMSoftware Bill of Materials软件物料清单是一个项目所有组件的结构化清单。它能回答一个最基本的问题这个项目里到底有哪些来自外部的代码。生成 SBOM 的工具有不少常见的有 Syft、Trivy、cdxgen。以 Syft 为例syft packages . --output spdx-json sbom.spdx.json这条命令会把当前目录当做一个文件系统扫描其中的依赖声明文件生成一份 SPDX 格式的 JSON。SPDX 是目前比较通用的 SBOM 格式之一。拿到 SBOM 后应该放入构建产物或 CI 产物而不是只放在本地。因为后续的许可证检查、漏洞审计、补丁追踪都依赖这份清单。如果原始材料没有给出具体版本落地前先确认 Syft 版本不同版本的输出格式可能存在差异。3.2 三个必查项漏洞、许可证、维护状态依赖预检至少要覆盖三个方面。第一漏洞。可以使用 Trivy 或 Grype 扫描文件系统比对 CVE 数据库输出风险等级。Trivy 的示例trivy fs --format json --exit-code 0 . trivy-report.json--exit-code 0的意思是即使扫描到漏洞也不让命令直接失败。这样做的目的是把完整报告交给后续脚本处理由脚本决定哪些漏洞允许豁免、哪些必须阻断。第二许可证。许可证决定了能否把代码用于商业项目、是否必须开源衍生代码。MIT、Apache-2.0、BSD 通常宽松GPL、AGPL 有较强的版权传染性。需要把项目不允许的许可证加入黑名单。第三维护状态。一个依赖即使没有已知漏洞也可能已经停止维护。判断方式包括最后提交时间、issue 活跃度、release 频率。这个检查可以写成一个定时任务而不是每次构建都执行。更推荐的做法是核心依赖在引入时评估一次并记录在依赖审批表中。3.3 一个最小示例用 Python 解析 SBOM 和漏洞报告下面的 Python 脚本用于演示如何把 SBOM 和 Trivy 报告整合成一条可读的风险清单。实际项目中需要根据自身使用工具的 JSON 结构调整字段名。import json import sys import argparse DENY_LICENSES {GPL-2.0, GPL-3.0, AGPL-3.0} def load_sbom(path: str) - list[dict]: with open(path, r, encodingutf-8) as f: data json.load(f) packages [] # SPDX JSON 中 packages 字段可能叫 packages 或 SPDXRef需要按实际调整 for pkg in data.get(packages, []): packages.append({ name: pkg.get(name), version: pkg.get(versionInfo) or pkg.get(version), license: pkg.get(licenseConcluded) or pkg.get(licenseDeclared), }) return packages def load_vulns(path: str) - list[dict]: with open(path, r, encodingutf-8) as f: data json.load(f) vulns [] for result in data.get(Results, []): for v in result.get(Vulnerabilities, []): vulns.append({ pkg: v.get(PkgName), id: v.get(VulnerabilityID), severity: v.get(Severity), title: v.get(Title) or v.get(Description), }) return vulns def main(sbom_path: str, trivy_path: str) - int: packages load_sbom(sbom_path) vulns load_vulns(trivy_path) print(f发现 {len(packages)} 个组件{len(vulns)} 个漏洞条目) blocked False for pkg in packages: if pkg[license] in DENY_LICENSES: print(f许可证阻断: {pkg[name]} {pkg[version]} - {pkg[license]}) blocked True for v in vulns: if v[severity] in (CRITICAL, HIGH): print(f漏洞阻断: {v[pkg]} {v[id]} {v[severity]}) blocked True if blocked: print(预检未通过) return 1 print(预检通过) return 0 if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--sbom, requiredTrue) parser.add_argument(--trivy, requiredTrue) args parser.parse_args() sys.exit(main(args.sbom, args.trivy))这个脚本的逻辑并不复杂读取 SBOM检查许可证黑名单读取 Trivy 报告阻断 CRITICAL 和 HIGH 漏洞只要有一项命中就让进程返回 1CI 随之失败。关键点在于脚本里的两个字段licenseConcluded和Severity。不同工具可能使用不同字段名。生产项目中不要把解析逻辑写死应该先打印一条示例数据确认结构后再实现。3.4 让检查结果成为合并的“门禁”脚本返回非零状态时CI 应该阻止合并。这个过程可以用 CI 的 job 状态实现python scripts/check_ingestion.py --sbom sbom.spdx.json --trivy trivy-report.json如果脚本执行失败该条 CI 任务就会失败。可以在仓库规则中要求“必须通过 vet-ingested-code 检查才能合并”。这样依赖漏洞和许可证问题就不再依赖某个人的提醒而是成为强制门槛。不过门禁不能设计得太死。完全不允许任何高危依赖存在也可能不合理。有些依赖没有替代品或者漏洞只影响特定场景。建议引入“豁免单”机制对于确实需要临时放行的依赖要求填写原因、创建工单、设定截止日期。豁免单本身也应该进入代码仓库接受审计。4. 从运行验证到接入报错排查自动化检查一旦接入 CI就会开始暴露环境、配置和工具链问题。很多团队在接入 AI 代码审查流程时遇到的第一个障碍往往不是审查规则本身而是工具不能正常跑起来。这个阶段需要知道如何运行、如何验证、如何从报错反推原因。4.1 在 CI 中运行预检脚本并读取输出把预检脚本接入 CI 后需要先做一次“人工触发”的验证而不是直接靠 PR 触发。可以在本地跑一遍同样的命令python scripts/check_ingestion.py --sbom sbom.spdx.json --trivy trivy-report.json预期输出应该包含组件数量、漏洞条目数量以及最终的“预检通过”或“预检未通过”。如果脚本报错优先检查两个 JSON 文件是否成功生成。很多时候是 SBOM 生成失败但脚本一直在报“文件不存在”。CI 中同样要保留完整输出。建议在 workflow 中增加上传报告的步骤- name: Upload report uses: actions/upload-artifactv4 with: name: ingestion-check-report path: | sbom.spdx.json trivy-report.json上传报告的目的是方便审查者查看原始证据而不是只看脚本的一句话结论。4.2 常见错误Key 缺失、模型名错误、编译环境问题当 AI 工具被引入开发流程且 AI 自动执行命令、安装依赖或调用模型 API 时项目会出现几类高频报错。以下是三个常见场景及排查方向。报错现象常见原因检查路径401 unauthorized: api_key_required调用模型或相关服务时没有携带有效 API Key检查环境变量是否设置、密钥是否过期、是否配置到了错误环境xxx is not a model this version of AI tool recognizes模型名称写错或本地客户端版本过旧核对服务商的模型列表升级客户端后重试cannot open source file sys/types.h项目构建时依赖的系统头文件缺失检查构建环境是否安装完整编译器工具链和 SDK第一种报错通常出现在 AI 客户端接入云模型服务时。它并不能说明代码本身有问题而是说明请求链路没有认证。正确的处理方式是使用密钥管理服务或本地环境变量不要把密钥写入代码库。第二种报错常见于 AI 客户端版本与服务端模型列表不一致。出现后不要盲目猜测先查看客户端帮助输出或官方模型列表确认模型名称完全一致。第三种报错是历史悠久的编译环境问题。比如在 Windows 上编译某些 C/C 项目时缺少sys/types.h通常不是代码问题而是没有安装合适的构建工具链。4.3 排错顺序从输入到输出别跳步排错时最忌直接修改代码。建议按下面的顺序检查确认输入文件是否存在。SBOM 或漏洞报告如果为空后面的脚本必然失败。确认工具版本匹配。Syft、Trivy 的新版本可能调整输出字段。确认命令执行路径正确。很多脚本报错是因为在错误目录下运行。确认环境变量是否注入。密钥类配置不要写死在 workflow 中。确认 CI 日志中的关键行。通常第一行异常就是根因不要在日志里大海捞针。确认策略是否合理。如果出现“全部依赖都被阻断”很可能是规则写得太宽松例如把许可证字符串匹配错误。这个顺序适用于大多数自动化审查流程的排错场景。5. 团队规范谁对 AI 生成的代码负责工具和流程只能解决“能不能发现风险”的问题无法解决“风险发生后由谁处理”的问题。团队规范的核心是把责任边界划清楚。5.1 责任不转移提交人始终是代码负责人无论代码是开发者手写还是 AI 工具生成最终提交代码的人都要为代码正确性负责。AI 不是法律或组织意义上的责任主体它不能站在 code review 的会议里解释设计意图也无法为线上故障承担责任。规范上可以这样约定每次使用 AI 辅助完成变更后提交人要在 PR 描述中说明哪部分由 AI 生成哪部分经过人工修改。这个要求不是歧视 AI 代码而是让审查者知道该用哪种标准去检查。如果提交人没有理解 AI 生成的代码就不应该合并。团队里可以增加一个简单问题作为提交人的自检“如果这段代码出问题你能不能不看文档就解释它的工作方式”如果答案是不能说明还没有达到合入门槛。5.2 定义 AI 不允许独立修改的红线文件不是所有文件都适合让 AI 直接修改。以下类型的文件应该进入红线清单文件类型示例建议认证与授权AuthenticationFilter、TokenService必须人工编写或人工逐行复核数据迁移migrations/*.sql不允许 AI 独立生成需要 DBA 审批支付与金额计算PaymentService、PriceCalculator需要测试用例支撑密钥管理SecretManager、CredentialProvider禁止 AI 生成防止硬编码凭据安全加密逻辑CryptoHelper必须由安全工程师审查红线清单可以用一个配置文件管理例如ai-governance.ymlai_generated_restricted_paths: - src/main/java/**/auth/** - src/main/java/**/security/** - migrations/** - src/main/java/**/payment/**CI 脚本可以读取这份配置当检测到 AI 标注的代码修改落入这些路径时强制将 PR 标记为needs-human-review。这样至少能让红线文件增加一道硬性门槛。5.3 从“读代码”改成“查证据”引入自动化审查后人工 code review 的方式也应该调整。过去 review 的重点是“这段代码写得对不对”但在 AI 摄入大量代码以后比较有效的 review 方式是“证据是否齐全”。一个合格的 PR至少要有以下证据变更涉及哪些依赖依赖为什么新增。SBOM 是否已经重新生成。漏洞扫描结果中的高危项是否已处理或豁免。新增代码是否标注了来源和生成方式。是否补充了针对核心路径的测试用例。如果 AI 修改了配置是否理解配置变更的影响面。这种“查证据”的 review 风格比逐行阅读代码更容易发现供应链风险。因为供应链风险往往不体现在单行代码的语法上而体现在依赖选择、来源信任、许可证合规和配置影响面上。6. 高频误区与发布前检查清单最后一部分聚焦实践中最容易踩的坑以及一个可以直接复制到团队文档中的发布前检查清单。6.1 三个容易踩的坑第一个坑是只扫描直接依赖忽略传递依赖。很多团队只检查package.json里列出的包却漏掉了传递依赖。一个间接依赖可能存在严重漏洞但因为它没有出现在顶层依赖文件里所以被忽略。解决方法是依赖 SBOM 或 lockfile 生成完整的依赖树。第二个坑是许可证字符串判断写死。SPDX 许可证格式并不统一同一个 MIT 可能是MIT也可能是MIT License或Expat。如果脚本只匹配MIT就会漏掉Expat。生产项目建议使用许可证解析库或者在规则表中维护多个别名。第三个坑是让 AI 生成代码后不验证直接合入。AI 可能生成调用不存在函数、版本不匹配的 API 或逻辑不完整的代码。即使代码能通过编译也不代表运行时行为正确。解决方式是约定 AI 生成的代码必须有可运行的测试用例至少覆盖正反两条路径。6.2 一个可直接使用的发布前检查清单在合入包含 AI 辅助代码的 PR 前团队可以按以下清单逐项确认是否知道新增代码来源如果标注AI-Generated: true是否补充了提示词摘要或 Source-Refs。是否重新生成 SBOM依赖清单是否仍与代码库一致。是否完成漏洞扫描Critical / High 漏洞是否处理。是否检查许可证新增依赖是否与项目许可证冲突。是否更新 lockfile是否因为 AI 的依赖安装动作产生了意外变更。是否检查红线路径认证、支付、迁移等文件是否被 AI 直接改动。是否补充测试核心逻辑是否有自动化用例。是否区分了人工修改部分PR 描述中是否说清哪些是 AI 生成的代码。清单不需要很长但每一条都要能被机器或提交人明确回答。6.3 生产环境还需要补齐的周边保障如果这套流程已经在开发环境跑通进入生产环境前还需要补充几个方面配置外置化API Key、数据库连接等敏感信息不要出现在代码仓库和 CI 日志里。SBOM 归档每次发布时把 SBOM 与制品一起保存方便事后审计和漏洞回溯。补丁追踪当某个依赖被曝出新漏洞时能快速定位到哪些发布版本受影响。回滚方案AI 生成代码如果导致线上故障团队要有快速回滚到上一个稳定制品的方式。监控与日志对 AI 生成的模块重点关注错误率、耗时和资源占用指标。版本兼容AI 工具和扫描工具的版本升级要纳入变更管理避免工具链本身失效。这些保障不是 AI 特有但在 AI 代码摄入频率提高后它们的优先级会显著上升。回到最初的问题谁审查 AI 的代码。答案不是一个固定的角色而是一套由元数据、CI 规则、依赖扫描、人工复核和团队规范组合起来的机制。机制运行起来之后AI 生成代码的能力仍然能够保留但它进入了仓库的速度会被人和机器共同设计的门禁控制住。对于团队来说最有价值的下一步不是争论 AI 该不该写代码而是先把“AI 写的代码从哪里来、是否安全、由谁负责”这三个问题做成每天都自动运行的检查。
AI生成代码审查指南：构建可追踪的开源代码摄入门禁
AI 编程助手已经不只是补全代码而是直接参与生成模块、安装依赖、从开源仓库复制方案。技术圈因此开始认真追问一个问题AI 生成的代码有没有被审查过在 Open Source Ingestion开源代码摄入越来越常见的今天这个问题的核心不是“AI 能不能写出好代码”而是“一个仓库每天可能摄入几十个开源来源的代码片段人如何确定这些代码是安全、合规、可维护的”。这篇文章想讨论的是作为一个开发团队如何把“AI 写了什么、从哪来、能不能进主干”变成一套可执行、可自动化的审查流程。先说明一个基本判断开源代码摄入本身不是新问题。包管理器、复制粘贴、开源组件依赖一直是软件供应链的一部分。AI 编程工具真正改变的是规模和粒度。过去一个依赖引入可能是版本更新现在 AI 可能会在一条提示词的驱动下从多个代码片段中生成一个完整函数同时自动修改依赖清单。整个过程可能只花几分钟但引入的代码来源却比一次人工引入复杂得多。团队如果仍然只靠“多找两个人 review”很快就会跟不上代码进入仓库的速度。更现实的做法是把审查拆成机器可执行的部分和人类判断的部分先让机器把规模问题处理掉再让人做真正的设计判断。1. 先理清“AI 写的代码”和“从开源摄入的代码”为什么难审查讨论解决方案之前需要先承认问题具有结构性。AI 生成的代码和传统的手写代码在审查难度上并不完全相同。理解差异才能设计出针对性的审查机制。1.1 开源代码摄入为什么是新的风险入口Open Source Ingestion 可以理解为一个软件项目主动或被动地把外部开源代码放入自身代码库的过程。常见形式包括通过 Maven、npm、pip、Go Modules 等包管理器安装开源依赖。从 GitHub、Gitee、极狐等平台复制代码片段。把某个开源仓库打成子模块或 vendor 目录。由 AI 编程工具根据训练数据间接复现开源项目中的实现思路。每一种形式都会把外部代码引入到内部工程中。过去引入一个依赖通常会经过依赖选型、版本评估、兼容性测试等环节。但 AI 工具让这个节奏发生了改变开发者在自然语言对话中提出需求AI 可能直接建议安装某个包甚至修改package.json或go.mod。如果审查流程没有同步跟上这些外部代码就会在较少的人工关注下进入生产环境。对很多业务系统来说开源代码摄入的主要风险并不是代码写得好不好而是来源是否可信、许可证是否允许、依赖是否携带已知漏洞、是否包含恶意代码。这些风险不依赖“代码是否由 AI 生成”但当 AI 让摄入次数和摄入量上升后单点风险被放大成了规模化问题。1.2 AI 编程工具如何把摄入规模推到人工无法跟踪的粒度以 Claude Code、Cursor、GitHub Copilot 等工具为例子它们有一个共同特点可以把“实现 XX 功能”翻译成多文件改动。在一次会话中AI 可能做这些事情读取当前项目结构。根据提示词生成新模块代码。自动安装运行时依赖。调整配置文件。引用第三方库中的工具函数。在这个过程里AI 训练数据中的开源代码会以“改写后”的形式出现。这已经不只是“引入依赖”这种显式摄入而是把开源代码的片段混入业务代码形成一种隐式摄入。隐式摄入的问题是代码审查者很难辨认某段逻辑究竟是开发者的原创设计还是来自某个许可证严格的仓库。如果从规模角度观察一次人工代码变更可能只涉及一个模块而一次 AI 辅助变更可能修改十几个文件、引入多个依赖。代码量变大的同时审查时间没有成比例增加。一个 PR 里出现 800 行 AI 生成代码时人类 reviewer 实际上很难判断其中是否存在隐蔽的逻辑错误、安全边界问题或第三方代码合规问题。这也是“Who Vets AIs Code”这个问题的直接来源AI 在编写代码但没有人能对它写的每一行负责。1.3 人工 review 为什么失效盲点、疲劳与责任模糊人工审查面对 AI 生成代码时会碰到三个现实问题。第一个是盲点。如果 AI 从某个不熟悉的开源库里借鉴了算法实现reviewer 在不了解该库的前提下很难发现代码其实是“不完全正确的移植版本”。尤其是一些涉及密码学、并发控制、时间处理的功能错误非常隐蔽。第二个是疲劳。AI 生成代码通常卷幅较大。人持续阅读大量结构相似、注释较少、命名风格略有差异的代码时注意力会迅速下降。结果是前面的 bug 容易被发现后面的代码容易放行。第三个是责任模糊。团队里经常无法回答“这段代码到底是谁写的”。严格来说提交人是开发者但如果开发者只是把 AI 生成结果原样提交他没有真正理解实现后续一旦出现问题排查和修复都更困难。人工 review 不能解决责任模糊只能靠流程和规范去界定。所以让机器先完成可枚举、可重复的检查是应对规模挑战的必然选择。机器可以做依赖扫描、许可证检查、漏洞比对、异常变更检测人只需要在机器输出结果的基础上做业务判断。2. 建立“可追踪”的 AI 代码审查管线审查 AI 生成代码的第一步不是读代码而是让代码“可追踪”。只有记录代码的来源、生成方式和关联依赖后续的检查才能有据可查。2.1 先给代码增加来源元数据不做无法审查的变更如果 AI 辅助产生的代码和普通提交没有任何区别审查者就失去了判断起点。可以在团队内部约定一套元数据规范在提交信息或独立 manifest 文件中记录变更是否由 AI 生成。使用了哪个 AI 工具。触发 AI 生成的提示词摘要。本次变更引用的开源仓库、依赖包和版本。生成后是否经过人工修改。一个示例提交信息可以这样写feat: 增加接口限流模块 AI-Generated: true AI-Tool: claude-code AI-Prompt: 用一个令牌桶实现接口级限流支持 Redis 分布式模式 Source-Refs: | go.mod: golang.org/x/time/rate v0.3.0 pkg/ratelimit/token_bucket.go: 参考 github.com/example/rate-limit/blob/main/bucket.go这段信息并不是用来追责而是让后续审查者知道“这段代码从哪里来”。如果之后发现许可证问题、漏洞问题或者设计问题可以通过Source-Refs快速定位到源头。如果 AI 工具会修改依赖清单提交信息里也应该明确标注。对文件级的追踪还可以使用文件头注释。例如// AI-Generated: true // AI-Tool: claude-code // Source: https://github.com/example/snippet/blob/main/foo.go package main func main() { }这种方式在脚本扫描时非常方便。但需要注意文件头注释不应过度使用否则会产生大量噪音。建议只在以下情况添加生成逻辑超过 30 行。代码来自某个明确引用的开源片段。涉及依赖或安全敏感的算法。2.2 用提交检查和 CI 门槛拦住“不知道从哪来的代码”本地 Git Hook 可以第一时间提醒开发者补充来源信息但本地 Hook 容易被绕过所以 CI 是更强的门禁。建议在 CI 中增加一个“代码摄入审查”阶段该阶段负责收集依赖清单、检查元数据、执行静态扫描。一个 GitHub Actions 的最小示例name: vet-ingested-code on: pull_request: paths: - **/*.go - **/*.py - **/*.js - **/go.mod - **/package.json jobs: vet: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: 生成 SBOM run: syft packages . --output spdx-json sbom.spdx.json - name: 扫描漏洞 run: trivy fs --format json --exit-code 0 . trivy-report.json - name: 检查来源与许可证 run: | python scripts/check_ingestion.py \ --sbom sbom.spdx.json \ --trivy trivy-report.json这个配置演示了三个步骤先生成 SBOM 来枚举依赖再用漏洞扫描器找出已知漏洞最后用脚本判断许可证和阻断条件。注意syft和trivy的安装方式需要根据实际平台调整上面的命令只用于说明流程。CI 门禁的价值在于它不会因为开发者忘记检查而失效。只要 PR 触发了该路径机器就会执行同样的规则。团队的审查文化可以从“靠自觉”变成“靠流程”。2.3 机器负责枚举人负责判断机器审查和人工审查不应该做同样的事。分工可以按这张表来设计审查内容谁来负责原因依赖是否来自允许的仓库机器可以配置 allowlist / denylist是否存在已知 CVE 漏洞机器数据库比对比人脑可靠许可证是否兼容当前项目机器基于 SPDX 匹配规则新增依赖数量是否异常机器可通过 diff 统计算法设计是否满足业务需求人需要业务上下文并发控制是否正确人需要理解执行模型是否引入不必要的复杂度人需要架构判断安全边界是否被绕过人需要结合威胁模型机器检查负责筛选“明显有问题的变更”人工检查负责判断“设计上是否正确”。当两类任务不混在一起时人工审查的负担会明显降低。3. 用依赖预检解决摄入的漏洞与许可证问题开源代码摄入最容易被自动化覆盖的部分就是依赖审查。一个依赖进入项目后它的许可证、漏洞和维护状态都是可以查证的。把这三项做成 CI 中的自动检查是成本最低、收益最明显的起步动作。3.1 SBOM 是审查的起点先让依赖可见SBOMSoftware Bill of Materials软件物料清单是一个项目所有组件的结构化清单。它能回答一个最基本的问题这个项目里到底有哪些来自外部的代码。生成 SBOM 的工具有不少常见的有 Syft、Trivy、cdxgen。以 Syft 为例syft packages . --output spdx-json sbom.spdx.json这条命令会把当前目录当做一个文件系统扫描其中的依赖声明文件生成一份 SPDX 格式的 JSON。SPDX 是目前比较通用的 SBOM 格式之一。拿到 SBOM 后应该放入构建产物或 CI 产物而不是只放在本地。因为后续的许可证检查、漏洞审计、补丁追踪都依赖这份清单。如果原始材料没有给出具体版本落地前先确认 Syft 版本不同版本的输出格式可能存在差异。3.2 三个必查项漏洞、许可证、维护状态依赖预检至少要覆盖三个方面。第一漏洞。可以使用 Trivy 或 Grype 扫描文件系统比对 CVE 数据库输出风险等级。Trivy 的示例trivy fs --format json --exit-code 0 . trivy-report.json--exit-code 0的意思是即使扫描到漏洞也不让命令直接失败。这样做的目的是把完整报告交给后续脚本处理由脚本决定哪些漏洞允许豁免、哪些必须阻断。第二许可证。许可证决定了能否把代码用于商业项目、是否必须开源衍生代码。MIT、Apache-2.0、BSD 通常宽松GPL、AGPL 有较强的版权传染性。需要把项目不允许的许可证加入黑名单。第三维护状态。一个依赖即使没有已知漏洞也可能已经停止维护。判断方式包括最后提交时间、issue 活跃度、release 频率。这个检查可以写成一个定时任务而不是每次构建都执行。更推荐的做法是核心依赖在引入时评估一次并记录在依赖审批表中。3.3 一个最小示例用 Python 解析 SBOM 和漏洞报告下面的 Python 脚本用于演示如何把 SBOM 和 Trivy 报告整合成一条可读的风险清单。实际项目中需要根据自身使用工具的 JSON 结构调整字段名。import json import sys import argparse DENY_LICENSES {GPL-2.0, GPL-3.0, AGPL-3.0} def load_sbom(path: str) - list[dict]: with open(path, r, encodingutf-8) as f: data json.load(f) packages [] # SPDX JSON 中 packages 字段可能叫 packages 或 SPDXRef需要按实际调整 for pkg in data.get(packages, []): packages.append({ name: pkg.get(name), version: pkg.get(versionInfo) or pkg.get(version), license: pkg.get(licenseConcluded) or pkg.get(licenseDeclared), }) return packages def load_vulns(path: str) - list[dict]: with open(path, r, encodingutf-8) as f: data json.load(f) vulns [] for result in data.get(Results, []): for v in result.get(Vulnerabilities, []): vulns.append({ pkg: v.get(PkgName), id: v.get(VulnerabilityID), severity: v.get(Severity), title: v.get(Title) or v.get(Description), }) return vulns def main(sbom_path: str, trivy_path: str) - int: packages load_sbom(sbom_path) vulns load_vulns(trivy_path) print(f发现 {len(packages)} 个组件{len(vulns)} 个漏洞条目) blocked False for pkg in packages: if pkg[license] in DENY_LICENSES: print(f许可证阻断: {pkg[name]} {pkg[version]} - {pkg[license]}) blocked True for v in vulns: if v[severity] in (CRITICAL, HIGH): print(f漏洞阻断: {v[pkg]} {v[id]} {v[severity]}) blocked True if blocked: print(预检未通过) return 1 print(预检通过) return 0 if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--sbom, requiredTrue) parser.add_argument(--trivy, requiredTrue) args parser.parse_args() sys.exit(main(args.sbom, args.trivy))这个脚本的逻辑并不复杂读取 SBOM检查许可证黑名单读取 Trivy 报告阻断 CRITICAL 和 HIGH 漏洞只要有一项命中就让进程返回 1CI 随之失败。关键点在于脚本里的两个字段licenseConcluded和Severity。不同工具可能使用不同字段名。生产项目中不要把解析逻辑写死应该先打印一条示例数据确认结构后再实现。3.4 让检查结果成为合并的“门禁”脚本返回非零状态时CI 应该阻止合并。这个过程可以用 CI 的 job 状态实现python scripts/check_ingestion.py --sbom sbom.spdx.json --trivy trivy-report.json如果脚本执行失败该条 CI 任务就会失败。可以在仓库规则中要求“必须通过 vet-ingested-code 检查才能合并”。这样依赖漏洞和许可证问题就不再依赖某个人的提醒而是成为强制门槛。不过门禁不能设计得太死。完全不允许任何高危依赖存在也可能不合理。有些依赖没有替代品或者漏洞只影响特定场景。建议引入“豁免单”机制对于确实需要临时放行的依赖要求填写原因、创建工单、设定截止日期。豁免单本身也应该进入代码仓库接受审计。4. 从运行验证到接入报错排查自动化检查一旦接入 CI就会开始暴露环境、配置和工具链问题。很多团队在接入 AI 代码审查流程时遇到的第一个障碍往往不是审查规则本身而是工具不能正常跑起来。这个阶段需要知道如何运行、如何验证、如何从报错反推原因。4.1 在 CI 中运行预检脚本并读取输出把预检脚本接入 CI 后需要先做一次“人工触发”的验证而不是直接靠 PR 触发。可以在本地跑一遍同样的命令python scripts/check_ingestion.py --sbom sbom.spdx.json --trivy trivy-report.json预期输出应该包含组件数量、漏洞条目数量以及最终的“预检通过”或“预检未通过”。如果脚本报错优先检查两个 JSON 文件是否成功生成。很多时候是 SBOM 生成失败但脚本一直在报“文件不存在”。CI 中同样要保留完整输出。建议在 workflow 中增加上传报告的步骤- name: Upload report uses: actions/upload-artifactv4 with: name: ingestion-check-report path: | sbom.spdx.json trivy-report.json上传报告的目的是方便审查者查看原始证据而不是只看脚本的一句话结论。4.2 常见错误Key 缺失、模型名错误、编译环境问题当 AI 工具被引入开发流程且 AI 自动执行命令、安装依赖或调用模型 API 时项目会出现几类高频报错。以下是三个常见场景及排查方向。报错现象常见原因检查路径401 unauthorized: api_key_required调用模型或相关服务时没有携带有效 API Key检查环境变量是否设置、密钥是否过期、是否配置到了错误环境xxx is not a model this version of AI tool recognizes模型名称写错或本地客户端版本过旧核对服务商的模型列表升级客户端后重试cannot open source file sys/types.h项目构建时依赖的系统头文件缺失检查构建环境是否安装完整编译器工具链和 SDK第一种报错通常出现在 AI 客户端接入云模型服务时。它并不能说明代码本身有问题而是说明请求链路没有认证。正确的处理方式是使用密钥管理服务或本地环境变量不要把密钥写入代码库。第二种报错常见于 AI 客户端版本与服务端模型列表不一致。出现后不要盲目猜测先查看客户端帮助输出或官方模型列表确认模型名称完全一致。第三种报错是历史悠久的编译环境问题。比如在 Windows 上编译某些 C/C 项目时缺少sys/types.h通常不是代码问题而是没有安装合适的构建工具链。4.3 排错顺序从输入到输出别跳步排错时最忌直接修改代码。建议按下面的顺序检查确认输入文件是否存在。SBOM 或漏洞报告如果为空后面的脚本必然失败。确认工具版本匹配。Syft、Trivy 的新版本可能调整输出字段。确认命令执行路径正确。很多脚本报错是因为在错误目录下运行。确认环境变量是否注入。密钥类配置不要写死在 workflow 中。确认 CI 日志中的关键行。通常第一行异常就是根因不要在日志里大海捞针。确认策略是否合理。如果出现“全部依赖都被阻断”很可能是规则写得太宽松例如把许可证字符串匹配错误。这个顺序适用于大多数自动化审查流程的排错场景。5. 团队规范谁对 AI 生成的代码负责工具和流程只能解决“能不能发现风险”的问题无法解决“风险发生后由谁处理”的问题。团队规范的核心是把责任边界划清楚。5.1 责任不转移提交人始终是代码负责人无论代码是开发者手写还是 AI 工具生成最终提交代码的人都要为代码正确性负责。AI 不是法律或组织意义上的责任主体它不能站在 code review 的会议里解释设计意图也无法为线上故障承担责任。规范上可以这样约定每次使用 AI 辅助完成变更后提交人要在 PR 描述中说明哪部分由 AI 生成哪部分经过人工修改。这个要求不是歧视 AI 代码而是让审查者知道该用哪种标准去检查。如果提交人没有理解 AI 生成的代码就不应该合并。团队里可以增加一个简单问题作为提交人的自检“如果这段代码出问题你能不能不看文档就解释它的工作方式”如果答案是不能说明还没有达到合入门槛。5.2 定义 AI 不允许独立修改的红线文件不是所有文件都适合让 AI 直接修改。以下类型的文件应该进入红线清单文件类型示例建议认证与授权AuthenticationFilter、TokenService必须人工编写或人工逐行复核数据迁移migrations/*.sql不允许 AI 独立生成需要 DBA 审批支付与金额计算PaymentService、PriceCalculator需要测试用例支撑密钥管理SecretManager、CredentialProvider禁止 AI 生成防止硬编码凭据安全加密逻辑CryptoHelper必须由安全工程师审查红线清单可以用一个配置文件管理例如ai-governance.ymlai_generated_restricted_paths: - src/main/java/**/auth/** - src/main/java/**/security/** - migrations/** - src/main/java/**/payment/**CI 脚本可以读取这份配置当检测到 AI 标注的代码修改落入这些路径时强制将 PR 标记为needs-human-review。这样至少能让红线文件增加一道硬性门槛。5.3 从“读代码”改成“查证据”引入自动化审查后人工 code review 的方式也应该调整。过去 review 的重点是“这段代码写得对不对”但在 AI 摄入大量代码以后比较有效的 review 方式是“证据是否齐全”。一个合格的 PR至少要有以下证据变更涉及哪些依赖依赖为什么新增。SBOM 是否已经重新生成。漏洞扫描结果中的高危项是否已处理或豁免。新增代码是否标注了来源和生成方式。是否补充了针对核心路径的测试用例。如果 AI 修改了配置是否理解配置变更的影响面。这种“查证据”的 review 风格比逐行阅读代码更容易发现供应链风险。因为供应链风险往往不体现在单行代码的语法上而体现在依赖选择、来源信任、许可证合规和配置影响面上。6. 高频误区与发布前检查清单最后一部分聚焦实践中最容易踩的坑以及一个可以直接复制到团队文档中的发布前检查清单。6.1 三个容易踩的坑第一个坑是只扫描直接依赖忽略传递依赖。很多团队只检查package.json里列出的包却漏掉了传递依赖。一个间接依赖可能存在严重漏洞但因为它没有出现在顶层依赖文件里所以被忽略。解决方法是依赖 SBOM 或 lockfile 生成完整的依赖树。第二个坑是许可证字符串判断写死。SPDX 许可证格式并不统一同一个 MIT 可能是MIT也可能是MIT License或Expat。如果脚本只匹配MIT就会漏掉Expat。生产项目建议使用许可证解析库或者在规则表中维护多个别名。第三个坑是让 AI 生成代码后不验证直接合入。AI 可能生成调用不存在函数、版本不匹配的 API 或逻辑不完整的代码。即使代码能通过编译也不代表运行时行为正确。解决方式是约定 AI 生成的代码必须有可运行的测试用例至少覆盖正反两条路径。6.2 一个可直接使用的发布前检查清单在合入包含 AI 辅助代码的 PR 前团队可以按以下清单逐项确认是否知道新增代码来源如果标注AI-Generated: true是否补充了提示词摘要或 Source-Refs。是否重新生成 SBOM依赖清单是否仍与代码库一致。是否完成漏洞扫描Critical / High 漏洞是否处理。是否检查许可证新增依赖是否与项目许可证冲突。是否更新 lockfile是否因为 AI 的依赖安装动作产生了意外变更。是否检查红线路径认证、支付、迁移等文件是否被 AI 直接改动。是否补充测试核心逻辑是否有自动化用例。是否区分了人工修改部分PR 描述中是否说清哪些是 AI 生成的代码。清单不需要很长但每一条都要能被机器或提交人明确回答。6.3 生产环境还需要补齐的周边保障如果这套流程已经在开发环境跑通进入生产环境前还需要补充几个方面配置外置化API Key、数据库连接等敏感信息不要出现在代码仓库和 CI 日志里。SBOM 归档每次发布时把 SBOM 与制品一起保存方便事后审计和漏洞回溯。补丁追踪当某个依赖被曝出新漏洞时能快速定位到哪些发布版本受影响。回滚方案AI 生成代码如果导致线上故障团队要有快速回滚到上一个稳定制品的方式。监控与日志对 AI 生成的模块重点关注错误率、耗时和资源占用指标。版本兼容AI 工具和扫描工具的版本升级要纳入变更管理避免工具链本身失效。这些保障不是 AI 特有但在 AI 代码摄入频率提高后它们的优先级会显著上升。回到最初的问题谁审查 AI 的代码。答案不是一个固定的角色而是一套由元数据、CI 规则、依赖扫描、人工复核和团队规范组合起来的机制。机制运行起来之后AI 生成代码的能力仍然能够保留但它进入了仓库的速度会被人和机器共同设计的门禁控制住。对于团队来说最有价值的下一步不是争论 AI 该不该写代码而是先把“AI 写的代码从哪里来、是否安全、由谁负责”这三个问题做成每天都自动运行的检查。