“我已经厌倦了给愚蠢的AI代码找bug！”一独立开发者彻底被无知的代码生成者逼疯！ 原创

编辑 | 伊风

Hacker News 上一篇帖子得到了广泛共鸣！一位开发者，已经彻底被逼疯了！因为他已经被客户无休止地让他修改AI 生成代码修改到“吐”！

为什么会这样？

图片

这位故事主角并不讨厌AI编程，相反，他还是Copilot的忠实用户。

真正令他厌恶的是，是许多代码中的错误暴露了用户几乎没有任何编程基础！并且客户还一次次向他发出请求，希望他继续帮助构建他们的应用。

在处理了n次类似于“帮帮我！我的交易机器人不工作了！”的求助之后，他终于怒发文章吐槽让他抓狂的那些bug。

在这篇文章的共鸣中，有网友继续吐槽，也有网友反思不只AI自己也经常会写弱智代码的时刻，更有开发者总结自己的AI编程经验、甚至推荐测试工具。从一条条贴文中，AI与编程之间的关系被思考得愈发深入，也愈发深刻。

1.烦不胜烦，客户频繁让自己修改AI生成代码

发帖的小哥是一位个人开发者。

就在今年年初，他出于个人使用和提高 Rust 编程经验的目的，构建了一些加密货币交易和数据收集工具。他进入了一些群聊进行交流，意外地发现他的工具有广泛的使用需求，甚至很多人愿意付费使用！

发现商机后，小哥立即设置了一些 API 端点，供人们免费访问数据，并以小额佣金提交交易。

小哥兴奋地说到“我开始有了一些客户，这是一次非常酷的体验，因为这是第一次有人为我自己构建的软件付费！我为功能公告和支持创建了一个 Telegram 频道，起初效果很好。但随着客户群体的慢慢增长，支持工作占用了我越来越多的时间。我知道这是任何 SAAS 初创企业都会遇到的情况，所以支持负担增加并不令人惊讶，毕竟，更多的客户是个好问题！”。

然而，真正困扰他的问题来了，“让我烦恼的不是请求数量，而是我收到的支持请求的质量。”

根据小哥的贴文说，他的工具对于有编程基础的人是很好上手的。“我的 API 只是几个文档详细说明的端点。如果你能搞清楚如何使用任何编程语言发送 POST 请求，你应该没有问题使用它。”

然而，讽刺的是“这对新一代的提示工程师编码员来说似乎是个过高的要求。”

AI编程工具的确降低了人们编写代码的门槛，然而，他们对编程的耐心和学习意愿也同样的低。

小哥说“自从开设支持频道以来，我处理了很多“帮帮我！我的交易机器人不工作了！”的支持请求。通常情况下，客户发来的代码基本没问题，但会有一些显而易见的错误，只要读过文档并有一定编程能力的人都能看出来。通常这种错误表现为试图访问一个不存在的端点，或者读取一个 API 响应中不存在的属性。在进一步探查之后，我的怀疑通常会得到证实——ChatGPT 幻觉了那个端点或属性，而与我交谈的客户几乎没有编程知识。”

对于请求，他还是尽量在帮助，然而却发现了许多用户会得寸进尺地“白嫖”他的劳动。

“我会帮助他们修复这些幻觉——这不费什么力气，还能培养一个潜在的付费客户。但通常情况下，客户设想的是一个更复杂的应用程序，而我只能告诉他们，“抱歉，您需要雇用一名专业开发人员来做这件事。” 

最糟糕的情况是请求开始时很简单——我帮他们修复了一个幻觉——但接下来那个客户想要构建更复杂的逻辑，而我似乎已经让他们认为我会无限期提供免费的支持。我收到过很多愤怒的信息，这些客户基本上是希望我免费为他们构建整个应用程序。”

最后，他感慨地说：我相信这些挑战对任何运营 SAAS 业务支持的人来说都很熟悉，但 AI 编程工具加剧了这个问题。帮助客户解决问题通常是非常有成就感的，但前提是我能为那些自己能完成大部分工作的客户扫清障碍。当客户因为自己没有能力而将软件工程任务转交给 AI 时，他们仍然需要找到开发人员来修复 AI 生成的错误。而我并不想成为那个开发人员！

2.评论区上演脱口秀：AI代码玩出了扫雷的感觉

在Hacker News的评论区， 许多人纷纷吐槽那些年AI不“增效”，只增工作量的瞬间。

一个用户说分享了自己的工作插曲：“当时我的同事问我，为什么他看似微不足道的 10 行代码会莫名其妙地出现错误。原来他有两个变量 `file_name` 和 `filename`，并用其中一个代替了另一个。我问他怎么会有这样的代码，他说是用 copilot 创建的。在不了解生成式人工智能的作用的情况下使用它的代码绝对不是一个好主意。”

图片

AI的这个bug在 Python 中经常会出现，因为它变量名的区分很严格的，甚至一个小小的拼写错误都可能导致不同的变量被创建。如果碰巧你又在后面的复制粘贴中分别使用了这两个变量——那么代码检查器也救不了你了。

比AI搞出一个bug更让人心烦的是，AI修复bug会把一切搞乱。在评论区AI编程界的王者Claude也遭到了无情吐槽：

“Claude给了我类似的bug，只不过这两个变量都用到了，而且都是全局变量，它搞不清楚什么时候该用哪个，要求它重构/修复它就更糟了，因为它会搞不清楚，把它们合并成一个变量——问题是它们的用途略有不同，这就破坏了一切，我不得不逐行检查代码来修复它。”

好家伙，工作量立即翻倍。所以该网友无奈地说，“对我来说，使用 Claude 还是比较快的，因为我可能要花一周的时间来编写代码。不过，可能到处都隐藏着这样的陷阱，这些陷阱总有一天会露出丑陋的面目。真希望有一个好的测试生成工具来配合代码生成工具......”

图片

上面的网友硬是把编程玩出了扫雷的感觉。

不过，他的想法很快得到了回复。真的有人做了相关的工具，帮助大家修改AI做的bug。

这位热心人说：“我在与 LLM 进行大量编码工作时发现，最好更新初始提示并重新开始，而不是要求修正。上下文中的错误似乎会 "污染 "结果，即使您明确要求修正，也会不断出现更多问题。这确实有一定道理，因为众所周知，LLM 对正面示例的反应要比负面示例好得多。如果 LLM 看到了错误的方法，它就会不由自主地受其影响，即使你的提示非常严厉地告诉它不要那样做。因此，你通常最好用积极的语言重新描述你想要的东西。实际上，我创建了一个人工智能编码工具来帮助实现备份和重新提示的工作流程：

​​https://github.com/plandex-ai/plandex”（感兴趣的朋友可以移步试一下）​​

图片

对于资深的编程开发者来说，令人痛心的还包括新程序员们对AI代码不经思考的依赖。

他痛心地说：“我们公司新招了一个人。在他的第一项任务中，他选择了编写一些 bash 代码，但纯粹是胡说八道。我的意思是，它包含了一些东西，比如：if [ -z "${Var}+x" ] 我明白他写这些是想做什么，但代码就是错的。我不介意人们不知道东西，尤其是当它本质上是 Bash 琐事的时候。但最让我伤心的是，我指出了问题所在，并链接了文档，但得到的回复却是 "我不知道这是什么意思，我只是用了 copilot"，然后他就直接删除了代码。真是浪费了一个学习的机会！”

图片

3.AI只是“副驾驶”，编程实力仍最重要

“AI编程工具、AI软件工程师会让人们失业”这种恐惧正在逐渐褪色。

人们希望AI不要再“喧宾夺主”，而是无缝地融入自己原本的编程工作中，越是自然，就越是好用！

一位开发者说到，“最好的 AI 集成是那些你几乎不会特别注意到的功能，它们无缝地融入到技术栈中，像拼写检查和代码检查器（linters）一样自然地被使用。换句话说，这些 AI 功能变得如此常见和方便，以至于用户感觉它们就是技术工具的一部分，而不需要特别强调或引用。”

图片

有网友在评论中为人工智能说句“公道话”：他真的就是有用用用用用啊！错的是那些想要天降神力使得一切都自动化了的蠢蛋！

图片

这说明，随着对AI的祛魅，大家看待AI越来越客观了。人们也相信无论是怎样强大的AI，目前都不可能把人变成开发者。

网友坦白说：“我做过很多复制粘贴的工作，但在不了解情况的情况下直接复制粘贴是行不通的。我认为 "人工智能 "代码的问题在于很多人几乎像信奉宗教一样相信AI。

互联网上有一些极客说，AGI 还需要几年时间。推而广之，目前的人工智能模型不该被视为在编写代码时不会犯错的东西。”

图片

况且，即使不存在人工智能，程序员也还是会写bug，那些低级错误并没有从代码世界里消失。

有人就反思说：“至少对我来说，像这样的愚蠢错误在调试时是最浪费时间的，而且不涉及人工智能。比如不小心在某个地方加了引号，或者不小心在变量中加了一个 "s"，我可能一开始都没正确处理出错信息所报告的内容。事后总觉得自己有点傻。”

图片

而AI在纠错中也是可以立功的。通过代码检查或询问 ChatGPT 出了什么问题，一般的错误能被排查。网友说，“我刚才还在想为什么 TSC_COMPILE_ERROR 没有跳过 TypeScript，因为我在环境变量中拼写的是 TSX_COMPILE_ERROR。”

AI只是给了人们选择更多工具的机会。一位网友说：“不仅要问 ChatGPT 出了什么问题，还要使用默认会进行自我反省的代理。每次看到有人使用裸聊天界面来生成代码，我都很难过。如今，我们已经有了更好的 API 工具。至少使用 Aider （类似于AI拼写检查器或代码检查器（linters））吧。”

4.写在最后：避免掉进兔子洞

AI编程工具没有什么魔力，尝试和总结是通向成熟的必经之路。

AI就像一位稚嫩的助手，但随着磨合，你们能有更加默契和高效的合作。

图片

然而，如果磨合的并不愉快，放弃也不是不可接受的。

就像一位网友的分享，他说：“在我的职业生涯中，有很多次，当我遇到预计是一次性的问题需要快速解决时，我会用我不熟悉的工具寻找快速而简单的解决方案。我想说的是，70% 的情况下，经过测试后 "就能 "很好地解决问题；10% 的情况下，虽然没有很好地解决问题，但我觉得这是一个很有前途的方法，而且我有动力去学习更多的知识，以便让它发挥作用；剩下的 20% 的情况下，我发现它比我想象的要复杂得多，所以宁愿放弃这种方法，转而使用其他方法；我从未对后者感到后悔。”

“很显然，这样我失去了很多学习的机会，但我也确信，我避免了自己陷入很多很深的兔子洞。例如，我已经决定不再尝试掌握 sed&awk——我会直接放弃使用它们，而选择用 Python 来完成任务。”

本文转载自​​51CTO技术栈​​，作者：伊风