Prompt Layer 的 Production 實踐：我怎麼用 400 行 Markdown 治理七個 AI

讓 AI Agent「越用越懂你」有兩條路。

Weight Layer：用 RL / fine-tune 直接改模型權重。知識刻在模型參數裡，理論上可累積、可泛化。代價是你需要 GPU 叢集、訓練管線、版本管理，而且一旦資訊過時，你無法「刪掉」那段記憶 — 必須重新訓練。

Prompt Layer：把經驗沉澱成可讀檔案 — markdown、rules、profiles — 每次啟動時載入。改的是 context 而不是 weights，不需要 GPU，成本低一個數量級，而且可審計、可回滾、可用 git 管理。

2026 年，幾乎所有 AI coding tool 的「越用越聰明」都走 prompt layer。Claude Code 的 CLAUDE.md、Cursor 的 .cursorrules、Codex 的 AGENTS.md — 本質上都是同一件事：用檔案而不是梯度來教 AI。

我選了 prompt layer，然後把它推到了一個大多數人不會去的深度。

400 行核心 + Hooks + Docs 的三層治理

我的 AI 工作環境是一個七成員的 Council：Claude（架構）、Codex（工程 + review）、Gemini（分析）、Perplexity Max（深度研究）、SuperGrok（即時情報）、qwen3.6（本地推論）、gemma4:31b（寫作）。每天跑 10-20 個任務，涵蓋寫 code、部署、分析、寫文章。

管理這七個 AI 的規則全部寫在文字檔裡。沒有 fine-tune，沒有 RLHF，沒有任何模型修改。

核心層（~400 行，每個 session 必讀）：

~/.claude/CLAUDE.md      # 全局規則
~/.claude/rules/*.md     # 行為約束（6 檔）

這一層定義了不可違反的紅線、決策框架、記憶系統、安全規則。400 行是刻意控制的 — 超過 500 行會觸發治理膨脹告警。

Hooks 層（程式碼強制執行）：

// settings.json hooks section
"PreToolUse": [...],  // 工具呼叫前檢查
"PostToolUse": [...]  // 工具呼叫後驗證

規則寫在 markdown 裡是「建議」，寫在 hooks 裡是「法律」。Hook 違規直接阻斷執行，不給 AI 商量的餘地。

Docs 層（按需載入）：

docs/governance/     # ACE 協議完整規格
docs/standards/      # ML 效能標準
docs/deploy-sop.md   # 部署 SOP

這些是參考文件，不是每個 session 都讀。只有遇到特定情境（部署、治理決策）才載入，避免 context 膨脹。

三層分離的設計原則：核心要短、hooks 要硬、docs 要按需。

五個實戰中打磨出來的機制

1. 撞牆停手（2 次失敗 → 強制停止）

同一問題嘗試 2 次失敗 → 立刻停止改動，整理問題說明給我。不得隱藏撞牆事實。

這條規則是被痛打出來的。早期 AI 會在錯誤的方向上連續嘗試 5-6 次，每次都信心滿滿地說「這次應該可以了」。結果是浪費 token、製造更多問題、把 codebase 搞得一團亂。

2 次是刻意選的門檻 — 第一次可能是偶發錯誤，第二次代表方向可能錯了。強制停手比強制成功更有價值。

2. 禁止猜測（每個判斷必須有來源）

每個判斷：{結論} ← {來源}。來源 = 命令輸出 / 使用者提供 / 讀到的 code。「應該是」「通常是」→ 停，去查。

AI 最危險的時刻不是它不知道答案，而是它假裝知道。「根據經驗，這個設定通常是...」— 這種措辭背後往往是幻覺。

我把禁用詞列表寫進規則：「應該是」「通常是」「根據經驗」「大概是」。AI 看到這些詞會自動替換成「我不確定 {X}，需要先確認」。

3. 四級 Preset 快速判定

不是每個任務都需要七個 AI 一起開會。判定邏輯只有四個問題：

1. Scope — 幾個檔案？（1 檔 ≤3 行 → fast-path）
2. 跨邊界？ — 跨 repo / infra / deploy？（→ 升級）
3. 不可逆？ — delete / migration / production？（→ 再升級）
4. 無法本地驗證？ — 只能上線觀察？（→ 再升級）

口訣：Scope 定起始，BIU 任一命中就升級。

大部分任務走 fast-path（AI 直接做）或 solo+review（做完 Codex 審）。Full-council 是 escalation，不是常態。

4. 記憶系統（memhall — 跨 session 持久化）

Prompt layer 的致命弱點是無狀態 — 每個 session 從零開始。我用 memhall（自建的記憶服務）解決：

• 開場：搜尋上次工作記錄，輸出「從哪裡接續」
• 收尾：寫入本次決策和進度，標記 TTL（permanent / expiring / scratch）
• 寫入前 4-question gate：跨 session 適用？ratified？會被搜？不重疊？

這讓 prompt layer 也能「記住」— 不是透過 weights，而是透過結構化的外部記憶。

5. Codex Review Gate（完成 → 必須審查）

完成功能 / 重構 / 大量修改 → 必須 Codex review，未審查前不得視為完成。

用另一個模型審查產出是 multi-agent 最直接的價值。不是讓 Claude 自己 review 自己 — 那跟學生批改自己的考卷一樣沒用。是讓 Codex（不同的模型、不同的 training data、不同的 bias）來看。

今天這篇文章的 after_date 參數改動就被 Codex review 抓到了一個 bug：do_search() 的 HTTP handler 用位置參數呼叫，插入新參數後把 use_rerank 的值傳給了 after_date。如果沒有 review gate，這個 bug 會直接上線。

為什麼不 Fine-Tune？

不是不能，是不值得。

成本：fine-tune 一次 GPT-4 等級模型的費用，夠我跑 prompt layer 一整年。而且模型每 2-3 個月大改版，fine-tune 的投資會隨著 base model 更新而貶值。

可控性：prompt layer 的每一條規則都是人類可讀的 markdown。我可以 git blame 查出每條規則是什麼時候、因為什麼原因加上的。fine-tune 的知識是黑盒。

跨模型：同一份 CLAUDE.md 可以（大致）用在不同模型上。fine-tune 是模型綁定的。

回滾：git revert 一行就能撤回一條規則。fine-tune 要回滾就要重新訓練。

唯一 fine-tune 比 prompt layer 好的場景是：你需要模型在沒有 prompt 的情況下就具備某種能力。但在 coding agent 的場景下，CLAUDE.md 永遠都在 — 它是 harness 的一部分，不是可選的附件。

Prompt Layer 的天花板在哪？

坦白說，有三個限制：

Context 成本：400 行的 CLAUDE.md 大約 2K token，加上 rules 和按需 docs，每個 session 的「治理開銷」大約 5-8K token。當 session 長到 500K+ 時，這個比例可以忽略。但如果你用短 session + 頻繁重啟，overhead 就很明顯。

一致性依賴模型服從度：規則寫得再好，模型不 follow 就沒用。Claude 4.x 系列的指令遵循率很高，但不是 100%。所以關鍵規則必須用 hooks 硬化，不能只靠 prompt。

跨模型移植有損：同一份規則給 Claude 和 Codex，執行效果不一樣。每個模型對 markdown 結構、條件邏輯、否定指令的理解都有微妙差異。所以 Council 裡每個成員的 briefing 都要針對性調整。

結語：Prompt Layer 是治理，不是 Prompting

很多人把 CLAUDE.md 當成「一份很長的 system prompt」。不是。它是一套治理框架 — 有紅線、有分級、有記憶、有審計、有回滾。

Weight layer 改的是模型的「本能」，prompt layer 改的是模型的「制度」。在一個模型能力每季翻倍的時代，制度比本能更持久。

你不需要七個 AI 才能開始。拿一份空白的 CLAUDE.md，寫上你遇到過的前三個問題的規則，commit 進 repo。下一個 session，AI 就會記得。

這就是 prompt layer。不需要 GPU，不需要訓練管線。只需要你願意把經驗寫下來。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。