會用ChatGPT≠工程師,Google資深員工發文,揭秘AI編程不為人知的真相

【導讀】蘇格拉底曾提到的門諾悖論(Meno’s paradox)認為,人只能學會自己已經知道的事情;而關於AI輔助編程,Google資深工程師最近的一篇博客告訴我們,類似的知識悖論同樣存在。

儘管程序員們紛紛反饋用上AI輔助之後,工作效率提升,但我們用到的軟件中bug依舊不少。

針對這一現象,前Google產品經理Peter Szalontay,以及現任的GoogleChrome的工程團隊領導Addy Osmani都給出了自己的分析,並提供了一些如何使用AI輔助編程的建議。

AI編碼工具的黑暗真相

1月7日,前Google產品經理Peter Szalontay發推,並配上了一個令人驚心動魄的標題: 「無人談論的AI編碼工具的黑暗真相」。 

「在華麗的demo和病毒式推文的背後,隱藏著半途而廢的項目和破碎的承諾。」

Peter Szalontay表示,作為Lazy AI的首席執行官,他在18個月的時間的時間中目睹了超過10萬名開發人員的苦苦掙扎,因此要為所有構建AI項目的開發者提供幾條建議。

Peter Szalontay本科畢業於加州大學洛杉磯分校,修讀了數學/經濟學和軟件工程專業,2016年-2019年期間曾擔任Google產品經理,領導著一支由1000多名員工組成的團隊,並推出了響應式搜索廣告(Responsive Search Ad)。

2023年3月,Szalontay成立初創公司Lazy AI並擔任CEO,旨在幫助用戶通過無代碼或低代碼的方式構建全棧Web應用程序。

1/ 智能體編碼≠打雜

「50%的AI編寫的代碼都毫無價值」。如果你試過Bolt、v0、Replit等工具來構建登錄頁面以外的東西,一定對這句話深有感觸。

因為每次代碼更改時,都有可能因prompt引入一些bug或不需要的行為。如果LLM每次對代碼進行5項更改,那麼代碼完成時,可能會出現許多個你自己都不知道怎麼會觸發的bug。

Lazy AI採取的方式是按照工程師的方式進行構建:發送prompt、測試更改,然後發送另一個prompt。這是獲得有效成果的唯一途徑。

2/ 「通用編碼器」是一個謊言

如果一家公司站出來說他們已經開發了一款產品,可以讓你只用prompt在任何框架中構建任何應用程序……冷靜點,這種說法很可疑。

Lazy AI首次嘗試同時支持Python和JavaScript編碼時,讓AI在JS文件中編寫Python,結果它混淆了依賴關係,甚至弄混了兩種語言的註釋語法。

最終確實有方法讓AI在兩種語言中都能可靠地工作——但只有為編程語言構建特定的修復程序,並驗證模型的每個響應之後才能做到。

3/ 不要把授權交給LLM

你可以在任何AI編碼工具中嘗試這個簡單的提示:「構建一個Google登錄頁面,並跳轉到顯示我的詳細信息的個人資料頁面。」

之後你就會看到層出不窮、千奇百怪的錯誤和bug:被破壞的OAuth流程,重定向URI錯誤,以及在Google Cloud Console中無休止地打轉以獲取API密鑰。

4/ LLM無法訪問數據庫

幾乎每個想法的實現都需要一個數據庫,但構建項目時,又總是需要更改數據庫。如果AI編碼工具按提示收費,那麼準備好迎接下面這些不斷重覆的場景:

你更改了數據庫,AI Agent混亂了……

你修改了了代碼,數據庫混亂了……

你需要遷移,結果AI編寫了有缺陷的遷移代碼……

5/ 現在付款,但永遠沒法成功

下面這些AI常見的智障錯誤,不知道你是否眼熟:

– 要求AI構建新功能時,AI卻刪除了一部分之前的內容

– AI複製了你的部分代碼 

– 你明確指示執行X操作,AI卻正在執行Y 

– AI因為無法修復自己創建的bug而卡住

當你現在為AI編碼工具付費時,期待模型在未來「變得更好」是不夠的,一個放錯位置的括號可能會破壞整個頁面。 在一個沒有從頭開始準備的平台上構建現實世界中的應用程序,就是在浪費錢。 

以上這些推文的內容或許過於簡明扼要,而且傾向性過強。如果要想更全面、更深入地探究AI輔助編碼的利弊,以及最佳的使用方法,GoogleChrome工程團隊領導Addy Osmani的這篇博客則更加有用。

原文鏈接:https://addyo.substack.com/p/the-70-problem-hard-truths-about 

AI輔助編程——新秀和老手的差距

對AI輔助編程工具的使用,存在兩種模式,第一種可以稱為「自舉模式」(bootstrapper),也就是使用諸如Bolt之類的工具,根據截圖產生代碼,使得程序員能夠在AI協助下完成初始代碼庫,從而在數小時或數天而非數週的時間,生成最小可用原型。

相比於從零開始,程序員更熟悉的方式是如下描述的「迭代模式」,即使用Cursor、Copilot等工具進行日常開發工作流程。

例如,使用人工智能進行代碼補全、進行複雜重構任務、生成測試和文檔,或是將AI智能體當作「小助手」,諮詢編程中遇到的問題,並尋求代碼改進建議。

在迭代模式下,新手和老油條看似都能在幾分鐘之內使用AI工具完成代碼搭建,但細看下來,資深程序員對AI的使用更加智慧。

他們不僅僅是接受AI的建議,而是試圖讓AI重構代碼,生成更小、更專業化的模塊。資深程序員還會增加AI遺漏的意外情況的處理模塊,同時對AI給出的建議保持質疑。

相反,新手則會盲從AI的建議,這樣生成的代碼會如同海邊的沙堡,看似堅固,但一遇到現實中的意外案例,就會崩潰。

這是由於,「新秀」會接受AI給出的錯誤或過時的代碼,忽略關鍵的安全性和性能考慮,也沒有對AI生成的代碼進行調試,從而構建出一個他們不完全理解的脆弱系統。

以上的差異可以說明,AI工具對經驗豐富的開發者幫助大於初學者。這似乎有些反直覺——AI不應該使編程變得更加人人可及嗎?

知識悖論——只有知道怎麼用才能用好

事實上,當前的AI,就像是在團隊中有一個工作積極性爆棚的初級開發者。他們可以快速編寫代碼,但需要不斷的監督和糾正。你知道的越多,就能更好地引導他們。

不止是在程序員群體之中,非工程師使用AI進行編碼時,也會遇到類似的問題,即發現自己遇到了令人沮喪的瓶頸。AI工具能出人意料地迅速完成70%的任務,但在最後、最難完成、最令人沮喪的30%上,卻只會收益遞減。

可以舉一個小例子來理解這個現象。比如,你試圖讓AI修復程序中的一個小bug,智能體給出一個看似合理的建議,但這個補丁破壞了其他部分。

接著,用戶會繼續要求AI修復新出現的問題,這又產生了更多的bug,從而使得局面變得更糟。這意味著最後的30%——使軟件準備進入生產、可維護和健壯的部分——仍然需要真正的工程知識。

人工智能並沒有使我們的軟件顯著改進,因為軟件質量可能從未主要受限於編碼速度。軟件開發中的難點——理解需求、設計可維護的系統、處理意外情況、確保安全和性能——仍然需要人類的判斷。

AI所做的,是讓我們能夠更快地進行迭代和實驗,通過更快的探索,可能帶來更好的解決方案。但前提是程序員必須保持工程規範,將AI作為工具,而不是替代良好軟件實踐的替代品。

記住:目標不是更快地編寫更多代碼。而是構建更好的軟件。如果使用得當,人工智能可以幫助我們做到這一點。但最終,我們仍需知道「更好」的含義以及如何實現它。

當下對AI輔助編程濫用的背後,還有一個更深層次的問題:AI工具讓編碼變得人人可行的實質,是代替你處理了程序的複雜性。從另一個角度來看,這實際上可能會阻礙新手的學習與成長。

AI只是把代碼放在你面前,並不能讓你理解其背後的原理時。由於新手缺少調試經驗,而這會反過來導致了一種對AI工具的依賴。他們需要不斷回到AI那裡去修復問題,而不是培養自己處理這些問題的專業知識。

如何使用AI編程——幾條建議

有鑒於AI輔助編程中的「知識悖論」,當前的人工智能工具最好被用於快速驗證想法,並用來生成最小可用的原型,或者作為有助於編程學習的輔助工具。

對於如何用好這些工具,作者給出了如下建議:

1. 從原型做起,使用AI進行快速原型設計

2. 使用人工智能處理孤立、定義明確的任務,逐步構建更大的功能

3. 花時間理解生成的代碼是如何工作的,並審核每一行代碼

4. 保持「模塊化」,將代碼分拆為功能單一的模塊和小文件,保持組件之間的清晰接口,記錄模塊的邊界

5. 在應用AI輔助編程的同時,學習基本編程概念,逐步建立知識基礎

6. 將人工智能作為學習工具,加速學習,而不僅僅是代碼生成器

7. 最重要的是,相信自己的判斷力,利用人工智能加速,而非取代判斷力

但以上這些都需要耐性和努力——這與許多人最初希望通過AI工具實現的目標正好相反。 

具體來說,在編程時,有益的AI工具使用可分為三種模式:

一是「AI初稿」模式:即讓AI生成一個基礎版代碼庫,之後程序員手動審查和重構以提高模塊化程度,並增加全面錯誤處理、撰寫詳盡的測試,同時記錄關鍵決策。

第二種是是恒定對話模式,即為每個不同的任務啟動新的AI聊天,在對話時保持語境集中且簡潔,程序員經常審查代碼並提交更改,在此過程中保持緊密的反饋回路。

第三種被稱為「信任但核實」模式,程序員使用AI進行初始代碼生成,對所有關鍵路徑進行手動審查,同時對可能的異常案例進行自動化測試,並定期進行安全審核。

展望未來——AI對程序員意味著什麼

儘管存在由於知識悖論帶來的挑戰,對人工智能在軟件開發中的作用,我們應持樂觀態度。這其中的關鍵在於,理解AI真正擅長的是什麼:

人工智能擅長幫助實施我們已理解的模式。它就像有一個無限耐性的、打字速度極快的程序員搭子,非常適合快速原型設計和探索不同的方法;也像一個沙盒,可以用於快速測試概念。

此外,AI還顯著縮短了處理模板和常規編碼任務所需的時間,並能自動處理日常事務,使程序員能夠專注於有趣的問題。

人工智能輔助開發的格局在2025年將發生巨大變化。儘管當前的工具已經改變了原型設計和迭代方式,但我們正站在一個更加重大變革的邊緣:即AI智能體軟件工程的興起。

未來的輔助編程系統,不僅僅是響應提示,它們還能規劃、執行並不斷迭代解決方案。

當前工具大多等待程序員的指令,但看看像Anthropic在Claude中實現的計算機使用,或Cline自動啟動瀏覽器和運行測試的新功能。這些不僅僅是美化版的自動補全——它們實際上是在理解任務並主動解決問題。

而自主編程AI不僅僅是提出修復方案,它還可以主動識別潛在問題,啟動並運行測試套件,檢查UI元素並捕獲屏幕截圖,提出並實施修復方案以及驗證解決方案是否有效。

下一代輔助工具可能不僅限於與代碼協同工作——它們可能實現無縫集成:視覺理解(UI截圖、原型、圖表)與語言交互(瀏覽器、終端、API)。

這種多模態能力意味著,AI工具可以像人類一樣理解和處理軟件——全面地,而不僅僅是代碼層面。

從使用這些工具的工作中,我們應意識到:未來並非關於 AI 取代開發者——而是 AI 成為一個越來越有能力的合作夥伴,它可以在尊重人類指導和專業知識的同時採取主動。

這種對開發工具交互方式的根本轉變,意味著在自然語言中清晰思考和精確溝通的能力正變得與傳統編碼技能一樣重要。

具體來說,2025 年最有效的團隊需要學會如下四點:

1. 明確為他們的 AI 智能體設定邊界和指南

2. 建立強大的架構模式,使智能體能夠在其中工作

3. 構建人類與AI能力之間的有效反饋循環

4. 保持人工監督的同時利用AI的自主性

這些都要求程序員提升技能,具備更強的系統設計和架構思維,更優的需求規範和溝通,更多關注質量保證和驗證,並提升人機協作能力。

參考資料: 

https://addyo.substack.com/p/the-70-problem-hard-truths-about 

https://x.com/Szypetike/status/1876647482295259411 

本文來自微信公眾號「新智元」,編輯:peter東 祖楊 ,36氪經授權發佈。