从Git提交追踪AI代码来源并生成物料清单

dev.to · AI#软件物料清单#AI编程#代码溯源

Editor brief · 编辑速览

文章以AT&T供应商条款为例，介绍扫描提交中的AI署名和会话链接，生成CycloneDX或SPDX文件的方法。这些记录只能证明AI参与过提交，无法精确识别其编写的代码行。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

客户要求交付软件物料清单（SBOM）时，可能还会追问：代码用了哪款 AI 工具，工具是否获批？作者拿 AT&T 的供应商条款做了一次真实仓库实验，发现 Git 提交记录能提供部分证据，却无法证明每行代码的来源。

这篇值得读的地方，是把「披露 AI 使用」拆成了可执行的检查，也明确划出了边界：生成合规格式的文件，距离完整、可靠的来源证明，还有一段路。

据原文，AT&T 的供应商 AI 条款 v2.1（2025 年 10 月）要求：如果供应商代码使用 AI 工具生成，首次交付及后续每次发布都要提交 SBOM，其中包含「AI Solution」的说明。AI 生成的工作还要标记为「AI Generated」。

此外，每款 AI 工具都必须事先获批；使用未经批准的工具，AT&T 没有义务为相关工作付款。

这把问题从「开发者喜欢用什么工具」，推到了「交付时能否拿出使用记录」。作者找到的 Lockheed Martin 分包条款副本，只要求按需提供 AI 生成内容的可追溯信息，表述更宽泛。AT&T 是作者找到的措辞如此具体的买方，不能据此推断整个行业都已采用同样要求。

作者选择从提交记录取证，因为不少编程代理会留下标记：

作者编写的 ai-code-sbom 是单个 Python 文件，除 Python 运行环境外只需要 git。它扫描一个发布范围内的提交，输出 CycloneDX 或 SPDX 文件及纯文本摘要，还能根据工具和提供商允许列表执行检查，发现列表外的记录就失败。

实测使用公开仓库 pyrail，从 v0.4.1 到 v0.5.0，共 151 次提交，其中 8 次带有 AI 标记：Copilot coding agent 和 Claude Code 各出现在 5 次提交中，有 2 次 squash merge 同时带着双方标记，因此不是 10 次独立提交。

这些提交涉及该版本 22 个变更文件中的 20 个。作者配置「只允许 Claude Code」后，检查失败，并列出了 5 次 Copilot 提交。这是实验最实用的结果：交付之前，可以先发现记录中不符合工具政策的使用情况。

但不能直接把提交里的代码都算给 AI。带标记的提交新增了 2,028 行，整个版本新增了 8,354 行。2,028 行只是这些提交中可能由 AI 生成的新增行数上限，不能当作实际生成量。

接下来是标准怎么装下这些信息。

按作者的说明，CycloneDX 和 SPDX 都还没有公认字段，完整表达「代码由 AI 工具 X、模型 Y 编写」。作者把工具放进 CycloneDX 的 formulation，用于描述版本如何被制作出来。若放进顶层 services，则会表达产品运行时调用 AI 服务，含义就变了。

在 SPDX 中，作者把它表示为 Tool，通过包的 usesTool 关系关联。

两种输出都通过了官方 schema 校验，但这是作者自行选择的映射。格式合法，只能证明文件符合结构要求，不能证明客户认可它的证据含义。

原文还指出，模型、提供商调用路径及证据观察方式，都缺少相应的公认表达。比如同样使用 Anthropic 模型，经 Anthropic direct、Bedrock 或 Vertex 调用，交付时可能需要区分，现有方案却还没有完整解决。

我认可作者优先收集明确记录的选择。它能回答「哪些提交留下了哪款工具参与的证据」，也能把允许列表检查接到发布流程里，比凭代码风格猜测更贴近客户询问的工具和提供商身份。

但这套方案的前提是提交标记足够可靠。编辑器内联建议可能不留痕迹，标记可以关闭，也可能在 squash 时丢失。空报告只能表示没找到证据，不能证明没用 AI。作者主动排除了检测猜测，因为它们无法给出条款要求的工具或提供商身份。

原文没有提供漏检率、误检率，也没有买方验收结果。仓库实验验证了扫描和策略检查能运行，没有验证它足以满足合同。相比人工填报，提交扫描有自动化优势；相比工具审批记录，它又缺少完整的授权上下文。两者更适合互相补充。