Karpathy力薦必讀博客：代碼功底，決定AI「開掛」倍數！

新智元報道

編輯：英智

【新智元導讀】Atharva博客揭示，AI是工程師能力的放大器。紮實的編程基礎搭配精準提示，能讓AI助你打造出極致產品。想知道如何用AI加速開發、少踩坑？快來看高手的秘訣！

最近，Karpathy在YC AI創業學校演講中推薦了一篇博客。

這篇博客中，Atharva表示，AI是放大器，coding功底越紮實，AI給的助力就越猛。

當你能用精準的提示詞拆解需求，當對系統設計有敏銳直覺，AI會把你的能力指數級放大；反之，模糊的指令只會讓AI輸出漏洞百出的代碼。

AI是打造認真、靠譜產品的工程團隊的好幫手，這需要對這些工具有着嫺熟的駕馭能力。

用AI開發，速度快得飛起！用對了，團隊能更快地縮短與用戶的反饋閉環，從而打造出更優秀的產品。

然而，用好AI工具也頗具挑戰。用得不好，代碼可能稀爛，甚至拖慢進度，深陷於垃圾代碼和技術債務的泥潭。

AI編程是個放大器

想讓AI發揮出色效果，首先要提升自己的水平。

AI是一個放大器。如果你的能力很差，收益自然微不足道；如果你的能力系數爲負，收益甚至可能是負值。

最優秀、經驗最豐富的工程師能從 AI 工具中榨取更多價值，原因如下：

極其擅長溝通技術理念，會把技術想法講清楚；

對構建優質系統有精準的判斷力和敏銳的直覺，能引導AI朝正確方向前進，即「老師傅的手感」；

基礎紮實，能在知識（而非技能）構成瓶頸的新工具和系統中能迅速上手；

AI對語言和風格很敏感，常常反映出提示者的偏好與審美。頂尖工程師品味高，對什麼可行、什麼不可行，有着更爲敏銳的品味和直覺。

所以，要秉持工匠精神。就算AI幫忙，也要對產出成果感到驕傲，這點在AI系統的最終產出中得到了清晰的印證。

舉個例子。下面這個提示詞不算差，但顯然不夠深思熟慮：

這個提示詞能生成一個勉強可用的結果，但很可能會忽略一些邊緣場景、最佳實踐和質量標準。

相比之下，高手可能會這樣提問：

優先考慮簡單、可讀性強的實現，避免過早優化。請僅用Python標準庫（stdlib），不要引入Redis或其他外部依賴。

哪個提示詞能更好地實現設計者的意圖？一目瞭然吧！

還有個卓有成效的技巧，叫「元提示」（metaprompting）。

先給模型一個簡單任務，讓它幫忙挖出需要權衡的因素和潛在的邊界情況，整理成技術規格，再讓另一個AI智能體去執行。

實際上，上面那個「高手提示」就是AI幫忙優化的，AI現在已經很擅長爲自己寫提示詞了。

AI工具的玩法總在變，但有一條金科玉律：努力提升自己，成爲一名優秀的工程師，你的習慣會迅速傳遞給AI。

這之所以有效，根本原因在於：凡是能幫人類更好地思考和工作的方式，同樣也能幫助AI。

能幫人類的，也能幫AI

在AI技術進步帶來顛覆性變革的今天，有必要重新審視軟件工程的定義。

軟件工程的核心不是光寫代碼，至少，這並非它的決定性特徵，正如寫作的本質並非只是在紙上揮灑筆墨。

軟件工程是一門藝術與科學，旨在維護一個龐大且定義明確的心智模型體系，以滿足業務需求。核心是打造和維護複雜的社會技術系統，代碼只是一種表現形式。

在AI強大到足以吞噬整個社會技術系統，並把培育它的人全踢出去之前，它必須要融入這個系統。

換句話說：在一個同樣適合人類發展的環境中，AI也能更好地茁壯成長。這意味着，團隊必須具備紮實的軟件工程基礎。

AI偏好的高質量團隊和代碼庫有這些特徵：

良好的測試覆蓋率、有意義的斷言；

自動化代碼檢查、格式化和測試，在代碼合併前執行；

持續集成與持續部署 (CI/CD)；

完善的變更文檔、技術規格（tech specs）、架構決策記錄（ADRs），以及清晰的提交信息；

代碼風格統一，通過格式化工具強制執行；

簡單、簡潔、結構清晰的代碼；

功能定義清晰，拆分爲多個小型的故事卡。

當今的AI能利用所有這些要素，自動搞定任務。

給一個編程智能體分配任務時，它會在其智能體循環中，通過運行測試用例和靜態分析工具來不斷進行自我修正。

這極大地減少了爲完成工作，而需要進行的手把手干預。豐富的環境與上下文，能幫助AI更好地工作。

在此分享一則軼事：Atharva曾參與一個項目，其中包含兩項服務。

一項服務具備上文描述的所有優點——良好的測試、完善的文檔、一致的代碼模式以及大量的檢查與防護機制。而另一項服務則混亂不堪，上述優點一概皆無。

結果，AI編程智能體在處理後者一個同等難度的任務時舉步維艱，遠不如處理前者時那般順利！

這很可能是因爲，那個混亂的代碼庫對AI造成的困惑，與對人類工程師造成的並無二致。

對於何爲正確的行事方式，它傳遞出了混亂甚至矛盾的信號。

編輯器中的工具與戰術

戰略講完了，來點乾貨戰術：

不計成本，使用最好的AI模型

務必使用當前最頂尖的編碼模型，不要爲了節省額度或開銷而選擇次級模型。

優質模型帶來的優勢會產生複利效應。擁有一個強大的編程模型作爲基礎，接下來介紹的所有戰術都將事半功倍。

提供精準的上下文

AI輔助編程的效果，很大程度上取決於爲LLM提供上下文的技巧有多嫺熟：

用智能體式（agentic）編碼工具，能自主讀取文件、運行shell命令、獲取文檔、創建並執行計劃、幾乎無需人工干預（只需最終批准）。推薦的工具有Claude Code、Windsurf、Cursor、Cline。

AI容易被雜亂上下文帶偏。應該只@相關代碼文件，鏈接對當前任務有幫助的文檔，幫助它聚焦。

將編碼規範寫入RULES.md文件，爲不同的智能體工具（如.cursorrules,.windsurfrules,claude.md,agents.md等）創建指向此文件的符號鏈接（Symlink）。

開發新功能或重構

拆解問題。指令越具體，AI的表現就越好。AI還能幫忙把提示寫清楚，讓指令變得更清晰、更具體。推理能力強的模型尤其擅長此道！

化整爲零，逐一擊破。在開發大型功能時，應將其拆分爲多個小任務，然後逐個交給AI處理，並在完成每個任務後進行一次代碼提交（commit）。如果你遵循用戶故事（story）的工作流，包含任務清單的故事卡描述對AI就是一份極佳的指南。

提供技術規格與相關文檔。不要在缺少產品宏觀背景的情況下直接要求AI寫代碼。應向其提供技術規格，以及所用程序庫的官方文檔。對於大多數工具而言，直接粘貼文檔鏈接通常是有效的。有些程序庫甚至會提供一個llms.txt文件，專供編碼智能體使用。

好的模式是把開發分成「計劃」和「執行」。一些先進的編程智能體已經內置了類似的流程。

審慎對待AI的建議。不要將其建議視爲理所當然，讓它解釋選擇的理由，提出替代方案，分析方案的優劣。

調試

用AI調試自己的bug。當AI生成的代碼出錯時，務必將最相關的錯誤上下文完整粘貼給它，以幫助其定位問題。（如使用專門的XML標籤，如，將錯誤日誌或輸出內容包裹起來）。

提供嘗試和觀察。向模型說明已經嘗試過的調試步驟和額外的觀察發現，這能幫它形成正確的假設並排除錯誤的推斷。提供豐富的上下文至關重要。

編輯器之外的實用招數

用AI提升個人技能與知識

AI是一位擁有海量知識、具有高效研究能力，超級有耐心的老師。

應積極用AI學習新知，揭開陌生代碼或技術棧的神秘面紗。堅持不懈地深入挖掘，探尋最佳實踐。同時，務必讓AI引用高質量的信源，確保學到的知識準確無誤。

創建海量詳盡文檔

把代碼庫信息提供給AI，就能輕鬆地創建大量細緻的文檔。比如：

闡釋功能，創建項目知識庫；

彙總當前所有的監控指標；

智能識別缺失的測試用例。

這樣做的好處顯而易見——如今，生成文檔的成本已極其低廉，而這些文檔又能反過來極大地提升AI以及人類成員的工作效率。

解決日常協作小摩擦

AI能極大降低團隊日常工作中遇到的各種小阻力：

利用AI創建模擬服務器（mockserver），用於協調前後端團隊的工作，消除開發過程中的阻塞。前後端對好接口契約就能開工；

通過向AI提供shell歷史會話記錄，爲基礎設施部署、常見故障排查等場景創建運行手冊（runbook）和指南；

將現有的運行手冊和指南提供給AI，讓它將其轉化爲能自動執行常見任務的腳本。

代碼評審 (Code Review)

爲合併請求（Pull Request）創建一個模板，將每個功能的代碼變更提交給AI，讓它解釋變更和部署步驟；

爲了縮短首次代碼評審的響應時間，可以引入代碼評審機器人來完成初步檢查。但切勿完全取代人工評審！

作爲評審者，當你遇到不理解的代碼變更時，可以先讓AI解釋。向它尋求澄清，在獲得了必要的背景信息後，再向開發者提問。

調試和監控線上應用

用AI的深度研究能力，尋找罕見錯誤的解決方案。調試線上問題時，可遵循與在編輯器中調試時相同的建議：提供儘可能豐富的上下文；

AI非常擅長爲可觀測性工具編寫查詢語句和告警規則，還能寫Python代碼分析和處理數據。

性能優化

用AI優化數據庫和調校配置。此時，務必向其提供有關基礎設施和硬件的上下文信息，並分享查詢計劃（query plan）。

數據庫優化故事

下面是近期一次互動實例：優化PostgreSQL中的一整套查詢。

每天要執行大約十次查詢，每天一次，用於生成一組用於分析的報表，基於事務表的非規範化視圖。這些查詢龐大且緩慢。

作爲一名訓練有素的工程師，他挑出最慢的查詢，然後：

等待了13分鐘後，得到了一份相當友好的輸出。

感謝像Hubert depesz Lubaczewski這樣的好人，提供了一個很棒的工具來處理這些相當友好的輸出。

通過這個工具，輸出變得更加友好，一個大大的紅框跳出來，清楚地告訴他哪裡出了問題。

但他訓練有素的工程師大腦卻在想：現在該怎麼辦？！

Sir depesz的工具暗示了一個work_mem問題，這是一個可以在夜間運行這些查詢時調整的旋鈕。這比重寫一個200行的、關聯了整個世界的SQL查詢要實用得多。

但該如何思考和推理這個問題？硬件能支持什麼？他對PostgreSQL的旋鈕調整幾乎沒有經驗。

在上述故事發生前一個月，也就是2024年10月，人們對一個當時被稱爲Sonnet 3.5（新版）、如今被稱爲Sonnet 3.6的模型讚不絕口。當時它無疑是最好的AI模型。

他把查詢計劃和硬件規格塞給了Sir Sonnet 3.5（新版），以下是提示：

並非所有建議都完全合理，但關鍵建議看起來不錯。於是他聽從了AI的建議，重新運行了查詢。然後數據庫崩潰了。

Sir Sonnet回答：

（想象一下，這裡還有幾次迭代，以及對Sir Sonnet過於自信的胡言亂語的一些抱怨。）

最終，查詢速度顯著提升。他嘗試調整了許多PostgreSQL參數，並整理了一個矩陣：

他和Srihari交流了經驗，像Srihari這樣經驗豐富的人可能一個下午就能搞定。

Sir Sonnet幫忙的地方在於，作爲一個從未調整過PostgreSQL參數的人，他能像Srihari一樣高效產出。而且，與 Sir Sonnet的對抗式互動讓他以前所未有的速度學習了PostgreSQL的內部機制。

如今，大模型比過去聰明得多。它們能更智能地推理，工具使用也更出色。

人們編寫軟件的方式正發生着鉅變，因此有必要重新審視一些曾被奉爲金科玉律的傳統智慧。

別急着搞複雜抽象：首先，花費過多時間去尋找和構建精巧的抽象，其價值正在降低。

DRY（不要重複自己）原則對確保代碼模式的一致性固然有用，但爲了應對需求變更而維護，本身就需要付出成本。

返工的成本極低。小範圍的代碼編寫不如整體代碼結構和組織重要。可以快速構建多個原型測試想法。

氛圍編程很適合原型開發，但事後要將原型拋棄並重新進行規範的開發。

驗證並修正一個既有方案，通常比從零開始創造它要容易得多。這極大地降低了人們嘗試新事物的阻力。

測試是絕對不容妥協的。AI能夠快速、批量地生成測試用例，這讓任何不寫測試的藉口都蕩然無存。

但請記住，必須時刻嚴格審查其生成的內容！

參考資料：

https://blog.nilenso.com/blog/2025/05/29/ai-assisted-coding/

https://simonwillison.net/2025/Jun/10/ai-assisted-coding/

https://x.com/deedydas/status/1936090859319259321