提交信息中的一小行，触发了更大的信任危机
微软正面临开发者的强烈反弹，因为 Visual Studio Code 悄然在 Git 提交中插入了一行“Co-Authored-by Copilot”，即使用户已经关闭了 AI 功能，这一行也可能出现。引发批评的原因并不在于它以一种显而易见的方式改变了应用输出，而在于它触及了软件开发中最敏感的记录之一：记录作者身份、意图和责任的提交历史。
据 The Decoder 报道，这一功能是由一位微软产品经理推动的，由一名首席工程师在没有说明的情况下批准，并很快合并。等这一行为在 GitHub 和 Hacker News 上变得可见后，开发者的回应立刻爆发。批评者认为，问题不仅在于出现了 AI 署名，还在于即便 Copilot 相关功能已被关闭，它仍然会出现。
为什么提交元数据如此重要
在许多团队中，附在提交上的文字并不只是装饰。它可能构成审计轨迹、内部合规流程、贡献统计，以及法律审查的一部分。共同作者一栏意味着参与。如果这一栏在没有使用 AI 的情况下却写上某个 AI 系统，或者在没有明确同意的情况下出现，就会让记录的含义变得模糊。
这也是为什么外界反应远不止于不满。报道中受访的开发者怀疑，微软可能是在试图夸大 Copilot 的使用指标。原文并没有独立证明这一动机，但它清楚表明，这种怀疑迅速形成。一旦用户相信工具厂商会为了产品宣传而篡改归属数据，信任成本就可能远远超过原本功能的影响范围。
在严格规范 AI 使用的组织中，这个问题会更严重。有些公司会规定生成式工具何时可以使用、必须如何披露，以及 AI 辅助编写的代码是否能够进入特定代码库。即便实际上并没有 AI 参与，自动且部分隐藏的共同作者行也可能在内部流程上引发冲突。
微软的回应很快，但属于被动补救
在舆论发酵后，微软开发者 Dmitriy Vasyura 承认了这一错误。他表示，当 AI 功能被关闭时，这一功能本不该运行；在没有 AI 参与的情况下，也不应把提交标记为 AI 生成。他还表示，默认设置将在 1.119 版本中回退。
这一回应解决了眼前的问题，但留下了更广泛的治理疑问。为什么一个影响提交作者信息的改动，会以用户感到未被披露，至少也是披露不足的形式发布？开发者工具公司越来越处在这样的环境中：细小的 UX 决策也可能带来政策、法律和声誉上的后果。AI 越接近核心工作流，模糊默认设置的空间就越小。
报道还提到，相关的 GitHub 讨论后来因垃圾信息被锁定。即便这类版主管理决定本身很常见，这种关闭方式也会加深外界印象，认为厂商是在压制争议，而不是完整面对争议。
AI 驱动开发工具内部更深层的冲突
这一事件凸显了编码助手中的结构性张力。厂商希望集成足够深入，让 AI 支持显得无缝且无处不在。相比之下，开发者希望能精确控制助手何时参与、如何记录这种参与，以及关于他们工作的哪些数据会被创建。
这两种目标并非不能共存，但前提是默认设置必须清晰且可逆。一旦归属信息在没有明确同意的情况下出现，产品就不再像助手，而更像一个把自己写入历史记录的行为主体。这在版本控制中尤其棘手，因为信任依赖于细节的完整性。
这场争议还表明，“关闭 AI”必须严格等同于用户理解中的含义。如果系统在 AI 被关闭时仍继续插入与 AI 相关的元数据，那么配置模型本身就会变得可疑。对开发者而言，被关闭的设置不是建议，而是指令。
这场反弹对行业意味着什么
开发者对激进 AI 集成的容忍度似乎正在下降。工程师可能接受能节省时间的助手功能，但他们不太可能接受隐藏行为、模糊归属，或优先服务厂商叙事而非用户控制的默认设置。围绕生产力的宣传越强烈，工具就越需要透明地说明自己做了什么、何时做的。
对微软来说，回退默认设置或许能平息眼前的事件。对更广泛的工具生态而言，教训则更大。编程环境中的 AI 功能不再只看输出质量，也要看来源、披露，以及对协作软件工作所依赖社会契约的尊重。
提交信息中的一行看起来或许微不足道，但实际上它同时触及了作者身份、合规和同意问题。正因如此，外界反应才会如此强烈，而其他工具厂商也很可能会认真研究这起事件。
本文基于 The Decoder 的报道。阅读原文。
Originally published on the-decoder.com