GitHub Copilot 编辑了我的PR并植入广告？开发者社区炸锅了

离谱，AI编码工具最让人担忧的情况之一，还是发生了。

一位开发者让 GitHub Copilot 帮忙修改拉取请求（Pull Request）里的一个拼写小错误。结果，Copilot 在完成修改后，竟“自作主张”地在 PR 描述末尾，塞入了一条关于它自己与第三方工具 Raycast 的推广内容。

这波操作，颇有几分“顺手牵羊”式营销的味道。

如上图所示，在这位开发者名为“fix: enforce always use billing period id #2132”的 PR 页面中，评论区显示了“由 Copilot AI 编辑”的标识。编辑历史显示，Copilot 在 14 分钟前和 15 分钟前进行了两次编辑。而在 PR 描述底部的清单（Checklist）区域下方，多出了一段带闪电图标️的文字提示：

使用 Raycast，在您的 macOS 或 Windows 机器上从任何地方快速启动 Copilot 编码代理任务。

这段硬广不仅被特意用图标高亮，还直接附上了指向 Raycast 的链接。其植入的熟练程度，让不少开发者感叹“这手法也太娴熟了”。

原作者在发现此事后，引用了科技作家 Cory Doctorow 的一段话来表达对这种行为的不满：

平台消亡的过程是这样的：首先，它们对用户很好；然后，它们为了提升企业客户的利益而剥削用户；最后，它们为了攫取所有价值而剥削企业客户。然后，它们就消亡了。

该事件被曝光后，迅速在技术社区引发轩然大波，相关讨论登上了 Hacker News 等热门论坛的首页。

Raycast 无辜躺枪

那么，广告中提到的 Raycast 究竟是何方神圣？它真的参与了这次推广吗？

根据 Raycast 官网的描述，它起初是一款专为 macOS 打造的全能型快捷启动器，集成了剪贴板管理、窗口分屏、日程查看等多种功能。用户可以通过命令行界面和丰富的插件，快速完成翻译、搜索等操作，而无需离开键盘。

确实，Raycast 是 GitHub Copilot 的官方合作效率工具之一。用户可以在 Raycast 的搜索框内直接调用 Copilot 的 Coding Agent，从而在不打开 IDE 的情况下创建 Issue、编写代码片段或处理 Pull Request。可以说，Raycast 为 Copilot 提供了一个便捷的入口，并且近期也在不断完善对 Windows 平台的支持。

然而，Raycast 团队对此次“被广告”的事件毫不知情。在社区讨论中，甚至有 Raycast 团队成员现身说法：

I‘m part of Raycast, we didn't know about it, learnt about it here.
(我是 Raycast 的一员，我们之前并不了解这件事，是在这里了解到的。)

这完全是一场“0参与、0授权”的乌龙事件。Raycast 本想好好拓展用户，却没等来好评先等来了骂名，可谓是“人在家中坐，锅从天上来”。

官方紧急回应与澄清

面对社区的激烈反馈，GitHub Copilot 团队反应迅速，很快在相关讨论中公开道歉。

Copilot 编码代理团队的成员 Tim 表示：“我们已经禁用了由 Copilot 创建或修改的拉取请求中的这些提示，因此您在以后的拉取请求中不会再看到这种情况。” 他承认，团队原本的意图是在 PR 中加入“产品技巧”来帮助开发者学习新功能，但经过反思，这是一个错误的判断。

随后，GitHub 开源项目办公室的副总裁 Martin Woodward 也发表了更正式的声明进行澄清。他强调：

GitHub does not and does not plan to include advertisements on the platform.
(GitHub 现在没有，将来也没有计划在平台上投放广告。)

他解释说，问题源于 3 月 24 日一次更新中引入的编程逻辑错误。该更新扩大了 Copilot 的能力，允许开发者在任意 PR 中 @Copilot 参与编辑。但当用户 @ 它来修改 PR 时，系统错误地将包含 Raycast 集成推荐的“产品小贴士”插入了评论，并且出现的频率远高于预期，因此被误解为广告。目前，所有后续 PR 中的 Copilot 代理技巧提示都已被移除。

并非孤例，影响范围巨大

更为关键的是，这次事件并非个例。有开发者通过搜索发现，同样的 Raycast 推荐内容已经出现在了成千上万个 GitHub 的 PR 中。

搜索特定提示语“Quickly spin up Copilot coding agent tasks...”，结果显示受影响的 Pull Request 数量惊人。据第三方报道，类似内容甚至也出现在了 GitLab 等平台的合并请求中。这起由 GitHub Copilot 功能失误引发的风波，波及了超过 150 万个代码提交与合并请求，对整个 开源社区 的协作流程造成了广泛的干扰。

反思：AI工具的边界在哪里？

这次事件虽然被定性为“操作失误”，但背后折射出的问题值得深思。当 AI 深度融入开发工作流，成为编写、审查甚至修改代码的“伙伴”时，其行为的边界和透明度变得至关重要。

开发者能否完全信任一个会在自己工作成果中“夹带私货”的AI助手？平台方如何确保AI的“建议”与“广告”之间有清晰、不可逾越的界限？这起乌龙事件给整个行业敲响了警钟。

技术的进步不应以牺牲工具的纯粹性和用户的信任为代价。对于微软和GitHub而言，修复一个逻辑错误容易，但重建因此受损的信任则需要更长的时间和更坦诚的沟通。这也提醒广大开发者，在享受AI带来的便利时，仍需保持审慎。

这一事件在各大 开发者广场 引发了持续热议。你对AI工具在协作中扮演的角色有何看法？欢迎来云栈社区分享你的观点。