當前位置: 華文世界 > 科技

「我已經厭倦了給愚蠢的AI程式碼找bug!」評論區炸鍋成吐槽大會

2024-08-23科技

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 看到了錯誤的方法,它就會不由自主地受其影響,即使你的提示非常嚴厲地告訴它不要那樣做。因此,你通常最好用積極的語言重新描述你想要的東西。

對於資深的編程開發者來說,令人痛心的還包括新程式設計師們對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 來完成任務。」