“我已經厭倦了給愚蠢的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技術棧??，作者：伊風
