AI編程 on KnightLi的博客

Karpathy 的 65 行 CLAUDE.md：讓 AI 編程少犯三類錯誤

Sun, 19 Apr 2026 18:27:23 +0800

最近 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 編程真正提升效率的前提，不是讓模型寫得更多，而是讓它寫得更準、更少、更可控。

Claude Code 額度省著用：模型選擇、上下文、快取與 /compact

Sun, 19 Apr 2026 15:29:06 +0800

最近很多人在用 Claude Code 或 Claude Max 時會遇到一個問題：明明買了 Pro、Max 5x，甚至 Max 20x，結果沒跑多久就提示額度快滿，或者直接需要等重置。尤其是在大專案裡讓 Claude Code 讀很多檔案、修複雜 bug、跑長任務時，這種感覺會更明顯。

這裡先說結論：額度不是按「時間」線性扣的，而是和模型、上下文長度、附件、程式碼庫規模、對話歷史、工具呼叫和目前容量都有關係。同樣 5 小時視窗，有的人能用很久，有的人十幾分鐘就耗盡，通常不是帳號壞了，而是每次請求都太重。

這篇整理一套比較實用的省額度習慣。

01 先理解 Claude 的用量視窗

Claude Pro 和 Max 都有使用限制，Claude Code 的使用量會和 Claude 網頁、桌面、行動端共享同一套訂閱額度。官方說明裡提到，訊息數量會受到訊息長度、附件大小、目前對話長度、所用模型或功能影響；Claude Code 還會受到專案複雜度、程式碼庫大小、自動接受設定等影響。

大致可以這樣理解：

Pro：適合輕量使用和小專案。
Max 5x：適合更頻繁使用和較大的程式碼庫。
Max 20x：適合更重度、日常高頻協作。
用量視窗按 5 小時會話重置。
長訊息、長對話、大檔案、複雜任務會更快消耗額度。
Opus 這類更強模型會比 Sonnet 更快觸發限制。

所以「我只用了 20 分鐘」這個說法不一定能說明問題。真正重要的是這 20 分鐘裡 Claude 讀了多少上下文、用了什麼模型、是否反覆處理大檔案、是否在同一個長對話裡繼續加任務。

02 第一件事：不要預設一直用最貴模型

Claude 系列裡常見的定位是：

Opus：能力最強，適合複雜推理、架構決策、疑難 bug。
Sonnet：能力和成本比較均衡，適合大部分日常編碼任務。
Haiku：更輕量，適合簡單分類、摘要、格式轉換等任務。

日常寫腳本、改小 bug、整理文件、解釋程式碼，大多數時候 Sonnet 已經夠用。Opus 更適合留給這些場景：

複雜架構設計。
多檔案深度重構。
難復現的 bug。
需要長鏈路推理的排障。
普通模型明顯卡住的任務。

Claude Code 裡可以用 /model 切換模型，也可以在 /config 裡設定預設模型。比較穩的習慣是：預設 Sonnet，關鍵節點再切 Opus，而不是整場任務都用 Opus 扛。

03 第二件事：控制上下文，不要讓舊任務拖著走

上下文越長，Claude 每次處理要看的內容越多，額度消耗也越高。Claude Code 官方文件明確建議主動管理上下文：

換到不相關任務時，用 /clear 清空歷史。
目前任務做完一個階段但還要保留重點時，用 /compact 壓縮。
想知道上下文裡什麼佔空間，用 /context。
想持續看到狀態，可以設定 status line。

一個好用的節奏是：

小階段完成：/compact
大任務結束：/clear
切換無關專案：/clear
上下文接近很高佔用：提前 /compact

/compact 會把前面的對話壓成摘要，保留關鍵任務狀態、結論、檔案路徑、待辦事項，但減少後續每次請求要攜帶的歷史。你也可以給它補一句重點：

`1`	`/compact 保留已修改檔案、測試結果、剩餘待辦和關鍵設計決策`

不要等自動壓縮才處理。官方文件提到，Claude Code 會在上下文接近容量上限時自動壓縮，但手動在階段邊界壓縮，通常更可控。

04 第三件事：長對話和大檔案會讓每次請求變貴

很多人以為「我只是繼續問一句」，應該很便宜。但在長對話裡，這一句背後可能帶著大量歷史、檔案摘要、工具定義和系統規則。

特別容易漲上下文的東西包括：

一直不清理的長對話。
讓 Claude 讀完整大檔案。
貼很長日誌、建置輸出、測試輸出。
一次性塞很多截圖或圖片。
讓它反覆掃描整個倉庫。
過長的 CLAUDE.md。
開了很多 MCP server。

比較省的做法是：日誌只貼關鍵報錯，測試輸出只給失敗部分，大檔案讓它先用 rg、head、tail、符號搜尋定位，再讀必要片段。能用命令列過濾的內容，不要整包塞進上下文。

05 第四件事：理解快取，但不要迷信快取

Anthropic 的 Prompt Caching 會快取重複的 prompt 前綴。預設快取生命週期是 5 分鐘，也支援 1 小時快取。快取命中時，重複的大段上下文不需要完整重新處理，有助於降低成本和改善額度利用。

但快取有幾個限制：

需要內容完全匹配，文字和圖片都要一致。
預設快取是短生命週期。
改模型、改工具、改系統提示、改上下文結構，都可能降低命中。
輸出 token 不會因為快取而消失，該生成的回答仍然要生成。
Claude Code 具體如何利用快取，是產品層實作細節，不要把它當成永遠穩定的「免費記憶」。

實際使用裡，最重要的不是研究快取細節，而是保持會話穩定：

同一階段盡量別頻繁切模型。
不要中途反覆改大量規則。
不要在同一任務裡不停貼新圖片。
長任務中間不要閒置太久後又繼續塞大請求。
階段結束主動 /compact。

這樣更容易讓重複上下文保持可複用，也能降低後續請求負擔。

06 關於尖峰時段：能避開就避開，但不要當固定公式

網路上常有人說某些時段額度會更緊。官方幫助中心的表述更謹慎：可發送數量會受到 Claude 目前容量、對話長度、附件、模型和功能影響。也就是說，尖峰容量確實可能影響體驗，但不要把某個地區的某個時間段當成永久固定規則。

實用建議是：

大重構、大批次分析盡量放到自己網路和服務都穩定的時段。
不要在快到休息時開啟一個超長任務。
預計會離開很久時，先 /compact 或 /clear。
如果只是小改動，不要開 Opus 加長上下文硬跑。

這比記一個固定「幾點到幾點不能用」的規則更可靠。

07 精簡 CLAUDE.md、rules、MCP 和 skills

Claude Code 會在會話中載入專案規則、工具資訊和一部分環境上下文。官方文件也建議把通用規則和專用規則分開，避免每次啟動都帶著一大包不相關內容。

比較推薦的拆法：

CLAUDE.md：只放全域都適用的核心規則。
rules：放特定路徑、特定檔案類型才需要的規則。
skills：放特定工作流，例如發文章、部署、生成圖片、提交程式碼。
MCP：只啟用目前任務真的會用到的 server。

如果 CLAUDE.md 寫了幾百上千行，每次會話都要帶進去。更好的方式是把「偶爾才用」的流程移到 skill 裡，需要時再呼叫。

MCP 也是一樣。工具多不等於效率高。Claude Code 文件提到可以用 /mcp 查看並停用不需要的 server，也可以用 /context 看是什麼佔用了上下文空間。

08 實用指令清單

日常最常用的是這幾個：

/model

切換模型。預設建議用 Sonnet，複雜推理再用 Opus。

/clear

清空目前上下文。換無關任務時用，最省。

`1`	`/compact`

壓縮歷史上下文。一個階段完成但還要繼續同一任務時用。

`1`	`/context`

查看上下文佔用，排查是什麼吃掉空間。

/status

查看目前訂閱或額度相關狀態。官方幫助中心也建議用它監控剩餘額度。

/mcp

查看和管理 MCP server，關閉目前不用的工具。

如果你用 API 計費模式，還可以關注 /cost；但如果是 Pro/Max 訂閱，官方文件說明 /cost 的美元估算不適合作為訂閱帳單依據，訂閱使用者更應該看 /stats 和 /status 這類使用資訊。

09 一套省額度工作流

比較順手的流程可以是這樣：

新任務開始前先 /clear。
預設用 Sonnet。
先讓 Claude 讀專案結構和關鍵檔案，不要一口氣讀全倉庫。
每做完一個小階段就 /compact。
複雜卡點再切 Opus。
日誌、報錯、測試輸出先過濾再給。
任務完成後 /clear，不要拖著舊上下文開新活。
定期檢查 CLAUDE.md、MCP 和 skills，把常駐上下文壓小。

這個流程的核心是：讓 Claude 每次只看目前真正需要看的東西。

10 小結

Claude Code 額度快速耗盡，通常不是單一原因，而是幾個因素疊加：用了高成本模型、長對話一直不清、檔案和日誌塞太多、MCP 和規則常駐過重、快取命中變差，再加上尖峰容量波動。

省額度的核心也很簡單：

日常任務優先 Sonnet。
Opus 留給真正複雜的問題。
階段完成用 /compact。
換任務用 /clear。
用 /context 找上下文佔用來源。
精簡 CLAUDE.md、rules、MCP 和 skills。
不要把整倉庫、整日誌、整圖片包都丟進去。

同樣的 Pro 或 Max 方案，能做多少事，很大程度取決於你怎麼管理上下文。把上下文變小、任務邊界變清楚，Claude Code 的可用時間和穩定性都會明顯好很多。

參考連結

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching