AI 生成代码的信任链终于有解了——加密溯源三件套把代码「谁写的」这件事彻底变了

AI 生成代码的信任链终于有解了——加密溯源三件套把代码「谁写的」这件事彻底变了

写完了三年代码，今天才发现一个尴尬的事实：git log 记录的是 git commit 是谁跑的，不是代码是谁写的。

这个差距在 2024 年还无所谓——那时候 AI 只是自动补全，写完人类还会 review 一遍。但到了 2026 年不一样了：行业数据显示，42% 的代码已经是 AI 生成的（Sonar State of Code 2026），Claude Code 这类工具已经从「辅助」变成了「主力」，很多团队的 PR 合并代码里 AI 贡献了大多数行数。

问题是：谁来证明这段代码是 AI 写的还是人写的？git log 说不清楚。

这件事在过去一年只是灰色地带，但 2026 年 8 月它变成立了。

EU AI Act 生效把这件事逼出了 deadline

欧盟 AI Act 第 50 条在 2026 年 8 月 2 日正式生效，虽然它针对的是面向用户的 AI 内容（聊天机器人、深度伪造），但企业合规链条的传导比想象中快：当一家公司开始需要证明 AI 生成的市场文案有溯源记录时，它的采购部门就会开始问：「你们软件里的代码，有多少是 AI 写的，有没有记录？」

这不是空想。SOC 2 和 ISO 27001 的审计员已经开始在问卷里直接问 AI 使用情况。GitHub 的企业客户安全评估里，也开始出现「代码库里的 AI 贡献比例」这道题。「我们估计大概 60%」这种答案，过不了审计。

与此同时，美国版权局的态度也很明确：纯 AI 生成的代码不受版权保护，AI 生成的部分必须被识别和声明，才能保护人类实际创作的部分。这意味着：如果某天有人告你代码侵权，说「这段代码是我们的」，你需要能说清楚这段代码是 AI 写的还是人写的。

这个需求，在 2026 年 8 月之前只是讨论。到了现在，它是真实发生的事。

三件套把「谁写的」变成了可验证的事实

解决这个问题的思路很直接：给 AI 生成的代码加一层密码学信封，让它不可篡改、可追溯。这套体系有三个层次的工具，分别对应不同的需求深度。

第一件：protect-mcp，给 Claude Code 加上签名前的守门员

protect-mcp 是 Claude Code 的一个插件，在每次工具调用（bash、edit、write）前后各加一层钩子。执行前，用 AWS Cedar 策略引擎做权限评估——比如设定「只允许 git/npm/ls 这些命令」「禁止 rm -rf」——Cedar 返回 deny 就直接阻断执行。执行后，用 Ed25519 私钥对这次调用的输入、输出、时间戳做签名，生成一张收据（receipt）写入本地 receipts 目录。

收据是 JCS 规范序列化的，内容包含工具名、输入哈希、输出哈希、策略摘要、时间戳，还有一个唯一请求 ID（来自 Anthropic API 的真实响应头）。收据之间是哈希链串联的，后一张收据包含前一张的哈希，所以任何一张被篡改，后续全部失效。

整个验证链不需要服务器，不需要网络电话，不依赖平台方——只要有公钥和 receipts 目录，任何人可以在任何时候离线验证这条链是否完整。

这个工具解决的是：谁来证明 Claude Code 做了哪些操作，策略是否真的被执行了，结果是否被改过。

第二件：agentmark，把 AI 生成的代码变成可验证的「出生证」

agentmark 是专门给 AI 代码管道设计的加密溯源工具。它的工作方式很有意思：当你给 LLM 提交一个任务时，agentmark 会先生成一个唯一的 challenge token，嵌入到 prompt 里发给 LLM。LLM 的回复里必须包含这个 token，agentmark 用它来证明：这个模型处理的是这个特定任务，不是重放，也不是伪造的。

同时，agentmark 捕获 API 返回的 request_id（每个云端 API 调用都有唯一标识），并对 LLM 的原始输出字节计算 SHA-256 哈希，与最终 commit 的代码哈希对比——如果有一个字节被手动改过，哈希就对不上。

最后用 Ed25519 私钥给整个 manifest 签名，manifest 里包含版本、模型、request_id、challenge token 的回显结果、输出哈希和签名，这整段内容直接写进 commit message。

所以 commit message 本身就成了一个可独立验证的证明文件。任何人拿到这个 commit，可以用公钥验证 manifest 签名是否有效，可以用 request_id 在 API 提供商那里核对这次调用是否真实发生，可以用 challenge token 证明模型确实见过这个任务，可以对比输出哈希确认代码没有被改过。

agentmark 自己也坦承了几个诚实限制：比如如果一个人完整地跑完了整个合规管道然后手动提交，工具无法区分他和 AI 的区别——因为他们做的是完全相同的事。另外 LiteLLM / Bedrock / Azure 等代理层会修改响应导致哈希失效，这些需要在架构上规避。

这个工具解决的是：谁来证明这段代码是走过了这个特定的 AI 管道，是真实 API 调用产生的，没有被人在中途篡改过。

第三件：ForgeProof，把溯源变成企业合规基础设施

ForgeProof 面向的是更大的组织。它把代码溯源这件事做成了企业级产品：Ed25519 签名 + 哈希链 + GitHub 深度集成，并且支持在溯源层之上叠加策略引擎。

策略引擎可以定义：哪些模型被允许提交生产代码（只有 GPT-5 和 Claude Sonnet 5），哪些司法区域被允许（涉密代码库要求模型在美国区域内运行），以及最关键的一条——生成代码的模型不能同时是审计它的模型（OpenAI 生成的代码必须由 Anthropic 来审计）。

不符合策略的 attestations 在进入溯源链之前就被拒绝，决策被记录下来，可以导出合规报告给审计人员。ForgeProof 的报告可以直接生成 PDF 证书，展示某季度所有 attestations 均来自美国区域内模型、经独立审计。

这个工具解决的是：谁来保证整个组织的 AI 代码治理策略被实际执行了，而不是只写在文档里。

三个工具怎么选

实际落地可以分三步走，不需要一次性投入。

第一步，今天就能做：在 Claude Code 项目里装 protect-mcp，配置 Cedar 策略把高危命令限制住，同时开启 Ed25519 收据签名。这一步成本最低，收益最直接——你至少知道每次 Claude Code 执行了什么操作、结果有没有被改过。

第二步，如果你已经在用 AI 代码管道提交到 GitHub：集成 agentmark，它会让你所有的 AI 生成 commit 带上密码学证明。commit message 本身就是证据，不需要额外的数据库或服务器。

第三步，如果你在受监管行业（金融、医疗、国防供应链）：直接上 ForgeProof 或者自建类似的策略 + 签名基础设施，配合合规报告导出。审计人员要的不是截图，是可离线验证的加密证据。

这件事对前端工程师意味着什么

可能有人觉得这是安全团队或者法务团队的事。未必。

你日常用的很多 npm 包，今天已经有一部分是 AI 生成的——尤其是在一些相对小众的工具库或者个人维护者增多的场景里。如果某天你依赖的一个包被发现有后门，你需要能说清楚：这个包是什么时候、以什么方式进入你的依赖树的，AI 在其中扮演了什么角色。

另外，如果你用 AI 编程工具帮团队提升产能，采购方或者客户的安全评估很可能会问你：「你们团队用的 AI 编程工具，是否有记录哪些代码是 AI 生成的？」这个问题现在没有统一答案，但有答案和没有答案，在信任上差距很大。

三件套都在快速演进。protect-mcp 是开源项目，agentmark 和 ForgeProof 都已有生产案例可用。2026 年接下来的几个月，随着 EU AI Act 合规审查开始落地，这个问题不会消失，只会越来越被认真对待。

你现在配的每一次 AI 编程工具调用，都是在给未来的某份审计报告写草稿。与其等着被问到时翻 git log，不如现在就搭好这层信任基础设施。