你好呀，我是歪歪。
前几天在阮一峰老师的科技爱好者周刊第 351 期中看到一个我觉得有点意思的瓜。
给你分享一下，我们一起吃瓜。
周刊中这个事情就是这样一句带过：
AI 程序员自信满满的提交了代码，结果有 BUG。
人类程序员告知它真的错了，AI 却觉得自己真没错。
这个画面让我联想到了这个经典的梗：
如果你对一个程序员说：你的代码有 bug。
他的第一反应是：你环境有问题吧？傻X你会用吗！
只是这里面的程序员，在周刊中的这个例子，不是人类，而是 AI。
吃瓜现场
Copilot，大家都知道一款非常牛逼的 AI 助手。
它的爸爸是微软。
毕竟是亲儿子，所以在微软内部大力推广、深度使用 Copilot 也非常的合理。
具体的一个体现就是在微软的 .NET Runtime 代码仓库里面，允许由 Copilot 自行对指定的 issue 进行代码修复，并自己发起 PR 请求。
干和人类程序员一样的活儿。
在这个过程中，有这样的一个由 Copilot 发起的 pr，引起了大家的关注：
首先，我们可以看到这个 PR 确实是由 Copilot 发起的，后面还跟上了一个 AI 的标识：
它把这个问题分给了 Copilot 和一个叫做 stephentoub 的哥们：
歪师傅一点不懂 .NET 这个老大哥语言，但是并不影响我吃这个瓜，因为这个瓜和技术的关系不大。
从描述来看，这是一个关于正则表达式的 BUG：
在某些情况下会出现数组越界的异常。
来，我问你，你作为一个正常的人类程序员。
或者再具体一点，你是一个 Java 程序员，当你的程序中出现数组越界的异常时，你的解决思路是什么？
是不是去排查代码为什么会出现数组越界？
Copilot 给出的解决方案是这样的：
添加了一个边界检查，当超出数组长度时就结束逻辑，避免抛出异常。
相当于是掩盖了问题。
确实不抛出异常了，但是并没有解决之前为什么会抛出异常这个问题。
再举一个更加贴切的例子。
也是歪师傅之前听朋友吐槽的一个真实事情。
说他之前做金融相关业务的时候，有段代码在某些情况下会出现金额为负数的异常情况。
他把问题交给其他小伙伴，让定位一下原因并解决一下。
最后小伙伴在并不知道为什么会出现负数的情况下，直接加了一段代码。代码的逻辑是当金额为负数的时候，就把金额重置为 0。
他说当他审核代码，看到这个解决方案的时候，甚至忍不住鼓起掌来，直呼：天才。
那个画面大概是这样的：
这种关于金额的问题，正常的解题思路是什么？
是不是得定位到金额具体在什么场景下会出现负数，从而基于场景制定解决方案。
直接上来一把梭，为负数了就设置为 0。
运气好，瞎猫碰到死耗子，问题真的能这样去解决。运气不好，你就等着出账务问题。
核心问题还是要找到问题所在，治标不治本的方案不可取。
回到 Copilot 这个案例中来。
Copilot 就相当于是在没有定位问题原因的情况下，直接把"金额设置为 0 了"。
所以，stephentoub 这个哥们在检查这个 PR 的时候，对 Copilot 的这个解决方案提出了质疑：
也就是歪师傅前面说的：治标不治本。
结果 Copilot 直接不鸟他。
搞得他还得再用召唤术来请这个大爷一次：
这次成功召唤出了 Copilot，并一次性回应了 stephentoub 的两次召唤。
首先回应了"治标不治本"的问题：
说了一大堆，大概意思就是：我不改，我的方案是正确的。
然后回应了第二次召唤：
大概意思就是：我寻思我的方案已经很优雅了，就这样吧。
歪师傅虽然不懂 .NET，但是从大家对这个评论的反馈来看，我有理由怀疑它是在一本正经的胡说八道：
stephentoub 老哥一看，行，你就算不改，那你动了代码，按照规范配套的测试用例得跟上吧？
然后让 Copilot 先把测试用例的问题修复了：
Copilot 很快就响应了，并进行了修复：
然而...
Copilot 加的测试用例也运行识别了。
再次翻车。
能感受到 stephentoub 老哥此时的无奈：修 BUG 不行就算了，测试用例也跑不通。
然后吃瓜群众就开始围观这个 PR 了。
其中有一个评论是这样的：
结合前面 Copilot 修复 BUG 的思路，那修复失败测试用例的方案就是删除这些失败测试用例。
处理起来快是真的快，但是同样是"治标不治本"。
所以这句话确实是有一点吐槽功力在的。
还有直呼别使用这个"制作粗糙"的玩意的：
另外有个吃瓜群众是这样说的：
where can I buy a good source of popcorn?
直译过来是：我在哪里可以买到优质的爆米花？
但是你知道的，歪师傅在英语方面是有一些造诣的。
这其实是一个英文梗，与字面"爆米花"无关，而是调侃或暗示"有好戏看咯"的幽默表达。
其实就是英文版的"吃瓜"表达。只不过我是吃的是社会主义种出来的瓜，他们吃的是资本主义弄出来的爆米花。
比如 I'm just here for the popcorn.
和我们常说的：我就是个不明真相的吃瓜群众。
有异曲同工之妙。
一个看起来毫无用处，实际上没啥卵用的英文梗送给你。
回到我们的 PR 中。
除了上面这些展示出来的调侃和嘲讽的评论外，还有很多其他类似的评论。
但是 stephentoub 老哥还是想给他的 AI 同事找回一点面子：
他说 Copilot 表现的不好的原因是因为配置问题，这些问题有团队在进行修复，他们会继续进行这样的实验。
但是大家并不吃他这一套说辞，还是觉得从 AI 的表现来看，不应该轻率的在这个重要的项目中进行试验。
此外，还有一些其他的 PR 都在上演类似的桥段：
那你觉得这个事情好笑吗？
确实我们可以把它包装成一个急功近利反而翻车的搞笑故事。
但是我觉得它也再次印证了我们可以预见的现实：AI 确实抢了程序员的饭碗。
我们不能只是盯着这几个失败的案例进行分析。
我看了一下，在整个仓库中，Copilot 一共发起了 32 个。
其中 5 个还是 open 状态，剩下的 27 个是 closed：
在 closed 的 27 个中，有 13 个都被 merged 了：
这个占比可是不少了。
修 BUG 这个活儿本来是人类程序员干的，现在 AI 也开始插手了。
这样想来，有没有突然觉得手里的瓜不香了？
吃瓜之后
在周刊中，这个事情对应的参考链接：
也就是这个博客地址：
在吃完这个瓜之后，这个博客中有这样一个章节，我觉得很不错，搬运一下给你看看：
首先第一个观点：成为 AI 专家。
然后是了解 AI 的边界，正确的使用 AI：
最后一点，也是非常重要的一点：
分享，多分享自己在 AI 使用过程中的心得或者问题。
当你用 AI 解决了一个复杂的问题，可以分享出来。
当你用 AI 解决不了一个复杂的问题，也可以分享出来。
有分享的习惯总归是一件好事儿。
不要与工具对抗
不知道在你所在的公司，AI 应用到什么程度了的。
但是歪师傅所在的公司，领导非常重视 AI 赋能的事儿，在日常开发中让 AI 协助编程现在已经不是可选性了，变成了必选项。
从最开始的旁观，到现在还不算深度的使用。
我也渐渐的想的越来越清楚了。
要适应这个趋势，谁能尽快的接受这个事实，并适应这个趋势，谁就能尽快的把趋势化为优势。
看着 AI 只需要几分钟，就能完成我一个小时甚至几个小时才能完成的工作，确实让我感到有点冲击。
在前面微软的例子中，Copilot 可以完全自主的解决一些 BUG，不论这些 BUG 是复杂还是简单，它至少把整个流程跑通了，后续一定会越跑越顺。
这也让我感受到冲击。
但是我不能假装这种冲击不存在，这件事情完全并不随个人意志而转移。
解题之道，我觉得就藏在前面提到的博客的这句话中：
Become the AI expert on your team. Don't fight the tools, master them. Be the person who knows when AI helps and when it hurts.
成为团队中的 AI 专家。
不要与工具对抗，而是掌握它们。
成为那个知道何时可以让 AI 来赋能，何时又不能让 AI 来减负的人。
前几天发了一个关于 AI 的牢骚：《编码之道，道心破碎。》
和这个话题其实也挺贴切的。
分享一下评论区来自读者 xiangqi 的高赞评论，我很赞同：
- AI 取代不了你多年的研究时间，"遇到问题去查"和"本来就会"在实际的工作中依然会带来极大的效率和准确度的差异。比如上面的第二个问题你可以一眼秒，某些人可能要等到系统出问题、看了日志、困惑之后再去问 AI。
- 工具是外部工具，用得好他也许能提高学习速度，但是代替不了学习本身。而"已经完成的学习"就是护城河，任何人如果要进入专业领域都要经历这个过程，AI 给了他更好的效率就如过去几十年一直在进步的其他学习工具一样。（换句话说，富人的专家贴身私教方式，其实也算是提前用上 AI 了）
- 当前 AI 的普惠价值很多，但是在个人身上，我觉得主要是两点："让所有人都能以不是特别专业的方式进入一个新的领域解决问题"、"提高学习效率"。