轉譯：為什麼大語言模型無法真正構建軟體 作者：Conrad Irwin 我花了大量時間做的一件事就是面試軟體工程師。這顯然是一項艱巨的任務，我不敢說自己有什麼絕招；但這段經歷確實讓我有時間去反思，一個高效的軟體工程師究竟在做什麼。 軟體工程的核心循環 當你觀察一個真正的行家時，你會發現他們總在循環執行以下幾個步驟： * 構建一個關於需求的心理模型。 * 編寫（希望如此？！）能夠實現需求的程式碼。 * 構建一個關於程式碼實際行為的心理模型。 * 找出兩者之間的差異，然後更新程式碼（或需求）。 完成這些步驟的方式有很多種，但高效工程師的過人之處，就在於他們能夠構建並維持清晰的心理模型。 大語言模型表現如何？ 平心而論，大語言模型在編寫程式碼方面相當出色。當你指出問題所在時，它們在更新程式碼方面也做得不錯。它們還能做所有真人工程師會做的事：閱讀程式碼、編寫並運行測試、添加日誌，以及（大概）使用除錯器。 但它們無法做到的是，維持清晰的心理模型。 大語言模型會陷入無盡的困惑：它們會假設自己寫的程式碼真的能用；當測試失敗時，它們只能猜測是該修復程式碼還是修復測試；當感到挫敗時，它們乾脆把所有東西刪掉重來。 這與我所期望的工程師特質恰恰相反。 軟體工程師會邊工作邊測試。當測試失敗時，他們可以對照自己的心理模型，來決定是修復程式碼還是修復測試，或者在做決定前先收集更多資訊。當他們感到挫敗時，可以通過與人交流來尋求幫助。儘管他們有時也會刪掉一切重來，但那是在對問題有了更清晰理解之後才會做出的選擇。 但很快就行了，對吧？ 隨著模型能力越來越強，這種情況會改變嗎？也許吧？？但我認為這需要模型在構建和優化方式上發生根本性的變化。軟體工程需要的模型，不僅僅是能生成程式碼那麼簡單。 當一個人遇到問題時，他們能夠暫時搁置全部的上下文，專注於解決眼前的問題，然後再恢復之前的思緒，回到手頭的大問題上。他們也能夠在宏觀大局和微觀細節之間自如切換，暫時忽略細節以關注整體，又能在必要時深入研究局部。我們不會僅僅因為往自己的“上下文窗口”裡塞進更多詞語，就變得更高效，那只會讓我們發瘋。 即便我們能處理海量的上下文，我們也知道當前這些生成式模型存在幾個嚴重的問題，這些問題直接影響了它們維持清晰心理模型的能力： * 上下文遺漏：模型不擅長發現被忽略的上下文資訊。 * 新近度偏見：它們在處理上下文窗口時，會受到嚴重的新近度偏見影響。 * 幻覺：它們常常會“幻想”出一些本不該存在的細節。 這些問題或許並非無法克服，研究人員也正在努力為模型增加記憶，讓它們能像我們一樣施展類似的思維技巧。但不幸的是，就目前而言，它們（在超出一定複雜度後）實際上無法理解到底發生了什麼。 它們無法構建軟體，因為它們無法同時維持兩個相似的“心理模型”，找出其中的差異，並決定是該更新程式碼還是更新需求。 那麼，現在該怎麼辦？ 顯然，大語言模型對軟體工程師來說很有用。它們能快速生成程式碼，並且在整合需求和文檔方面表現出色。對於某些任務來說，這已經足夠了：需求足夠清晰，問題足夠簡單，它們可以一蹴而就。 話雖如此，對於任何有點複雜度的任務，它們都無法足夠精確地維持足夠的上下文，來通過迭代最終產出一個可行的解決方案。你，作為軟體工程師，依然需要負責確保需求清晰，並保證程式碼真正實現了其宣稱的功能。 在 Zed，我們相信未來人類和 AI 智能體可以協同構建軟體。但是，我們堅信（至少在目前）你才是掌控方向盤的駕駛員，而大語言模型只是你觸手可及的又一個工具而已。