最近 GitHub 上有一個圍繞 AI 編程的專案很火，核心其實只是一個大約 65 行的 CLAUDE.md 文件。它之所以能拿到大量 star，不是因為技術實作複雜，而是因為它抓住了很多人使用 AI 寫程式時反覆遇到的問題。

這個專案的背景，要從 Andrej Karpathy 對 AI 編程的觀察說起。Karpathy 是 AI 領域很有影響力的教育者和工程師：史丹佛博士，參與過 OpenAI 早期工作，也曾在 Tesla 負責 Autopilot 視覺系統。後來他持續分享對大模型、教育和 AI 工具的理解，所以他對編程方式變化的判斷，總會引起很多開發者關注。

他在一次分享中提到，自己使用 Claude Code 幾週後，編程方式發生了明顯變化：過去大概是 80% 手寫程式、20% AI 輔助，現在更接近 80% 讓 AI 寫程式，自己做 20% 修改。他形容這像是「用英語編程」，透過自然語言告訴 LLM 要寫什麼。

但他也指出了 AI 編程的幾個典型問題。

01 錯誤假設

第一個問題是模型很容易替使用者做假設，然後沿著這個假設一路寫下去。它不一定會主動管理自己的困惑，也不一定會在需求含糊時停下來追問。

比如使用者只說「新增使用者匯出功能」，模型可能會預設匯出全部使用者，預設輸出 JSON，預設寫成本地文件，預設權限和欄位都不需要再確認。等程式寫完，使用者才發現它理解的需求和真實場景並不一致。

更好的做法應該是先把不確定點列出來：匯出全部使用者還是篩選結果？是瀏覽器下載還是後台任務？需要哪些欄位？資料量大不大？是否有權限限制？這些問題不問清楚，後面寫得越快，偏得也越遠。

02 過度複雜化

第二個問題是模型很容易把簡單問題寫複雜。一個函式能解決的問題，它可能加上抽象類、策略模式、工廠模式、配置層和一堆「未來可能有用」的擴充點。

這類程式看起來很工程化，實際卻增加了維護負擔。AI 尤其擅長快速生成大量結構，但並不總能判斷這些結構是否真的必要。結果就是一百行能解決的任務，被膨脹成一千行。

判斷標準其實很直接：一個資深工程師看到這段改動，會不會覺得它過度設計？如果答案是會，就應該刪掉多餘層次，用最少的程式碼解決當前問題。

03 附帶傷害

第三個問題是模型有時會修改或刪除自己沒有充分理解的程式碼。它可能在修一個小 bug 的時候順手改註釋、重排格式、清理看似無用的 import，甚至動到和當前任務無關的邏輯。

這類「順手優化」很危險，因為它擴大了變更範圍，也讓 review 變得更困難。使用者本來只想修復一個空 email 導致驗證器崩潰的問題，結果模型順便增強了 email 驗證、加了使用者名稱校驗、改了文件字串，最後很難判斷到底哪一行影響了行為。

更穩妥的原則是：只動必須動的程式碼，只清理自己造成的問題。原本就存在的死程式碼、格式問題或歷史包袱，除非任務明確要求處理，否則最多提醒一句，不要直接改。

04 把吐槽變成 CLAUDE.md

在 Karpathy 的觀點被大量傳播後，開發者 Forrest Cheung 做了一件很聰明的事：他把這些吐槽整理成可以執行的行為準則，寫進一個 CLAUDE.md 文件。

這個專案沒有複雜程式碼，關鍵就是把 AI 編程中最容易出問題的地方，轉成明確的工作規則。大致可以概括為四條。

第一條是先想再寫。不要默默假設，不要隱藏困惑；如果需求有多種理解，就把它們列出來；如果存在更簡單的方案，也要說出來；該追問時追問，該反駁時反駁。

第二條是簡單優先。不新增沒被要求的功能，不為一次性程式碼做抽象，不加入多餘配置，也不為極小機率場景寫大量防禦程式碼。如果 50 行能解決，就不要寫成 200 行。

第三條是精準修改。每一行改動都應該能直接追溯到使用者請求。不要順手改善鄰近程式碼，不要重構沒壞的東西，盡量匹配專案既有風格。

第四條是目標驅動。不要只給模型一個模糊指令，而是給它可驗證的成功標準。比如「修復 bug」可以變成「先寫一個能復現 bug 的測試，再讓測試通過」；「新增校驗」可以變成「寫無效輸入測試並通過」。成功標準越清楚，模型越容易自己循環到完成。

05 為什麼它會火

這個專案能火，不是因為內容很玄，而是因為它足夠貼近真實開發。

很多人用 AI 編程時都經歷過類似場景：模型自信地誤解需求，程式越寫越複雜，或者在不該動的地方動手。CLAUDE.md 的價值，是把這些經驗變成可以放進專案裡的協作規則。

它的門檻也很低：一個文件就能開始生效，不需要複雜接入。再加上 Karpathy 本人的影響力，以及專案裡有實戰對比案例，它很自然會在 Claude Code 使用者和 AI 編程社群裡傳播開來。

更重要的是，這類規則不是只適用於 Claude Code。無論使用哪種 AI 編程工具，本質問題都很相似：模型需要知道什麼時候該問、什麼時候該簡化、什麼時候該停手、怎樣判斷任務已經完成。

06 對普通開發者的啟發

這件事給普通開發者的啟發很簡單：AI 編程不是把一句需求丟給模型，然後等待奇蹟發生。真正有效的方式，是給模型建立邊界。

需求不清楚時，讓它先暴露假設。實作方案變複雜時，讓它主動回到最小可行解。修改程式碼時，讓它只圍繞任務目標行動。完成任務時，用測試、命令或明確檢查點來驗證結果。

AI 寫程式的能力已經很強，但它仍然需要好的協作約束。一個短小的 CLAUDE.md 能獲得大量關注，說明開發者真正需要的並不只是更聰明的模型，也包括更可靠的工作方式。

簡單總結：

• 先想再寫，減少錯誤假設。
• 簡單優先，避免過度設計。
• 精準修改，控制變更範圍。
• 目標驅動，用可驗證標準推動完成。

這四條並不複雜，卻很實用。AI 編程真正提升效率的前提，不是讓模型寫得更多，而是讓它寫得更準、更少、更可控。