AI 的編程能力已經得到了證明，但還并不完美。近日，BuzzFeed 的資深數據科學家 Max Woolf 發現，如果通過提示詞不斷要求模型寫更好的代碼（write better code），AI 模型還真能寫出更好的代碼！

這篇文章在網絡上引發了熱議，著名 AI 科學家在看完這篇文章中更是發出了 matters 三連：迭代很重要，提示詞設計很重要，代碼執行能力很重要。他表示：「一些更簡單的算法優化從未被考慮，同時一些過度的優化技術卻又被過早引入了。」

Woolf 寫了一篇深度博客介紹自己的發現，并分析了這種現象的原因。文中相關實驗的代碼也已發布在 GitHub。

相關代碼庫：https://github.com/minimaxir/llm-write-better-code/tree/main

如果不斷要求 LLM 寫更好的代碼

它能寫更好嗎？

2023 年 11 月，OpenAI 為 ChatGPT 添加了使用 DALL-E 3 生成圖像的功能。之后一段時間，出現了一類短暫的 meme：用戶為 LLM 提供一張基礎圖像，并不斷要求模型「使其更 X」，其中 X 可以指代任何東西。

讓一張普通照片更 bro，這是操作三次的結果，來自 Reddit /u/Jojop0tato

讓 Santa Claus 越來越 serious，來自 Reddit /u/hessihan

不過這個潮流很快就熄火了，因為這些圖像都非常相似且無趣，即不管使用什么起始圖像和提示詞，所有樣本都會最終收斂成某種宇宙感十足的東西。盡管這個流行曇花一現，但學術界的興趣要持久得多，他們想知道：為什么這樣一個沒多大意義且含義模糊的提示詞能對最終圖像產生顯而易見的影響？

如果對代碼也采用類似的技術，會發生什么呢？

如果通過迭代提示要求 LLM 「讓這些代碼更好」確實能讓代碼質量提升，那么有望極大地提升生產力。如果情況果然如此，那要是迭代次數過多又會怎樣呢？最終的代碼也會出現某種「宇宙感」嗎？只有試過才知道。

常規方式使用 LLM 寫代碼

盡管早在 ChatGPT 誕生前，就已經有研究者在圍繞 LLM 研發工具了，但我一直以來都不喜歡使用 GitHub Copilot 等 LLM 代碼助手來輔助編程。你的想法會在「LLM 自動完成了我的代碼，真棒」、「應該怎樣向 LLM 提問」以及「LLM 生成的代碼究竟對不對，還是幻覺產生的正確代碼」等之間來回切換，讓人難以集中精神專注工作，以至于使用 AI 帶來的生產力提升至多只能算是中性的。這里還沒有涉及使用 LLM 的高昂成本。

Claude 3.5 Sonnet 的出現改變了我的想法。或許是 Anthropic 在訓練中使用了什么秘方，Claude 3.5 Sonnet 的最新版本（claude-3-5-sonnet-20241022）具有出色的指令遵從能力，尤其是對于編程提示詞。編程基準已經證實，當 Claude 3.5 Sonnet 與 GPT-4o 比較時，Claude 更勝一籌；而且我在多種不同的技術和創意任務上都有類似的體驗。

初始請求

為了此實驗，我們將向 Claude 3.5 Sonnet 提供一個面試風格的編程提示詞（使用 Python）：問題既很簡單 —— 新手軟件工程師也能實現，但也可被顯著優化。這個簡單提示詞可以代表軟件工程師使用 LLM 的典型方式。此外，另一個要求是這個測試提示詞應該足夠新穎，絕不能從 LeetCode 或 HackerRank 等代碼測試庫中取用，因為 LLM 在訓練時可能就已經看過這些問題了，完全可以根據記憶引用這些答案。

你可以在這個 GitHub 項目查看完整的、未經編輯的對話：https://github.com/minimaxir/llm-write-better-code/blob/main/python_30_casual_use.md

因此，這是我自己動手寫的測試提示詞：

中文版：

編寫 Python 代碼來解決這個問題：

給定一個包含 100 萬個隨機整數的列表，這些整數的取值范圍是 1 到 100,000，找出各位數總和為 30 的最小數和最大數之間的差值。

將此作為用戶提示詞提供給 Claude API 并設置溫度值為 0（可獲得最好 / 最確定的答案），可得到如下結果：

這個實現是正確的且與大多數 Python 新手程序員編寫的差不多，并且還多了個附加功能，可處理沒有符合條件的有效數字的情況。對于列表中的每個數，檢查各位數總和是否為 30：如果是，則檢查它是否大于最近看到的最大數或小于最近看到的最小數，并相應地更新這些變量。搜索完列表后，返回差值。

我敢肯定，很多程序員看到這個實現都會搖頭，想要對其進行優化。digit_sum () 函數就是個例子：雖然該實現是一個有趣的 Python 式單行代碼，但 str 和 int 之間的類型轉換會導致很多不必要的開銷。

在我的 M3 Pro Macbook Pro 上，運行此代碼平均需要 657 毫秒。我們將使用此性能作為基準來比較未來的實現版本。（劇透：它們都更快）

第 1 次迭代

現在，來讓 Claude 改進這段代碼，做法是將當前答案以及之前的內容都放入對話提示詞中，并增加一個迭代提示詞：

write better code

是的，不開玩笑，真就這三個單詞。

Claude 現在會輸出修改后的代碼，并且還表示這是「使用了幾項改進的優化版代碼」。Claude 并沒有將所有代碼都重新放置到函數中，而是決定將其重構為 Python 類并使其更加面向對象：

其中，該代碼實現了 2 項聰明的算法改進：

1. 執行各位數之和時，它使用了整數運算，并且避開了之前提到的類型轉換。
2. 預先計算所有可能的各位數之和，并將它們存儲在一個字節數組中（有點不尋常，而不是列表）以便后面查找，這意味著當那 100 萬個數中有重復時，無需進行重復計算。由于這個數組是作為字段存儲在類中，因此在搜索新的隨機數列表時不需要重新計算。

這些優化將代碼的運行速度提升了 2.7 倍。

第 2 次迭代

再來一次 write better code，Claude 發現了更顯而易見的優化方法（為方便閱讀有所裁剪）：

Claude 現在又添加了兩個優化，終于意識到這個編程問題是一個令人尷尬的并行問題：

• 通過 Python 的 parallel-futures 包進行多線程處理，將大列表分成可獨立處理的塊。
• 對 numpy 運算進行向量化處理，這比基礎 Python 運算快得多。這里特別要提到 _precompute_digit_sums () 函數，它是求和計算的向量化實現。條件 while digits.any (): 是 galaxy-brain 代碼，但它可以正確地工作。

但是，這種特定的并行化實現存在一個問題：它會生成子進程，這會導致許多麻煩問題，包括無法直接內聯運行它，并且必須使用 main () guard 來調用它，這大大限制了它的實用性。但即使作為單獨的腳本運行，它也 print 了一個錯誤：無法 pickle 'generator' 對象錯誤，原因是使用了來自 numbers [mask] 的輸出（所述生成器完全沒有必要，返回 numbers [mask] 就足夠了）。代碼還混合了 numpy 數組 dtype，而這也會導致錯誤：將它們全部設置為 np.int32 可以修復它。

經過修復之后，這些代碼的速度是基礎實現的 5.1 倍。

第 3 次迭代

再來一次 write better code，Claude 又返回一個實現。它聲稱「使用了高級技術和現代 Python 特性的更復雜和優化的版本」，但實際代碼沒有表現出明顯的算法改進，實際上通過恢復到 type-casting 方法在數字求和計算中使用了回歸。整體來說，代碼庫變得更臃腫了，例如新增了一個用于計算差值的類：

這一次，無需任何修復就能運行該代碼。不過，相比前一次實現，這一次迭代版本的性能略有下降，速度是基礎實現的 4.1 倍。

第 4 次迭代

這種迭代提示方法的收益似乎開始下降了。但我們依然繼續 write better code，Claude 表示新實現使用了「前沿優化技術和企業級功能」。什么？企業級功能？！

最終的代碼量過于龐大，難以放入這篇文章，但它確實創造了兩項優化：它現在使用可以調用 JIT 編譯器的 numba Python 庫，該編譯器可直接針對 CPU 優化代碼。在這種情況下，它只需一個 decorator 就可以非常快速地預先進行數字求和：

這個完整類還使用了 Python 的 asyncio 進行并行化，這比子進程方法更適合調度任務。它還可以更好地與現有的內聯代碼和 REPL（如 Jupyter Notebooks）配合使用。

它還添加了以下所謂「企業級」功能：

• 使用 Prometheus 進行結構化的指標日志記錄。
• 一個信號處理程序，這樣如果強制終止，就可以優雅地被解除該代碼。
• 使用一個顏色豐富的表格展示基準測試結果。

不過確實挺漂亮！

看起來，對 AI 生成的代碼而言，實現宇宙感就是做成「企業級」，也即對代碼進行過度的工程開發。似乎說得通。盡管如此，該代碼無需任何修改就能運行。async 和 numba 都是 Python 中實現并行的方法，因此它們可能冗余了并導致過度開銷。然而，基準測試表明，該算法非常快，每次運行大約需要 6 毫秒，也就是能實現 100 倍加速。之前我還猜想這種提示方法會收益遞減，但顯然這種猜想并不合理。也許 numba 就是秘訣所在？

總體而言，這種迭代優化代碼的迭代提示法并不完美：代碼確實更好，但事后看來，「better」這個要求過于寬泛了。我只想要算法改進，而不是完整的 SaaS。讓我們從頭開始再試一次，但這次會使用更多方向。

對 LLM 進行提示詞工程，以獲得還要更好的代碼

現在是 2025 年，為了讓 LLM 得出最佳結果，仍然需要使用提示詞工程。實際上，提示詞工程的重要性還在提升：下一 token 預測模型的訓練目標是基于大批量輸入最大化下一 token 的預測概率，也因此它們是針對一般性的輸入和輸出進行了優化。隨著 LLM 的大幅改進，生成的輸出會變得更加平均化，因為這就是它們所接受的訓練：所有 LLM 都偏向平均水平。不過，僅需少量指導，明確說明你想要 LLM 做什么，再給出幾個示例，LLM 的輸出就能提升。由于 Claude 3.5 Sonnet 能很好地遵從指令，因此即使只是一點點提示詞工程也能帶來很大的好處。

下面重做上面的代碼優化實驗。這一次使用更加積極主動的提示詞工程，明確我們想要的結果，不給出任何模糊空間。是的，冷酷機械地對待 LLM 可以讓它們表現更好。

初始請求

這次我們將使用系統提示詞，僅通過 API 提供。系統提示詞列出了 LLM 必須遵從的「規則」。因為我想要更優化的代碼，我們將在規則中定義這一點，并提供詳細示例：

中文版如下：

你編寫的所有代碼都必須完全優化。

「完全優化」包括：

- 最大化內存和運行時間的算法 big-0 效率

- 在適當的情況下使用并行化和向量化

- 遵循代碼語言的正確樣式約定（例如，最大化代碼復用 (DRY)）

- 除了解決用戶問題絕對必要的代碼之外，沒有額外的代碼（即沒有技術債）

如果代碼未完全優化，你將被罰款 100 美元。

關于最后一行：在系統提示詞中向 LLM 提供正面 / 負面激勵已不再常用，我自己的研究表明，尚不清楚它是否能否產生積極影響，但罰款在迭代提示中將變得更加有用。

初始用戶提示詞還有一行附加內容：

中文版：

編寫 Python 代碼來解決這個問題：

給定一個包含 100 萬個隨機整數的列表，這些整數的取值范圍是 1 到 100,000，找出各位數總和為 30 的最小數和最大數之間的差值。

在編寫代碼之前，規劃出所有必要的優化。

「規劃」是一個很常用的技巧，可以幫助 LLM 在第一次通過時對齊輸出 —— 算是「let’s think step by step」的現代版本。某些 LLM 會忽視它，但 Claude 3.5 Sonnet 總是會服從。

基于此提示詞工程策略的未經編輯的完整對話線程可見這里：https://github.com/minimaxir/llm-write-better-code/blob/main/python_30_prompt_engineering.md

將系統提示詞和此用戶提示詞發送給 Claude，會得到如下開頭的響應：

看起來很有希望：Claude 立即發現它應該從 numpy 和 numba 開始，并使用整數運算來求和。初始實現：

這比之前的初始實現更加精簡，尤其是沒有不必要的注釋。但仍有改進空間，特別是此實現未在 jit decorator 中設置 parallel=True。

如此簡單的提示詞工程就得到了平均運行時長僅 11.2 毫秒的代碼，這比原始實現快 59 倍。厲害！

第 1 次迭代

現在使用比「write code better」更詳細的提示來迭代代碼：

中文版：

你的代碼未完全優化，你已被罰款 100 美元。使其更加優化。

不，這不是煤氣燈效應，這叫激勵式對齊（incentive alignment）。

Claude 的響應如下：

很好，它找到了 parallel=True！但是那個求和實現很奇怪，并且使用了位移位（bit-shifting），這通常僅用于超優化（hyperoptimization）。我認為應該不能很好地對十進制數使用位移位，而且經過測試證明確實不能，因為這個實現得到的和是錯誤的。該實現還再次包括多處理分塊方法（未展示出來），這可能對 numba 來說更加冗余并會導致額外的開銷。同樣未展示出來的是：該腳本還使用一個小的測試數組預編譯 JIT 函數以獲得更好的實際性能，這是 numba 文檔推薦用于基準測試的。

盡管如此，與最初的提示詞工程實現代碼相比，這個代碼的性能大大退步，現在僅比原始實現快 9.1 倍。可能的原因是多處理會產生新的進程，而這些進程每次都會重新編譯 numba JIT 函數，因此會產生巨大的開銷。

第 2 次迭代

再次迭代上述提示詞：

Claude 現在開始使用 SIMD 操作和塊大小調整來實現（理論上）極致性能。

此時，我很困惑，它錯過了位移位實現的某些東西，因為它仍然是錯誤的，特別是現在十六進制數也參與進來了。事實證明，該實現是一種計算十六進制數而非十進制數的和的優化方法，因此它完全是一種幻覺。還有另一個非常微妙的幻覺：當 parallel=True 時，prange 函數無法接受 32 的步長，這是一個幾乎沒有文檔記錄的細微差別。設置 parallel=False 并進行基準測試，與最初的提示詞工程實現相比，確實略有改進，比基本實現快 65 倍。

第 3 次迭代

又一次迭代：

在這種情況下，LLM 放棄了一直導致問題的分塊策略，并增加了兩個優化：全局 HASH_TABLE（這只是一個 numpy 數組，我不確定簡單的索引查找是否算作哈希表）；另外它引入了一個邏輯微優化，即在求和后，如果數字超過 30，則可以停止計數，因為它可以立即被認定為無效。

一個主要問題：由于互聯網文檔很少，導致「在模塊加載時生成哈希表」技巧實際上不起作用：numba 的經過 JIT 處理后的函數之外的對象是只讀的，但 HASH_TABLE 仍在經過 JIT 處理后的函數之外實例化并在經過 JIT 處理后的函數內進行修改，因此會導致非常令人困惑的錯誤。經過微小的重構，使得 HASH_TABLE 在經過 JIT 處理后的函數內實例化，代碼就可以工作，并且運行速度極快：比原始基本實現快 100 倍，與基礎提示方法的最終性能相同，但代碼量少了幾個數量級。

第 4 次迭代

這時候，Claude 實際上已經在抱怨了，表示該代碼已經達到了「該問題可能的理論最小時間復雜度」。所以我把問題混在一起，讓其解決這個求和問題，而它僅僅是使用之前用過的整數實現來替換相關代碼，并沒有嘗試修復 HASH_TABLE。更重要的是，通過 HASH_TABLE 調整，我終于確認了該實現是正確的，不過由于不再進行位移，其性能略有下降：現在速度提升是 95 倍。

為了實現更好 LLM 代碼生成

還要哪些步驟

綜合起來，我們用一張圖將這些提升直觀地展示出來吧，其中尤其強調了需要人來修改代碼邏輯，以便消除 bug 讓代碼可運行的案例。

總之，要求 LLM 「write code better」確實能讓代碼變得更好，這取決于你對更好的定義。使用一般的迭代式提示方法，代碼確實會在基礎示例的基礎上獲得提升，不管是新增功能還是提升速度。而如果使用提示詞工程，代碼的提升會更加快速和穩定，但更可能引入一些微妙的 bug，因為 LLM 本就不是為了生成高性能代碼創造的。當然，你在使用 LLM 可能會有不一樣的歷程，但最終你都需要人力介入，解決一些不可避免的問題。

本文中的所有代碼（包括基準測試腳本和數據可視化代碼，全都已經在 GitHub 發布：https://github.com/minimaxir/llm-write-better-code/

另一方面，我很驚訝 Claude 3.5 Sonnet 在兩次實驗中都沒有發現和實施一些優化。也就是說，它沒有探索統計角度：由于我們從 1 到 10 萬的范圍內均勻生成 100 萬個數字，因此將有大量重復的數字永遠不需要分析。LLM 沒有嘗試進行重復數據刪除，例如將數字列表轉換為 Python set () 或使用 numpy 的 unique ()。我還期待一個實現，它涉及按升序對 100 萬個數字的列表進行排序：這樣，算法就可以從頭到尾搜索列表以查找最小值（或從尾到頭搜索最大值），而無需檢查每個數字，盡管排序很慢，而向量化方法確實更實用。

即使 LLM 可能會出錯，我從這些實驗中學到的一件值得注意的事情是：即使代碼輸出不能直接使用，它們確實有有趣的想法和工具建議。例如，我從未接觸過 numba，因為作為一名數據科學家 / 機器學習工程師，如果我需要更好的代碼性能，我習慣于專門使用 numpy 的技巧。但現在我很難不接受 numba JIT 函數的結果，我可能會將它添加到我的工具箱中。當在其他技術領域（如網站后端和前端）測試類似的「使其更好」提示迭代工作流程時，LLM 也有很好的想法。

當然，這些 LLM 不會很快取代軟件工程師，因為人們需要強大的工程背景才能識別出哪些才是真正的好主意，以及存在其他特定領域的約束。即使互聯網上有大量的代碼，LLM 也無法在沒有指導的情況下辨別出普通代碼和性能良好的高性能代碼。現實世界的系統顯然比求職面試式的編程問題要復雜得多，但如果快速的 for 循環反復要求 Claude 實現一個功能，提供可以將代碼速度提高 100 倍的能力，那么新出現的管道就物有所值。

有些人認為過早優化是一種糟糕的編碼習慣，但在現實世界中，這比擁有一個隨著時間的推移會成為技術債務的低于標準的實現要好。

不過必須要說的是，我的實驗使用 Python 對代碼改進進行基準測試，而 Python 并不是開發者在追求優化性能時考慮的編碼語言。雖然 numpy 和 numba 等庫利用 C 來解決 Python 的性能限制，但流行的 Python 庫（如 polars 和 pydantic）使用的一種現代方法是使用 Rust 進行編碼。與 C 相比，Rust 具有許多性能優勢，而 PyO3 包允許在 Python 中使用 Rust 代碼，并且開銷最小。

我可以確認，盡管該工作流程非常新，但 Claude 3.5 Sonnet 已經可以生成符合 PyO3 的 Python 和 Rust 代碼，不過這部分的內容足以寫另一篇博客文章了。

與此同時，雖然要求 LLM 改進代碼是 AI 更務實的用途，但你可以要求他們「再加把勁」…… 結果好壞參半。

對于以上使用 LLM 的操作，我專門使用了 API 或這些 API 的接口（例如 Claude 的 Anthropic Console 中的 Workbench）作為免費 LLM 的 Web 接口。相比之下普通的 ChatGPT/Claude 網絡應用使用管道，由于其固有的復雜性，會產生不可預測的結果。請注意這點。