Claude Code 用久了為什麼會「變笨」？用六層架構的系統設計思維來解決
Claude Code 用久了會開始「忘記」你的指令、輸出格式不穩定、該跑的流程跳過不跑。不是 AI 變笨了，而是你的系統設計出了問題。用六層架構（Six-Layer Architecture）的思維重構 Claude Code 專案，指令遵循穩定性明顯提升。
- Claude Code 的上下文窗口（Context Window）約 200K token，但系統指令、工具定義、CLAUDE.md、Memory 都在搶空間——你的指令 budget 只剩 100-150 條，而且注意力（Attention）會隨資訊量遞減。
- 六層架構（上下文、執行、控制、子代理、快取、驗證）是一個系統設計框架，幫助你判斷哪些問題該在哪一層解決，而不是把所有東西塞進 CLAUDE.md。
- 實測結果：將 300 行 CLAUDE.md 拆分為 40 行核心指令 + 3 個按需載入的 Skills 後，Claude 的指令遵循穩定性明顯提升，fact-check 不再被跳過。
你的 Claude Code 是不是越用越笨？
如果你用 Claude Code 超過兩週，大概會經歷這個過程：一開始驚豔於它的能力，然後隨著專案變複雜，開始往 CLAUDE.md 裡塞越來越多規則。角色設定、工作流程、格式規範、注意事項⋯⋯寫到某個臨界點之後，Claude 開始出現詭異行為——該跑的 fact-check 跳過了、輸出格式時對時錯、明明寫好的規則卻被無視。
我有兩個 Claude Code 專案：blog-writer（AI 內容產線）和 gwarket-site（網站重建）。blog-writer 的 CLAUDE.md 寫到了 300 行，裡面混雜著角色設定、指令一覽、選題流程、轉寫流程、14 家公司的來源清單、三種平台的輸出格式規範、事實查核規則。結果就是 Claude 時不時忘記跑 fact-check、輸出格式不穩定。另一個專案 gwarket-site 則完全沒有驗證機制，改完代碼要靠我自己肉眼看有沒有問題。
我花了兩天時間重構這兩個專案的 Claude Code 架構。這篇文章記錄的不是操作步驟，而是以一個管理者的角度怎麼把系統設計的思維套用到 AI Agent 的專案上。
CLAUDE.md 寫越多 Claude 反而越不聽話的原因
直覺告訴你：給越多指令，AI 應該表現越好。但大型語言模型（LLM）的運作方式剛好相反。
Context Window 的物理限制
Claude 的 context window 大約 200K token。聽起來很多，但這個空間要同時容納系統指令、工具定義、CLAUDE.md、Memory、你的對話歷史、Claude 讀取的每一個檔案、每一次指令執行的輸出。根據 ZenML 對 Claude Code 架構的分析，當 context 使用率達到約 92% 時，系統會自動觸發壓縮（Compaction）。壓縮意味著遺忘——早期的架構決策、你精心寫的規則，都可能在壓縮過程中被摘要掉。
Attention 的稀缺性比 Token 更致命
更關鍵的問題是 attention 的有限性。根據 HumanLayer 的研究分析，frontier thinking model 能穩定遵循的指令數大約是 150-200 條。而 Claude Code 自己的系統指令就佔掉了約 50 條。也就是說，你的 CLAUDE.md 只剩下 100-150 條指令的 budget。資訊越多，每條指令分到的注意力越少。「以防萬一多放點」的心態，實際上是在稀釋每一條真正重要的規則。
這跟管理團隊的道理完全一樣：你給一個員工 200 條 SOP，他不會每條都記住，他會記住最常被提醒的那 10 條。剩下的 190 條等於不存在。
六層架構：把 Claude Code 當系統來設計
理解了問題的本質之後，解法就清楚了——不是「寫更好的 prompt」，而是「設計更好的系統」。Anthropic 在《Building Effective Agents》中強調：「最成功的 Agent 實作不是用複雜框架，而是簡單、可組合的模式。」
以下這個六層架構，是我在重構自己專案時歸納出的思考框架：
第一層：上下文層（CLAUDE.md + Skills + Memory）— 決定 Claude「知道什麼」
這一層的核心問題是：哪些資訊需要常駐，哪些按需載入？
根據 Anthropic 官方的 Skills 文件，Skills 採用漸進式揭露（Progressive Disclosure）機制：啟動時只載入 metadata（約 100 token），被觸發時才讀取完整內容（不超過 5K token）。這意味著你可以安裝很多 Skills 而不會有 context 負擔。
我的做法：blog-writer 的 CLAUDE.md 從 300 行壓縮到約 40 行，只留指令骨架。寫作風格、輸出格式規範、fact-check 規則各拆成獨立 Skill，只有在對應任務時才載入。
第二層：執行層（Tools + MCP）— 決定 Claude「可以做什麼」
工具不是越多越好——Claude 需要在每次代理迴圈（Agentic Loop）中判斷該用哪個工具，工具太多會增加決策負擔。Context Engineering 的原則是：工具應該是「self-contained、non-overlapping、purpose-specific」的。
實際例子：gwarket-site 用 preview server 做即時視覺驗證，blog-writer 用 WebFetch 抓取來源文章。兩個專案的工具集完全不同，因為任務性質不同。
第三層：控制層（Hooks + 權限）— 確保該發生的事 100% 發生
這是最被低估的一層。Anthropic 官方文件明確區分了：CLAUDE.md 裡的指令是「advisory」（建議性的），Hooks 是「deterministic」（確定性的）。
白話說：你在 CLAUDE.md 寫「每次改完代碼要跑 build 驗證」，Claude 有時候會忘記。但你設一個 Hook 在每次檔案編輯後自動觸發 build，它就 100% 會執行。靠文字指令不夠穩定的事情，就該搬到 Hooks。
第四層：子代理層（Subagents）— 隔離上下文避免 token 污染
Claude Code 的架構是單執行緒主迴圈（Single-threaded Master Loop）設計，所有對話共用同一條 message history。當你讓 Claude 研究一個問題時，它讀取的每個檔案都會吃掉主對話的 context。子代理在獨立的 context window 中運作，只回傳摘要結果。
就像你不會讓整個團隊都參加每一場會議——需要深入研究的任務，派一個人去調查，帶結論回來就好。
第五層：快取層（Prompt Caching）— 減少重複計算
系統指令和 CLAUDE.md 這些每次都一樣的內容，透過提示快取（Prompt Caching）可以大幅降低延遲和成本。這一層你不太需要手動優化，但理解它的存在有助於你做架構決策——保持 CLAUDE.md 穩定不常改動，快取效率就越高。
第六層：驗證層（測試、Lint、人工確認）— Agent 跑越自動驗證越重要
Anthropic 官方文件把「給 Claude 驗證自己工作的方式」列為最高槓桿的最佳實踐。
gwarket-site 重構後的規則是：每次修改代碼後自動執行 npm run build，確認零錯誤才算完成。這不是寫在 CLAUDE.md 裡的建議，而是透過工作流程強制執行的驗證。
Before / After：兩個專案的實際重構
Blog-Writer：從 300 行混亂到 40 行精準
Before：1 個 300 行的 CLAUDE.md，所有東西混在一起——角色設定、指令一覽、選題流程、轉寫流程、14 家公司的來源清單、WordPress/Facebook/LinkedIn 三種格式規範、fact-check 規則。Claude 經常跳過 fact-check，輸出格式不穩定。
After：
- CLAUDE.md 壓縮到約 40 行（只留指令骨架、篩選規則、流程概要）
- 3 個 Skills 按需載入：writing-style（寫作風格）、output-formats（三平台格式規範）、fact-check（查核規則）
- 來源清單獨立為 sources.md
- 新增 article-log.md 追蹤已寫文章，避免重複觀點
- 新增 HANDOFF.md 做跨 session 交接
Gwarket-Site：從零驗證到結構化管理
Before：沒有驗證層、沒有交接文件、改完代碼全靠肉眼確認。
After：修改後的變化
- CLAUDE.md 59 行（通過自定的 80 行上限）
- 2 個 Skills：ui-design（設計風格指南）、code-conventions（技術慣例）
- 新增 HANDOFF.md 記錄專案狀態
- 工作規則：修代碼後自動跑 build 驗證、超過 3 個檔案的修改需先列計畫
拆分的判斷邏輯
每次 session 都需要的資訊 → 留在 CLAUDE.md。特定任務才需要的知識 → 拆成 Skill（按需載入，不佔常駐 context）。靠文字指令不夠穩定的動作 → 改用 Hook（確定性執行）。跨 session 要記住的狀態 → HANDOFF.md。
兩個專案的上層目錄還放了一份共用 CLAUDE.md（約 30 行），只有角色定位、溝通風格、session 管理規則。像是公司的通用規範，不需要每個專案都重寫一遍。
驗證結果：重構完成後讓 Claude Code 自行驗證——CLAUDE.md 行數合格、Skills 的 YAML frontmatter 格式正確、HANDOFF.md 與專案狀態一致、npm run build 通過（4 個靜態頁面零錯誤）。
我的觀點：Context Engineering 正在取代 Prompt Engineering
做完這次重構，我最大的體會是：Claude Code 不是「更強的寫程式 AI」，它是一個需要被設計的代理系統（Agent System）。
過去我們談提示工程（Prompt Engineering）——怎麼問好問題、怎麼給好 few-shot examples。但當你用 Claude Code 跑一個持續數週的專案，單次 prompt 的品質只是冰山一角。真正決定成敗的是上下文工程（Context Engineering）：怎麼設計系統讓 AI 在每一次互動中都有正確的上下文。
這不是 Claude Code 獨有的問題。任何 Agent 工具——Cursor、Windsurf、Copilot——都面臨同樣的架構挑戰。Context window 是物理限制，attention 是稀缺資源。你用哪個工具不重要，你怎麼設計資訊架構才重要。
HANDOFF.md 這個小機制對我幫助最大。我不是全職工程師，每週只有幾小時碰這些專案，session 經常中斷。HANDOFF.md 讓每次回來都能快速接上進度，不需要花 20 分鐘回憶「上次做到哪了」。如果你也是利用碎片時間用 Claude Code 的人，強烈建議加上這個機制。
目標不是讓 AI 幫你解決問題，而是讓 AI 成為「你做工具的工具」。而好的工具，需要好的系統設計。
Claude Code 的 CLAUDE.md 應該寫多長？
根據 HumanLayer 的分析，frontier model 能穩定遵循約 150-200 條指令，而 Claude Code 系統指令本身就佔約 50 條。建議 CLAUDE.md 控制在 60-80 行以內，只放每次 session 都需要的資訊，其餘拆到 Skills 按需載入。
什麼時候該用 Hooks 而不是在 CLAUDE.md 寫規則？
當某個動作必須 100% 執行時用 Hooks。CLAUDE.md 裡的指令本質是「建議」，Claude 可能在 context 擁擠時忽略。Hooks 是確定性腳本，例如每次編輯檔案後自動跑 ESLint，不依賴 LLM 的注意力分配。
Context Engineering 和 Prompt Engineering 有什麼差別？
Prompt Engineering 關注「怎麼問好問題」，是單次對話的優化。Context Engineering 關注「怎麼設計系統讓 AI 每次都有正確的上下文」，是整個 Agent 架構的設計。前者是技巧，後者是工程。
本文為 gwarket 原創內容，作者 Aaron Huang。
