首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >VS Code 新版本出现大bug:开发者怒骂,微软下场向开发者道歉!

VS Code 新版本出现大bug:开发者怒骂,微软下场向开发者道歉!

作者头像
GoLang学习记
发布2026-05-09 14:33:26
发布2026-05-09 14:33:26
680
举报

2026 年 5 月初,微软在 VS Code 上搞了个“小动作”,结果直接点燃了整个开发者社区的怒火。事情的起因是:VS Code 开始默认在 Git 提交消息里添加 “Co-authored-by: Copilot” 这行字。本来这个功能在之前已经是预览功能,没什么说的,但是很多开发者发现,自己纯手写的代码也被标上了 AI 署名,甚至在完全关闭 AI 功能的情况下依然出现。

社区炸锅了,Hacker News 冲上榜首,VScode在GitHub PR 被骂到锁评论,微软不得不公开道歉并快速回滚。

一、事件全貌:微软到底干了啥?

故事要从一个不起眼的 Pull Request 说起 —— PR #310226

这个 PR 把 VS Code Git 扩展里的设置 git.addAICoAuthor 默认值从 “off” 改成了 “all”

在这里插入图片描述
在这里插入图片描述

意思就是:只要 VS Code 检测到“AI 参与了代码变更”(包括 inline completions、Chat、Agent 等),就会自动在 commit 消息末尾加上:

代码语言:javascript
复制
Co-authored-by: Copilot

听起来好像挺合理,对吧?很多工具确实会给 AI 生成的内容打标签,方便追踪 provenance(出处)。问题是,微软这次默认开启,而且实现上存在 bug:

  • 即使你设置了 chat.disableAIFeatures: true,它还是偷偷加标签。
  • 纯手工编辑的代码也被误判成 AI 贡献。
  • 最气人的是:这个标签在 VS Code 的 Commit UI 里根本看不到!你改完 commit 消息,按下 push,它才在后台默默加一行。你签字画押的时候完全不知情。
在这里插入图片描述
在这里插入图片描述

这就像你写了一封情书,寄出去之后发现落款多了“代笔:ChatGPT”。你说尴尬不尴尬?开发者们可不只是尴尬,他们直接怒了。

二、开发者为什么这么生气?

很多人第一反应是“又在推 Copilot 吗?” 甚至有的人因此直接卸载了VSCode

下面是一个老兄的感慨

在这里插入图片描述
在这里插入图片描述

翻译过来就是说:已卸载,再见。我再也不会换回微软那款粗制滥造的编辑器了。

细细思考,引众怒背后的真实原因可能更深:

  1. 信任崩塌 开发者最在乎的是对自己代码的控制权。Commit 历史不是随便玩的,它是技术血统证明、审计记录、甚至法律证据。默默改 commit 消息,等于在你的签名文件上偷偷盖了个章,这严重违反了 “What You See Is What You Get”(所见即所得)的原则。
  2. 版权与法律风险 目前很多司法管辖区认为纯 AI 生成的内容无法获得版权保护。如果你的 commit 被标成 “Co-authored-by: Copilot”,以后代码所有权、开源协议兼容性、企业合规审计都会出大问题。有人开玩笑说:“这可能会让我丢掉工作!”虽然夸张,但不是完全没可能。
  3. 营销嫌疑 不少人怀疑微软想通过这种方式人为增加 Copilot 使用数据。毕竟 Copilot 是付费服务,数据好看对财报有帮助。社区直接把这事定性为营销噱头。
  4. 无声无息的推送 没有醒目的通知,没有 changelog 重点标注,就这么悄无声息地进了稳定版。开发者最恨这种“偷偷摸摸”。

这次事件暴露了微软在 AI 产品化上的一个经典矛盾——商业目标 vs 开发者体验。微软当然希望大家多用 Copilot,但把“默认开启 + 隐形操作”当成策略,确实低估了开发者的敏感度。开发者不是普通用户,他们对工具的信任是建立在多年血泪史上的,一次小 bug 就能引发大地震。

这个事情也反映出:评估一个技术价值,不能仅看功能强弱,更要看它是否增强了人的自主判断与真实协作。

三、Copilot 自己都提前预警了!

最讽刺的是,GitHub Copilot 的 AI Review 功能在 PR 阶段就警告过这个问题。

AI Reviewer 明确指出:配置 schema 和运行时代码不一致,可能导致“unexpected behavior”。内部测试也发现了问题。但 PR 还是被批准并合并了。

Dmitriy Vasyura(VS Code 首席软件工程师)后来在 Hacker News 上公开认错:

“我是批准这个 PR 的人……我为在没有足够前期验证的情况下就把这个功能默认开启而道歉。” “没有邪恶公司的恶意,只是想支持一些客户期望的 AI 代码归属功能……但显然,当 disableAIFeatures 开启时不应该工作,也不应该给非 AI 变更打标签。我会修复这些,同时在 1.119 版把默认值改回 off。”

这句道歉其实挺诚恳的。承认错误、快速回滚、公开接受反馈,这点微软做得不错。但也说明了大公司常见的问题——流程和验证机制在 AI 功能上还不够成熟。连 Copilot 自己都看出风险了,人却没当回事,这本身就很搞笑

四、微软的快速响应与回滚

社区压力下,微软动作很快:

  • 5 月 3 日左右,Dmitriy 在 HN 发帖道歉。
  • 很快合并了新 PR #313931,把默认设置改回 “off”。
  • 计划在 VS Code 1.119 版本推送,并修复相关 bug。
  • 未来会作为明确 opt-in 功能提供。

这波操作让事件快速降温,但社区的警惕心已经拉满。很多人表示:“下次再看到类似 silent change,我直接换编辑器(Zed、Cursor 等)。”

五、AI 时代谁的代码算谁的?

这次事件不是孤立的,它反映了 2026 年开发者工具领域的几个核心矛盾:

  • Attribution(归属) vs PrivacyAI 辅助越来越强,如何透明记录贡献,同时不侵犯开发者主权?
  • 默认设置的哲学默认开启方便新手,但对老鸟可能是灾难。微软应该多提供“极简模式”或“零 AI 干扰”配置。
  • Human-in-the-LoopAI 再强,最终签字的还是人类。任何工具都不能替人决定“这是谁写的”。
  • 开源协作的影响很多开源项目可能开始拒绝带 AI co-author 的 PR,以避免法律风险。这会让贡献流程更复杂。

AI 工具的终极目标应该是放大人类创造力,而不是抢镜或者制造混乱。Copilot 本身是非常强大的生产力工具,但类似这次的“默认骚操作”会严重损害用户信任。微软作为行业龙头,有责任把“AI 治理”做得更好——透明、尊重用户选择、可解释。

我特别欣赏 Dmitriy 亲自出来道歉的态度,这比很多公司甩锅强多了。但长远看,微软需要建立更严格的“开发者影响评估”流程,尤其涉及 Git、Commit、知识产权这些敏感领域。

幽默地说:AI 想当 co-author 可以,但得先问问“主人”同不同意。强行上位,只会变成“被嫌弃的 AI 室友”。

反观VS Code的对手cursor则对此有自己的看法:Cursor不会自动添加署名,因为其工作流默认假设你在提交前会审查每一处代码变更。提交作者就是执行git commit操作的人,仅此而已。

微软这次道歉事件,像一面镜子,照出了 AI 快速迭代中开发者工具的成长痛。表面是小小的 commit 标签,背后是控制权、信任、透明度这些永恒话题。

开发者社区这次的快速反应再次证明:我们不是被动接受者,而是工具真正的主人。未来 AI 编码工具会越来越强,但只有真正把开发者放在第一位的,才会赢得长期信任。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-05-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 golang学习记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、事件全貌:微软到底干了啥?
  • 二、开发者为什么这么生气?
  • 三、Copilot 自己都提前预警了!
  • 四、微软的快速响应与回滚
  • 五、AI 时代谁的代码算谁的?
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档