Karpathy力薦必讀博客：代碼功底，決定AI「開掛」倍數！
最近，Karpathy在YC AI創業學校演講中推薦了一篇博客。
這篇博客中，Atharva表示，AI是放大器，coding功底越扎實，AI給的助力就越猛。
當你能用精準的提示詞拆解需求，當對系統設計有敏銳直覺，AI會把你的能力指數級放大；反之，模糊的指令只會讓AI輸出漏洞百出的代碼。
AI是打造認真、靠譜產品的工程團隊的好幫手，這需要對這些工具有著嫻熟的駕馭能力。
用AI開發，速度快得飛起！用對了，團隊能更快地縮短與用戶的反饋閉環，從而打造出更優秀的產品。
然而，用好AI工具也頗具挑戰。用得不好，代碼可能稀爛，甚至拖慢進度，深陷于垃圾代碼和技術債務的泥潭。
AI編程是個放大器
想讓AI發揮出色效果，首先要提升自己的水平。
AI是一個放大器。如果你的能力很差，收益自然微不足道；如果你的能力系數為負，收益甚至可能是負值。
最優秀、經驗最豐富的工程師能從 AI 工具中榨取更多價值，原因如下：
- 極其擅長溝通技術理念，會把技術想法講清楚；
- 對構建優質系統有精準的判斷力和敏銳的直覺，能引導AI朝正確方向前進，即「老師傅的手感」；
- 基礎扎實，能在知識（而非技能）構成瓶頸的新工具和系統中能迅速上手；
- AI對語言和風格很敏感，常常反映出提示者的偏好與審美。頂尖工程師品味高，對什么可行、什么不可行，有著更為敏銳的品味和直覺。
所以，要秉持工匠精神。就算AI幫忙，也要對產出成果感到驕傲，這點在AI系統的最終產出中得到了清晰的印證。
舉個例子。下面這個提示詞不算差，但顯然不夠深思熟慮：
寫一個Python速率限制器，限制用戶每分鐘10次請求。
這個提示詞能生成一個勉強可用的結果，但很可能會忽略一些邊緣場景、最佳實踐和質量標準。
相比之下，高手可能會這樣提問：
請使用Python實現一個token桶速率限制器，并滿足以下要求：
- 針對每個用戶（通過
user_id字符串識別），速率限制為每分鐘10次請求。 - 實現必須是線程安全的，以支持并發訪問。
- 能自動清理過期用戶的條目。
- 函數返回一個元組
(allowed: bool, retry_after_seconds: int)，分別表示請求是否被允許，以及需要等待多少秒后才能重試。
需考慮以下問題：
- token是應該隨時間逐漸填充，還是一次性補滿？
- 當系統時鐘發生變更時，程序的行為應是怎樣的？
- 如何防止因用戶長時間不活躍而導致的內存泄漏？
優先考慮簡單、可讀性強的實現，避免過早優化。請僅用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標簽，如
<error>，將錯誤日志或輸出內容包裹起來）。 - 提供嘗試和觀察。向模型說明已經嘗試過的調試步驟和額外的觀察發現，這能幫它形成正確的假設并排除錯誤的推斷。提供豐富的上下文至關重要。
編輯器之外的實用招數
用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中的一整套查詢。
每天要執行大約十次查詢，每天一次，用于生成一組用于分析的報表，基于事務表的非規范化視圖。這些查詢龐大且緩慢。
作為一名訓練有素的工程師，他挑出最慢的查詢，然后：
EXPLAIN ANALYZE <my slow query>
EXPLAIN ANALYZE <my slow query>等待了13分鐘后，得到了一份相當友好的輸出。
感謝像Hubert depesz Lubaczewski這樣的好人，提供了一個很棒的工具來處理這些相當友好的輸出。
通過這個工具，輸出變得更加友好，一個大大的紅框跳出來，清楚地告訴他哪里出了問題。
但他訓練有素的工程師大腦卻在想：現在該怎么辦？！
Sir depesz的工具暗示了一個work_mem問題，這是一個可以在夜間運行這些查詢時調整的旋鈕。這比重寫一個200行的、關聯了整個世界的SQL查詢要實用得多。
但該如何思考和推理這個問題？硬件能支持什么？他對PostgreSQL的旋鈕調整幾乎沒有經驗。
在上述故事發生前一個月，也就是2024年10月，人們對一個當時被稱為Sonnet 3.5（新版）、如今被稱為Sonnet 3.6的模型贊不絕口。當時它無疑是最好的AI模型。
他把查詢計劃和硬件規格塞給了Sir Sonnet 3.5（新版），以下是提示：
This is a PostgreSQL EXPLAIN ANALYZE outputTell me what configuration parameters I can tune to make this go faster.<system_info>RAM = 32 GBCurrent parameters: synchronous_commit: "on" max_connections: "200" shared_buffers: "8GB" effective_cache_size: "24GB" maintenance_work_mem: "2GB" checkpoint_completion_target: "0.9" wal_buffers: "16MB" default_statistics_target: "100" random_page_cost: "1.1" effective_io_concurrency: "200" work_mem: "20971kB" # NOTE: but for just this query, we temporarily have set it to 1.5GB, which is the most we can push it safely min_wal_size: "1GB" max_wal_size: "4GB" max_worker_processes: "4" max_parallel_workers_per_gather: "2" max_parallel_workers: "4" max_parallel_maintenance_workers: "2"</system_info>Sir Sonnet回應道：# PostgreSQL Performance Analysis## Key Performance Metrics- Total Execution Time: 813.4 seconds (13.5 minutes)- Planning Time: 26.5ms- Total Rows: 30,302,109- Buffer Usage: - Shared Hit: 1,741,739 - Shared Read: 6,483,035 - Temp Read: 8,284,857 - Temp Written: 8,284,920## Major Performance Issues Identified1. **Heavy Disk I/O for Sorting** - Multiple large external sorts occurring - Largest sort using 8018MB of disk space - Many temp buffers being read and written2. **Parallel Query Execution Limitations** - Only using 2 parallel workers - Several large sequential scans that could benefit from more parallelism3. **Memory Pressure** - Multiple operations spilling to disk despite high work_mem - Large hash joins and sorts requiring temporary files## Recommended Parameter Adjustments### Critical Changes1. `max_parallel_workers_per_gather`: 4 (currently 2) - Justification: Query shows heavy parallel operations with large sequential scans - This change alone could significantly improve the performance of the parallel operations2. `work_mem`: 2GB (currently 1.5GB) - Justification: Multiple sorts spilling to disk - With 32GB RAM and considering the parallel workers, we can safely increase this - Note: Effective memory per sort will be work_mem × number of parallel workers3. `max_parallel_workers`: 8 (currently 4) - Justification: System has enough RAM to support more parallel workers - Will allow better utilization of parallel operations### Secondary Adjustments4. `maintenance_work_mem`: 4GB (currently 2GB) - Justification: Large sorts occurring in maintenance operations - System has enough RAM to support this increase5. `effective_io_concurrency`: 300 (currently 200) - Justification: Heavy I/O operations occurring - If using SSDs, this can be increased further6. `random_page_cost`: 1.0 (currently 1.1) - Justification: If using SSDs, this should be lowered to better reflect actual I/O costs## Monitoring RecommendationsAfter implementing these changes:1. Monitor temp file usage (`pg_stat_database`)2. Watch for memory pressure using `pg_stat_activity`3. Track parallel execution effectiveness with `pg_stat_statements`
This is a PostgreSQL EXPLAIN ANALYZE output
Tell me what configuration parameters I can tune to make this go faster.
<system_info>
RAM = 32 GB
Current parameters:
synchronous_commit: "on"
max_connections: "200"
shared_buffers: "8GB"
effective_cache_size: "24GB"
maintenance_work_mem: "2GB"
checkpoint_completion_target: "0.9"
wal_buffers: "16MB"
default_statistics_target: "100"
random_page_cost: "1.1"
effective_io_concurrency: "200"
work_mem: "20971kB" # NOTE: but for just this query, we temporarily have set it to 1.5GB, which is the most we can push it safely
min_wal_size: "1GB"
max_wal_size: "4GB"
max_worker_processes: "4"
max_parallel_workers_per_gather: "2"
max_parallel_workers: "4"
max_parallel_maintenance_workers: "2"
</system_info>
Sir Sonnet回應道：
# PostgreSQL Performance Analysis
## Key Performance Metrics
- Total Execution Time: 813.4 seconds (13.5 minutes)
- Planning Time: 26.5ms
- Total Rows: 30,302,109
- Buffer Usage:
- Shared Hit: 1,741,739
- Shared Read: 6,483,035
- Temp Read: 8,284,857
- Temp Written: 8,284,920
## Major Performance Issues Identified
1. **Heavy Disk I/O for Sorting**
- Multiple large external sorts occurring
- Largest sort using 8018MB of disk space
- Many temp buffers being read and written
2. **Parallel Query Execution Limitations**
- Only using 2 parallel workers
- Several large sequential scans that could benefit from more parallelism
3. **Memory Pressure**
- Multiple operations spilling to disk despite high work_mem
- Large hash joins and sorts requiring temporary files
## Recommended Parameter Adjustments
### Critical Changes
1. `max_parallel_workers_per_gather`: 4 (currently 2)
- Justification: Query shows heavy parallel operations with large sequential scans
- This change alone could significantly improve the performance of the parallel operations
2. `work_mem`: 2GB (currently 1.5GB)
- Justification: Multiple sorts spilling to disk
- With 32GB RAM and considering the parallel workers, we can safely increase this
- Note: Effective memory per sort will be work_mem × number of parallel workers
3. `max_parallel_workers`: 8 (currently 4)
- Justification: System has enough RAM to support more parallel workers
- Will allow better utilization of parallel operations
### Secondary Adjustments
4. `maintenance_work_mem`: 4GB (currently 2GB)
- Justification: Large sorts occurring in maintenance operations
- System has enough RAM to support this increase
5. `effective_io_concurrency`: 300 (currently 200)
- Justification: Heavy I/O operations occurring
- If using SSDs, this can be increased further
6. `random_page_cost`: 1.0 (currently 1.1)
- Justification: If using SSDs, this should be lowered to better reflect actual I/O costs
## Monitoring Recommendations
After implementing these changes:
1. Monitor temp file usage (`pg_stat_database`)
2. Watch for memory pressure using `pg_stat_activity`
3. Track parallel execution effectiveness with `pg_stat_statements`并非所有建議都完全合理，但關鍵建議看起來不錯。于是他聽從了AI的建議，重新運行了查詢。然后數據庫崩潰了。
Sir Sonnet回答：
（想象一下，這里還有幾次迭代，以及對Sir Sonnet過于自信的胡言亂語的一些抱怨。）
最終，查詢速度顯著提升。他嘗試調整了許多PostgreSQL參數，并整理了一個矩陣：
他和Srihari交流了經驗，像Srihari這樣經驗豐富的人可能一個下午就能搞定。
Sir Sonnet幫忙的地方在于，作為一個從未調整過PostgreSQL參數的人，他能像Srihari一樣高效產出。而且，與 Sir Sonnet的對抗式互動讓他以前所未有的速度學習了PostgreSQL的內部機制。
如今，大模型比過去聰明得多。它們能更智能地推理，工具使用也更出色。
人們編寫軟件的方式正發生著巨變，因此有必要重新審視一些曾被奉為金科玉律的傳統智慧。
別急著搞復雜抽象：首先，花費過多時間去尋找和構建精巧的抽象，其價值正在降低。
DRY（不要重復自己）原則對確保代碼模式的一致性固然有用，但為了應對需求變更而維護，本身就需要付出成本。
返工的成本極低。小范圍的代碼編寫不如整體代碼結構和組織重要。可以快速構建多個原型測試想法。
氛圍編程很適合原型開發，但事后要將原型拋棄并重新進行規范的開發。
驗證并修正一個既有方案，通常比從零開始創造它要容易得多。這極大地降低了人們嘗試新事物的阻力。
測試是絕對不容妥協的。AI能夠快速、批量地生成測試用例，這讓任何不寫測試的借口都蕩然無存。
但請記住，必須時刻嚴格審查其生成的內容！
