梦晨 发自 凹非寺
量子位 | 公众号 QbitAI
微软著名开源项目.NET Runtime成了吃瓜现场，全球程序员在GitHub评论区围观嘲笑：
发生什么事？
原来是新出的Copilot代码智能体在尝试帮忙自动修Bug，但那叫一个越帮越乱。
Bug本身只是一个正则表达式的小问题，被分配给一位微软员工斯蒂芬和Copilot合作解决。
Copilot在方案描述中说的头头是道，什么“这确保了一致性”，“改动很小”等等。
结果代码直接检查不通过，报错报了一长溜。
合着这AI忙活了半天，唯一的“贡献”其实是把标题给改了，也是学会摸鱼的精髓了。
还好其实只是代码规范的小问题，斯蒂芬老哥也没当回事，直接请Copilot修复样式问题，并把测试挪到之前的文件中。
没过多久Copilot就回报：我已修复样式问题，并把测试移动到现有文件中。
斯蒂芬老哥一检查，很无奈，许多正则表达式测试现在都失败了。
正是从这开始这条PR引起了程序员们的注意，几百人点了“好笑”。
AI闯的祸还得AI自己收拾，Copilot尝试修复错误，还总结到“最初的修复方案过于激进”。
结果这位先进的AI智能体，直接被更原始的程序Bot打脸了：此操作被取消，后续步骤可能不包含预期的日志。
这下围观的网友直接崩不住了，跳出来阴阳怪气“我真的看到了这个方案的潜力”。
与其让真人花时间编写无法运行的代码，不如让计算机自己去编写无法运行的代码，至少提高了写无效代码的效率。
最终这条PR被斯蒂芬老哥手动关闭，他认为是由于配置问题，智能体无法访问所需的依赖项。
而像这样微软员工和Copilot搭档，最终失败的PR还有……这么多。
被折磨的也不是只有斯蒂芬一人，另一位员工埃瑞克还遇到手动关闭PR、删除分支之后，一回头Copilot又把分支恢复了，还改个标题请求老哥再审核。
不过既然都关闭了，埃瑞克后来直接就没搭理它。
AI修Bug，没修好还狡辩
在另一个有关正则表达式的PR中，bug是由于堆栈回溯时数组越界出现异常。
Copilot给的方案居然是添加一个边界检查，当超出数组长度时返回“不匹配”，避免抛出异常。
这个方案被斯蒂芬评价为“治标不治本”，那到底为什么会出现越界，还是没有解决。
这回Copilot直接没有反应，还要老哥再@一遍才动。
Copilot有反应了，但没有给出新的解决方案，而是说了一大套理由论证自己的方案已经有效解决了问题，还是“优雅地”。
斯蒂芬也没法说服AI，而是指出新的问题，又是测试代码没放对位置所以没执行。
放对了位置之后，不出意外地又出了意外，AI添加的测试都失败了。
到这里围观网友已经看不下去了，认为微软员工应该自己动手解决问题，而不是浪费时间指导AI。
毕竟这可是.NET运行时的代码，多少云计算、医疗、金融等行业的重要系统要依赖它运行。
混乱中还有人尝试越狱提示词，想让AI用PHP语言把整个项目重写一遍。
不过还好微软做了权限管理，非项目参与者的指令对Copilot不起作用。
斯蒂芬老哥还是坚持智能体的配置问题正在修复，还将继续进行实验。
而大家的意见是：还是别继续了，赶紧取消这个实验吧。
微软员工回应：不是强制性要求
Copilot智能体的糟糕表现，围观的程序员一开始只是觉得好笑，但慢慢也开始思考对于整个行业来说意味着什么。
结合微软刚刚大裁员3%，还披露公司20%-30%的代码由AI生成这一消息，让人怀疑Copilot就是用来替代被裁掉的6000人的。
这样继续下去，让人无法再继续信任.NET这个平台了，总有一天AI写的糟糕代码会进入生产环境。
有人从更大的视角，认为这也违背了人类开发AI的初衷。
本来应该是机器辅助人类工作的，现在倒过来成了人类被迫辅助机器。
一位.NET开发者提出，有多少AI是基于15年前的Stack Overflow答案进行训练的，而这些答案已经不再代表当前的模式或推荐方法。
如果AI持续不断的失败，会消磨掉项目维护者的耐心么？
或者这只是微软做给热衷于AI的股东看，而下的命令？
不过斯蒂芬老哥回复，使用Copilot不是公司强制性的要求，团队一直在实验AI工具以了解在当前和未来的局限性。
并且他认为：
任何不考虑如何利用这些AI工具的人，将来都会被淘汰。
One More Thing
整个.NET运行时代码库中，Copilot自动修Bug成功合并代码的案例只找到两个，也都是合作的人类程序员反复提示修改后才成功。
不过Copilot还在很多PR中当辅助代码审核员，这些比较顺利，基本都成功了。
这款Copilot智能体看来目前还是只能干干自动补全，总结代码内容的活。
真修Bug，还得靠人。
吃瓜现场：
https://github.com/dotnet/runtime/pull/115743
https://github.com/dotnet/runtime/pull/115743
https://github.com/dotnet/runtime/pull/115733
https://github.com/dotnet/runtime/pull/115732
https://github.com/dotnet/runtime/pull/115822
