隐形作者问题：当 AI 编写大部分代码时如何进行 Git Blame

当生产环境出现故障时，工程师们首先会想到 git blame。提交哈希值指向 PR，PR 指向作者，而作者则指向上下文——Slack 讨论串、设计文档，或者是记住了代码初衷的那个大脑。这条链路是团队排查事故、进行安全审计以及积累机构知识的方式。它假设每一行代码都有一个理解自己在做什么的人类作者。

AI 已经悄然打破了这一假设。目前约 46% 的代码由 AI 生成，在 Java 团队中，这一比例甚至超过了 60%。这些代码中的大部分都不携带任何有意义的溯源元数据。git blame 链条依然在运转——只是现在它终止于一名开发者，他们接受了一个可能并未完全理解的建议，而且没有记录提示词、模型版本或 AI 拒绝的备选方案。

这就是隐形成员问题：软件工程中的问责体系是为人类作者设计的，而它在大规模应用中正在失效。

问责链条如今已成死胡同

传统的 git blame 之所以奏效，是因为署名作者拥有该项变更的心智模型。他们记得当时的权衡，能解释为什么要选择这种方案而不是另一种。他们能回答生产事故中至关重要的问题：“你当时认为这段代码是在做什么？”

当 AI 编写代码时，这种心智模型便缺失了。提交代码的开发者审核了它——可能只是在时间压力下草草看了一眼——但并不是代码的作者。调查发现，66% 的开发者表示，修复 AI 生成的代码所花费的时间比编写时节省的时间还要多。一项针对企业级代码库的大型研究发现，AI 生成的代码包含的高严重性漏洞比人类编写的代码多 2.5 倍，且泄露凭据（secrets）的概率是基准水平的两倍。

当这些漏洞出现时，责任归属变得模糊不清：53% 的工程师责怪安全团队，45% 责怪接受建议的开发者，42% 责怪审批 PR 的人。每个人都指向别处，因为没有人拥有明确的所有权。

一个关于治理失效的具体例子：某主流 IDE 厂商发布的一个版本，即使在 AI 辅助被禁用的情况下，也会自动在提交中添加 Co-authored-by: 属性。虽然回滚出现在下一个版本中，但这反映出目前围绕 AI 作者身份标注的工具链是多么地随意。这个领域目前主要靠惯例和善意，而非协议在运行。

无人谈及的知识流失

问责制只是问题的一部分，更深层次的问题是知识流失。

工程师传统上通过阅读代码来获取系统专长——翻阅遗留层，琢磨某个抽象存在的原因，理解前任工程师的思维轮廓。这种缓慢的积累正是团队建立机构知识的过程，而机构知识能让事故响应变得迅速。当你读过三次认证中间件的代码，当令牌（token）开始失效时，你就知道该往哪看。

AI 生成的代码切断了这一循环。代码库在增长，测试套件通过了，功能发布了。但没有人对正在构建的系统拥有心智模型。43% 的 AI 生成代码变更需要在生产环境中进行调试。当这些事故发生时，负责的工程师越来越多地是在诊断那些无人设计的代码故障——这些代码产生于一系列的提示词和确认操作，没有任何人类思考过其中的边缘情况。

这是一种不会出现在 Linter 或类型检查器中的技术债。它只会在凌晨两点浮现，此时那位“本该了解情况”的高级工程师不在，而团队正盯着一个没人记得写过的模块里的堆栈跟踪信息发呆。

评审瓶颈正在恶化而非好转

自然的反应是加大对代码评审的投入。但数据表明情况并不乐观。

AI 将代码编写速度提高了约 55%，但在 AI 使用密集的团队中，PR 评审时间增加了 91%。高级工程师评审 AI 生成的建议平均需要 4.3 分钟，而评审人类编写的代码只需 1.2 分钟。智能体（Agentic）AI PR——即 AI 自主进行了一系列更改——的响应时间比无辅助 PR 长 5.3 倍。工程师们正在主动拖延评审 AI 生成的代码。

其中的认知动态值得深思。受过训练、能发现人类代码错误的评审员寻找的是熟悉的故障特征：缺失的空检查、差一错误（off-by-one）、循环中的边缘情况。AI 代码在语法上看起来很整洁，它通过了自动化检查，符合预期的模式。这产生了一种“模板盲视”：评审员粗略扫过那些看起来正确的表面，而没有审视其内在逻辑。AI 不会犯低级错误，所以评审员不再寻找低级错误，进而错过了那些非显而易见的错误。

结果就是，生成代码带来的速度增益在评审阶段消失殆尽，每个拉取请求（PR）的事故数增加了 23.5%，高级工程师的时间被他们认为毫无成就感的评审工作所占据。这不是一种可持续的资源分配方式。

溯源基础设施应有的样子

行业正开始构建工具，尽管共识远未达成。

在过去的 18 个月中，出现了两种相互竞争的方法：

提交级注释工具如 git-ai 使用 Git Notes 将归属元数据附加到提交上，而无需修改提交历史。它们追踪哪些行是生成的，哪些是人类编写的，是由哪个模型生成的，并将这些信息通过 PR 审查带入生产环境。这种方法非常轻量——不需要新文件，也不需要仓库配置——但依赖于代理准确地自我报告其创作的内容。

边车溯源文件采取了不同的方法。它们不将元数据嵌入 Git 基础设施，而是作为人类可读的 Markdown 文件存在于 .provenance/ 文件夹中，每个概念性变更对应一个文件。每个文件包含对话历史、被拒绝的备选方案以及所采取方案的理由。其目标不仅是问责，还在于可解释性——未来的工程师可以重建作者（或代理）的推理过程。

一项更具雄心的标准，由包括 Cursor、Cloudflare、Vercel 和 Google 在内的联盟支持，引入了基于 JSON 的追踪记录，将代码范围与其起源对话联系起来，并在行粒度上将贡献分类为人类、AI、混合或未知。

关键问题：这些方法互不兼容。采用一种方法的团队无法在不进行转换的情况下读取另一种方法的输出。在标准出现之前，溯源元数据在每个团队、每个工具和每个仓库中都是孤立的——跨仓库查询（这对供应链安全至关重要）仍然无法实现。

现行有效的团队实践

在工具层趋于成熟的同时，工程团队已经开发出值得立即采用的操作模式：

机器人担保：任何由 AI 代理创作的 PR 都需要一个指定的人员为其承担明确责任——不仅是 “由其合并”，还需要有注释声明其已阅读并理解了该变更。这并不能解决知识断层问题，但它填补了问责制的空白。

双路径审查：将机器可检查的部分与人类判断层分离。AI 处理第一轮验证——密钥检测、lint 检查、基础漏洞扫描。人类则将审查周期集中在逻辑、架构和安全设计上。这减轻了审查者的认知负荷，同时又不会降低人类对关键决策的审查质量。

提示词日志：重度使用 AI 的工程师会记录重大变更背后的提示词和对话上下文。一些团队正将其纳入 PR 模板——对于任何 AI 编写的代码超过阈值比例的 PR，这都是必填字段。其开销很低，但在事件响应中的收益却非常显著。

基于风险的分层：并非所有 AI 生成的代码都承担相同的责任负担。Lock 文件的更新和脚手架代码只需要最低限度的溯源。身份验证变更和数据流水线逻辑则需要完整的人类审查及文档化的理由。显式地将这种分层制度化——而不是留给审查者自行裁量——既能减少审查疲劳，也能在关键环节填补问责空白。

更深层次的反思

“隐形作者” 问题本质上不是工具问题。工具是答案的一部分，但核心问题在于，软件工程行业吸收结构性变化的速度超过了其问责规范的适应速度。

在软件历史的大部分时间里，代码的作者也理解代码。这不再是一个安全的假设。这意味着建立在该假设之上的实践——基于 git blame 的调试、通过代码审查进行的知识转移、安全事件的所有权模型——需要显式的重新审视，而不是被悄无声息地侵蚀。

如果团队将 AI 仅仅视为更快的打字员，最终会遇到这样一种情况：速度的提升其实是从未来借来的。git blame 所代表的制度性知识不仅是元数据——它是对系统运行原理的累积理解。当 AI 编写了大部分提交时，这种理解必须通过溯源记录、担保规范和提示词日志来刻意重建，否则它根本就不存在。

问题不在于是否使用 AI 来编写代码。在这一点上，大势已定。问题在于，你是在提升速度的同时构建问责基础设施，还是仅仅在透支未来，等到生产环境中再去结清账单。