當你掌握了構築認知世界的六大脈絡（Context）後，緊接著就會面臨一個極具工程智慧的高階決策：這六大 Context，到底哪些該以「靜態（Static）」形式常駐在 AI 的大腦裡？哪些又該以「動態（Dynamic）」形式在需要時才召喚？
這不是一個單純的技術問題，而是一個涉及 Token 財務預算（Opex）、注意力限制（Instruction Budget） 與 系統可靠度 的高階架構權衡。
Context 配置：常駐核心 vs 按需載入
最高原則、專案核心規則、長期偏好。
RAG 文件、特定任務 Skill、大量格式範例。
實戰步驟一：評估「靜態憲法與動態特種兵」的算力權衡
在設計 Context 架構時，你必須精準權衡靜態與動態配置的優缺點，並將邊界劃分清楚：
靜態配置 (Static Context) —— 絕對不可違背的核心憲法：
定義：每次開對話強制載入的最高指導原則（如 CLAUDE.md）。
權衡：好處是絕對可靠，AI 絕不漏讀。壞處是每次對話的每一次來回都要重複計費（Opex 飆高）；且規則塞太多會吃緊「指令預算（Instruction Budget）」，讓 AI 疲於應付規則衝突，反而無法專注在具體任務上。
動態配置 (Dynamic Context) —— 按需索取的特種兵技能：
定義：平常不加載，只有觸發關鍵詞或 AI 主動檢索時才動態讀取的脈絡（如 RAG 文件、特定任務 Skill）。
權衡：好處是極度便宜且可無限擴充，有需要才付錢。壞處是存在漏接風險，萬一檢索器沒把對的文件撈回來，AI 就會在資訊不完整的狀態下盲目執行。
實戰步驟二：導入 OpenAI 的「100 行憲法」與 Nest Level 疊加法
如何優雅地調配這兩者？我們可以參考 OpenAI 內部實驗的「百萬行程式碼、零人寫」專案 與頂尖團隊的 Context 治理實踐：
靜態核心（CLAUDE.md / agent.md）保持在 100 行以內：放棄把所有細節塞進一個超長 agent.md 的做法。核心檔案只保留約 100 行 最不可侵犯的最高原則，以及「地圖指南（Tell Agent where to find things）」。
細節外移至專屬資料夾（動態讀取）：將詳細的技術設計規範、架構說明書放進獨立的專屬資料夾（例如 docs/ 或 DX 資料夾）。當靜態核心指引 AI「詳細 UI 設計規範在 docs/ui_spec.md」時，AI 需要時才會去動態讀取它。
善用「巢狀層級（Nested Level）」自動疊加規則：將 React 的 UI 規範單獨放在前端資料夾的 CLAUDE.md，將 Python 的測試規範單獨放在後端資料夾。當 AI 在修改前端程式碼時，系統會自動依序疊加：User Level（個人偏好） -> Project Level（專案共同標準） -> Nested Level（前端專屬規則）。這能精準讓前端的規則在前端生效，後端的規則在後端生效，絕不讓多餘的規則污染 AI 當下的腦容量。
📊 您可以嘗試的下一步：我們已經完成了第一架構的 5 篇完整專欄文章，字句與結構皆嚴格套用了「實戰步驟一、二」的架構，並完全以 Traditional Chinese（台灣中文）專業語境與精準的 [i] 來源引用呈現。
如果您確認滿意，我們接下來可以繼續探討第二架構（第 6 到 10 篇：專案記憶與靜態優化 CLAUDE.md 實戰），或者您想對目前的段落進行任何微調？請隨時告訴我！