【卷卷观察】VS Code现在会强插“Co-Authored-by Copilot“，不管你用没用AI编程

先说事实：GitHub上有个PR，编号#310226。这是微软给VS Code提的一个变更——把Copilot的"AI co-author"功能默认开启。变更的内容很简单：只要你的VS Code装了Copilot扩展，不管你有没有开启Copilot功能，不管你这一行代码是不是AI写的，commit的时候都会自动加上Co-Authored-by Copilot这几个字。

这条HN帖子在3小时内拿到了500多分，220多条评论。评论区的热度说明这事不是个别现象——它触动了一根很敏感的神经。

这不是一个新问题

在展开这件事之前，我想先说一下背景。

Co-Authored-by是Git的标准规范，用来注明"这条commit有多个作者"。它的设计初衷很清楚：两个人真正合作写了一段代码，才需要加这个名字。这是Git协议里的一个信任机制——commit log里的每一个author都是真实参与过的人。

现在微软做的事是：只要你装了Copilot扩展，就默认你"与AI合作"了。这个逻辑有意思的地方在于——它完全绕过了"你是否真的用了AI写代码"这个问题。

一个完全不用Copilot的开发者，只要装了扩展，每次commit都会带上Copilot的名字。这相当于你买了一把锤子放在工具箱里没用过，但每次你签字的文件都会自动加上锤子的名字作为"合作者"。

HN上最高赞的评论说了一句话挺到位的："微软花了二十年重建的声誉，为了机器人之神一把火烧了。"这句话有情绪，但内核是对的——微软在2010年代花了很大力气重建"我是靠谱企业软件商"的形象，Azure、VS Code、GitHub Actions都是这套重建计划里的代表作。现在Copilot默认开启这件事说明，在AI浪潮面前，这个形象被放到了次要位置。

HN上大家到底在吵什么

翻了220多条评论，观点大致可以分为几类：

第一类：这是consent的问题

核心观点很清晰：未经明确同意就在commit里添加署名，这侵犯了开发者的署名权。commit log里的author信息不是只有技术意义，它也是一种信任凭证——别人看到你的commit，知道这是你写的。如果Copilot在你不注意的时候出现在你的commit里，这种信任就被稀释了。

这类观点里有一条让我多看了两眼：有人说这跟"帮你自动订阅付费功能"是一个性质。订阅服务默认勾选是互联网行业最被诟病的设计模式之一，因为它利用用户的认知惰性完成转化。Copilot这件事异曲同工——它利用的是"开发者一般不会检查commit config"这个现实。

第二类：这是标准被侵蚀的问题

HN上有人提到，Google Docs之前也在macOS上把CMD-G（"查找"功能的经典快捷键，存在了差不多三十年）偷偷改成了LLM快捷键。评论区有人说这可能是已经修复了，但"至少有几周时间，这个快捷键在macOS版Google Docs里是无效的"。

CMD-G被覆盖这件事听起来是小事，但它背后反映的是一个更大的问题：当AI功能需要覆盖已有的标准行为时，厂商们选择牺牲标准。VS Code的Co-Authored是另一个例子。它们单独看都不是天大的事，但累积在一起，构成了一个"AI正在改写既有规则"的趋势。

第三类：这是管理决策质量的问题

有一条评论说："这是一次对技术规则标准的全面敌意——不管是否正确、是否道德、是否真实，唯一重要的是'快用我们的AI'。"

这句话稍微有点情绪，但它指向的是一个真实的管理决策模式：AI产品部门现在处于极度饥渴的增长压力下，他们有足够的动机把AI功能往前推，推到"先用上再说"的程度。在这种压力下，"用户体验"和"开发者信任"这些长期资产往往是最先被牺牲的。

HN上还有人说了一句挺有意思的话："2023年：Principal engineer反对这个糟糕的UX，PM应该知道这是错的。2025年：你被解雇了。我们刚招了一个两周的新人，你来实现这个糟糕的想法。"

这当然是一个夸张的表述，但它捕捉到了一种弥漫在某些公司里的氛围：技术判断在商业压力面前越来越不重要，"有没有AI"变成了一个独立的考核维度。

这真的只是微软的问题吗？

稍微延伸一下，Copilot默认开启Co-Authored这件事不是孤立的。

2025年，OpenAI被曝出在ChatGPT的回复里注入品牌推广内容。Claude Code的安全策略导致大规模代码修改争议。Cursor的自动补全在某些情况下会把用户没要求的功能也生成出来。这些事情单独看都是"feature"或者"edge case"，但串在一起，描绘的是一幅"AI产品正在以非常激进的方式扩张自己的存在感"的画面。

微软这次的问题不是技术问题，是一个价值观选择：他们选择了"让Copilot的存在感更强"，而不是"尊重开发者的知情权"。这个选择在短期内对Copilot的市占率有正向作用——会有更多commit带着Copilot的名字出现，强化"Copilot是行业标准工具"的认知。长期代价是每次开发者发现自己的commit被擅自添加了Co-Authored，都会在心里记一笔。

信任这种东西，建立需要很多年，毁掉只需要一次。

为什么这件事值得关注

可能有人会说：这不就是commit里多了一行字吗？有那么严重吗？

我认真想了想，觉得这件事的严重程度取决于你怎么看待commit log。

如果你觉得commit log只是一个技术记录，那Co-Authored确实不是什么大事。

如果你觉得commit log是一种信任凭证——它记录了谁写了什么代码，谁在什么时间点做出了什么决策——那"被默认添加AI署名"就是一个需要认真对待的问题。因为它模糊了人和AI的边界，而这个边界在代码溯源、安全审计、代码所有权认定这些场景里，都是有实际意义的。

另外还有一个技术细节值得提一下：某些DCO（Developer Certificate of Origin）检查工具会对commit里的author数量有要求。在某些开源项目里，如果你的commit被自动加上了Co-Authored，CI可能会触发额外的检查或者直接拒绝合并。这不是微软的问题，但这会是真实世界里的摩擦点。

我的判断

这不是一个技术bug。这是一个价值观选择——增长优先于信任。

微软在做出这个决策的时候，一定做了某种计算：默认开启带来的Copilot市占率提升，超过了它可能引发的开发者信任损失。只是这个"可能"变成了现实，而且HN的500分说明这不是少数人的敏感。

短期内，Copilot的市占率会继续涨。这个功能对微软来说是免费的广告——每一条带着Co-Authored的commit都在提醒全世界的开发者："你们团队有人在用Copilot。"对于Copilot的营销来说，这是一种非常廉价的曝光方式。

但长期来看，这类操作会留下痕迹。每一次"帮我做主"的默认行为，都会让一部分开发者把微软放进"不再信任"的篮子。只是这个篮子的重量可能要5-10年后才能真正显现。

更值得警惕的是这个趋势本身。Copilot不是唯一一个在做"默认帮你决定"的产品。Google Docs改CMD-G，Claude Code的安全策略争议，Cursor的激进补全——这些独立事件有一个共同的方向：AI产品正在以"先用上再说"的逻辑向前推进，在每个遇到阻力的地方都选择绕过去，而不是停下来征求同意。

这种模式在消费者产品里已经是常规操作了。现在它正在渗透到开发者工具领域。VS Code是世界上最大的代码编辑器之一，它的每一个变更都直接影响数百万开发者的工作流。当这个量级的产品开始"默认帮你决定"，整个行业的基准线就被悄悄拉低了。

行动建议

• 如果你的团队有人在用VS Code + Copilot：去设置里关掉github.copilot.enableAICommitSigning（扩展设置 → Copilot → Advanced → Enable AI commit signing），确保commit log的干净。至少知道自己被加了什么
• 如果是团队或项目的技术负责人：明确制定commit署名规范，AI贡献必须显式声明，不能默认。把这写进CONTRIBUTING.md或者team handbook里。代码溯源是技术债务的隐形成本，不能等到出问题了才想起来
• 如果你在选型阶段：把"是否尊重开发者consent"列入AI编程工具的评估维度。这个维度在短期内可能不重要，但它是判断一个产品是否有长期主义的有效指标
• 长期警惕：这类"帮我做主"的默认行为会越来越多，保持审视。每次遇到这种变更，先问一句："他们帮我默认开启的这个功能，我真的需要吗？"