AI编程助手写的代码，谁来签名？

最近GitHub上有个挺有意思的功能内测：提交代码的时候可以加上"Co-authored-by: Claude"或者"Co-authored-by: Copilot"这样的标识。

看起来挺正规的对吧？就像真正的协作开发一样。

但我们来想一个问题：Git的作者信息是可以随便改的。任何人都能在自己的电脑上执行两条命令，然后假装成Linus Torvalds提交代码。Git本身从来不会验证"你说你是谁，你真的是谁"。

所以这个"Co-authored-by"本质上就是一个文本标签。它可以被随意设置，可以被伪造。

问题在于，这个标签正在被用于一些它不该承受的信任决策。

当标签变成"通行证"

AI编程助手刚出来的时候，大家主要用它写文档、做实验。现在不一样了——它们直接改生产代码、合并PR、修改基础设施。

这个时候，"这段代码是谁写的"就不再是可有可无的信息了。

很多团队的CI/CD流水线会根据提交者来做判断：

• 某些作者可以跳过代码审查直接合并
• 可信贡献者的PR会被标记为低风险
• AI审查工具会给"老熟人"更高的权重

所有这些判断，都建立在"提交者声称自己是谁，就是谁"这个前提上。

但这个前提本身是不成立的。

研究者已经演示过这个攻击面：只要改几行git配置，就能在自动化流程里冒充可信贡献者。没有漏洞利用，没有恶意代码——只是伪造了一个名字，系统就信了。

这不是Git的bug。Git的设计本来就是这样的——谁都可以声称自己是谁。GPG签名就是来解决这个问题的。

真正的bug是我们开始把一个可以随便填的字段当成信任凭证。

为什么这个问题现在开始严重了

很多创业公司现在靠AI助手干活，每周的提交记录里可能有一半都是AI写的。

你的流水线可能已经在信任这些AI提交者了——虽然你不一定意识到。

更复杂的是多智能体工作流。现在的开发流程经常是链式的：一个AI写代码，一个AI做审查，还有一个AI负责部署。每个环节都可能声称自己是"作者"。

没有加密签名，你就是在无条件相信AI说的话。

就像你不会因为一张手写的"CEO已批准"字条就放行一笔采购，但你却在因为一行"Co-authored-by: AI"的文本就信任一段代码进入生产环境。

解决方案：让签名有实际意义

关键不是去掉"Co-authored-by"这个标签——而是要让标签背后的声明可以被验证。

思路是这样的：

给每个AI编程助手配一把钥匙。 每个助手实体有自己的密钥对。代码提交用私钥签名，验证的时候用公钥验证。这时候"Co-authored-by"变成了一条可以查证的声明，而不是一句空话。

具体怎么落地？

人类可读的部分还是有用的。 标签上写着"Claude 3.5写的这段代码"，人看还是需要看的。但现在这层信息变成了一道"待验证的声明"，不再是"直接信任的标签"。加上模型版本、会话ID、提供商这些结构化信息，审计的时候能追溯到具体的上下文——"这段代码是哪次对话产生的"。

SSH提交签名是现成的实现方式。 GitHub和GitLab现在都原生支持了。每个AI助手实体持有一对密钥，私钥存在运行环境里。它签名的每一条提交，都经过密码学验证。任何人拿到公钥都能确认：这条提交确实来自这个助手，因为只有它持有对应的私钥。

生产环境要上硬件密钥。 私钥放在专用安全芯片里，AI运行时环境和密钥隔离。这样就算运行AI的容器被攻破，攻击者也拿不到签名密钥。密钥永远不会离开安全区，AI只是调用它来签名。

签名能带来什么？

有了密码学意义上的出处证明，很多之前做不到的事情现在可以做了。

审计日志有实际效力。 合规要求你回答"这段代码是哪个模型生成的"，你能给出密码学可验证的答案。这个答案任何人都能查证，不是靠"我相信系统没改过记录"。

信任可以分级流转。 以后可以设计这样的系统：代码质量有记录的模型产出的代码，获得更宽松的审查流程；来源不明的代码走更严格的检查。这个机制需要先有可信的出处层，否则无从谈起。

知识产权边界能划清楚。 很多开发者同时做开源和商业项目，AI工具的服务条款有时候模糊。如果代码有密码学签名，就能清楚地区分"我写的"和"AI帮我写的"。公司要求"不要把工作代码提交到公开仓库"，有签名的代码才能被自动化检查合规性。

模型评估有数据支撑。 把签名主体和代码质量指标关联起来，你才能知道哪个模型、哪家提供商、哪种提示词策略真的产出了更好的代码。无法衡量的东西无法改进，而无法验证的归属关系也无法用于衡量。

AI需要身份基础设施

这个问题背后是一个更大的缺口：AI编程助手正在被整合到关键基础设施里，但我们还没有为它们准备好身份和信任体系。

人类有PKI，Web服务有OAuth，敏感操作有硬件令牌。但对于写代码、改工单、布署变更的AI助手？大家基本就是在靠一行"我是我声称的那个AI"的文字。

这不是说AI助手不好——它们在做我们让它们做的事。这是系统设计的缺失。

当AI助手成为开发流程里的一级参与者，它们需要一级参与者的身份基础设施。

对于开发团队来说，这意味着开始像对待服务账号一样对待AI助手主体：每个AI助手需要自己的凭证、限权范围、审计日志、密钥轮换策略。代码签名只是这套基础设施的可见部分。

对于平台和工具开发者来说，这意味着在审查流程里加上签名验证。不要信任提交者字段——去验证签名。把未验证的元数据当成未验证的输入：该清理就清理，该忽略就忽略。

"Co-authored-by"这个标签不会消失，它作为人类可读信息是有用的。但把它当成信任凭证——尤其是在做信任决策的时候——是这个行业不能再忽视的风险。

工具已经有了。标准在成熟。唯一的问题是，我们会不会等到出了大事才来建这套基础设施。

通常来说，非得出了事才会重视。希望这次能不一样。