黑盒AI代码正成为一项责任：为什么溯源是下一个合规层

在软件发展历史的大部分时间里，问责是隐性的。代码由人编写、由人理解，一旦出了问题，人也能够解释它为什么会这样做。从一行代码追溯到某个决策、某个人的脉络始终存在，即便从来没有人把它写下来。

AI 悄无声息地打破了这种状况。当代码库的大部分内容由模型生成时，那条隐含的脉络便消失了。大部分代码并非出自人手，也没有人能完全理解全部代码。当监管者、审计员或法院问起"为什么这段代码会这样做？是谁批准的？"时，诚实的回答越来越多地变成"我们也不确定"。这不是技术差距，而是责任风险。

解决之道不是停止使用 AI，而是让 AI 生成的代码有意地变得可追溯。Provenance（溯源）——一份可验证的记录，标明某次变更满足了哪份 spec、由哪个模型生成、由哪位真人审核接受——正在成为下一个合规层。现在就开始构建它的团队，将能把 AI 代码送入受监管的市场；不构建的团队，则只能困于解释自己都无法交代的代码。

是什么让黑盒 AI 代码成为责任？

黑盒 AI 代码，是指那些能正常运行、却没人能完全解释、也无法追溯到具体决策和所有者的代码。当这样的代码出现故障、违反规则或造成伤害时，你无法说明它为什么会这样运行、它本来应该做什么、又是谁批准放行的。监管者要求可追溯性，这构成法律责任；你无法推理自己不理解的代码，这构成安全责任；没人能理解的系统将变得无法安全地修改，这构成运营责任。

危险不在于 AI 写出有缺陷的代码，而在于 AI 大规模地产出不透明的代码——正是这种不透明，把小 bug 变成了无法回答的问题。

当一个人手写某个函数时，背后有你可以还原的意图；而当模型根据一段早已不存在的 prompt 生成它、又在匆忙中被审查通过时，意图便消失了。把这种情况放大到整个代码库，你得到的就是这样的系统：一直正常工作，直到某一天忽然不行了，而在它崩溃之后，没有人能自信地解释原因。

监管者已经注意到了，法院也是如此。"是 AI 干的"这类辩护正在被堵死，举证责任转移到了部署系统的一方，要求他们证明系统本应做什么、由谁负责。没有记录，你就无法满足这样的举证要求。

代码溯源到底是什么？

代码溯源，是一份附加到每个 AI 生成变更上的可验证记录，回答它从何而来、由谁负责。一份最小可用的记录应包含：该变更所满足的 spec 版本、生成它的模型与提供商、产生它的 prompt 或任务、审查并接受它的人，以及它通过的测试。它把一段匿名的生成代码，变成了一件拥有清晰谱系与明确所有者的可审计产物。

溯源，说到底就是把"这段代码从哪里来"的答案，以日后可以验证的方式写下来。

真正有用的溯源是具体的。对于 agent 产生的每一个变更，你都要记录：它为满足哪份 spec 而构建、编写它的确切模型与提供商、触发它的任务、接受它的人，以及它通过的检查项。这五个事实，随变更一并留存。

只要捕获得当，溯源就不是最后才额外补上的工作。在 spec 驱动、审查把关的工作流中，这些事实在每个交接节点上本就存在。你只需把它们发出来并保存下来，记录便会作为现有开发流程的副产品自然累积。

为什么溯源正在成为合规要求？

因为法规正在要求 AI 系统具备可追溯性，而代码正是系统的一部分。欧盟《AI 法案》的高风险义务自 2026 年 8 月 2 日起生效，要求系统具备防篡改的审计追踪、记录输入与决策、留存记录，并内建人类监督。文档是监管者首先检查的对象。产品责任规则正越来越多地把软件和 AI 视为产品并适用严格责任，而新近的法律也禁止以系统的自主性作为抗辩理由。溯源，就是你拿出这些法规假定你本应握有的证据的途径。

到了 2026 年，这已不再是纸上谈兵。

欧盟《AI 法案》的主要高风险义务将于 2026 年 8 月 2 日起正式执行，而这些义务正是围绕可追溯性展开的。系统必须生成相关事件的审计追踪，记录足以还原行为的信息，保留这些记录，并具备一开始就设计在内、而非事后补加的人类监督。关键在于，文档是监管者首先检查的对象；只有当文档记录不足以说明问题时，才会触发更深入的检查。如果你的 AI 生成代码没有文档化的谱系，那么你的文档记录从一开始就是不合格的。

责任层面的变化进一步强化了这一点。软件和 AI 正越来越多地被视作可能存在缺陷的产品，由此打开了严格责任的风险敞口；同时，新法律也堵死了把责任归咎于系统自主性的选项。在这样的环境中，能够证明某次变更满足了哪份 spec、由谁批准的团队，是有防御能力的；做不到的团队，则完全暴露在风险之中。溯源，正是这些规则假定你早已维护好的证据层。

实践中如何捕获溯源？

在工作流的每一个环节发出溯源记录，并让它成为变更本身的一部分。生成一条包含 spec、模型、任务、审查者和测试的结构化记录，把它附加到提交上，最好再签名使其防篡改。然后以"记录是否存在"作为合并的门槛，让没有谱系的 AI 生成变更根本无法落地。由于这些事实在 spec 驱动、经过审查的流程中早已存在，溯源便成为流水线自动产出的结果，而非事后手工补写的文书。

一旦你认定这条记录必不可少，具体操作其实非常简单。

首先，定义记录——它是整个机制赖以运转的核心构件。

{
  "change": "a3f9c21",
  "spec": "specs/payments.md@v4",
  "generatedBy": { "model": "claude-opus-4-x", "provider": "anthropic" },
  "task": "implement idempotent refund handler per payments spec",
  "reviewedBy": "engineer:jdoe",
  "testsPassed": ["refund.idempotency", "refund.authz", "refund.limits"],
  "timestamp": "2026-06-29T10:14:00Z"
}

其次，把它绑定到变更之上，并使其防篡改。将记录附加到提交并签名，使谱系在事后无法被悄悄改动。

## 将溯源附加到提交并签署证明
git commit --trailer "Provenance: $(sha256sum provenance.json | cut -d' ' -f1)"
cosign attest --predicate provenance.json --key cosign.key "$ARTIFACT"

第三，让它成为强制要求。用一道 CI 关卡拦截任何缺少完整有效溯源记录的变更，把这项实践从"愿望"变成"现实"。

## 没有完整有效谱系的 AI 生成变更不得合并
- run: provctl validate provenance.json --require spec,model,reviewer,tests
- run: provctl verify-signature provenance.json --key cosign.pub

这就是完整的闭环：定义记录，绑定并签名，强制执行。只要做一次，之后每一个变更都会自带可问责的记录。

为什么溯源也是一种安全控制？

因为溯源就是 AI 生成代码的供应链完整性保障。它精确地告诉你每一份产物由什么生成、依赖了什么，这正是你发现幻觉（hallucination）或恶意依赖、把漏洞归因到引入它的那次变更和那个模型、并证明代码在审查后未被篡改的方法。防篡改的签名谱系，同时就是你的事件响应线索：一旦出了问题，你可以在几分钟内——而不是几天内——追溯到确切的变更、spec、审查者和测试。

溯源与安全，其实是同一件事的两个视角。

一份签名记录，写明了某个变更由什么生成、引入了什么依赖，这正是 AI 时代捍卫软件供应链所必需的。它让你注意到模型凭空发明的陌生依赖，让你把漏洞追溯到引入它的那一次具体生成，也让你证明交付上线的正是审查通过、未被篡改的内容。

当事故发生时，这份记录是你最快控制局面的路径。你无需在成千上万个 AI 生成的变更中猜测究竟是哪一个造成的，只需查询谱系，就能找到对应的变更、它声称满足的 spec、生成它的模型，以及批准它的人。溯源让"我们正在调查"变成"我们已经知道"。

为什么溯源是竞争优势，而不只是成本？

因为合规正在成为采购的硬性要求，而溯源正是让你通过筛选的东西。金融、医疗、政府和关键基础设施领域的受监管买家，在签约之前会越来越多地要求你拿出证据，说明 AI 生成代码是如何生产、如何被管控的。能够按需出示签名谱系的团队可以赢得订单，做不到的团队连门都进不去。尽早构建，溯源就不再是额外成本，而会成为一座护城河：它是信任的证明，为你打开那些对仍在交付黑盒代码的人紧闭着的市场。

本能的反应是把溯源当成一种税负；而走在前面的团队，则把它当成打开市场的渠道。

随着 AI 生成代码进入受监管的系统，这些软件的买家自身也要向监管机构负责，于是他们会把同样的要求传导给你。采购环节的问题就变成了："给我们看看，这段代码是如何生产、如何治理的？"一份干净且签名完整的谱系，就是"可以"；沉默，则意味着出局。

这就是"合规即优势"的关键一招：你为满足监管而建立的纪律，最终成为赢得合同的资质。当竞争对手还在争相拼凑一份并不存在的文档记录时，你已经交出审计材料，直接进入签约阶段。早期构建的溯源不是成本中心，而是你能够留在牌桌上的原因。

团队应该从哪里开始？

从把溯源设为 AI 生成代码的一项强制且自动的要求开始。定义最小记录项：spec、模型、任务、审查者和测试；在 spec 驱动、审查把关的工作流的每一个交接点自动发出它，让记录随之自然累积；为它签名以防篡改，并以它的存在作为合并的门槛；按你所属监管框架的要求留存记录；然后把这份谱系同时用作合规证据和事件响应线索。

以下是一份可供起步的简短清单：

• 你是否为每一个 AI 生成的变更，都定义了包含 spec、模型与提供商、任务、审查者和测试在内的最小溯源记录？
• 这条记录是否由工作流自动生成，而不是事后手工补写？
• 记录是否已附加到变更并经过签名，使谱系无法被篡改？
• CI 是否会拦截任何缺少完整有效溯源记录的 AI 生成变更？
• 记录是否留存了足够长的时间以满足你所处监管体系的要求，并支持审计导出？
• 今天，你是否能把任何已上线的变更，追溯到它的 spec、模型、审查者，以及它通过的测试？

如果这份清单你能全部回答"是"，那么你的 AI 生成代码就是可辩护的：对监管者可解释、在事故中可追溯、对买家可证明。如果连最后一个问题都答不上来，那你就是在交付黑盒代码——责任已经在不断累积。

让你的 AI 代码为自己作答

这个时代令人不安的转变在于，我们现在交付的代码数量庞大，却没有任何单个人写过、也没有任何单个人能完全理解。这一趋势不会逆转。可以改变的，是这些代码能否为自己作出解释。

黑盒 AI 代码之所以是责任，恰恰因为它做不到这一点。它能正常工作，直到有一天被质疑，然后就再也没有任何东西可以指认。溯源，就是用一条显式的、实际上更好的线索，去取代被 AI 抹去的那条隐含线索：它经过签名、可以查询、内容完整——这是人类记忆永远无法做到的。

法规正在落地，责任真实存在，买家也开始发问。那些把溯源视为下一个合规层、并将其内建到代码生成流程中（而不是事后补救）的团队，将把义务转化为优势。在一个 AI 撰写代码的世界里，能够证明代码的来龙去脉，不是官僚主义，而是"可信代码"的新定义。

构建溯源层——这条让 AI 生成代码可解释、可追溯、合规的签名谱系——正是把监管负担转化为竞争优势的治理工作。而这，正是我们在做的事。

• 原文链接： medium.com/@ancilartech/...
• 鸿途知科网 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～