“微软工程师的心声：GitHub Copilot新代理让人崩溃！”

整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

如果你上周关注了微软的 Build 2025 大会，肯定听说了他们推出的新智能助手——GitHub Copilot Coding Agent。简单来说，这个新助手能把 Copilot 从“聊天式编程助手”升级为真正的“开发合作伙伴”。开发者现在可以把 GitHub Issue 直接交给它处理，让它尝试自动解决，之后再由自己来审核，仿佛多了一个“实习生”在帮忙。

目前，这个智能助手已经进入公测阶段，甚至有网友注意到它已经在 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 仓库上线了，不过在实际使用中暴露出了一些问题。比如说，它号称“已解决”的某些问题，其实根本就没解决。

我们来看个例子——有一条 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 的修复之路：不断挑战与反馈

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 才开始对代码进行真正的修改。

标题：当AI遇上程序员：一场代码审查的“斗智斗勇”

这段时间，团队里的变动可真不少，结果在这个拉长的 PR 下，代码审查的人员列表变得特别长。

可惜的是，尽管 Copilot 一次次被提醒，结果还是屡屡提交失败，逻辑混乱，修复方案也显得很生硬，根本没解决关键问题。

一位名叫 lloydjatkinson 的开发者发声了：「作为一个外部观察者，同时也是 .NET 的开发者，我该对这些在代码库中随意“撒野”的 AI 代理感到多大的担忧呢？未来的 .NET 版本中，会有多少是由 AI 编写的代码，而我们却对此毫不知情？」

这将对安全性、开源许可、代码质量、整体一致性、公共 API、性能等方面产生怎样的影响？AI 模型中究竟有多少是基于15年前的 Stack Overflow 回答训练出来的？那些答案现在还适用吗？

接二连三的问题 PR，会不会最终让 .NET 的维护者们失去耐心？到底有没有人真的想要这个功能，还是只是为了跟风 AI 热潮、迎合股东的企业命令呢？

再说了，就在两周之前，还有人随便往 .NET 官方文档里加了一段内容，鼓励使用 AI 只是为了给 JSON 属性改个名字，那段文档简直毫无意义。究竟有多少工程师的时间和精力被浪费在帮 AI“擦屁股”上呢？

“不如实习生？”

当然，除了这个 PR 之外，其他多个 PR 中也能看到微软工程师与 Copilot 斗智斗勇的情况，结果这款 AI 代理还是没能解决实际问题。

### 聊聊AI和程序员的那些事儿

最近，一些开发者在PR的讨论区里表达了他们的疑问和无奈：

• “我觉得这种互动太有趣了：AI说‘我修好了’，人类则回应‘没有，你搞砸了’，然后AI又说‘我又修好了’，就这样不断循环。”

• “可惜的是，我在现实中确实遇到过这样工作的程序员。”

• “关键是，没有任何证据表明这种模型在未来十年会变得可靠。测试和研究是一回事，而真正投入使用又是另一回事。毕竟大公司是要为股东赚钱的。”

还有位用户diggan也提到：

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

这难道只是在修修补补，而没有真正解决问题吗？

我也碰到过类似的情况——如果没有给大型语言模型设置一个好的系统提示来引导它的行为，它就会反复犯错。最搞笑的是，有些PR通过直接删除测试用例或修改断言来“解决”测试失败的问题。相比之下，Google和Microsoft的模型似乎更容易这样做，而OpenAI和Anthropic的模型就少见。我很好奇这是否反映了它们内部的某种差异。

刚才提到的那个PR后面还有三条信息，最后人类开发者似乎彻底放弃了：

请检查一下

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

你加的测试失败了

我真不敢想象那些处理这些事情的开发者的心情。这就像带着一个完全不听话、也不理解的初学者程序员。

还有一个PR的链接：
https://github.com/dotnet/runtime/pull/115732/files 。这个东西到底怎么评审？页面的90%都被“Check failure”占据，根本看不到代码和修改。而且更讽刺的是，单元测试里还写着：“测试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

GitHub Copilot coding agent in public preview

📢 2025全球产品经理大会

2025年8月15–16日

北京·威斯汀酒店

2025全球产品经理大会将汇聚互联网大厂、AI创业公司、ToB/ToC实战一线的产品人，围绕产品设计、用户体验、增长运营、智能落地等核心议题，展开12大专题分享，洞察趋势、拆解路径、对话未来。