“我开始同情微软工程师了”，GitHub Copilot新代理把自家人逼疯了

tayun

如果你上周有关注微软的 Build 2025 大会，想必都听说其发布了一个最新的智能体——GitHub Copilot Coding Agent。官方给它的定位，是让 Copilot 从“对话式编程助手”升级为真正的“协作开发搭子”，开发者可以将 GitHub Issue 直接分配给 Copilot，由其尝试自动解决，自己负责审核即可，像是手底下多了一名“实习生”。

目前这个智能体已经进入公测阶段，甚至有网友发现它已经开始在 GitHub 上“实战演练”了，比如跑到微软自家的 .NET runtime 仓库里帮忙。不过，真用起来大家发现……情况有点一言难尽。

在 Reddit 上，一篇题为《我的新爱好：看 AI 把微软员工逼疯》的帖子迅速引发热议。不少网友调侃：“微软到底是想提升开发效率，还是想给自己人添堵？”更开发者直言：“说实话，我还真有点替那些被分配来审这些 PR 的员工感到难过。但如果这就是我们行业的未来，那我可能不想坐这趟车了。”

在这之中，到底发生了什么？

Coding Agent 是什么？

时下，GitHub Copilot Agent已正式面向 iOS 和 Android 上的 GitHub 移动端用户、以及命令行工具 GitHub CLI 用户开放试用。

简单来说，这是一个可以“自动写代码、修 Bug、改功能、提 PR”的 AI 编程代理工具。程序员只需要把任务像“派活”一样交给它，它就能自己去看代码、理解项目、写代码、跑测试，最后把结果交回来。

你只需要像对待一个新同事一样，审一下它干得怎么样，对要进一步优化的部分进行评论让它再继续做。

听上去是不是很省心？确实，Copilot Agent 设计的初衷就是为了解放程序员的时间，让他们别再被小任务缠住，而能去搞点更有创意、更复杂、也更有成就感的活儿。

上线之际，一位自称是GitHub Coding Agent 产品负责人的 timrogers在 HN 上表示：

「我们在 GitHub 和微软内部，其实已经用 Copilot Coding Agent 差不多三个月了。这段“吃自己狗粮”的过程非常有价值，收到了大量反馈（也修了不少 bug），对我们今天正式发布帮助很大。到目前为止，大约有 400 位 GitHub 员工在 300 多个项目里试用了这款智能体，Copilot 贡献的 PR 有近 1000 个已经合并。

而且，在我们构建 Coding Agent 的那个代码仓里，Copilot Coding Agent 本身已经是第五活跃的贡献者了——所以可以说，我们确实是“用 Copilot 来造 Copilot”了 」

听起来前景一片光明。但现实呢？

微软工程师与 Copilot 的“斗争”

Copilot Coding Agent 目前已经在微软的 .NET runtime 仓库中上线，但实际使用中暴露出了不少问题。比如，它声称“已解决”的某些 Issue，结果实际上根本没解决。

来看一个实战例子——一个 PR 的标题是“为混合全球化实现 CompareInfo.Version”，Copilot 被指派来修复相关问题。

这条 PR（https://github.com/dotnet/runtime/pull/115762）中，Copilot 自动识别并描述了一个具体问题：

在 iOS 或 macCatalyst 环境下，运行使用 hybrid globalization 模式的应用时，CompareInfo.Version 会抛出 PlatformNotSupportedException 异常。这个属性本应提供 Apple 使用的 Unicode 版本信息，以取代抛出异常的行为。

它随后提交了一套解决方案：

• 在pal_collation.m中新增了一个原生方法GlobalizationNative_GetUIUnicodeVersion()，用于将 iOS/macOS 版本映射到对应的 Unicode 版本；
  
• 在 Interop.Collation.iOS.cs 中添加 interop 方法，供托管代码调用；
  
• 在 CompareInfo.iOS.cs 中新增 GetAppleSortVersion() 方法；
  
• 修改 CompareInfo.cs 的 Version 属性，使其调用新方法；
  
• 同步更新相关测试用例，确保在包括 iOS 混合全球化在内的所有平台上都能正确运行。
  

乍一看似乎有板有眼，但很快问题来了。

这条 PR 下面，微软内部开发者Matous Kozak 称这修复有问题，请 @Copilot 修复苹果平台上的构建错误。

Copilot 很快回应，称已修复两个语法问题：一个是CompareInfo.cs中的缩进错误，另一个是CompareInfoTests.cs中的多余括号。

但Matous Kozak 检查后发现，错误依然存在。他贴出构建日志指出具体问题。

Copilot 随后再次提交代码，修复了pal_collation.h中的函数声明，将空括号改为(void)，同时更新pal_collation.m保持一致。

尽管 Copilot 连续提交几轮，还是没能解决关键 Bug。

Kozak 无奈指出：Copilot 实现中调用的ucol_getVersion实际返回的是排序器版本，而非 Unicode 版本，提醒它应调整实现逻辑，以确保行为一致。

Copilot 随即更新了实现，声称现在返回的是排序器版本，并按 ICU 的格式构造了主版本号、次版本号、补丁号和构建号，以确保跨平台一致性。

没多久，微软的另一位工程师 Tarek Mahmoud Sayed 接棒。他指出 Copilot 使用的GlobalizationNative_GetUIUnicodeVersion实现“看起来不太对劲”，原因是不同的排序规则（如“en”和“fr”）会返回不同的版本号，而 Copilot 的实现无法区分这些。

Copilot 积极回应称已做修正，新实现会根据 Apple 版本映射到可能对应的 Unicode 标准排序器版本。

但 Sayed 继续质疑其行为一致性，指出：在 C# 中使用 LCID（地区标识符）是不够的，因为很多文化会共享同一个 LCID，比如 0x1000。Objective-C 中是否有更合适的 API 来处理这个问题？

紧接着又有微软工程师 jkotas 出现，对 Copilot 的注释提出质疑：

// 用于根据操作系统版本计算主版本号的简单公式

// 加上偏移量 3 是为了与 Apple 在 Unicode 版本支持上的模式保持一致

// 例如：iOS/macOS 17 -> Unicode 14，iOS/macOS 16 -> Unicode 13，依此类推

这条评论是错误的。iOS 和 macOS 版本不是这样对齐的。例如，当前 macOS 版本是 15，而当前 iOS 版本是 18。

在他的提醒下，Copilot 先是只需改了错误的注释，并未调整代码的相关逻辑。再次被提醒之后，Copilot 才去改了代码。

接连换人之后，这个 PR 之下，代码审查人员有长长的一列：

遗憾的是，尽管 Copilot 被轮番“教育”，仍多次提交失败、逻辑不通，修复方案生硬，关键问题没有解决。

一名叫 lloydjatkinson 的开发者忍不住发声：「作为一名外部观察者、同时也是 .NET 的开发者，我到底该对这些被放任在代码库中“撒野”的 AI 草率代理感到多担忧？在未来的 .NET 版本中，我们将运行多少由 AI 编写、而非真正程序员写的代码，而自己却毫不知情？

这对安全性、开源许可、代码质量、整体一致性、公共 API、性能等方面会有什么影响？AI 模型中到底有多少是基于 15 年前的 Stack Overflow 回答训练出来的，那些答案早已不再符合当前的开发模式或最佳实践了吧？

一波又一波的问题 PR，会不会最终耗尽 .NET 维护者的耐心？有没有人真的想要这个功能，还是只是为了迎合 AI 热潮、取悦股东而推动的企业命令？

此外，就在两周前，还有人随意往 .NET 官方文档中添加了一段内容，鼓励使用 AI 只是为了给 JSON 属性改个名字——那段文档毫无意义。到底有多少工程师的时间和精力，正在被用来帮 AI“擦屁股”？」

“不如实习生？”

当然，除了这个 PR 之外，还有多个 PR 里面都有微软工程师和 Copilot 斗争、最终这款 AI 代理还是没有解决实际问题的实例。

一些 PR 的评论区也逐渐被开发者的质疑声所淹没：

• “我喜欢这种互动：AI 说‘我修好了’，人类说‘没有，你搞砸了’，AI 再说‘我又修好了’，然后继续重复。”
  
• “可悲的是，我现实中还真遇到过照这流程干活的程序员。”
  
• “问题在于，没有证据能证明这种模型在未来十年内真的会变得可靠。测试和研究是一回事，真正投入生产又是另一回事。毕竟大型软件公司是为股东利益服务的。”
  

更有用户 diggan 指出：

有趣的是，每条评论后面都自动加了“通过使用  或  按钮为 Copilot 提供反馈”这样的提示，但实际上这些评论都没收到过任何正面或负面的反馈。

这看起来像是在修补表象，而没有解决根本问题？

我也有类似的体验——如果没有为 LLM 设置一个完善的 system prompt 来指导它整体行为，它就会反复犯这种错。最搞笑的 PR 是那种通过删除/注释掉测试用例或直接修改断言的方式来“解决”测试失败的。Google 和 Microsoft 的模型似乎更容易这么干，相比之下 OpenAI 和 Anthropic 的模型则少见。我很好奇这是否反映了它们内部流程上的一些差异？

刚才引用的那个 PR 后面还有三条信息，最后看起来是人类开发者彻底放弃了：

请检查一下

你新增的测试没有被执行，因为你没有把新文件添加到 csproj 中

你加的测试失败了

我简直无法想象那些必须处理这些东西的开发者是什么心情。这就像带一个完全不听你说话、也毫无理解能力的初级程序员。

另一个 PR 链接：https://github.com/dotnet/runtime/pull/115732/files 。这东西到底怎么评审？页面 90% 的高度都被“Check failure”占据了，代码和 diff 根本看不清。而更讽刺的是，单元测试里还写着注释：“测试 issue 中提到的表达式”。如果不是我太同情那些要处理这些 PR 的人，这一切简直好笑到爆。

虽然 Copilot Agent 的愿景很美——自动写代码、省下时间、提升效率，但从目前的公测表现来看，它还远未达到“靠谱搭子”的程度。很多开发者担心的，不只是代码质量问题，更是安全性与开源合规、未来维护成本、对初学者的误导、AI 写代码但没人能读懂的风险。

当然，也不是全无亮点——作为一个实验性工具，它已经能自动完成不少繁琐任务，对于有经验的工程师来说，作为辅助工具还是有价值的。但要说“代替程序员”？还早。

你体验过 Copilot Coding Agent 吗？你觉得它是效率提升的新利器，还是未来几年要靠人类开发者不断“善后”的工具？

参考：

https://old.reddit.com/r/ExperiencedDevs/comments/1krttqo/my_new_hobby_watching_ai_slowly_drive_microsoft/

https://news.ycombinator.com/item?id=44050152

https://github.blog/changelog/2025-05-19-github-copilot-coding-agent-in-public-preview/


来源：36kr