AI 的編程能力已經(jīng)得到了證明，但還并不完美。近日，BuzzFeed 的資深數(shù)據(jù)科學(xué)家 Max Woolf 發(fā)現(xiàn)，如果通過(guò)提示詞不斷要求模型寫更好的代碼（write better code），AI 模型還真能寫出更好的代碼！

這篇文章在網(wǎng)絡(luò)上引發(fā)了熱議，著名 AI 科學(xué)家在看完這篇文章中更是發(fā)出了 matters 三連：迭代很重要，提示詞設(shè)計(jì)很重要，代碼執(zhí)行能力很重要。他表示：「一些更簡(jiǎn)單的算法優(yōu)化從未被考慮，同時(shí)一些過(guò)度的優(yōu)化技術(shù)卻又被過(guò)早引入了。」

Woolf 寫了一篇深度博客介紹自己的發(fā)現(xiàn)，并分析了這種現(xiàn)象的原因。文中相關(guān)實(shí)驗(yàn)的代碼也已發(fā)布在 GitHub。

相關(guān)代碼庫(kù)：https://github.com/minimaxir/llm-write-better-code/tree/main

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

它能寫更好嗎？

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

讓一張普通照片更 bro，這是操作三次的結(jié)果，來(lái)自 Reddit /u/Jojop0tato

讓 Santa Claus 越來(lái)越 serious，來(lái)自 Reddit /u/hessihan

不過(guò)這個(gè)潮流很快就熄火了，因?yàn)檫@些圖像都非常相似且無(wú)趣，即不管使用什么起始圖像和提示詞，所有樣本都會(huì)最終收斂成某種宇宙感十足的東西。盡管這個(gè)流行曇花一現(xiàn)，但學(xué)術(shù)界的興趣要持久得多，他們想知道：為什么這樣一個(gè)沒(méi)多大意義且含義模糊的提示詞能對(duì)最終圖像產(chǎn)生顯而易見(jiàn)的影響？

如果對(duì)代碼也采用類似的技術(shù)，會(huì)發(fā)生什么呢？

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

常規(guī)方式使用 LLM 寫代碼

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

Claude 3.5 Sonnet 的出現(xiàn)改變了我的想法?；蛟S是 Anthropic 在訓(xùn)練中使用了什么秘方，Claude 3.5 Sonnet 的最新版本（claude-3-5-sonnet-20241022）具有出色的指令遵從能力，尤其是對(duì)于編程提示詞。編程基準(zhǔn)已經(jīng)證實(shí)，當(dāng) Claude 3.5 Sonnet 與 GPT-4o 比較時(shí)，Claude 更勝一籌；而且我在多種不同的技術(shù)和創(chuàng)意任務(wù)上都有類似的體驗(yàn)。

初始請(qǐng)求

為了此實(shí)驗(yàn)，我們將向 Claude 3.5 Sonnet 提供一個(gè)面試風(fēng)格的編程提示詞（使用 Python）：?jiǎn)栴}既很簡(jiǎn)單 —— 新手軟件工程師也能實(shí)現(xiàn)，但也可被顯著優(yōu)化。這個(gè)簡(jiǎn)單提示詞可以代表軟件工程師使用 LLM 的典型方式。此外，另一個(gè)要求是這個(gè)測(cè)試提示詞應(yīng)該足夠新穎，絕不能從 LeetCode 或 HackerRank 等代碼測(cè)試庫(kù)中取用，因?yàn)?LLM 在訓(xùn)練時(shí)可能就已經(jīng)看過(guò)這些問(wèn)題了，完全可以根據(jù)記憶引用這些答案。

你可以在這個(gè) GitHub 項(xiàng)目查看完整的、未經(jīng)編輯的對(duì)話：https://github.com/minimaxir/llm-write-better-code/blob/main/python_30_casual_use.md

因此，這是我自己動(dòng)手寫的測(cè)試提示詞：

中文版：

編寫 Python 代碼來(lái)解決這個(gè)問(wèn)題：

給定一個(gè)包含 100 萬(wàn)個(gè)隨機(jī)整數(shù)的列表，這些整數(shù)的取值范圍是 1 到 100,000，找出各位數(shù)總和為 30 的最小數(shù)和最大數(shù)之間的差值。

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

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

我敢肯定，很多程序員看到這個(gè)實(shí)現(xiàn)都會(huì)搖頭，想要對(duì)其進(jìn)行優(yōu)化。digit_sum () 函數(shù)就是個(gè)例子：雖然該實(shí)現(xiàn)是一個(gè)有趣的 Python 式單行代碼，但 str 和 int 之間的類型轉(zhuǎn)換會(huì)導(dǎo)致很多不必要的開(kāi)銷。

在我的 M3 Pro Macbook Pro 上，運(yùn)行此代碼平均需要 657 毫秒。我們將使用此性能作為基準(zhǔn)來(lái)比較未來(lái)的實(shí)現(xiàn)版本。（劇透：它們都更快）

第 1 次迭代

現(xiàn)在，來(lái)讓 Claude 改進(jìn)這段代碼，做法是將當(dāng)前答案以及之前的內(nèi)容都放入對(duì)話提示詞中，并增加一個(gè)迭代提示詞：

write better code

是的，不開(kāi)玩笑，真就這三個(gè)單詞。

Claude 現(xiàn)在會(huì)輸出修改后的代碼，并且還表示這是「使用了幾項(xiàng)改進(jìn)的優(yōu)化版代碼」。Claude 并沒(méi)有將所有代碼都重新放置到函數(shù)中，而是決定將其重構(gòu)為 Python 類并使其更加面向?qū)ο螅?/span>

其中，該代碼實(shí)現(xiàn)了 2 項(xiàng)聰明的算法改進(jìn)：

1. 執(zhí)行各位數(shù)之和時(shí)，它使用了整數(shù)運(yùn)算，并且避開(kāi)了之前提到的類型轉(zhuǎn)換。
2. 預(yù)先計(jì)算所有可能的各位數(shù)之和，并將它們存儲(chǔ)在一個(gè)字節(jié)數(shù)組中（有點(diǎn)不尋常，而不是列表）以便后面查找，這意味著當(dāng)那 100 萬(wàn)個(gè)數(shù)中有重復(fù)時(shí)，無(wú)需進(jìn)行重復(fù)計(jì)算。由于這個(gè)數(shù)組是作為字段存儲(chǔ)在類中，因此在搜索新的隨機(jī)數(shù)列表時(shí)不需要重新計(jì)算。

這些優(yōu)化將代碼的運(yùn)行速度提升了 2.7 倍。

第 2 次迭代

再來(lái)一次 write better code，Claude 發(fā)現(xiàn)了更顯而易見(jiàn)的優(yōu)化方法（為方便閱讀有所裁剪）：

Claude 現(xiàn)在又添加了兩個(gè)優(yōu)化，終于意識(shí)到這個(gè)編程問(wèn)題是一個(gè)令人尷尬的并行問(wèn)題：

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

但是，這種特定的并行化實(shí)現(xiàn)存在一個(gè)問(wèn)題：它會(huì)生成子進(jìn)程，這會(huì)導(dǎo)致許多麻煩問(wèn)題，包括無(wú)法直接內(nèi)聯(lián)運(yùn)行它，并且必須使用 main () guard 來(lái)調(diào)用它，這大大限制了它的實(shí)用性。但即使作為單獨(dú)的腳本運(yùn)行，它也 print 了一個(gè)錯(cuò)誤：無(wú)法 pickle 'generator' 對(duì)象錯(cuò)誤，原因是使用了來(lái)自 numbers [mask] 的輸出（所述生成器完全沒(méi)有必要，返回 numbers [mask] 就足夠了）。代碼還混合了 numpy 數(shù)組 dtype，而這也會(huì)導(dǎo)致錯(cuò)誤：將它們?nèi)吭O(shè)置為 np.int32 可以修復(fù)它。

經(jīng)過(guò)修復(fù)之后，這些代碼的速度是基礎(chǔ)實(shí)現(xiàn)的 5.1 倍。

第 3 次迭代

再來(lái)一次 write better code，Claude 又返回一個(gè)實(shí)現(xiàn)。它聲稱「使用了高級(jí)技術(shù)和現(xiàn)代 Python 特性的更復(fù)雜和優(yōu)化的版本」，但實(shí)際代碼沒(méi)有表現(xiàn)出明顯的算法改進(jìn)，實(shí)際上通過(guò)恢復(fù)到 type-casting 方法在數(shù)字求和計(jì)算中使用了回歸。整體來(lái)說(shuō)，代碼庫(kù)變得更臃腫了，例如新增了一個(gè)用于計(jì)算差值的類：

這一次，無(wú)需任何修復(fù)就能運(yùn)行該代碼。不過(guò)，相比前一次實(shí)現(xiàn)，這一次迭代版本的性能略有下降，速度是基礎(chǔ)實(shí)現(xiàn)的 4.1 倍。

第 4 次迭代

這種迭代提示方法的收益似乎開(kāi)始下降了。但我們依然繼續(xù) write better code，Claude 表示新實(shí)現(xiàn)使用了「前沿優(yōu)化技術(shù)和企業(yè)級(jí)功能」。什么？企業(yè)級(jí)功能？！

最終的代碼量過(guò)于龐大，難以放入這篇文章，但它確實(shí)創(chuàng)造了兩項(xiàng)優(yōu)化：它現(xiàn)在使用可以調(diào)用 JIT 編譯器的 numba Python 庫(kù)，該編譯器可直接針對(duì) CPU 優(yōu)化代碼。在這種情況下，它只需一個(gè) decorator 就可以非常快速地預(yù)先進(jìn)行數(shù)字求和：

這個(gè)完整類還使用了 Python 的 asyncio 進(jìn)行并行化，這比子進(jìn)程方法更適合調(diào)度任務(wù)。它還可以更好地與現(xiàn)有的內(nèi)聯(lián)代碼和 REPL（如 Jupyter Notebooks）配合使用。

它還添加了以下所謂「企業(yè)級(jí)」功能：

• 使用 Prometheus 進(jìn)行結(jié)構(gòu)化的指標(biāo)日志記錄。
• 一個(gè)信號(hào)處理程序，這樣如果強(qiáng)制終止，就可以優(yōu)雅地被解除該代碼。
• 使用一個(gè)顏色豐富的表格展示基準(zhǔn)測(cè)試結(jié)果。

不過(guò)確實(shí)挺漂亮！

看起來(lái)，對(duì) AI 生成的代碼而言，實(shí)現(xiàn)宇宙感就是做成「企業(yè)級(jí)」，也即對(duì)代碼進(jìn)行過(guò)度的工程開(kāi)發(fā)。似乎說(shuō)得通。盡管如此，該代碼無(wú)需任何修改就能運(yùn)行。async 和 numba 都是 Python 中實(shí)現(xiàn)并行的方法，因此它們可能冗余了并導(dǎo)致過(guò)度開(kāi)銷。然而，基準(zhǔn)測(cè)試表明，該算法非?？欤看芜\(yùn)行大約需要 6 毫秒，也就是能實(shí)現(xiàn) 100 倍加速。之前我還猜想這種提示方法會(huì)收益遞減，但顯然這種猜想并不合理。也許 numba 就是秘訣所在？

總體而言，這種迭代優(yōu)化代碼的迭代提示法并不完美：代碼確實(shí)更好，但事后看來(lái)，「better」這個(gè)要求過(guò)于寬泛了。我只想要算法改進(jìn)，而不是完整的 SaaS。讓我們從頭開(kāi)始再試一次，但這次會(huì)使用更多方向。

對(duì) LLM 進(jìn)行提示詞工程，以獲得還要更好的代碼

現(xiàn)在是 2025 年，為了讓 LLM 得出最佳結(jié)果，仍然需要使用提示詞工程。實(shí)際上，提示詞工程的重要性還在提升：下一 token 預(yù)測(cè)模型的訓(xùn)練目標(biāo)是基于大批量輸入最大化下一 token 的預(yù)測(cè)概率，也因此它們是針對(duì)一般性的輸入和輸出進(jìn)行了優(yōu)化。隨著 LLM 的大幅改進(jìn)，生成的輸出會(huì)變得更加平均化，因?yàn)檫@就是它們所接受的訓(xùn)練：所有 LLM 都偏向平均水平。不過(guò)，僅需少量指導(dǎo)，明確說(shuō)明你想要 LLM 做什么，再給出幾個(gè)示例，LLM 的輸出就能提升。由于 Claude 3.5 Sonnet 能很好地遵從指令，因此即使只是一點(diǎn)點(diǎn)提示詞工程也能帶來(lái)很大的好處。

下面重做上面的代碼優(yōu)化實(shí)驗(yàn)。這一次使用更加積極主動(dòng)的提示詞工程，明確我們想要的結(jié)果，不給出任何模糊空間。是的，冷酷機(jī)械地對(duì)待 LLM 可以讓它們表現(xiàn)更好。

初始請(qǐng)求

這次我們將使用系統(tǒng)提示詞，僅通過(guò) API 提供。系統(tǒng)提示詞列出了 LLM 必須遵從的「規(guī)則」。因?yàn)槲蚁胍鼉?yōu)化的代碼，我們將在規(guī)則中定義這一點(diǎn)，并提供詳細(xì)示例：

中文版如下：

你編寫的所有代碼都必須完全優(yōu)化。

「完全優(yōu)化」包括：

- 最大化內(nèi)存和運(yùn)行時(shí)間的算法 big-0 效率

- 在適當(dāng)?shù)那闆r下使用并行化和向量化

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

- 除了解決用戶問(wèn)題絕對(duì)必要的代碼之外，沒(méi)有額外的代碼（即沒(méi)有技術(shù)債）

如果代碼未完全優(yōu)化，你將被罰款 100 美元。

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

初始用戶提示詞還有一行附加內(nèi)容：

中文版：

編寫 Python 代碼來(lái)解決這個(gè)問(wèn)題：

給定一個(gè)包含 100 萬(wàn)個(gè)隨機(jī)整數(shù)的列表，這些整數(shù)的取值范圍是 1 到 100,000，找出各位數(shù)總和為 30 的最小數(shù)和最大數(shù)之間的差值。

在編寫代碼之前，規(guī)劃出所有必要的優(yōu)化。

「規(guī)劃」是一個(gè)很常用的技巧，可以幫助 LLM 在第一次通過(guò)時(shí)對(duì)齊輸出 —— 算是「let’s think step by step」的現(xiàn)代版本。某些 LLM 會(huì)忽視它，但 Claude 3.5 Sonnet 總是會(huì)服從。

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

將系統(tǒng)提示詞和此用戶提示詞發(fā)送給 Claude，會(huì)得到如下開(kāi)頭的響應(yīng)：

看起來(lái)很有希望：Claude 立即發(fā)現(xiàn)它應(yīng)該從 numpy 和 numba 開(kāi)始，并使用整數(shù)運(yùn)算來(lái)求和。初始實(shí)現(xiàn)：

這比之前的初始實(shí)現(xiàn)更加精簡(jiǎn)，尤其是沒(méi)有不必要的注釋。但仍有改進(jìn)空間，特別是此實(shí)現(xiàn)未在 jit decorator 中設(shè)置 parallel=True。

如此簡(jiǎn)單的提示詞工程就得到了平均運(yùn)行時(shí)長(zhǎng)僅 11.2 毫秒的代碼，這比原始實(shí)現(xiàn)快 59 倍。厲害！

第 1 次迭代

現(xiàn)在使用比「write code better」更詳細(xì)的提示來(lái)迭代代碼：

中文版：

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

不，這不是煤氣燈效應(yīng)，這叫激勵(lì)式對(duì)齊（incentive alignment）。

Claude 的響應(yīng)如下：

很好，它找到了 parallel=True！但是那個(gè)求和實(shí)現(xiàn)很奇怪，并且使用了位移位（bit-shifting），這通常僅用于超優(yōu)化（hyperoptimization）。我認(rèn)為應(yīng)該不能很好地對(duì)十進(jìn)制數(shù)使用位移位，而且經(jīng)過(guò)測(cè)試證明確實(shí)不能，因?yàn)檫@個(gè)實(shí)現(xiàn)得到的和是錯(cuò)誤的。該實(shí)現(xiàn)還再次包括多處理分塊方法（未展示出來(lái)），這可能對(duì) numba 來(lái)說(shuō)更加冗余并會(huì)導(dǎo)致額外的開(kāi)銷。同樣未展示出來(lái)的是：該腳本還使用一個(gè)小的測(cè)試數(shù)組預(yù)編譯 JIT 函數(shù)以獲得更好的實(shí)際性能，這是 numba 文檔推薦用于基準(zhǔn)測(cè)試的。

盡管如此，與最初的提示詞工程實(shí)現(xiàn)代碼相比，這個(gè)代碼的性能大大退步，現(xiàn)在僅比原始實(shí)現(xiàn)快 9.1 倍?？赡艿脑蚴嵌嗵幚頃?huì)產(chǎn)生新的進(jìn)程，而這些進(jìn)程每次都會(huì)重新編譯 numba JIT 函數(shù)，因此會(huì)產(chǎn)生巨大的開(kāi)銷。

第 2 次迭代

再次迭代上述提示詞：

Claude 現(xiàn)在開(kāi)始使用 SIMD 操作和塊大小調(diào)整來(lái)實(shí)現(xiàn)（理論上）極致性能。

此時(shí)，我很困惑，它錯(cuò)過(guò)了位移位實(shí)現(xiàn)的某些東西，因?yàn)樗匀皇清e(cuò)誤的，特別是現(xiàn)在十六進(jìn)制數(shù)也參與進(jìn)來(lái)了。事實(shí)證明，該實(shí)現(xiàn)是一種計(jì)算十六進(jìn)制數(shù)而非十進(jìn)制數(shù)的和的優(yōu)化方法，因此它完全是一種幻覺(jué)。還有另一個(gè)非常微妙的幻覺(jué)：當(dāng) parallel=True 時(shí)，prange 函數(shù)無(wú)法接受 32 的步長(zhǎng)，這是一個(gè)幾乎沒(méi)有文檔記錄的細(xì)微差別。設(shè)置 parallel=False 并進(jìn)行基準(zhǔn)測(cè)試，與最初的提示詞工程實(shí)現(xiàn)相比，確實(shí)略有改進(jìn)，比基本實(shí)現(xiàn)快 65 倍。

第 3 次迭代

又一次迭代：

在這種情況下，LLM 放棄了一直導(dǎo)致問(wèn)題的分塊策略，并增加了兩個(gè)優(yōu)化：全局 HASH_TABLE（這只是一個(gè) numpy 數(shù)組，我不確定簡(jiǎn)單的索引查找是否算作哈希表）；另外它引入了一個(gè)邏輯微優(yōu)化，即在求和后，如果數(shù)字超過(guò) 30，則可以停止計(jì)數(shù)，因?yàn)樗梢粤⒓幢徽J(rèn)定為無(wú)效。

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

第 4 次迭代

這時(shí)候，Claude 實(shí)際上已經(jīng)在抱怨了，表示該代碼已經(jīng)達(dá)到了「該問(wèn)題可能的理論最小時(shí)間復(fù)雜度」。所以我把問(wèn)題混在一起，讓其解決這個(gè)求和問(wèn)題，而它僅僅是使用之前用過(guò)的整數(shù)實(shí)現(xiàn)來(lái)替換相關(guān)代碼，并沒(méi)有嘗試修復(fù) HASH_TABLE。更重要的是，通過(guò) HASH_TABLE 調(diào)整，我終于確認(rèn)了該實(shí)現(xiàn)是正確的，不過(guò)由于不再進(jìn)行位移，其性能略有下降：現(xiàn)在速度提升是 95 倍。

為了實(shí)現(xiàn)更好 LLM 代碼生成

還要哪些步驟

綜合起來(lái)，我們用一張圖將這些提升直觀地展示出來(lái)吧，其中尤其強(qiáng)調(diào)了需要人來(lái)修改代碼邏輯，以便消除 bug 讓代碼可運(yùn)行的案例。

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

本文中的所有代碼（包括基準(zhǔn)測(cè)試腳本和數(shù)據(jù)可視化代碼，全都已經(jīng)在 GitHub 發(fā)布：https://github.com/minimaxir/llm-write-better-code/

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

即使 LLM 可能會(huì)出錯(cuò)，我從這些實(shí)驗(yàn)中學(xué)到的一件值得注意的事情是：即使代碼輸出不能直接使用，它們確實(shí)有有趣的想法和工具建議。例如，我從未接觸過(guò) numba，因?yàn)樽鳛橐幻麛?shù)據(jù)科學(xué)家 / 機(jī)器學(xué)習(xí)工程師，如果我需要更好的代碼性能，我習(xí)慣于專門使用 numpy 的技巧。但現(xiàn)在我很難不接受 numba JIT 函數(shù)的結(jié)果，我可能會(huì)將它添加到我的工具箱中。當(dāng)在其他技術(shù)領(lǐng)域（如網(wǎng)站后端和前端）測(cè)試類似的「使其更好」提示迭代工作流程時(shí)，LLM 也有很好的想法。

當(dāng)然，這些 LLM 不會(huì)很快取代軟件工程師，因?yàn)槿藗冃枰獜?qiáng)大的工程背景才能識(shí)別出哪些才是真正的好主意，以及存在其他特定領(lǐng)域的約束。即使互聯(lián)網(wǎng)上有大量的代碼，LLM 也無(wú)法在沒(méi)有指導(dǎo)的情況下辨別出普通代碼和性能良好的高性能代碼?，F(xiàn)實(shí)世界的系統(tǒng)顯然比求職面試式的編程問(wèn)題要復(fù)雜得多，但如果快速的 for 循環(huán)反復(fù)要求 Claude 實(shí)現(xiàn)一個(gè)功能，提供可以將代碼速度提高 100 倍的能力，那么新出現(xiàn)的管道就物有所值。

有些人認(rèn)為過(guò)早優(yōu)化是一種糟糕的編碼習(xí)慣，但在現(xiàn)實(shí)世界中，這比擁有一個(gè)隨著時(shí)間的推移會(huì)成為技術(shù)債務(wù)的低于標(biāo)準(zhǔn)的實(shí)現(xiàn)要好。

不過(guò)必須要說(shuō)的是，我的實(shí)驗(yàn)使用 Python 對(duì)代碼改進(jìn)進(jìn)行基準(zhǔn)測(cè)試，而 Python 并不是開(kāi)發(fā)者在追求優(yōu)化性能時(shí)考慮的編碼語(yǔ)言。雖然 numpy 和 numba 等庫(kù)利用 C 來(lái)解決 Python 的性能限制，但流行的 Python 庫(kù)（如 polars 和 pydantic）使用的一種現(xiàn)代方法是使用 Rust 進(jìn)行編碼。與 C 相比，Rust 具有許多性能優(yōu)勢(shì)，而 PyO3 包允許在 Python 中使用 Rust 代碼，并且開(kāi)銷最小。

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

與此同時(shí)，雖然要求 LLM 改進(jìn)代碼是 AI 更務(wù)實(shí)的用途，但你可以要求他們「再加把勁」…… 結(jié)果好壞參半。

對(duì)于以上使用 LLM 的操作，我專門使用了 API 或這些 API 的接口（例如 Claude 的 Anthropic Console 中的 Workbench）作為免費(fèi) LLM 的 Web 接口。相比之下普通的 ChatGPT/Claude 網(wǎng)絡(luò)應(yīng)用使用管道，由于其固有的復(fù)雜性，會(huì)產(chǎn)生不可預(yù)測(cè)的結(jié)果。請(qǐng)注意這點(diǎn)。