新智元報道
新智元報道
編輯：英智
【新智元導讀】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速率限制器，限制使用者每分鐘10次請求。
這個提示詞能生成一個勉強可用的結果，但很可能會忽略一些邊緣場景、最佳實踐和質量標準。
相比之下，高手可能會這樣提問：
請使用Python實現一個token桶速率限制器，並滿足以下要求：
user_id字串識別），速率限制為每分鐘10次請求。(allowed: bool, retry_after_seconds: int)，分別表示請求是否被允許，以及需要等待多少秒後才能重試。需考慮以下問題：
優先考慮簡單、可讀性強的實現，避免過早最佳化。請僅用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 <myslowquery>
等待了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 to1.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 largeexternal sorts occurring- Largest sort using8018MB of disk space- Many temp buffers being read and written2.**Parallel Query Execution Limitations**-Onlyusing2 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 withlarge 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-With32GB 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`
並非所有建議都完全合理，但關鍵建議看起來不錯。於是他聽從了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