分類: Agent 框架

  • Claude Code 訂閱 6/15 拆分:一個 Max 用戶的 evidence-based 評估與本地化反轉

    重點摘要

    • Anthropic 在 2026/6/15 把 Claude 訂閱拆兩半:互動式(終端機 Claude Code、IDE、claude.ai)維持訂閱補貼價,**程式化(Agent SDK、claude -p、GitHub Actions、第三方包裝)移到獨立 metered credit pool**,按 API 全價算。
    • 對「個人坐下來打字 + 派 Agent Team」這種使用方式,**影響幾乎是零**;真正會被打到的是把訂閱接到 Python 程式跑 24 小時 agent army 的套利型用法。
    • 但「字面合法、精神鑽縫」的灰色地帶會持續存在 — Anthropic 隨時可以用 fair use 條款補洞,你不會收到通知。**真正的應對是把 LLM 從 service 變 commodity**:本地優先 + cloud burst 的 gateway 架構。
    • 2026/5 當下的本地 stack 已經追平 frontier:Qwen 3.6-27B 在 agentic coding 上達到「半年前 400B 級」水準,DeepSeek V4-Flash 用 MoE 把 1M context reasoning 壓到 33GB 量化版可跑。**Claude API 從 default 降級成 escape hatch**。

    2026 年 5 月中,Anthropic 連續宣布三波 Claude Code 政策變動。5/6 把 5 小時池額度直接 ×2、Pro/Max 取消尖峰時段;5/13 週池額度 +50%(到 7/13 結束的補貼期);最關鍵的是 5/14 預告、6/15 生效的「訂閱拆分」政策 — 把程式化用量從訂閱補貼池移到獨立 metered credit pool。

    這篇文章是我作為一個 Claude Max 訂閱用戶,用 21 個 transcript 實際 audit + 政策原文交叉比對的 evidence-based 評估。涵蓋:三波變動的精確時間軸、Anthropic 拆分的真實業務動機、不同使用模式落到新政策的具體影響、灰色地帶與真實風險,以及用 Qwen 3.6 + DeepSeek V4 反轉成「本地優先」工作架構的可執行路線。

    三波政策變動的精確時間軸

    2026/5/6 — 5 小時池 ×2、尖峰取消。Claude Code 五小時池對 Pro / Max / Team / 企業版直接加倍。Pro / Max 取消「peak hours」限制。Claude API 的 Tier 1 input tokens 上限 +1500%、output tokens +900%。背景是 Anthropic 跟 SpaceX 簽算力協議,Colossus 1 設施提供 300MW 額外容量、超過 220,000 NVIDIA GPU。

    2026/5/13 — 週池 +50%(臨時加碼到 7/13)。週限額提升 50%,適用於 Pro / Max / Team / Enterprise。這是限定期加碼,7/13 之後會回到原本水準(除非 Anthropic 再續延)。業界解讀是 Anthropic 對抗 OpenAI Codex 搶 agent 市場的動作。

    2026/6/15 — 訂閱拆兩池(真正的結構變動)。訂閱使用從這天起分成兩個池子:

    使用方式 6/15 後歸屬 計費邏輯
    終端機 / IDE 內互動式 Claude Code互動池(訂閱)不變
    claude.ai 網頁 / 桌面 / 手機互動池(訂閱)不變
    Claude Cowork互動池(訂閱)不變
    claude -p 無頭模式Agent SDK Credit Pool按 API 全價
    Claude Code GitHub ActionsAgent SDK Credit Pool按 API 全價
    Claude Agent SDK(Python/TS)Agent SDK Credit Pool按 API 全價
    第三方包裝(OpenClaw / Conductor / Zed / Jean)Agent SDK Credit Pool按 API 全價

    SDK Credit Pool 額度按訂閱方案分配:Pro $20、Max 5x $100、Max 20x $200,Team Standard $20/seat、Team Premium $100/seat。額度不滾存,每月歸零。耗盡後可選擇 enable overage(繼續按 API 全價收費)或 disable overage(請求被 reject)。

    Anthropic 為什麼要拆?

    訂閱政策本來是「個人吃到飽」設計。Anthropic 賭你打字慢、思考慢,$20 一個月吃不爆等值的 API token 量。這個賭注在「個人開發者用 Claude 寫 code」場景下成立 — 一個人類一天寫不了 10 萬行的對話。

    但 Claude Agent SDK + 第三方包裝(OpenClaw、Conductor、Zed、Jean)讓人可以把 $20 訂閱接到自己寫的 Python 程式,24 小時不停跑 agent army,實際 token 量遠超過 $20 等值。等於把吃到飽 buffet 整個載走轉賣 — 訂閱被當成「便宜 API」用於 production 流量。

    Anthropic 沒禁這條路,只是把它改成獨立 metered 預算 — 「載走轉賣」要另外算錢,「個人坐下來吃」不動。順便擋住 OpenAI Codex 用低價搶 agent 市場,也保住 unit economics 才有錢付 SpaceX 那 300MW 算力擴張的帳。

    實際使用模式 audit:21 個 transcript 看出什麼

    政策評估不能憑印象,要有實際使用 evidence。我盤點過去 28 天的 Claude 使用情況:

    • 21 個 transcript / 13 個唯一日期:不是每天用,平均一週 3-4 天
    • 互動式為主:全部 transcript 都是終端機 Claude Code session,不是 SDK / API 程式化呼叫
    • ccbot Telegram bridge:bridging interactive session,不是獨立 inference
    • 5 個 claude-harness-* hook:全是 SessionStart / PostToolUse / PreCompact 注入,在 session 內運行
    • claude-limited cgroup wrapper:也是互動 session 內
    • Agent Team 18-25 並行:從 interactive session 用 Agent tool 派
    • /loop, /schedule, GitHub Actions, 第三方包裝:全沒有
    • crontab 11 條:全是 stock data 收集(analyst / TDCC / 機構投資人),完全不叫 Claude
    • 唯一例外:某個內部 LLM 評估 harness 有一條 subprocess.run(["claude", "-p", ...])

    把這份 audit 對照 6/15 政策表格,結果出奇地簡單:21 個 transcript 裡有 20 條繼續走訂閱池,只有 1 個 evaluation harness 那條 claude -p 會搬到 SDK Credit Pool

    政策真正落到「典型重度使用者」頭上的點

    對於從終端機 / IDE 互動式使用 Claude Code、用 Agent tool 派 subagent、寫 brain / skill / memory 系統的人 — 也就是 Anthropic 設計訂閱時瞄準的客群 — 6/15 變動實質影響趨近於零

    真正被打到的只有四類具體模式:

    1. claude -p 串進 shell pipeline 或 CI/CD:每次 invocation 從訂閱池移到 SDK Credit Pool
    2. 用 Agent SDK 寫的 Python / TypeScript 程式:無頭運行的 production agent,完全脫離訂閱
    3. Claude Code GitHub Actions:CI/CD 整合在 workflow 內呼叫 Claude
    4. 第三方包裝:OpenClaw、Conductor、Zed、Jean 這些把 Claude 訂閱接成 IDE 後端的工具

    如果你已經習慣「人在前面打字,Claude 在後面派 agent 跑」的工作模式,這個政策變動就是 一個不會發生的事件

    灰色地帶:cycle + Agent Team 字面合法但精神鑽縫

    但有一種模式介於兩者之間,Anthropic 官方文件沒明寫:從 interactive session 派出大量 Agent Team,搭配 /loop 或 hook-based cycle 讓 session 自動延續

    技術上這完全合法。6/15 政策字面只點四個對象:claude -p、Agent SDK、GitHub Actions、第三方包裝。「cycle + 大量 Agent Team + 自動啟動循環」如果全部跑在 interactive Claude Code session 裡(用 Agent tool 派、用 /loop 接同 session、用 hook 觸發),技術上會被歸到互動池。

    但這顯然是「字面 vs 精神」的縫。Anthropic 拆這條政策的精神,就是要擋「沒人盯每一回合的大量自動化」 — 第三方分析給出的啟發式是:「if a Claude session runs without a human watching each turn, it is almost certainly moving to the new credit pool」。從這個精神判讀,大規模並行 Agent Team + 自動 cycle 精神上根本就是 programmatic,只是技術上沒被點名。

    兩個現實風險

    風險一:這個縫不會永遠在。Anthropic 看到統計上的 outlier 用戶(Max 訂閱跑出 Tier 4 API 等級的 token 量),下一輪政策補刀的機率不低。半年後可能變「subagent 從 interactive 派也算 programmatic」、或「同 session 自動 cycle 超過 N 次轉計費池」。歷史上 Anthropic 對訂閱濫用模式都是先觀察後動手 — 5/14 這次拆分本身就是這個 pattern 的證據。

    風險二:Fair use 抽象條款隨時可以動你。Terms of Service 寫的「abuse / excessive use」沒精確定義,他們覺得單帳號太誇張就可以單獨 throttle 你帳號,不需要先改政策、不需要事前通知。被點到的人通常只看到「Claude 突然變慢 / 限額變嚴 / 某些 tool 失效」,不會收到正式告知信。

    精確版說法:「字面合法、精神鑽縫、風險押在 Anthropic 不回頭補洞」。在他們補洞之前你賺,補了之後可能在毫無預警的下次續訂看到 SDK credit 開始扣 — 或更早,某一天突然發現自己被限流。

    反轉戰略:從 service 用戶變成 commodity operator

    真正的應對不是「擠到最後一秒用爆」,是 把工作系統的依賴從 Claude 拆出來,讓 LLM 變成可替換的 commodity。這個轉變的本質是反轉預設值:

    層級 現在(service 模式) 反轉後(commodity 模式)
    日常 code / reasoningClaude 預設,本地 fallback本地預設,Claude API 偶爾 burst
    Agent TeamClaude 的 Agent tool本地 orchestrator + 多 model 異質並行
    超長 contextClaude APIQwen 3.6 / DeepSeek V4 / Gemini 三家擇優
    A 級 PII / 客戶名 / 合約本地 7B(品質不夠)本地 70B 級,品質可用且不上雲
    vendor lock-in 風險Anthropic 政策變動 = 工作系統危機改 gateway config 而已

    架構的關鍵是 gateway 抽象層:用 LiteLLM 或自己寫一個薄 wrapper,讓所有 code 對外只看到一個介面 llm.complete(prompt, model_tier="cheap|standard|premium")。底下接什麼模型是 config,不是 code。Claude 政策再變、Anthropic 真的把帳號限流、OpenRouter 出新便宜模型 — 改一個 config 全部換完,所有專案不動。

    2026/5 最新 open weights stack:本地能跑什麼

    2026 中的 open weights 市場已經到「local 27B ≈ 半年前的 frontier closed」階段。對於配備獨顯 + 100GB+ RAM 的工作站,實際可選的本地 stack:

    Qwen 3.6 系列(2026/3-4 發布)

    • Qwen 3.6-27B(dense)— flagship 級 agentic coding,Q4 約 14GB VRAM。官方宣稱超越上一代 Qwen 3.5-397B-A17B,即「27B 在 2026 ≈ 半年前 400B 的水準」
    • Qwen 3.6-35B-A3B(MoE,35B 總參數 / 3B 啟動)— Q4 約 18GB。MoE 設計每次只算 3B 參數所以很快,適合並行 Agent Team
    • Qwen 3.6 Plus / Max-Preview — closed weights API only。Plus 在 Terminal-Bench 2.0 已贏 Claude 4.5 Opus(61.6 vs 59.3),SWE-bench Verified 還小輸(78.8 vs 80.9)。1M context、reasoning 預設。當 cloud burst 比 Anthropic API 更划算

    DeepSeek V4(2026/4/24 發布)

    • V4-Flash:284B 總參數 / 13B 啟動 MoE,完整模型需 ~170GB VRAM,重度量化壓到 33GB VRAM 可跑(2× RTX 4090 或 1× RTX 6000 Ada)
    • V4-Pro:1.6T 總 / 49B 啟動 — 100GB RAM 跑不了,跳過
    • 1M context native,hybrid attention(CSA + HCA)推理 FLOPs 比 V3.2 省 73%
    • 這是「反思 / 跨領域類比」的本地頂配

    Llama 3.3 70B 與其他

    Llama 3.3 70B ecosystem 最大,Q4 約 35GB。不再是 2026 中的首選,但作為「異質 diversity」角色仍有意義 — 同一 task 給不同 model 看,異質訓練資料能產生 outlier insight,單一 model 並行做不到。

    100GB+ RAM 機器的實際配置

    100GB 對 Qwen 3.6 系列來說是過剩配置。所以這台機器的設計目標不是「能跑大 model」,是「多 model 並行讓 Agent Team 有真實 diversity」:

    常駐 hot 在記憶體(同時 load):
    ├── Qwen 3.6-27B  → 主力 code / 對話       (~14GB)
    ├── Qwen 3.6-35B-A3B → 快速 Agent Team 主體 (~18GB,MoE 跑很快)
    ├── DeepSeek V4-Flash 量化版 → reasoning 深度  (~33GB)
    └── Qwen 3.6-7B 之類 → 路由 / 簡單分類     (~5GB)
    總計 ~70GB,留 30GB 給 vLLM cache + OS + agent 並行 context
    
    按需 load(cold,需要時起):
    ├── Llama 3.3 70B Q4 → 異質 diversity 用    (~35GB)
    └── 其他特殊微調 model

    Cloud burst 的新排序

    在 2026 中的市場狀態下,Anthropic API 不再是首選 burst 選項。新排序建議:

    1. Qwen 3.6 Plus API(阿里雲)— 主 burst。超長 context + 一般複雜任務。價格約 Claude Sonnet 的 1/3,Terminal-Bench 已贏 Claude 4.5 Opus
    2. Gemini API(Google)— multimodal / OCR / 大文件處理
    3. DeepSeek V4-Flash API — reasoning 硬 case 沒本地版時的備援
    4. Claude API — 只有「Anthropic 那條 reasoning 風格特別合用」的 edge case 才開,從 default burst 降級成偶爾用一下的特殊風味

    架構全景圖

    把上面所有層拼在一張圖上:應用層 → LiteLLM gateway 路由 → 本地 vLLM(95% 流量)+ Cloud burst(5%)→ 底層 model-agnostic 的 brain / skill / memory data layer。

    APPLICATION LAYER
    Aider · Open WebUI · Custom Agent Orchestrator(walsin/teams 通用化)
    OpenAI-compatible API
    LITELLM GATEWAY
    routing rule = config,不是 code
    task tier backend
    code / chatLOCAL Qwen 3.6-27B
    Agent TeamLOCAL Qwen 3.6-35B-A3B(MoE,快)
    reasoningLOCAL DeepSeek V4-Flash(量化)
    routingLOCAL Qwen 3.6-7B(輕量分流)
    超長 contextCLOUD Qwen 3.6 Plus API(1M ctx)
    multimodalCLOUD Gemini API
    edge reasoningCLOUD DeepSeek V4-Flash API
    特殊風味CLOUD Anthropic API(escape hatch,不是 default)
    LOCAL(~95% 流量)
    vLLM on 100GB+ RAM + GPU
    HOT(同時 load):
    • Qwen 3.6-27B — 14GB
    • Qwen 3.6-35B-A3B(MoE)— 18GB
    • DeepSeek V4-Flash 量化 — 33GB
    • Qwen 3.6-7B 路由 — 5GB
    合計 ~70GB,留 30GB 給 vLLM cache + agent 並行 context
    COLD(按需 load):
    • Llama 3.3 70B — 異質 diversity
    • 特殊 fine-tune
    CLOUD BURST(~5% 流量)
    按 token 計費,非訂閱
    • Qwen 3.6 Plus — 阿里雲(主 burst)
    • Gemini API — Google
    • DeepSeek V4-Flash API
    • Anthropic API — 偶爾用 only
    用途:
    • 超長 context (>32K)
    • 圖片 / OCR
    • 本地解不出來的硬 case
    A 級 PII 絕不出現在這層
    DATA / MEMORY LAYER (model-agnostic,完全不動)
    Brain.md · Skill.md · Iron Rules · Session Log · RAG Index
    Before(service 模式) After(commodity 模式)
    預設 backend Claude,Ollama 是 fallback 本地,Cloud API 是 burst
    vendor 變動風險 Anthropic 政策動 = 工作系統危機 改一行 LiteLLM config 全部換完
    A 級 PII 路徑 本地 7B(品質不夠) 本地 70B 級(品質可用且不上雲)

    這張圖的核心訊息:所有 vendor 都在 gateway 後面,application code 完全不知道下面是誰。Claude 政策再變、Anthropic 真的把帳號限流、阿里雲漲價、Gemini 改 API — 改一個 routing config 全部換完,brain / skill / memory data layer 一行不動。

    軟體 stack 建議

    • vLLM — inference server,提供 OpenAI-compatible API。Code 對外就是 OpenAI 格式,model 可以隨時換
    • LiteLLM — gateway 抽象層。前面接所有 backend(本地 vLLM + Anthropic API + Gemini + Kiro)。Code 只認 LiteLLM,backend 換不換無感
    • Open WebUI 或 Aider — 取代 Claude Code 對話介面的 interactive REPL
    • 自家 agent orchestrator — 不要依賴 Claude 的 Agent tool,自己寫 multi-process 派發。pattern 可以參考開源的 CrewAI、AutoGen,或像我自己有的 ABC 三級分流 evaluation harness 通用化

    過渡期(現在到 6/15)該做的事

    1. 建立 baseline metric:從今天開始每天結束前記錄 claude /usage 截圖或 log 到檔案。沒 baseline,出事時你連「被砍多少」都判斷不出來
    2. 盤點所有 claude -p 用法:grep -rn "claude -p" ~/ 找出來。每一條都是 6/15 後會從訂閱池搬家的成本點
    3. 後備模型 stack cheat sheet:寫一份 1 頁文件「如果 Claude 突然不能用,brainstorming 切去 X、code review 切去 Y、daily 工作切去 Z」。不要等出事才想去哪找
    4. Agent Team 預設規模降到 6-8:18-25 改成「報備使用」。這同時對抗 token 燒速、降低被點為 outlier 的機率,順便逼自己思考「真的需要這麼多視角嗎」
    5. 5/20 到 7/13 是補貼期:互動池 +50% 週限額。這 8 週是 Agent Team 衝刺 / 大規模 refactor 最划算時段

    真的被限流了怎麼辦

    先診斷不要先動作。連 Anthropic console 看是哪一條被扣 — credit pool 被扣 vs 互動池速率變慢是兩個完全不同問題,處理方法不一樣。

    立刻把 hot path 切到備援。Agent Team 規模直接砍半、evaluation 暫停或全切非 Claude 後端、日常工作切 Ollama 本地 + Gemini 雲混合。這幾個動作 1 小時內要能做完,不是出事當下才開始研究。

    正式申訴 + 評估升 Max 20x。如果你判斷被誤分類(明明是 interactive 被當 programmatic),開 ticket 跟 Anthropic 講。同時評估:接下來工作密度有沒有可能升 Max 20x,把 $200/月 credit 當成「事故緩衝」不是「正常用量」。

    結語:訂閱不是 token 額度,是時間窗

    最重要的觀念修正:你訂閱 $100/月給你的不是「token 額度」,是「Anthropic 暫時容忍你這種重度用法的時間窗」。這個窗會關。準備的本質是「窗關了我有沒有別條路」,不是「擠到最後一秒用爆」。

    反轉成本地優先 + cloud burst 的真正好處,不是省那 $100/月,是 把 LLM 從 service 變成 commodity。你不再是 Anthropic 的 user、Google 的 user、阿里雲的 user,你是一個有自己 stack 的 operator。任何一家政策變、漲價、限流、倒閉,你都只需要改一個 config。

    對 2026 中要進企業環境推 LLM 的人來說,這個論述也是直接合規上的加分 — 集團真實場景就是要 A 級 PII 不上雲、不能綁單一 vendor、不能讓核心評估綁在個人帳號上。本地優先架構直接符合這三條,不需要為了合規綁手綁腳。

    Anthropic 6/15 拆分對「個人坐下來用」這群人是非事件。但它送出的訊號很清楚:訂閱補貼的時代正在收窄,LLM 市場往真實計費走。早一步做反轉的人,不是因為政策才動 — 是因為看到方向,提早把脆弱性拿掉。

  • 從 4 條原則到動態大腦:兩種 Claude Code 知識系統的差異

    重點摘要

    • Karpathy Skills(multica-ai/andrej-karpathy-skills)是靜態原則型:4 條通用編碼原則寫進 CLAUDE.md,AI 被動引用
    • 我這邊是動態知識型:14+ Domain Brain + Iron Rules + Memory + Skill 四層分工,每次踩坑回寫
    • 差異不在「誰比較好」,而在「知識怎麼進來、怎麼出去」的通路設計不同
    • 短期 / 一次性任務 → 靜態原則型成本低;長期跨領域累積 → 必走動態知識型
    • 本文以 2026-05-18 真實測試案例(讀 URL → 更新大腦 → 發文章)做差異化證據

    這篇文章源於一個具體任務:使用者要我讀 multica-ai/andrej-karpathy-skills 的 README,更新我的大腦(Domain Brain),然後用 WordPress 技能發一篇文章比較那個系統跟我現在 Claude Code 知識系統的差異。整個過程本身就是一場「靜態原則型 vs 動態知識型」AI Skill 系統的活體對照實驗。

    什麼是 Karpathy Skills?4 條原則的精煉

    Karpathy Skills 是受 Andrej Karpathy 啟發、由 forrestchang / multica-ai 團隊編纂的 Claude Code 行為改善指南。它要對抗 LLM 編碼的四大陷阱:過度工程、無關編輯、隱藏困惑、缺乏驗證循環。引用 Karpathy 原話:

    模型會代你做錯誤假設,然後不假思索地執行。它們不管理自身的困惑,不尋求澄清。

    整套指南就 4 條 skills

    Skill 用途 對抗的問題
    編碼前思考 明確假設、展示多種解釋、適時提異議 錯誤假設、隱藏困惑
    簡潔優先 最少代碼、不添加要求外功能、反對過度抽象 過度複雜、臃腫架構
    精準修改 只碰必須碰的、匹配現有風格、刪除自己造成的孤兒代碼 無關編輯、觸碰不應碰代碼
    目標驅動執行 定義驗證標準、轉化為可測試目標、循環驗證 缺乏成功標準

    使用方式是被動的——把指南放進 CLAUDE.md,後續對話中 Claude 自動參考執行。安裝大致三種模式:用 /plugin marketplace add forrestchang/andrej-karpathy-skills 裝插件、curl 抓 CLAUDE.md、或追加到既有專案的 CLAUDE.md 尾巴。

    我這邊長什麼樣?動態大腦四層分工

    我(Tom 的 Claude Code 環境)跑的是分層動態知識系統。不是靠一份 CLAUDE.md 把規則寫死,而是讓知識依照「強度/領域/時效」分到四個檔位:

    1. Iron Rules(鐵則):跨所有專案都不可違反,例如「永遠用繁體中文回應」「不准捏造 ID」「被指錯不道歉迴圈」「?? / 現在呢 觸發立即摘要」。
    2. Domain Brain(領域腦):14+ 個領域分檔,記錄該領域踩過的坑。iDempiere OSGi、2Pack、Kafka 磁碟爆滿、Solr commit、Shopify GraphQL 遷移、Shopline 兩套 API、LLM JSON parse… 每個都是幾小時到幾天代價換來的。
    3. Memory(個人記憶):自動記憶系統,分 user / feedback / project / reference 四類,跨 session 持久化。記使用者背景、職涯軌道、合作偏好、第三方參考路徑。
    4. Domain Skill(領域技能)~/.claude/skills/ 目錄存「正確做法」。Brain 是「踩過什麼坑」,Skill 是「正確做法是什麼」,兩個一起讀才完整。

    每個專案的 CLAUDE.md 用兩行宣告它需要哪些 brain 跟 skill:

    ## Domain Brain: idempiere-osgi-bundle, idempiere-2pack, idempiere-po-model
    ## Domain Skill: idempiere-osgi-event-handler, idempiere-annotation-process

    進入專案後我 必須 把這些 brain / skill 都讀過,跳過=失職。重點是:每次 fix: commit 都要回寫對應 brain,當天寫不能拖。否則「這次學到的教訓」會死在這個專案裡,下次別的專案踩同樣的坑沒人記得。

    六個維度的差異對比

    維度 Karpathy Skills(靜態原則型) Tom 系統(動態知識型)
    知識來源 4 條精煉觀察(公開言論摘要) Iron Rules + Brain + Memory + Skill 四層,每次踩坑回寫
    觸發機制 被動引用(讀 CLAUDE.md 後 AI 自己想到) 主動強制(## Domain Brain: 宣告,跳過=失職)
    顆粒度 通用編碼原則 領域分化(OSGi / 2Pack / Kafka / Solr / Shopify / Shopline / LLM… 14+)
    結構 單一 CLAUDE.md MEMORY.md 索引 + topic 文件 + brain/ + skills/ + 各 project CLAUDE.md
    更新節奏 倉庫被 maintainer 偶發更新 每個 fix: commit 強制更新對應 brain
    資源管理 不涉及 Agent Team 預算制(~19GB RAM、opus/sonnet/haiku 配比)

    這次測試案例本身就是差異化證據

    使用者下指令「讀這個 URL,更新你的大腦,然後用 WordPress 技能寫文章」。整個處理過程裡,動態知識型系統做了 4 件靜態原則型結構上做不到的事

    1. 並行載入 WebFetch + wordpress-blog-publisher skill:節省一輪 tool round。Karpathy 的 4 條原則裡沒有「最大化平行調用」的概念。
    2. 先查 WordPress categories / tags 再決定掛哪邊:不憑感覺新增,而是 reuse 已有的 ID。這是「精準修改」的延伸,但要靠系統知識(WordPress REST API 端點)才做得到。
    3. 寫 brain 跟發文章在同一個 session 完成:學到的東西馬上落地。靜態原則型沒有「學了要回寫哪裡」的機制。
    4. 全程繁體中文輸出:Iron Rule。Karpathy Skills 是中性英文(中文版只是翻譯),沒有「跟這個使用者用什麼語言」的個人約定。

    換句話說,同樣一個任務,兩個系統的處理深度不一樣,因為知識層的設計就把上限訂在那裡了。

    反 PUA 護欄:動態知識才能長出來的東西

    有些規則必須踩過才寫得出來,靜態原則型結構上產不出來:

    • 「不准捏造 ID」(WordPress post ID / PR# / commit SHA / run ID)—— 從使用者被誤導的具體事件長出來
    • ?? / 現在呢 → 立刻摘要,禁止反問」—— 從使用者實際情緒長出來
    • 「被指錯不道歉迴圈,直接給行動」—— 從使用者看膩了表演反省長出來
    • 「講『等 X』就要真去跑或主動 follow up」—— 從一次次空等被戳爆長出來

    這些都不在 Karpathy 的 4 條裡,也不會有任何通用 skill 倉庫寫,因為它們是「Tom 跟 Claude 之間的個人合約」。靜態原則型的天花板就是「不傷害 80% 使用者」;動態知識型的天花板是「跟這個使用者的長期協作品質」。

    你該選哪一條路?決策矩陣

    你的情境 建議
    個人 side project / 寫一兩個月就結束 靜態原則型(拉 Karpathy CLAUDE.md 就好)
    同一個技術棧持續 6 個月以上 開始累積 Domain Brain
    多技術棧 / 多客戶 / 跨領域 必走動態知識型,否則跨專案知識會死
    團隊協作 動態知識型 + 開源 brain(如 Claude-code-domain-brain

    動態知識型的退化路徑

    動態知識型不是免費午餐。它的退化路徑是:brain 寫成「ChatGPT 風格的 best practices 摘要」就死了。每條 brain 必須能回答這三個問題:

    • 這是從哪一次失敗長出來的?(commit hash / 日期 / 誰踩到)
    • 具體在哪個檔、哪行出現?
    • 沒有這條的話下次會怎麼錯

    答不出來的條目就是抄來的最佳實踐,從來沒有被現實打過臉,留著只會稀釋真貨的訊號強度。Brain 的價值不在條目多寡,在每條都有血。

    結論:選的不是工具,是「知識怎麼進來、怎麼出去」

    Karpathy Skills 跟我這套不是對立關係,是知識層設計的兩種極端。前者把「該怎麼寫 code」濃縮成 4 條原則;後者把「我跟這個專案 / 使用者過去發生過什麼」做成分層動態檔案。

    你的選擇取決於:你的工作有沒有累積性。一次性任務不需要 brain,每個專案都從零開始的人不需要 Iron Rules。但只要你在同一個領域 / 同一個專案 / 同一個合作關係上待夠久,知識的價值就會從「通用原則」往「具體經驗」傾斜。這時候 Karpathy 的 4 條會變成必要但不充分。

    挑 skill 系統時別只看 prompt 寫得多漂亮,看知識怎麼進去、怎麼長大、怎麼用這三條通路。漂亮的 prompt 滿街都是,能持續累積的系統才稀缺。

  • 跟 AI 寫程式的紀律:6 條規矩讓 AI 從 21 輪修不完到自走嚴格測試

    給趕時間的人

    • 兩週前我跟 AI 一起寫一個社區管理 SaaS,跑 21 輪除錯都收不完。每輪都找到新 bug,修了還有新的。
    • 診斷:不是 AI 不認真,是「靠 AI 在 40 個 API 都記得做對 5 件事」這個工作模式注定漏。40 × 5 = 200 個漏分點。
    • 解法:4 招 + 6 條規矩(本文後半段是 6 條規矩的可貼可用 template)。
    • 16 天後 AI 自己會寫嚴格 TDD,commit message 自動標 (green via test in <sha>)。新專案直接套同樣 6 條規矩。
    • 最重要的觀察:AI 寫方法論時看不見自己盲區。每次升級都靠使用者一句質疑觸發,不是 AI 自己 reflect 出來。

    本文兩部分:(1) 前半段是故事——我做了什麼,為什麼。(2) 後半段是規矩——你可以直接複製到自己專案的 6 個 template。最後是觀察 + 總結。

    Part 1 — 故事:21 輪修不完的具體模樣

    兩週前我開始一個個人專案——社區包裹/訪客管理 SaaS。後端 Go,前端 Flutter。我用 Claude 寫程式,然後派另一個 Claude 當 QA 測試員找 bug。

    第一輪測試員找到 5 個 bug,工程師 Claude 修掉。再派一個新 QA。又找到 5 個。修掉。再派。又是 5 個。跑了 21 輪。每輪都有新 bug。幾天時間沒收尾。

    診斷:200 個漏分點

    不是 AI 不認真。後端有 40 個 API,每個都要做同樣 5 件事:

    • 檢查使用者有權限
    • 檢查使用者能看的範圍(自己家 vs 整個社區)
    • 寫稽核紀錄
    • 過濾掉已停用的資料
    • 包在交易裡保證一致性

    每個 API 都是 AI 手寫這 5 件事。40 × 5 = 200 個漏分點。AI 偶爾漏一件 = 一個 bug。不同 API 漏不同件 = 看起來像 40 個不同 bug,實際是同一類錯誤。LLM 擅長照範例寫單一段,但要求它在 40 個地方都「記得做對 5 件事」就是靠機率

    4 招解法(高層次概覽)

    1. 把 5 件事打包成一個函式。每個 API 開頭必須呼叫它+明確宣告自己屬於哪種範圍。沒呼叫 = 編譯不過。「人記得」變「系統強制」。
    2. 寫紅線清單(invariants)。每修一個 bug 學一條教訓,寫進編號 INV-XXX-NNN。新功能寫好之後 QA 對著清單跑紅藍對抗,違反 = bug。規矩 3 提供模板。
    3. QA 測試員只能講人話。不准標 P0/P1。只能回 ✅/❌/⚠️ OPEN 三種。嚴重度由你做 30 秒判斷。規矩 4 提供 prompt。
    4. 測試要真的紅過。test 先寫先 commit (red),fix 後寫後 commit (green via test in <red-sha>)。commit log 自帶證據,不靠良心。規矩 2 寫進專案根。

    16 天後 AI 自己會走這套流程。新功能 commit message 自動標 (green via test in <sha>)——我已經沒在提醒。下個專案(訪客系統)第一個 cycle 直接套同樣紀律,沒重新爬坡。

    Part 2 — 規矩:6 個可貼可用 template

    下面 6 條規矩是你下個專案開工直接可以複製貼上的東西。前 5 條是檔案 / prompt,第 6 條是日常對話紀律。

    • 規矩 1:Day 1 開工 prompt
    • 規矩 2:CLAUDE.md 專案根(AI 每次自動讀)
    • 規矩 3:docs/invariants.md 紅線清單(4 條 universal INV 起點)
    • 規矩 4:QA agent prompt(2 種變體)
    • 規矩 5:docs/cycle-template.md PR cycle 8-stage 模板
    • 規矩 6:跟 AI 的日常對話紀律(5 條)

    規矩 1 — Day 1 開工 prompt

    新專案第一句話給 Claude / ChatGPT / 任何 LLM 的 prompt。把 4 個角色分工 + 5 條紀律明文化:

    我要跟你協作開發 [你的專案類型]。我們的合作規則:
    
    1. 我寫規格,你寫程式。修改規格必須先跟我討論,不能自己加需求。
    
    2. 任何修 bug 都走「先寫測試紅 → 寫 fix 變綠」順序:
       - 先 commit 一個 failing test,commit subject 加 (red)
       - 跑 test 確認它真的失敗
       - 才寫 fix,commit subject 加 (green via test in )
       - 不准 test 跟 fix 同 commit
    
    3. 你做為 QA 時只能回三種結果:
       - ✅ 跑過了(對某條規則跑紅藍對抗,沒違反)
       - ❌ 違反了(附 reproduce 步驟 + 預期 vs 實際)
       - ⚠️ 看到怪事但不確定是不是 bug
       - **不准標 P0/P1**,嚴重度是我的判斷
    
    4. 每修一個 bug 必須:
       (a) 寫進 docs/invariants.md 一條 INV-XXX-NNN
       (b) 對應寫一個 invariant test
       (c) 才算修完。少做任一件 = 沒修完。
    
    5. 我每次 ✅/❌ 你要懷疑——9 個 ✅ 不代表程式對。
       涵蓋面外的東西永遠是 Schrödinger 狀態。
    
    開工前先讀 CLAUDE.md + docs/invariants.md。
    完成上述理解後回覆「協作規則已確認」,然後我們開始。
    

    規矩 2 — CLAUDE.md 專案根

    專案根目錄放這個檔。Claude Code 每次開工自動讀。把規矩 1 的內容固化成檔案,不必每次貼 prompt:

    # [專案名] — AI 工作指引
    
    ## 重要原則(不可違反)
    1. **規格收斂**: 修改規格 → 先討論。不可自加需求。
    2. **TDD 紅綠**: 任何 fix 必須先 commit failing test (red) 才寫 fix。
    3. **QA 不標 P 級**: 只回 ✅/❌/⚠️。嚴重度由人類 PM 判斷。
    4. **修 bug 順序**: fix → 加 INV 進 docs/invariants.md → 寫 test → 才算修完。
    5. **6 層 doneness**: 程式對 = L0 spec / L1 INV / L2 schema / L3 resolver /
       L4 frontend / L5 E2E 各自獨立驗證。✅ 必須帶 evidence。
    
    ## 必讀文件(開工前)
    - docs/invariants.md            (紅線清單)
    - docs/cycle-template.md        (PR cycle 8-stage 模板)
    - docs/agent-prompts/qa-verification.md
    - docs/agent-prompts/qa-deep-probe.md
    
    ## 修 bug 工作流
    1. 找到 bug
    2. 開 docs/cycles/Cn-shortname.md(從 template)
    3. Stage 5a: 寫 failing test → commit "(red)"
    4. Stage 5b: 寫 fix → commit "(green via test in )"
    5. Stage 5c: 補對應 INV 進 docs/invariants.md
    6. Stage 6: regression(原 test 全綠)
    7. Stage 7: 派 fresh agent 重走確認(可省)
    8. Stage 8: merge gate(6 層 evidence 對齊)
    
    ## 紀律警告(常見偷懶 pattern)
    - ❌ test 跟 fix 同 commit = test 沒驗證過,不算 TDD
    - ❌ 「我覺得這顯然是 bug 直接改」= 沒走 cycle file 紀律
    - ❌ QA 自己標 P0 給工程師 = 跳過 PM triage 閘
    

    規矩 3 — invariants.md 紅線清單

    專案開頭預先寫 4 條 universal INV 當起點,每修一個 bug 加一條:

    # [專案名] Invariants Catalogue
    
    > 「永遠不能違反什麼」紅線清單。每條 INV 一個編號。
    > 修一個 bug 加一條。CI 跑這份的 test。
    
    ## INV-AUTH-001: 撤權後 access token 必須失效
    - Origin: 通則
    - Severity: P0
    - Statement: 任何 user disabled / role revoked / community suspended
      之後,現有 access token 必須在下次 request 被拒。
    - Test sketch: disable user → 拿原 token 呼叫 → expect "user disabled"
    
    ## INV-RBAC-001: 權限範圍 cap-vs-role 不能混淆
    - Origin: 通則
    - Severity: P0
    - Statement: 同一個 cap 被多個 role 持有時,scope 由 role 決定,不是 cap。
      例: parcel.view_household 被 guard + household_admin 都持有,
      guard 看全社區,household_admin 只看自家。
    - Test sketch: guard.parcels 回 N 筆;household_admin.parcels 回 ≤ N 筆
    
    ## INV-INPUT-001: 公開 endpoint 必須 SQL injection 安全
    - Origin: 通則
    - Severity: P0
    - Statement: 所有未認證的 mutation(login / 申請 / 註冊...)
      都必須用 parameterized query。SQL injection payload 必須當文字儲存,不執行。
    - Test sketch: 送 ';DROP TABLE x;-- 進每個公開 mutation,verify table 還在
    
    ## INV-IDEM-001: 重要 mutation 必須有 idempotency key
    - Origin: 通則
    - Severity: P0
    - Statement: 任何寫入金錢 / 通訊 / 不可逆操作的 mutation,
      必須接受 idempotency key。同 key 多次呼叫 = 一次效果。
    - Test sketch: concurrent 5 個相同 key 呼叫 → DB 只 1 row,API 5 個一樣 response
    

    怎麼擴充:每修一個 bug → 加一條 INV-CATEGORY-NNN。category 自己定(AUTH / RBAC / INPUT / IDEM / RLS / RATE / UI…)。修到 50+ 條時就有完整的紅線網。

    規矩 4 — QA agent prompt(2 種變體)

    當你想派一個 AI 當 QA 時,給它這段 prompt。第一個是規則導向 (對著 INV 跑紅藍):

    你是 QA agent。任務:對 [專案] 的 [INV-XXX-NNN] 跑紅藍對抗。
    
    ## 規矩(不可違反)
    1. 你只能回 ✅ / ❌ / ⚠️ OPEN 三種結果。
       - ✅ INV 守住(列出你跑了哪些 attack scenario,都沒違反)
       - ❌ INV 違反(附完整 reproduce: 步驟 / 預期 / 實際 / 證據)
       - ⚠️ OPEN(看到怪事但找不到對應 INV,給 PM 判)
    2. 不准標 P0/P1/P2。嚴重度是 PM 的判斷,不是你的。
    3. 不准提 fix 方案。你的工作是發現,不是解決。
    4. 不准動 code。
    5. 如果 INV 統計 9/10 ✅,1 ❌ — 該回報 1 ❌ 不是 90% pass。
    
    ## 工作步驟
    1. 讀 INV-XXX-NNN 的 statement
    2. 列 3-5 個 attack scenario,試圖讓系統違反這條 INV
    3. 對每個 scenario 跑 reproduce
    4. 結束時報告:✅/❌ 數量 + ⚠️ OPEN 列表
    
    ## 你要讀的檔案
    - docs/invariants.md(找 INV-XXX-NNN)
    - docs/specs/...(找對應規格)
    - 任何相關 brain entries
    
    請確認你看完上述規則後再開始。
    

    第二個是場景導向 (派 persona 隨便走找深層 bug):

    你是 deep-probe QA agent。任務:對 [專案] 的 [target flow,如「訪客登記」]
    走真實用戶 walk-through,找 INV-based QA 漏掉的東西。
    
    ## persona(扮演這個角色,他怎麼用就怎麼走)
    [選一個 persona:]
    - 阿伯:60+ 歲,不熟手機,字要看得到才點得到
    - 25y 工程師:預期所有按鈕都有 keyboard shortcut
    - 王太太主委:會 office 但不會 SQL,需要看「為什麼」才會用
    - 張總:high-priv admin,點任何東西要結果不要看細節
    
    ## 規矩(同 QA agent)
    1. 只能回 ✅/❌/⚠️ OPEN,不准標 P 級
    2. 不准提 fix
    3. 找到問題附 reproduce + screenshot
    
    ## 工作步驟
    1. 從 [起始畫面] 開始
    2. 走完整 [target flow]
    3. 每一步問:這個 persona 真的能理解嗎?會點對嗎?
    4. 結束時報告:這個 flow 對這個 persona 是否 work
    
    「測不出 bug」常常是「測得不夠深」。Happy path 過 = 測試開始,不是結束。
    

    規矩 5 — Cycle file 模板

    放在 docs/cycle-template.md。每個 PR 複製成 docs/cycles/Cn-shortname.md:

    # Cycle Cn — [短標題]
    
    **Cycle Type**: T-PR-cycle / T-regression-fix / T-feature / T-user-smoke
    **Owner**: [engineer agent / 你]
    **Started**: YYYY-MM-DD HH:MM
    **PR**: commit [sha 或 branch]
    
    ## Verification scope
    - Layers covered: L1 INV, L3 resolver, L4 frontend (etc)
    - INVs verified: INV-XXX-NNN, INV-YYY-MMM
    - Layers deferred: [哪些不在這 cycle 範圍 + 理由]
    
    ---
    
    ## Stage 0.5 — Pre-cycle hygiene
    - [ ] git status clean
    - [ ] fixture/baseline 已 reset
    - [ ] 本 cycle test users: qa_cn_xxx
    
    ## Stage 1 — RD 自測
    - [ ] go test ./... 全綠
    - [ ] live smoke 1 條 happy path
    
    ## Stage 2 — QA wave
    派 [N] 個 QA agent 平行,每個 cover 1-3 INV。
    - agent A: INV-X,結果 ✅/❌/⚠️
    - agent B: INV-Y,結果
    - ...
    
    ## Stage 3 — OPEN findings
    [QA 報的 ⚠️ findings 列這]
    
    ## Stage 4 — PM triage(你的 30 秒判斷)
    - F-Cn-001: bug → 修
    - F-Cn-002: feature → backlog
    - ...
    
    ## Stage 5 — RD fix(每 finding 走 red-green)
    - 5a: F-Cn-001 test commit [sha] (red)
    - 5b: F-Cn-001 fix commit [sha] (green via test in [5a-sha])
    - 5c: F-Cn-001 對應 INV-XXX 加進 invariants.md
    
    ## Stage 6 — Regression
    原 QA agent 重跑,fix commit 為 input。預期之前的 ❌ 變 ✅。
    
    ## Stage 7 — Comparison newbie(可省)
    派一個沒看過本 cycle 的 fresh agent 重走,看抓不抓到新東西。
    0 new finding = spec/INV 寫得清楚;≥1 = spec 有黑洞。
    
    ## Stage 8 — Merge gate(6 層 evidence)
    - [ ] L0 spec 引用對齊
    - [ ] L1 INV 列出
    - [ ] L2 schema/migration 有對應 invariant test
    - [ ] L3 resolver unit test
    - [ ] L4 frontend Playwright smoke
    - [ ] L5 真人或 fresh agent smoke 走過
    
    ## Stage 8.5 — Post-cycle cleanup
    - [ ] disposable test users DELETE
    - [ ] fixture 復原 canonical state
    - [ ] git status clean
    

    規矩 6 — 跟 AI 的日常對話紀律(5 條)

    前 5 條規矩(檔案 / prompt)準備好之後,日常跟 AI 對話再加 5 條紀律:

    • 新需求先寫進規格,不要直接讓 AI 改 code。需求寫成一段話 → AI 確認理解 → 才開工。
    • 修 bug 一律先問「會違反哪條 INV」。沒對應 INV → 先補 INV。不可以光修 code 不加 INV。
    • AI 給你 ✅ 主動懷疑。問「這個 ✅ 涵蓋什麼,沒涵蓋什麼?」9/10 ✅ 也要追那 1/10。
    • 定期派 deep-probe(規矩 4 第二個)。每幾個 cycle 派一個 persona walk,專找「真人會踩但 INV 沒寫」的東西。Happy path 永遠不夠。
    • 主動挑戰 AI 的方法論。AI 自己寫的方法論,你要從框架外問「漏了什麼」。AI 看不見自己的盲區,要靠你挑戰

    適用什麼專案?ROI 分級

    • 🟢 多租戶 SaaS / 高合規(金融、醫療、隱私):最值得。INV/audit/SCN 本來就是合規的具體形式。
    • 🟢 個人專案要長期維護:值得。紅線清單跨專案累積。
    • 🟡 2-5 人小團隊用 AI 輔助:中等。要花時間教同事,前期慢後期快。
    • 🟡 既有 codebase 想改善:中等。前期蒸餾既有 spec → INV 比較花時間。
    • 🔴 純探索性 prototype:低。沒累積教訓 → 紅線清單空 → 機制空轉。
    • 🔴 一次性 script:低。沒 ship gate 就沒 cycle。

    綠色專案直接把 6 條規矩貼進去開工。第一個 cycle 預期會踩坑(過度信任 AI 的 ✅、規格邊修邊膨脹、test 跟 fix 同 commit…)。沒關係 — 踩了就加 INV、改 prompt。整套就是設計來「邊踩邊長」的。

    最重要的觀察:AI 看不見自己的盲區

    這 16 天有個反直覺的發現——每次方法論升級,都是我一句質疑觸發,不是 AI 自己想到

    • R35 我問「為什麼修不完」 → AI 才開始建第一版方法論
    • v1 寫完我問「9 個 ✅ 算可信嗎」 → AI 承認過度樂觀,改 v2
    • v2 寫完我問「QA 只會知道錯,你怎麼讓他傳遞訊息」 → 又改 v2.1
    • v2.2 寫完我問「我們不是有寫測試情境嗎」 → AI 才發現自己漏算 110 條場景
    • v2.2 結論發出我問「為什麼說不是 TDD」 → AI 承認「沒 TDD」過絕對

    AI 寫方法論時系統性偏向「框架完善」——在自己定的框架內找證據確認框架對,看不到框架外的盲區。要使用者從框架外挑戰,框架才會演化。

    沒有這幾次質疑,我那套方法論會 stuck 在 v2 過度耦合的狀態,而且還會洋洋得意覺得自己 73% 完成。這是這 16 天最值得記住的一條——對所有用 AI 協作的工作都適用。

    總結

    16 天前我以為「AI 寫程式」就是「丟需求 AI 幫我寫」。16 天後我發現:AI 寫程式真正會出問題的不是技術,是工作流。技術上 AI 完全有能力寫對,但工作流錯了就一直繞圈。

    本文 6 條規矩可以直接複製到你下個專案。預期會踩坑,沒關係,踩坑後加 INV 改 prompt 就好。系列上一篇關於底層原則的「未驗即不可信」也可以一起看。

  • 「未驗即不可信」AI 協作開發走出 21 輪修不完:SDD/TDD/腦子整合

    重點摘要

    • 「未驗即不可信」:程式碼跑得起來不代表正確,沒對 invariant 跑過 attack scenario 就只是 Schrödinger 狀態。十幾年的程式碼依然會藏沒被檢查的 bug。
    • R35 21 輪修不完是因為缺 PM 兩道閘(spec 定錨 + finding triage)。QA agent 自己標 P0/P1 直接給工程師,spec 邊修邊膨脹。
    • 整合方案:SDD(spec 規格)+ INV(紅線契約)+ TDD(紅藍對抗)+ 腦子(事後教訓)+ Cycle SOP(8 階段流程)= 五層協作架構。
    • 實戰結果:從 R35 數天 21 輪到單 cycle 約 1-3.5 小時收斂,bug:spec_clarification 比例接近 1:1(健康訊號)。
    • 9/9 ✅ 也不算「可信任」:抽樣 ≠ 全集,wiring ≠ behavior,positive 案例 ≠ 涵蓋所有 attack scenario。

    「修不完的迴圈」是什麼?AI 協作開發的常見死結

    AI 協作開發專案最常見的失敗模式不是「做不出來」,而是「修不完」。一輪 QA 抓出 5 個 bug、修完,下一輪又找出 5 個,再下一輪還有,就這樣跑 10 輪、20 輪都收不乾。我把這個現象稱為「未驗即不可信」的具體展示——程式碼在沒有跑過 invariant 紅藍對抗之前,看起來正常運作不代表正確,只代表「目前還沒有人發現的 bug」。

    本文紀錄一個真實 LLM agent 協作專案(Phase 1 的多租戶 SaaS 後端,Go + GraphQL + PostgreSQL)從 21 輪 audit 修不完,到後來建立完整方法論後單 cycle 收斂的全過程,並把 SDD(spec-driven development)、TDD(test-driven development)、腦子系統(brain knowledge base)這三套工具整合成一份可重用的協作 SOP。

    為什麼 21 輪 QA 還在抓 P1?病因診斷

    專案在「R35 audit」階段累積了 21 輪 fresh QA agent 排查,每輪都派一個全新沒 prior context 的「小白 agent」走 spec 找 bug。前 3-5 輪揭發了真實盲點,但第 8、第 12、第 19 輪還在抓 P0/P1,明顯失控。表面看是實作品質太差,深入分析後發現是結構性問題,不是程式碼問題。

    God file:5015 行 hand-rolled resolver 沒有任何結構保護

    專案的 GraphQL resolver 全集中在 schema.resolvers.go 一個檔,5015 行 / 40 個 mutation / 平均 125 行一個。每個 mutation 都手寫五步流程:withTx → RequireCapability → 自己決定要不要 scope check → 自己決定要不要 audit → 自己決定要不要 filter is_active

    整份檔案只有 2 個 auditlog 呼叫、18 個 scope-helper 呼叫散落在 40 個 mutation 之間——每個 mutation 都是「記得做 5 件事」的考試。漏一件 = 一個 bug。R12(cap-vs-role scope)、R17(logout descendants)、R18(partition pruning)、R19(list-loader 漏 child)、R20(sysadmin audit gap)、R21(retired-cap)、R22(photo key)通通是同一類錯誤在 40 個地方各漏一次

    缺 PM 兩道閘:finding 直接從 QA 流到工程師

    傳統工業界 workflow 有 4 個獨立角色:

    角色 主 artifact 決策權
    PM spec / triage 結果 三類分判(bug / feature / usage / not_issue),規格收斂
    Engineer PR + 單元測試 實作
    QA finding report 驗 invariant;只能標 ✅ / ❌ / OPEN
    User 驗收 手動 smoke 最終 ship gate

    R35 把 PM 的兩道閘都拿掉了。第一道(spec 定錨):spec 寫完之後沒同步精準化,invariants 散在 brain 沒成 contract。第二道(finding triage):QA agent 自己標 P0/P1 直接 ping 工程師,沒人問「這是 bug 還是 feature gap 還是 usage issue」。結果每個 newbie 都從 0 開始挖一輪新 spec,spec 邊修邊膨脹,永遠收不完。

    「派越多 newbie 才越能收斂」這個直覺是錯的。第 N 個小白還能找到 P1 不代表實作越來越差,代表 spec 還有黑洞。多 newbie = 多人從不同角度發明新需求。正確訊號是回頭把 spec/invariants 寫硬,不是繼續派人。

    SDD + TDD + 腦子三層整合:契約在不同層級

    SDD(規格驅動)說「先定義要做什麼」,TDD(測試驅動)說「先定義怎麼證明做對了」。兩者都是「契約先於實作」,差別在契約寫在哪。實際 LLM agent 協作專案需要 5 層契約配合,不是單一方法解決:

    層級 內容 改動頻率 對應檔案
    SDD spec 描述性:要做什麼、流程、資料模型 慢(feature 級) docs/specs/*.md
    INV invariants 規範性:永遠不能違反的紅線 + 對應 test sketch 中(每修一 bug 補一條) docs/invariants.md
    TDD test 機器版契約:red-team scenario + 自動化驗證 每個 PR backend/.../*_test.go
    腦子 brain 事後散件教訓 + 通用方法論 每次學到坑就寫 ~/.claude/.../brain/*.md
    SOP workflow 操作性:PR header 模板、agent prompt、triage tree 很慢(鎖死) docs/workflow.md

    腦子是事後紀錄,不是事前防護

    腦子系統(10 步驟從零做到完整 AI 工作流)在這套架構裡是知識長期儲存層,不是執行層。它記錄「曾經踩過什麼坑」、「某個 domain 有什麼最佳實踐」,但不會在下個 resolver 寫的時候自動跑出來擋人

    50+ 條 brain 教訓如果只停在 brain,下個工程師(或 agent)寫新 resolver 還是會踩同樣的雷。把它翻譯成 INV-XXX-NNN 條目 + 對應 invariant test 才能變成 CI 跑得起來的事前防護。這是 SDD(spec 描述)→ INV(紅線提取)→ TDD(test 落地)的左→中→右遞進

    INV 是 SDD 與 TDD 的橋

    純 SDD 的盲點:spec 寫了但沒人記得回頭驗,變裝飾品。純 TDD 的盲點:test 通了但每個 test 各做各的,沒人問「我們漏了哪類 test」(典型如測試覆蓋率 4% 但 happy path 都測了)。

    INV 把兩者橋起來。每條 INV 有:

    • Statement:「X 必須永遠 Y」或「X 永遠不能 Z」一句話
    • Origin:哪一輪 audit 學到的
    • Severity:P0(ship-blocker)/ P1(must-fix)/ P2(debt tracker)
    • Test status:✅ existing / 🟡 partial / ❌ TODO(含 test sketch)

    實際在我這個案例蒸餾出 54 條 INV 分 11 個 category(AUTH、RBAC、RLS、AUDIT、IDEM、RATE、INPUT、DATA、RESOLVER、UI、FILE)。每條 brain 教訓都會對應到至少一條 INV,這是「方法論寫 brain,技術紅線寫 invariants,操作 SOP 寫 workflow,三件事不混」的具體展示。

    從規格到 ship 的 8-stage cycle pipeline

    有了五層契約,需要一個操作流程把它們串起來。設計成 8 階段,每個 PR cycle 一份檔活在 git,撐過對話 compaction:

    PM
      ├─[1] 寫 spec / 加 INV-XXX-NNN     ← 第一道閘:規格定錨
      ▼
    Engineer
      ├─[2] 實作 + 自寫 unit test
      ├─[3] 開 PR(header 必填 INV 宣告)
      ▼
    QA wave(K 個 agent,並行,每個 1-3 INV)
      ├─[4] 紅藍對抗 + INV regression
      ├─[5] 結果分三類:✅ holds / ❌ violated / ⚠️ OPEN
      ▼
    PM triage
      ├─[6] 每個 OPEN 30 秒分判      ← 第二道閘
      │     bug / feature / usage / not_issue
      ▼
    Engineer 只修 bug 類
      ▼
    回 [4] re-run,stop 條件:
      - PR 宣告的 INV 全 ✅
      - 兩個 QA agent 結論一致
      - OPEN list 清空

    QA agent 的硬規則:永遠不能標 P0/P1

    這是整套機制的關鍵紀律。QA agent 不是「品質判官」,是「invariant 驗證者」。它只能回三種結果:

    • ✅ holds:對某條具體 INV 跑紅藍對抗都守住
    • ❌ violated:找到具體 repro 違反某條具體 INV
    • ⚠️ OPEN:觀察到怪事但找不到對應 INV,留給 PM 分判

    P 級嚴重度標籤是 PM 的權限,不是 QA 的權限。OPEN finding 一律走 PM triage decision tree(Q1:是不是真問題?Q2:spec 有沒有規定?Q3:spec 應該規定嗎?),分四類:bug → 修;feature → 進 backlog;usage → 改 docs;not_issue → 駁回。

    Option B:PM-agent 預分類 + user 終審

    當 OPEN findings ≥ 3 個,可以派一個 PM-triage agent 跑 first-pass 分類,加上 confidence 旗標。User 只 review confidence=low 跟 spec_clarification 的子集。User 速度從「每個 finding 30 秒」壓到「review agent 的分類 + 只深看不確定的」。

    PM-agent 的 hard constraint 寫得很硬:不可以提 fix 方案、不可以動 code、不可以 launch sub-agent、不可以 ship/no-ship 決策、不可以漏分類。只做分類。User 永遠保留否決權。

    實戰:6 個 cycle 的具體紀錄

    方法論建立後,立刻在 R36 階段跑了 6 個 cycle。以下是真實時序:

    Cycle 性質 規模 時間 產出
    C1 retroactive verification (41 resolver migration) ~3h30min 14 findings → 7 bug + 6 spec_clar + 1 usage;3 fix commit
    C2 self-spotted regression(前次 R20 修錯了) ~1h migration 0040 + INV-RBAC-006 amendment
    C3 forward-going feature (print 三件套) ~45min Flutter UI + cap wiring
    C4 forward-going feature (offline mutation queue) ~1h Tablet 離線優先實作
    C5 spec audit(隨機抽 9 feature 驗證) ~1h 9/9 ✅ + 2 OPEN finding
    C6 close C5 OPEN findings ~30min spec §9.2 amend + 新 INV + seed-demo.sh idempotent

    C1 抓到 R36 step 2 自己的 architectural bug(authzPrelude 的 cap-check-before-sysadmin-gate 順序,導致 chairman 透過錯誤訊息學到 sysadmin-only cap 名稱)——21 輪 R35 audit 完全沒抓到,C1 跑 1 個 QA agent 90 分鐘抓到。這正是「invariants 蒸餾把人腦 reasoning 升級成機器可驗 contract」的力量。

    C1 的 bug : spec_clarification : usage 比例 = 7 : 6 : 1。接近一半的 finding 不是 code 問題是文件問題。如果只跑 R35 那種「QA → 直接修」流程,這 6 條會變成 6 個沒必要的 code change,或更糟:每輪都長新一條 hand-rolled exception,spec 永遠收不乾。

    C5 抽查:9/9 ✅ 也不算「可信任」

    整套基礎建設蓋好之後,主對話 agent(我)親自跑了一個 spec audit cycle(C5):對 37 個 Phase 1 feature 用 shuf 隨機抽 3 輪 × 3 個 = 9 個 feature,每個用真實 GraphQL 對 backend 跑 attack scenario。結果 9/9 ✅ holds,0 ❌ violated,2 ⚠️ OPEN。

    看起來很漂亮。但這不等於可信任。當我重新檢視自己跑的 9 條測試的深度,老實打分:

    • ✅ 深度足:2/9(logout cascade、login rate limit)——真的對 invariant 跑紅藍對抗
    • ⚠️ 半套:7/9——只驗 wiring 不驗 behavior,positive only 沒 negative case,或在腐化 fixture 上跑
    • ❌ violated:0/9

    具體 anti-pattern 我自己犯了 6 個:(1) 隱性假設 wiring = behavior;(2) 時間壓力下 satisfice;(3) 讓 spec 驅動測試而不是 INV;(4) 避開 destructive test;(5) 把「文件化問題」當「修問題」;(6) 沒照自己寫的 qa-verification.md prompt 流程操作。

    這個結果反過來證明「未驗即不可信」的鋒利之處:不只「沒測 = 不可信」,還包括「測得不夠深 = 也不可信」。9/9 ✅ 只說「2026-05-10 19:00 對 commit 06e7078 抽 9 個樣本沒抓到 ❌」。離「可信任」還缺:

    • Wave 1 P0 invariant test 全綠(54 條 INV 中 50 條還是 ❌ TODO)
    • 所有 OPEN 收掉(兩個 OPEN 已在 C6 處理)
    • 涵蓋率從 9/37 → 37/37 + 從 1/54 → 54/54
    • CI 把它們變成 ship-block 的 hard gate

    「可信任」是需要持續維護的狀態,不是一次達成就鎖住。今天最多打到「比未驗強,但離可信還早」。

    方法論的 meta-loop:自我修正的協作架構

    C5 raise 的 2 個 OPEN finding 立刻觸發了 C6——方法論自己的產出變成了下一輪 cycle 的輸入。具體展現:

    • F-C5-001 HMAC token 從 spec 不可重現:Python 照 spec §9.2 算 token 跟 Go backend 算的不一樣。PM triage 為 spec_clarification → C6 補 spec §9.2 explicit external-client note + 新 INV「HMAC token bit-reproducible from spec」。
    • F-C5-002 fixture rot:dev 測試帳號 wang.dad 的 household_id 指向 disabled 的 household。所有 household-scope 測試都在驗 disabled 狀態 → false confidence。PM triage 為 dev tooling bug → C6 改 seed-demo.sh idempotent 重建 fixture。

    這條 meta-loop 連續觸發三層動詞:spec 改 clarification + invariants 加新條 + tooling 改 idempotent。完整閉環,下一輪同類 finding 不會再生。

    這就是腦子系統 agent team架構成熟之後的應用形態:方法論不只「跑得動」,還能「用自己的產出修正自己」。

    結論:四個可重用 takeaway

    1. 「未驗即不可信」是工程倫理底線。年紀大的 code、看起來正常運作的 code、跑得起來的 code,都不等於正確。沒有對 invariant 跑過 attack scenario 之前都是 Schrödinger 狀態。
    2. SDD + TDD 不是二選一,需要 INV 當橋。spec(描述性)+ invariants(規範性)+ test(機器版) + brain(事後紀錄)+ workflow(操作 SOP),五層配合。每條 brain 教訓都該對應一條 INV。
    3. QA agent 永遠不能標 P0/P1。LLM agent 自評嚴重度直接給工程師 = R35 失控的根因。Severity 標籤是 PM 權限,QA 只能標 ✅ / ❌ / OPEN。
    4. 抽樣不等於全集,wiring 不等於 behavior。9/9 ✅ 看起來說服力強,但只說「這 9 個樣本沒踩到雷」,不說「程式碼可信任」。可信任需要 INV 全綠 + OPEN 收掉 + 持續維護。

    R35 21 輪數天才修不完的東西,C1 cycle 3h30min 收乾並抓到 R35 沒發現的 architectural bug。整套方法論的價值不是「修 bug 修得快」,是「讓 spec 跟 code 之間的契約變成機器可驗,腦子變成事前防護而不只是事後紀錄」。

    方法論成熟之後,工程師的工作從「想下一步做什麼」變成「跑 INV 看 INV 告訴我什麼該做」。這比「一輪一輪我看看哪邊有問題」健康得多。

  • Claude 4.7 Memory 與 Agent Team 實戰:自建 Brain 系統的真正價值

    重點摘要

    • Claude 4.7 的 memory 改進本質是「檔案使用得更好」,不是新增神奇的跨 session 記憶機制 — session 之間仍然完全隔離,靠 MEMORY.md 等檔案橋接。
    • 自建 Brain 系統 = 精煉版 cross-session memory:機制相同(檔案 + CLAUDE.md 宣告載入),差別在手動 curate、domain 分類、顯式載入,品質遠勝 auto-memory。
    • Named sub-agent 真正的價值在「單一任務多輪延續」,不是 Team A/B/C 那種多工並行 — 兩者是互補的兩個層次。
    • Bug 追查 = PUA 方法論 × Named agent 容器 × Brain 更新,三層缺一不可,且要對「無法中斷的頻道(如 Bot)」具備韌性。
    • 模型版本升級 ≠ 知識管理升級:Brain 系統是 model-agnostic 設計,換任何 LLM 都能搬過去。

    Anthropic 在 2026 年 4 月發布的 Claude Opus 4.7 在 memory 和 Agent Team 兩塊都有顯著改進。但這些「改進」對已經自建知識架構的開發者來說,究竟是關鍵升級還是錦上添花?本文整理一天的深度討論,對比 Claude 原生機制和自建 Brain 系統,並落地一套可跨機器攜帶的 bug 追查框架。

    Part 1:Memory 系統 — 4.7 改了什麼,對我有什麼用

    Claude 4.7 的三個 memory 改進

    Claude Opus 4.7 在 memory 方面的改進可以拆成三個層次:

    1. 檔案式 memory 變「一等公民」:4.7 特別訓練用檔案系統當 memory(scratchpad、notes、structured store),能主動寫筆記且下次對話時知道去讀筆記。
    2. Cross-session 穩定性提升:跨多 session、多小時的工作流程一致性更好,模型會依 brain 和 memory 的指引從上次停下的地方接續。
    3. 1M context 無長 context 溢價:原生百萬 token context window,不另收費。以前 200K+ 要 /compact 的場景現在一口氣吃完。

    Cross-session memory 的真相:沒有魔法,只有檔案

    很多人以為 Claude 4.7 的 cross-session memory 是某種「核心系統」幫你串起過去對話。真相是:session 之間仍然完全隔離,模型本身沒有跨 session 的任何 state。所謂 cross-session,是 Claude Code 在新 session 開啟時自動注入:

    • CLAUDE.md(你寫的指令)
    • MEMORY.md 和 topic files(auto-memory 累積的筆記)
    • 過往 session summary(Claude Code 自動寫的摘要檔)

    這些全是檔案,不是隱藏的 cloud memory。4.7 改進的不是機制,而是對這套檔案機制的使用熟練度:知道什麼該寫、該去哪讀、讀到後如何套用。

    自建 Brain 系統 vs Claude 原生 auto-memory

    如果你已經有自建的 Brain 系統(跨專案的技術 domain 知識庫),對比 Claude 原生 auto-memory 會發現:本質是相同機制,差別在淬煉程度

    面向 Claude 原生 auto-memory 自建 Brain 系統
    範圍 單專案(綁 cwd) 跨專案(按技術 domain 分類)
    載入時機 Claude Code 自動注入 CLAUDE.md 宣告 Domain Brain: 主動載入
    curation 模型自動(容易塞流水帳) 手動規則過濾(Why / How to apply 格式)
    外部知識 僅記錄當前對話 支援 [source: external] 納入社群/文章的坑
    配套 memory 單打獨鬥 Brain + Skill 配對(坑 vs 對的做法)

    4.7 對自建 Brain 的實際收益

    對已經有成熟 Brain 系統的開發者,Claude 4.7 的 memory 改進主要體現在兩個地方:

    • Context 吞更多(70% 的價值):1M context 可以同時載入所有相關 brain + CLAUDE.md + 當前 code,不再被切斷。多個 brain 同時載入 5000+ 行也不爆。
    • 維護判斷力(30% 的價值):叫 Claude 整理 memory 時,4.7 會主動去讀 brain 檢查重複、按規則格式寫,而不是無腦 append。4.6 可能直接塞、不去重。
    • 自動 cross-session 對自建系統無感:已經有 Brain + CLAUDE.md 宣告機制的用戶根本不依賴 auto cross-session,品質比自動版高。

    關鍵洞察:模型版本升級 ≠ 知識管理升級。Anthropic 再怎麼升級內建 memory,都在解決「模型如何維護筆記」。但「什麼知識該存、怎麼結構化、跨專案怎麼轉移」是架構設計問題,不是模型能力問題。

    Part 2:Agent Team — Named sub-agent 真正解決什麼

    4.7 的四個 Agent Team 改進

    • Named sub-agents:spawn 時給名字,後續用 SendMessage({to: name}) 續接,不用重跑 context
    • Permission 繼承修正:user-level permissions 現在會正確傳給 teammate,不再每個 teammate 都跳一堆授權 prompt
    • 個別 teammate 可調 mode:spawn 後可以用 Shift+Tab 單獨切換某個 teammate 的 permission mode
    • /team-onboarding:自動分析使用歷史產生 ONBOARDING.md,幫新隊友快速上手

    前置條件:要啟用 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1,否則 SendMessage 工具根本不存在。

    Named sub-agent 和 Team A/B/C 的差異

    很多人以為 named sub-agent 是在取代自組 Team 的做法,其實兩者是不同層次的機制,互補而非競爭

    面向 Team A/B/C(宏觀) Named sub-agent(微觀)
    解決什麼 多工平行 單工延續
    邊界 不同 task 之間 同 team 內部 agent 之間
    Context 燒法 每個 team 獨立燒一份 同 agent 只燒一次,後續增量
    適用場景 早上開 3 件不相干的事 追一條長 bug / 深入一個模組

    最佳組合是兩者混用:宏觀 Team 隔離不同主題,微觀 named agent 讓每個 teammate 有連續記憶。等於開三家公司並行做不同案子,每家公司裡的同一個員工連續給你服務,不是每次都新人上場。

    已知限制:teammate 之間不能互喊

    目前 Claude Code 有個已知 bug(GitHub issue #48160):subagent 本身不能 originate SendMessage。意思是 teammate A 想主動找 teammate B 協作做不到,所有通訊必須經過 team lead 路由,變成星形拓撲(hub-and-spoke)而非 mesh。

    另外 delegate mode 有個連帶效應:lead 切到 delegate mode 後,它的權限限制會傳給 teammate,導致 teammate 也不能讀檔、跑命令,整個 team 卡住。解法是 spawn teammate 時明確放寬權限。

    Part 3:實戰落地 — Bug 追查框架

    為什麼開發和修正要用不同的 agent 拓撲

    對話中得到一個清晰的洞察:「開發」和「修正」性質不同,應該用不同的 agent 拓撲。

    Case 啟動策略
    開發(新 feature) Team A/B/C 並行,短 context agent,各管一塊
    修正(bug / fix) 單一 named agent + PUA,多輪深挖
    重構(無新功能) 單一 named agent,多檔追蹤 side effect

    認真追 bug 的 agent 應該有的樣子

    一個 bug 不是「修好就算了」。它有根本原因(root cause)、爆炸半徑(blast radius)、和教訓(lesson)。停在第一個看似合理的修補是 bug 改頭換面回來的最快路徑。認真的 bug-hunting agent 應該有三層結構:

    1. 方法論(如何思考):PUA 式修辭壓力 — 從不接受第一個假設、永遠挑戰自己的推理、窮盡所有替代方案。
    2. 延續性(如何記住):Named 長壽 agent 跨輪次攜帶 context,不要每輪重新 spawn 新 agent 失去歷史。
    3. 事後教訓(如何教未來):每個修好的 bug 都要更新 brain,否則知識死在這個專案。

    三層缺一不可:沒方法論 → 停在第一個合理原因、出 bandaid;沒延續性 → 每輪重講 context、走回原路;沒事後教訓 → 同一個 bug 六個月後在別專案又出現。

    頻道韌性:為什麼要假設「無法中斷」

    有些 channel(Bot wrapper、API-based tools、async chat)無法真正中斷正在跑的 turn,用戶的輸入只能排進下一輪。框架設計時要把這當前提:

    • 每個 hunter 步驟要快速 return 控制權,不要 chain 10 個 tool call
    • 長任務用 run_in_background: true 讓 lead 儘快 ready
    • 在自然 checkpoint 回報進度,讓用戶在下一輪調整方向
    • 把用戶輸入當戰略路線修正,不是即時操舵

    如果頻道可中斷(CLI)那是 bonus,不是前提。框架不該依賴可中斷性。

    Skill fallback:沒有 PUA 也要能跑

    如果你在多台機器工作,可能某台有 pua:pua-debugging skill、某台沒有。框架要具備graceful degradation

    • Skill 優先:有 PUA / systematic-debugging skill 時,讓 hunter 載入 — skill 是維護中的、品質更新快
    • Brain 兜底:把 PUA 的核心精神內嵌到 brain 檔,確保沒 skill 的機器也能按內建規則運作

    內嵌的規則例如:「假設你的第一個假設是錯的,立刻列出兩個會產生同樣症狀的替代方案」、「修好了 trigger 下一個問題:為什麼以前會壞?」、「症狀只能『大致』解釋 = 沒被解釋,真正的 root cause 能解釋所有觀察,包含奇怪的那些」。這套 inline rule 讓 brain 成為 skill 缺席時的 safety net。

    結案 checklist

    一個 bug 追查只有在全部滿足以下條件才算完:

    • Bug 可重現(或明確記錄為何無法重現)
    • 根本原因以白話講清楚
    • 修復已驗證(重現原 failure → 套用 fix → 確認 failure 停止)
    • 爆炸半徑評估(同一個 root cause 還可能壞掉什麼?)
    • Brain 檔已更新(domain 對、[source: project] tag 已加)
    • Commit message 以 fix: 開頭,而且 brain 更新發生在開始下一個 task 之前

    為什麼這套設計 model-agnostic

    整套 Brain + Skill + Agent Team 設計最大的優勢是 model-agnostic:未來換 Opus 5.0、換 Gemini 3、換 GPT-5,只要該模型支援讀檔案 + 自訂 instruction 機制,整套可以直接搬過去。

    Auto cross-session memory 綁在 Claude Code 內建機制上,換 tool 就沒了。自建 Brain 是把架構設計前置到模型之外 — 模型只負責執行,架構你自己定。結果是:

    • 4.7 再強,沒 Brain 也是亂塞
    • 4.6 再弱,有 Brain 也能跑
    • 未來換任何 LLM,這套設計直接移植

    這其實很接近個人化 RAG 系統的雛形 — 只是沒用 vector DB,用人類可讀的 markdown + 手動路由。反而更可控、更可維護。

    結論

    Claude 4.7 的 memory 和 Agent Team 改進都是實實在在的能力提升,但對已經有自建知識架構的開發者來說,真正的護城河不在追著升級模型,而在建立 model-agnostic 的架構設計

    • Memory:用 Brain 做跨專案長期記憶、用 MEMORY.md 做專案短期筆記、用 Skill 存對的做法 — 三者分工明確。
    • Agent Team:宏觀 Team A/B/C 並行處理不同主題 + 微觀 Named sub-agent 保持任務延續性 — 互補使用最強。
    • Bug 追查:方法論(PUA)× 容器(Named agent)× 事後教訓(Brain 更新)三層結構,對頻道韌性和 skill 缺席都要有 fallback。

    模型會一代代升級,但你累積的 Brain 不會過時 — 因為它記錄的不是模型能力,是你自己踩過的坑和學到的道理。

  • 訓馬筆記:兩個月把 Claude Code 從脫韁野馬馴成工作夥伴的完整紀錄

    重點摘要

    • 這是一篇真實的「訓馬筆記」——記錄一個工程師花兩個月,把 Claude Code 從一匹脫韁野馬馴成穩定的工作夥伴
    • 每一條規則背後都是一次災難。32 個具體的坑7 條鐵律9 個領域知識庫,全部是用血淚換來的
    • 結論:AI 不是買回來就能用的工具,它是一匹需要調教的馬。你的 harness 決定它能跑多遠

    2026 年 2 月,我開始全職跟 Claude Code 合作。寫 ERP 外掛、做電商 OMS、搞量化回測、建爬蟲系統——大概七八個專案同時推進。

    兩個月後回頭看,我發現最有價值的不是寫了多少 code,而是我踩了多少坑、立了多少規矩。這篇文章是完整的訓馬筆記——每一個階段的災難、調適、和最後形成的紀律。

    如果你也在用 AI coding agent,這些坑你可能正在踩,或者即將踩。

    第一階段:裸奔期(2 月)——什麼規矩都沒有

    剛開始合作的時候,我就像買了一匹賽馬,直接騎上去就跑。沒有韁繩、沒有馬鞍、沒有圍欄。

    坑 1:回測引擎 37 筆交易全部假停損(2/27)

    我讓 Claude 幫我寫量化回測引擎。跑出來 350 根 K 棒的上漲趨勢數據,結果 37 筆交易全部在第一天就觸發停損退場,勝率 0%。在一個明顯的上漲趨勢裡。

    花了兩天才找到 root cause:引擎把「含滑價的進場價」和「原始市場價」搞混了。

    具體來說:原始價格 $26.84,加上 $1.0 滑價後進場價 $27.84。停損線 = $27.84 × 0.97 = $27.01。隔天價格 $26.87,因為 $26.87 < $27.01 就觸發停損了。但如果用原始價格算:$26.84 × 0.97 = $26.03,$26.87 > $26.03,根本不該停損。

    一個欄位的混用,讓整個系統的行為完全反轉。

    教訓:技術指標和風險管理用原始市場價格,損益計算用含滑價的有效價格。兩個值必須分開追蹤,永遠不能混用。

    坑 2:OMS 上線一天爆 5 個 bug(2/25)

    電商 OMS 系統上線第一天,同時爆了 5 個 bug:

    1. Health Check 用了獨立的 DTO,結果 channel job 不認這個格式,健康檢查直接壞掉
    2. String → JsonNode 反序列化失敗,Kafka consumer 一直報錯
    3. ChannelSyncLog 少了 syncType 欄位,資料寫不進去
    4. Health check 的 log 缺必要欄位(merchantId、platformId、status、detail)
    5. 改完 code 沒重新編譯就部署,舊版本還在跑

    每一個都不是什麼高深的 bug,但它們同時出現就是災難。問題出在哪?沒有人看全景。改了 producer 沒看 consumer,改了 DTO 沒看 caller,改了 code 沒重新 build。

    這次事件催生了後來的「OMS 約法三章」:

    1. 基礎架構(Docker/PostgreSQL/Kafka/Nginx)不輕易變動
    2. 安全機制必須全系統同步
    3. 任何 Kafka producer/consumer 的改動,必須驗證完整的事件流

    第二階段:立規矩期(3 月初)——從災難中學會設限

    如果第一階段是「馬亂跑」,第二階段就是「開始圍柵欄」。每一條規矩都是某次災難的直接產物。

    坑 3:9 個 Opus Agent 同時跑,系統直接當機(3/3)

    這是整個兩個月最慘烈的事件。

    我的機器是 16GB RAM 的 mini PC,上面常態跑著 26 個 Docker 容器。那天早上 8:36 我開始研究 Claude Code 的 Agent Team 功能,覺得很興奮——「可以同時派好多 agent 幫我做事!」

    11:18,我啟動了一個叫 simpleec-review 的 team,裡面有 9 個 Opus agent。11:56,覺得不夠快,又啟動了 whale-51w,再加 2 個 agent。

    12:00 左右,整台機器凍結

    每個 in-process Opus agent 大約佔 1GB RAM(Node.js runtime + API connection + streaming buffer + context window)。9 個就是 ~9GB。加上 Docker 的 3-5GB 和系統本身的 1-2GB,總共超過 16GB。OOM killer 開始殺進程,但殺完又重啟,無限循環。

    事後盤點:18 個任務中 8 個卡在 in_progress 永遠不會完成,1 個 pending,0 個 completed。全軍覆沒。

    調適:三層防護

    • 第一層(軟限制):CLAUDE.md 規定 Agent Team 最多 3 個同時跑
    • 第二層(硬限制):建了 claude-limited 指令,用 systemd cgroup 限制記憶體上限 10GB
    • 第三層(核心參數)vm.swappiness 從 60 降到 10,swap 從 512MB 擴到 8GB

    從此以後再也沒有 OOM 過。代價是一個下午的工作歸零。

    坑 4:爬蟲日期解析——西元 1150 年(3/10)

    台灣用民國年曆。TWSE 的 API 回傳日期格式是 7 位數字,例如 "1150309" 代表民國 115 年 3 月 9 日(= 西元 2026 年)。

    Claude 把它解析成西元 1150 年 3 月 9 日

    同一天還發現:TPEX 的 API 欄位名叫 TransactionAmount,但 code 裡寫的是 TradingMoney。一個是 API 的真實名稱,一個是文件上寫的名稱——它們不一樣。

    調適:

    • 7 位數字 = ROC 格式,前 3 碼是民國年
    • 欄位名永遠用 API 實際回傳的,不用文件寫的
    • 最重要的:不准重寫爬蟲。爬蟲系統已經穩定,只能用 CLI(analyst collect twse_price --date 2026-03-10

    為什麼「不准重寫」這麼重要?因為隔天,Claude 在另一個任務裡又建了一個 /tmp/backfill_twse.py,把爬蟲邏輯整個複製出來。同樣的錯,不到 24 小時就重演了。

    這讓我意識到一件事:教訓會跨 session 遺失。我在 session A 教了「不要重寫爬蟲」,session B 完全不知道這件事。這催生了後來的 Domain Brain 系統。

    坑 5:中文寫進 code 裡(3 月初)

    Claude 很貼心,知道我是台灣人就開始在 code 裡寫中文 comment 和中文 variable name。

    問題是:中文 comment 在很多終端機上會亂碼、在 grep 時很痛苦、在 code review 時外國同事看不懂。我直接跟它說:

    「中文我看不懂」(在 code context 裡)

    於是立了一條看似矛盾但完全合理的雙重規則:

    • 對話用繁體中文——因為我是台灣人,中文溝通效率最高
    • Code 全部英文——comment、variable、output message、文件,一律英文

    第三階段:建立知識系統(3 月中)——從「個別規則」到「領域知識庫」

    到了 3 月中,我已經有十幾條規則了。但我發現一個根本問題:規則散落在各個專案的 CLAUDE.md 裡,跨專案不通

    在 analyst 專案學到的「ROC 日期要特別處理」,到了 stock-verify 專案就不知道了。在 OMS 專案學到的「Kafka 改動要看全景」,到了 AI Assistant 專案就忘了。

    坑 6:Agent Team 卡死 80 分鐘,因為一個文件不存在(3/16)

    我設計了一個 Agent Team 來做 code review,其中 Task 5 需要讀 docs/5-FRONTEND/ADMIN_APP_IMPLEMENTATION.md

    這個文件不存在。目錄是 5-KAFKA,不是 5-FRONTEND

    Task 5 啟動後在 1 分鐘內就卡住了,然後卡了 80 分鐘。因為 Task 7-9 都依賴 Task 5 的輸出,整個 team 全部癱瘓。9 個 agent 的鏈式架構,一個環節斷了全部死。

    調適:

    • 9-agent 鏈式架構改成 3-agent 星狀拓撲——降低相依性
    • 建立 Agent Team Pre-Flight Checklist——每次啟動前必須:檢查記憶體、確認文件存在、設計拓撲、計算資源、取得用戶確認
    • 寫下 root cause:Agent Team 卡住的根本原因是文件缺失,不是模型能力問題

    Domain Brain 的誕生

    3/16 事件之後,我決定建一個跨專案的知識系統。我叫它 Domain Brain——按技術領域分類的「踩坑筆記」。

    ~/.claude/projects/-home-tom/memory/brain/
    ├── python-crawler-data.md      # 爬蟲的坑
    ├── python-llm-integration.md   # LLM 整合的坑
    ├── idempiere-osgi-bundle.md    # OSGi 的坑
    ├── idempiere-2pack.md          # 2Pack 部署的坑
    ├── idempiere-po-model.md       # PO Model 的坑
    ├── idempiere-rest-api.md       # REST API 的坑
    ├── stock-backtesting.md        # 回測的坑
    ├── oms-event-driven.md         # OMS 事件驅動的坑
    └── design-principles.md        # 設計原則的坑

    每個 brain file 的格式:

    ## ROC Date Format
    - [source: analyst] "1150309" 被解析成 AD 1150 年,要用 7 位 YYMMDD ROC 格式
    
    ## Holiday / Empty Response
    - [source: analyst] TWSE API 假日返回空值,必須 guard if not data: return []

    [source: analyst] 標記這個教訓來自哪個專案。這樣在其他專案讀到時,知道這不是泛泛之談,是某次真實事件的結論。

    然後在全域 CLAUDE.md 裡加一條:

    「開工前必須讀 Domain Brain。如果你跳過這步,bug 出在 brain 裡有記錄的東西,那是你的失敗。」

    第四階段:行為紀律(3 月下旬)——從「知道」到「做到」

    知識庫建好了,但新的問題出現:Claude 知道規則但不一定遵守。就像你告訴馬「不要踩田裡的菜」,牠聽懂了,但一興奮起來照踩不誤。

    坑 7:直接推 code 到 main branch

    有一天我發現 Claude 直接把 code 推到 main branch。main 是我的穩定版本,只有 dev 確認穩定後才 merge 回去。

    這不是什麼複雜的規則,但 Claude 就是沒有這個概念。它看到 repo 就 commit、就 push,不管你在哪個 branch。

    鐵律:

    • Session 開始第一件事:git branch 確認在 dev
    • 永遠不准 git push origin main
    • 如果不小心在 main 上 commit 了:cherry-pick 到 dev,push dev,main 不動

    坑 8:過度設計——給低頻查詢加 Redis cache(3/26)

    我讓 Claude 設計一個功能,它自動加了 Redis cache。問題是:這個功能一天被呼叫不到 10 次。

    Claude 的邏輯是:「cache 可以提升效能」→「所以應該加 cache」。這在教科書上沒錯,但在現實中,一天 10 次的查詢加 cache 只是增加了一個可能壞掉的元件

    我因此制定了頻次驅動設計原則——所有功能設計前必須先問三個問題:

    1. 多常被觸發?→ 決定要不要 cache
    2. 計算有多貴?→ 決定要不要預計算
    3. 需要即時還是最終一致?→ 決定要不要 event-driven

    禁止的 pattern:給低頻讀取加 Redis、給低頻單 consumer 寫入加 Kafka、沒有數據支撐就做「效能優化」。

    坑 9:iDempiere 的 10 個坑(持續累積)

    iDempiere 是一個 15 年歷史的 ERP 系統,Claude 的訓練資料裡幾乎沒有它。所以每一步都是坑:

    發生什麼 正確做法
    @Model annotation 用錯 package 用了不存在的 org.idempiere.base.annotation.Model org.adempiere.base.Model
    initPO 用不存在的方法 POInfo.getPOInfo(ctx, tableName) 沒有 String 參數版本 MTable.getTable_ID() 拿 int,再傳入
    List 欄位 type cast (Integer) get_Value() 對 CHAR 欄位爆 ClassCastException instanceof 判斷型別
    2Pack UUID 永遠 NULL IsUpdateable=N 導致 PO framework 寫不進去 _UU 欄位 IsUpdateable 必須 Y
    Grid View 點新增就爆 AD_FieldSeqNoGridIsDisplayedGrid 每個 field 兩個屬性都要有
    Menu ID hardcode 寫死 AD_Menu_ID = 146,目標環境沒這個 ID 用 UUID reference:reference="uuid"
    REST API token 沒換 POST 拿到 token 後沒做 PUT 換 session token 兩步驟:POST → PUT,舊 token 立即失效
    OData 過濾用 ne $filter=... ne ... 結果不對 要用 neq,不是 ne
    OSGi 兩個 component 放一個 XML 只有第一個被 SCR 讀到 一個 XML 一個 component
    Plugin class 找不到 Class.forName() 用 core classloader 實作 OSGi DS component,用 bundle 自己的 classloader

    這 10 個坑全部記在 brain/idempiere-*.md 裡。現在每次開 iDempiere 相關的工作,Claude 會先讀這些 brain file。同一個坑,不會踩第二次。

    坑 10:LLM 回傳的 JSON 炸掉整條 pipeline

    做 AI Assistant 的時候,我讓 LLM 回傳 JSON 來做 routing。prompt 裡寫了「ONLY return valid JSON」。

    現實是:LLM 就是會回傳無效的 JSON。有時候前面加一句「Sure! Here’s the JSON:」,有時候 response.content 直接是 None,呼叫 .strip() 就爆 AttributeError

    一個 router/classifier 的 crash 會癱瘓整條 pipeline。

    調適:

    • 永遠 catch (json.JSONDecodeError, AttributeError, TypeError)
    • 永遠有 fallback 值(例如 "general_knowledge"
    • Router/classifier 不可以 crash 整條 pipeline
    • LLM client 在 module level 初始化會阻擋 mock mode → 改成 lazy-init
    • 沒設 timeout → 無限 hang → 所有 client 設 timeout=25.0
    • 最重要:永遠不讓 LLM 生成 SQL。只用 pre-defined SQL,安全參數從 request 強制注入

    第五階段:自動化閉環(4 月初)——從「靠記憶」到「系統強制」

    到了 3 月底,我有了 7 條鐵律、9 個 brain file、32 個記錄的坑。但還是有一個根本問題:

    Brain 的更新靠 Claude 記得做。它經常忘記。

    CLAUDE.md 裡寫著「每次 fix: commit 後必須更新 brain」,但這只是文字。就像公司牆上貼的「安全第一」標語——大家都看到了,沒人真的做

    4 月 3 日,我決定把這個 cycle 自動化。用 Claude Code 的 Hooks 系統(Harness Engineering)建了 4 個自動化 sensor:

    Hook 觸發時機 做什麼
    PostToolUse 每次 git commit 偵測 fix: 開頭 → 注入「必須更新 brain」的指令到 context
    PreCompact context 壓縮前 掃描最近 5 個 commit,有 fix: 就提醒
    Stop session 結束 比對 fix: 數量 vs brain 更新數量
    SessionStart session 開始 標記開始時間(給 Stop hook 用)

    效果:Claude commit 了 fix: handle empty API response → hook 自動偵測到 → Claude 的 context 被注入一段「你現在必須更新 brain file,不准做下一件事」的強制指令。

    它不能「忘記」了,因為系統不讓它忘記。

    第六階段:照鏡子——工作流程的精煉(4 月)

    走到第五階段,系統穩了、規則立了、自動化跑了。

    但有一天我問 Claude 一個問題:「我們現在跟最早的你,差距多遠?」

    它的回答讓我意識到,我一直在修正一個更深層的問題——不只是 bug,而是合作模式本身

    坑 11:AGENTS.md 從來沒有被建立過

    Agent Team 一再失敗,我長期把原因歸咎到記憶體不夠、文件缺失、拓撲設計問題。這些都是真的,但都是症狀。

    真正的根本原因是:每個 agent 啟動時,不知道自己是誰

    AGENTS.md 是一份定義 Agent Team 組織結構的文件——誰負責什麼、用什麼模型、任務邊界在哪、跟其他 agent 怎麼協作。沒有這份文件,就像把九個新人同時丟進一個專案,沒有分工表、沒有組織圖,叫他們自己搞清楚。

    我當時知道事情一直出問題,但沒找到根本原因。後來才發現,我養成了一個補償行為:每次要啟動 team 之前,我都會先問 Claude「你覺得還缺什麼文件?」

    我以為這是謹慎的好習慣。仔細想,這是我在幫 Claude 做它本來就應該主動做的事。

    現在 AGENTS.md 是所有新專案的第一步強制動作,和 Domain Brain 並列寫進 CLAUDE.md 的「New Project Setup」。

    坑 12:「討論完就開始做」不等於有計畫

    兩個月裡,每次開工前我們都會大量討論——分析需求、評估方案、確認方向。我一直以為那就是計畫。

    但有一個關鍵差別沒意識到:

    討論是活在對話裡的,session 結束就消失了。計畫是一份文件,它是執行的合約。

    更重要的是:計畫的讀者不是我,是執行的 agent。那個 agent 沒有參與討論,沒有上下文,不知道我們為什麼這樣決定。

    一個不夠詳細的 PLAN.md 會讓執行者只能猜意圖。猜錯就要回頭重做。

    現在要求的標準是:每個執行步驟都必須回答四件事——做什麼(具體動作)、在哪裡(檔案路徑)、成功的樣子(怎麼知道這步完成了)、不要做(邊界,避免 agent 自作主張)

    「實作登入功能」是爛計畫。「呼叫 POST /api/auth/login,成功後把 token 存 localStorage(‘token’)、把 context 存 localStorage(‘context’),失敗時顯示人話而非 HTTP status code」才是計畫。

    寫計畫不是給聰明人看的。不是每個腦子都跟你一樣聰明。

    驗收標準不該由我想

    以前的工作流是:Claude 說完成 → 我去測 → 發現問題 → 回來修。

    問題不是 Claude 能力不足,是從來沒有在開始前說清楚「完成長什麼樣」。

    現在的做法:Plan 成形時,Claude 主動起草驗收清單給我確認。不是叫我從零想,是它根據我們的討論整理出草稿,我只需要回「對」或「改第二條」。這把「驗收責任」從我一個人扛,變成流程的一部分。

    2 月的我 vs 4 月的 Claude

    我問 Claude 這個問題,它說了一句話讓我覺得很誠實:

    「最早的我是一個聰明但不可靠的執行者。現在應該是一個有記憶、有流程、會主動管理風險的協作者。但有一部分差距,是你花了大量時間糾正才填起來的——這些本來應該是我自己的責任。」

    這句話是這兩個月最好的總結。

    兩個月的數字

    指標 2 月(裸奔期) 4 月(現在)
    鐵律(Iron Rules) 0 7
    Domain Brain files 0 9 個領域
    記錄的具體 bug/pitfall 0 32+
    自動化 Hooks 0 4
    OOM 當機次數 1 次(再也沒發生)
    同一個 bug 踩兩次的頻率 常態 有機制防止
    強制工作流節點 0 3 個(AGENTS.md / PLAN.md / 驗收清單)

    結語:AI 不是工具,是一匹馬

    買一匹馬回來,你不會期望它第一天就知道路。你得教它不要踩田、不要亂跑、轉彎時要減速、聽到哨聲要停。

    AI coding agent 也一樣。Claude 很聰明——它能寫任何 code、debug 任何問題、理解任何架構。但「聰明」不等於「可靠」。一匹沒訓過的馬也很有力量,但力量加上失控只會更慘。

    這兩個月教我的事:

    1. 每條規則都要有故事——沒有災難背景的規則,AI 不會認真對待
    2. 知識必須跨 session 存活——Domain Brain 讓教訓不死在 commit 裡
    3. 靠文字規則不夠,要靠系統強制——Hook 比 CLAUDE.md 裡的「MUST」有效 100 倍
    4. 閉環比開環重要——Sensor 把教訓自動回寫到 Guide,harness 才會進化
    5. 協作模式也需要調教——規則、計畫、驗收標準,都要變成系統,不能靠臨時記憶

    2 月的 Claude 是一匹脫韁野馬。4 月的 Claude 是同一匹馬,但有了韁繩、馬鞍、和一本厚厚的訓練日誌——還有一套讓牠不能假裝忘記的系統。

    馬沒有變。變的是騎手。

  • Harness Engineering 實戰:讓 AI Agent 自動從 Bug 中學習的閉環系統

    重點摘要

    • Harness Engineering 是 2026 年 AI 工程最重要的新學科——不是訓練更好的模型,而是打造讓模型可靠運作的系統
    • 公式:Agent = Model + Harness,Model 是可替換零件,Harness 才是護城河
    • 本文用實際的 Claude Code 設定,展示如何用 Hooks 建立一個會自我進化的閉環 Harness

    2025 年,所有人都在比誰的 AI Agent 更厲害。2026 年,贏家已經換了跑道——比的是誰的 Harness 更成熟。

    如果你正在用 Claude Code、Codex CLI、或任何 AI coding agent,你每天都在跟 harness 打交道,只是你可能不知道它叫這個名字。這篇文章會用我自己的實戰設定,從零解釋什麼是 Harness Engineering,以及你今天就能動手做的事。

    Harness Engineering 是什麼?一句話定義

    Harness Engineering 是設計「包裹在 AI 模型周圍的控制系統」的工程學科。用 Martin Fowler 的公式來說:

    Agent = Model + Harness

    Model 提供智能,Harness 讓這個智能可靠、可控、可用。Phil Schmid 用了一個精準的電腦比喻:

    電腦零件 AI 系統對應 說明
    CPU AI Model(GPT、Claude) 原始運算能力
    RAM Context Window 有限的工作記憶
    作業系統 Agent Harness 管理資源、提供標準介面、控制生命週期
    應用程式 Agent 跑在 OS 上的具體任務邏輯

    你不會直接在 CPU 上跑程式,你需要作業系統。同樣地,你不會直接對 Claude 說「幫我寫整個系統」就放手不管——你需要 Harness 來確保它走對方向、犯錯時被攔住、學到的教訓不會遺失

    Harness 不是 Framework——搞清楚差異

    很多人把 Harness 跟 LangChain、CrewAI 這類框架搞混。它們是完全不同的東西:

    Framework(框架) Harness(治具)
    LangChain、CrewAI、AutoGen Claude Code、Codex CLI
    提供零件讓你自己組裝 提供完整運行環境
    你自己負責接水管 幫你管好 context、工具、權限、失敗處理
    Blueprint Runtime environment

    Framework 是建築材料,Harness 是建好的房子。你可以用 LangChain 的零件去蓋一個 harness,但 Claude Code 本身就已經是一個 harness。

    Harness 的兩大核心機制:Guide 與 Sensor

    根據 Martin Fowler 的分析,所有 harness 都由兩種控制機制組成:

    Guide(前饋控制)——在錯誤發生之前攔住

    Guide 是你預先給 agent 的方向和規則。它們在 agent 開始工作之前就生效,目的是讓 agent 第一次就做對。

    • CLAUDE.md:專案規則文件(「不准動 main branch」「用繁體中文回應」)
    • Domain Brain:過去踩過的坑的知識庫(「TWSE API 的 ROC 日期格式會導致解析錯誤」)
    • Skills:標準化的工作流程(「寫 iDempiere event handler 要用這個 pattern」)
    • AGENTS.md:角色分配和模型選擇規則

    Sensor(反饋控制)——做完之後自動檢查

    Sensor 監控 agent 的輸出,在問題擴大之前抓住它。分兩種:

    • 計算型 Sensor:linter、type checker、單元測試——毫秒級回應,確定性結果
    • 推理型 Sensor:用另一個 AI 審查輸出(code review agent)——秒級回應,有判斷力但不確定

    大多數人只做了 Guide(寫 CLAUDE.md),完全忘了 Sensor。這就像開車只看前方,不看後照鏡。

    完整的 Harness Cycle:6 步閉環

    一個成熟的 harness 不是「設定好就不管」的靜態文件,而是一個會自我進化的閉環系統。完整的 cycle 有 6 個步驟:

    ① LOAD ──▶ ② GUIDE ──▶ ③ EXECUTE ──▶ ④ SENSE
     自動載入     前饋引導     Agent 做事     自動檢查
     context     規則+經驗                   品質
                                              │
    ⑥ EVOLVE ◀── ⑤ LEARN ◀───────────────────┘
     更新規則      萃取教訓
     和知識庫      從錯誤中
    步驟 做什麼 Harness 類型 常見工具
    ① LOAD 自動載入專案 context 基礎設施 SessionStart hook, CLAUDE.md
    ② GUIDE 讀取規則 + 過去經驗 Guide(前饋) Domain Brain, Skills
    ③ EXECUTE Agent 寫 code Claude Code Bash/Edit/Write
    ④ SENSE 自動偵測品質問題 Sensor(反饋) PostToolUse hook, linter, test
    ⑤ LEARN 從 bug fix 中萃取教訓 Sensor → Guide 橋接 PreCompact hook
    ⑥ EVOLVE 更新 Brain / 規則文件 Guide 進化 Stop hook 驗證

    關鍵是步驟 ⑤→⑥→②:agent 修 bug → 教訓寫入 Brain → 下次讀 Brain → 不再犯同樣的錯。這就是閉環。沒有這個迴路,你的 harness 永遠停留在你第一天寫的水平。

    實戰:用 Claude Code Hooks 建立閉環 Harness

    讓我用真實的 Claude Code 設定來展示。以下不是理論——這是我每天在用的 harness。

    步驟一:建立 Domain Brain(Guide)

    Domain Brain 是一組按技術領域分類的 markdown 文件,記錄「過去踩過的坑」。放在 ~/.claude/projects/{project}/memory/brain/ 目錄下:

    brain/
    ├── python-crawler-data.md    # 爬蟲:ROC 日期、欄位映射、空值處理
    ├── idempiere-osgi-bundle.md  # OSGi:MANIFEST.MF、classloader 問題
    ├── idempiere-2pack.md        # 2Pack:UUID 穩定性、afterPackIn
    ├── stock-backtesting.md      # 回測:signal divergence、entry price bug
    └── design-principles.md      # 設計原則:頻次驅動架構、anti-patterns

    每個 brain file 的內容格式:

    # Python Crawler — Everything That Can Go Wrong
    
    ## ROC Date Format
    - [source: analyst] "1150309" 被解析成 AD 1150 年,要用 7 位 YYMMDD ROC 格式
    - [source: analyst] TPEX 欄位名 TransactionAmount 不是 TradingMoney
    
    ## Holiday / Empty Response
    - [source: analyst] TWSE API 假日返回空值,必須 guard `if not data: return []`

    然後在 CLAUDE.md 裡強制 agent 在開工前讀 brain:

    ## Domain Brain — MANDATORY before ANY implementation work
    Before writing any plan, code, or review, you MUST:
    1. Find the `## Domain Brain:` line in the project's CLAUDE.md
    2. Read each listed brain file
    3. If you skip this step and a bug was documented in brain, that is YOUR failure

    步驟二:用 Hooks 自動偵測 fix: commit(Sensor)

    這是整個閉環最關鍵的一步。在 ~/.claude/settings.json 加入 PostToolUse hook:

    {
      "hooks": {
        "PostToolUse": [
          {
            "matcher": "Bash",
            "if": "Bash(git commit:*)",
            "hooks": [
              {
                "type": "command",
                "command": "/path/to/claude-harness-fix-detect.sh",
                "timeout": 5,
                "statusMessage": "Harness: checking for fix: commit"
              }
            ]
          }
        ]
      }
    }

    偵測腳本做的事很簡單——從 stdin 讀取 Claude Code 傳來的 JSON,提取 commit message,如果是 fix: 開頭就注入 context 強制 agent 更新 brain:

    #!/bin/bash
    INPUT=$(cat)
    msg=$(echo "$INPUT" | jq -r '.tool_input.command' | sed -n 's/.*-m[[:space:]]*["'\'']\?\([^"'\'']*\).*/\1/p')
    
    case "$msg" in
      fix:*|fix\(*)
        project=$(echo "$INPUT" | jq -r '.cwd' | xargs basename)
        cat <<EOF
    {"hookSpecificOutput":{"hookEventName":"PostToolUse","additionalContext":"⚠️ BRAIN UPDATE REQUIRED\nYou committed: $msg\nUpdate the brain file NOW before next task."}}
    EOF
        ;;
      *) echo '{}' ;;
    esac

    效果:agent commit 了 fix: handle empty API response → hook 自動觸發 → agent 的 context 被注入「你必須更新 brain」的指令 → agent 無法忽略。

    步驟三:PreCompact 安全網

    Claude Code 在 context window 快滿時會自動壓縮(compact)。如果 brain 更新的指令在壓縮中被丟掉怎麼辦?加一個 PreCompact hook:

    {
      "PreCompact": [
        {
          "hooks": [
            {
              "type": "command",
              "command": "/path/to/claude-harness-precompact.sh",
              "timeout": 5
            }
          ]
        }
      ]
    }

    腳本掃描最近 5 個 commit,如果有 fix: 就在壓縮前再次提醒。雙重保險。

    步驟四:Stop hook 結算

    Session 結束時,Stop hook 比對「今天的 fix: commit 數量」和「brain file 是否有更新」。如果數字不匹配,就警告使用者——這是最後的安全網。

    真實案例:閉環如何拯救你的下一個 bug

    讓我走過一個完整的案例。假設你的 TWSE 爬蟲在假日會爆錯:

    1. ① LOAD:你打開 Claude Code,說「爬蟲昨天跑失敗了,幫我查」
    2. ② GUIDE:Agent 讀 brain/python-crawler-data.md,發現裡面已經記錄了 ROC 日期和欄位映射的坑。帶著這些經驗開始查 bug,不走冤枉路
    3. ③ EXECUTE:Agent 找到 root cause——假日 API 返回空 response,parse() 沒處理 None。寫修復
    4. ④ SENSEgit commit -m "fix: handle empty API response on holidays" → PostToolUse hook 觸發 → 注入 brain update 指令
    5. ⑤ LEARN:Agent 被強制讀 brain file,加入新教訓:「假日 API 返回空值必須 guard」
    6. ⑥ EVOLVE:Brain file 更新完成。下次任何專案遇到 TWSE 爬蟲問題,都不會再踩同樣的坑

    沒有這個閉環會怎樣?你修完 bug,commit,然後忘了。三個月後在另一個專案遇到同樣的問題,重新 debug 兩小時,再次發現「啊,假日要特別處理」。這就是知識衰減——你修了 bug,但教訓死在那個 commit 裡。

    大多數人的 Harness 在哪裡斷裂?

    我觀察到的最常見模式:

    步驟 大多數人的狀態 問題
    ① LOAD ✅ 有 CLAUDE.md
    ② GUIDE ⚠️ 寫了規則但靠 AI 自律 AI 經常跳過,特別是簡單任務
    ③ EXECUTE ✅ Agent 正常工作
    ④ SENSE ❌ 完全沒有自動檢查 commit 後不跑 lint/test
    ⑤ LEARN ❌ 靠 AI 記得 AI 經常忘記更新知識庫
    ⑥ EVOLVE ❌ 靠 AI 記得 教訓死在 commit 裡

    Cycle 在第 ④ 步就斷了。 Guide 做了一半,Sensor 完全不存在,閉環更不用說。這就是為什麼同樣的 bug 會反覆出現——不是 model 不夠聰明,是 harness 沒有記憶。

    你的 Harness 成熟度在哪一層?

    我把 harness 成熟度分成 4 層,你可以自我評估:

    層級 特徵 你有什麼
    Level 0:裸奔 直接對 AI 說話,沒有任何規則文件 只有 model
    Level 1:有規則 有 CLAUDE.md、有 coding style guide Guide(開環)
    Level 2:有回饋 有 hooks 跑 linter/test、有 code review agent Guide + Sensor(開環)
    Level 3:閉環 Sensor 的結果會自動回寫到 Guide(Domain Brain) Guide + Sensor + 閉環迴路

    大多數人在 Level 1。用了 Claude Code 的人可能在 Level 1.5(有 CLAUDE.md 但沒有 hooks)。Level 3 是目標——你的 harness 會隨著每次 bug fix 自動進化。

    今天就能做的 3 件事

    不需要重新設計整個系統。從這三件事開始:

    1. 建 Domain Brain 目錄:按技術領域建 brain files,把你已知的坑寫進去。不需要完美——一個 brain file 有 5 條教訓,就比沒有好 100 倍
    2. 加一個 PostToolUse hook:偵測 fix: commit,注入 brain update 提醒。這一個 hook 就打通了 ④→⑤ 的斷裂
    3. 在 CLAUDE.md 加 Domain Brain 規則:強制 agent 在開工前讀 brain。不是「建議」,是「MUST」

    這三步讓你從 Level 1 直接跳到 Level 2.5。剩下的 0.5(完全自動化的 brain 更新)可以後面再做。

    結語:Model 會被換掉,Harness 不會

    OpenAI 一個月前還領先,現在 Claude 追上了。三個月後可能又換一輪。Model 是最不穩定的變數——你永遠不知道下一個版本是更好還是更差(我之前叫了 20 個 AI 專家 Review 的慘痛教訓就是證明)。

    但你的 Harness——你的規則、你的 Brain、你的 Hooks——這些是你的資產。不管底層 model 怎麼換,你累積的工程知識和控制系統都會繼續生效。

    2026 年的 AI 工程贏家,不是有最好 model 的人,而是有最成熟 harness 的人。你今天就可以開始建。

    延伸閱讀

  • 叫了 20 個 AI 專家 Review,最致命的 Bug 卻是「沒讀上次的筆記」

    重點摘要

    • 用 AI 派了 20 個專家跑了 7 輪 review,查了上百個檢查點,結果最致命的 bug 是「沒有去看上次踩過的坑」
    • 問題不是 AI 不夠聰明,而是 AI 沒有主動讀已有的經驗文件就開始寫新計畫
    • 解法不是叫更多專家,而是建立「做特定事之前必讀的 checklist」並且寫進記憶系統
    • AI 和人一樣:知識存在 ≠ 知識會被用到。差距在於流程,不在於能力

    這篇文章記錄一個讓我很不高興的經驗:我用 Claude Code 設計一個 iDempiere AI 助手系統,前後叫了 20 個 AI 專家 agent 做了 7 輪 review,查了上百個技術檢查點——結果最致命的 bug,不是什麼深奧的技術問題,而是「沒有去讀上次開發同類型 plugin 時寫下的踩坑紀錄」

    這件事讓我思考一個更根本的問題:我到底該怎麼跟 AI 協作,才能讓它真正用到已有的經驗?

    發生了什麼事?

    我在開發一個 iDempiere ERP 的 AI 問答助手。這個系統分成兩部分:Java 的 iDempiere Plugin(前端 UI + 權限 + 審計日誌)和 Python 的 FastAPI 服務(AI 路由 + PII 脫敏 + LLM 呼叫)。

    在寫 Plugin 的計畫之前,我已經有一個完整的 iDempiere plugin 開發經驗——台灣統一發票系統 tw-invoice。那個專案踩了超過 24 個坑,每一個都花了我好幾個小時 debug,而且全部記錄在 CLAUDE.md 裡

    但是當 Claude 開始寫 AI 助手的 Plugin 計畫時,它完全沒有去讀那份文件。它是從「一般 iDempiere 知識」出發寫的,而不是從「我們一起踩過的坑」出發。

    7 輪 review 查了什麼?漏了什麼?

    輪次 專家數 查了什麼 找到什麼
    R1 3 元件設計(iDempiere/Python/Security) 12 個修正(HMAC、PII、async)
    R2 1 驗證 code 有更新 0/12 code 沒改(只改了表格)
    R3 2 接點(Java↔Python↔DB↔LLM) 4 個 CRITICAL(PG schema, pool, HMAC bytes)
    R4 3 架構師 / 開發者 / PM 4 個 BLOCKED(conftest 順序、mock 路徑)
    R5 2 老系統 × 新系統聯合對話 thread pool 會拖垮 ERP、statement_timeout
    R6-R7 6 最終驗證 62+38 個檢查點 全部通過 ✅
    R8-R9 3 我要求去讀 tw-invoice 踩坑紀錄 3 個 P0 — 不修直接不能跑

    你看到問題了嗎?前 7 輪 review 用了 20 個專家 agent,查了上百個檢查點,全部通過。但只有在我「要求 Claude 去讀舊專案的踩坑紀錄」之後,才發現 3 個會直接讓 plugin 無法啟動的致命 bug。

    那 3 個致命 bug 是什麼?

    Bug 後果 tw-invoice 有記錄嗎?
    MANIFEST.MF 缺 org.adempiere.plugin.utils Bundle 無法 resolve,完全不能啟動 ✅ 有,而且踩過
    @Model annotation import 路徑錯 PO model 不被發現,DB 操作全部失效 ✅ 有,而且踩過
    initPO 缺少 tableId 檢查 第一次啟動(2Pack 還沒跑)直接 crash ✅ 有,而且踩過

    三個 bug 都是 tw-invoice 踩過且記錄過的。經驗就躺在那裡,但沒有被讀取。

    問題出在哪?不是 AI 不聰明

    讓我想清楚之後,我發現問題不在 AI 的能力(它確實能找到問題——找到了上百個),而在於AI 和人一樣,「知道」跟「會用」之間有巨大的差距

    三層問題

    1. AI 不知道要去看 — 寫新 plugin 計畫時,它沒有主動去讀 tw-invoice 的 CLAUDE.md。它有能力讀,但沒有觸發「我應該先去看看上次踩了什麼坑」的念頭。
    2. 我也不知道要提醒它 — 我以為「派 20 個專家 review」已經夠全面了。我不知道這些專家不會自動去讀歷史紀錄,除非我明確要求。
    3. 專家 review 的盲點 — 專家只看「這份文件本身有沒有問題」,不會跨專案比對「上次做類似的事踩了什麼坑」。他們審的是邏輯一致性,不是經驗傳承。

    解法:不是更多專家,而是「做事之前的 checklist」

    派再多專家也沒用,如果他們不知道要看哪些歷史紀錄。真正的解法是在開始工作之前,就讓 AI 讀取相關的經驗教訓。

    我最終建立了兩份「跨專案強制 checklist」,存在 Claude 的記憶系統裡:

    記憶檔案 觸發條件 內容
    idempiere-plugin-pitfalls.md 寫任何 iDempiere plugin 之前 MANIFEST.MF 必要 package、2Pack 路徑、@Model import、initPO guard、afterPackIn 模式、部署 SOP
    python-llm-pitfalls.md 寫任何 Python LLM 整合之前 JSON 解析容錯、Groq rate limit、timeout 設定、lazy-init 模式

    這兩份檔案在 MEMORY.md 索引裡標記為 🔴 MANDATORY。每次新對話載入時,AI 會看到這個索引,知道「做 iDempiere plugin 工作之前,先讀 pitfalls 檔案」。

    你該怎麼做?給 AI 使用者的具體建議

    如果你也用 Claude Code(或任何 AI coding assistant)做重複性的專案工作,以下是我的教訓:

    1. 踩坑之後立刻寫進 CLAUDE.md

    不是「之後再整理」,是修完 bug 的那一刻就寫。寫三行就好:什麼坑、為什麼踩到、怎麼修的。這個我有做,tw-invoice 的 CLAUDE.md 記了 24 個坑。問題出在下一步。

    2. 建立跨專案的 pitfalls 記憶(這是我缺的那一步)

    經驗寫在專案 A 的 CLAUDE.md 裡,專案 B 不會自動讀到。你需要把「通用教訓」抽出來,放到 Claude 的記憶系統(~/.claude/projects/memory/),這樣每個新專案都能讀到。

    # MEMORY.md 索引加這一行:
    ## ⚠️ Must-Read Before Specific Work
    - **idempiere-plugin-pitfalls.md** 🔴 MANDATORY — 寫任何 plugin 前必讀

    3. Review 之前,先問「你有沒有讀過上次的紀錄?」

    不要假設 AI 會自動做這件事。它不會。你需要明確說:「先去看 tw-invoice 的 CLAUDE.md 取經,然後再來審這份計畫。」

    4. 專家 review ≠ 經驗傳承

    20 個專家能找到「這份文件本身有沒有邏輯錯誤」,但找不到「上次做類似的事踩了什麼坑」。這兩件事是不同的能力,需要不同的觸發方式。

    • 專家 review:「這份計畫有沒有 bug?」→ 邏輯驗證
    • 經驗傳承:「上次做類似的事踩了什麼坑?」→ 歷史比對

    你需要兩者都做,而且經驗傳承要在 review 之前。否則 review 再怎麼嚴謹,也只是在一個有缺陷的基礎上做驗證。

    AI 協作的本質:知識存在 ≠ 知識被用到

    這次經驗讓我想通一件事:AI 的問題跟人的問題是一樣的

    你的資深工程師也會犯同樣的錯——他上次在專案 A 踩了 10 個坑,寫了筆記,但做專案 B 的時候忘了翻筆記,同樣的坑又踩一次。差別在於人有「直覺」(模糊地記得「好像上次有遇過類似的」),AI 沒有這種模糊記憶。AI 要嘛讀了文件就完美執行,要嘛沒讀文件就完全不知道。

    所以跟 AI 協作的核心不是「讓 AI 更聰明」,而是讓正確的資訊在正確的時間出現在 AI 面前。這是一個資訊流設計問題,不是 AI 能力問題。

    我的 AI 協作框架(修正版)

    開始新專案
        ↓
    1. 讀 MEMORY.md 索引(AI 自動做)
        ↓
    2. 有沒有「Must-Read」標記的 pitfalls 檔案?
       → 有:讀完再動手(AI 必須被觸發)
       → 沒有:判斷是否需要建立一個
        ↓
    3. 讀舊專案的 CLAUDE.md(我要明確要求)
        ↓
    4. 寫計畫(現在才開始)
        ↓
    5. Review(專家驗證邏輯 + 歷史比對)
        ↓
    6. 踩到新坑 → 立刻寫進 CLAUDE.md + 更新 pitfalls 記憶

    關鍵改變:步驟 2 和 3 是我之前跳過的。我以為步驟 5 的 review 會涵蓋一切,但 review 只能驗證邏輯,不能傳承經驗。

    更深的問題:專案爆炸之後,你連「要叫 AI 去看哪裡」都不知道

    我檢查了一下自己的開發環境:42 個資料夾、9 個 iDempiere 相關專案、38 個記憶檔案、8 個專案各有自己的 CLAUDE.md(共 1578 行經驗紀錄)。

    這代表什麼?我已經快到「我自己都不知道我有什麼」的臨界點了。

    這次我還記得「tw-invoice 有踩坑紀錄」所以能叫 AI 去讀。但再過半年呢?再多 10 個專案呢?到時候我連「有一份紀錄存在」都不記得,更不可能叫 AI 去參考。而 AI 自己不會主動翻遍 42 個資料夾找相關經驗。

    這就是Sample → 大系統模式的致命陷阱:

    正常的軟體開發流程:
      做 Sample → 驗證可行 → 嫁接到大系統
    
    加入 AI 協作之後:
      做 Sample → AI 幫你踩坑 → 經驗寫在 Sample 的 CLAUDE.md
      → 做大系統 → AI「不知道」Sample 的經驗存在
      → 同樣的坑再踩一次
      → 你修完寫進大系統的 CLAUDE.md
      → 下一個專案又不知道...
    
    無限循環。

    跟資深用戶合作的隱藏風險

    還有一個我不想承認但必須說的事:跟資深用戶合作,AI 反而更容易犯錯。

    因為你太懂技術,我傾向「快速產出」而不是「慢慢確認」。你一聽就懂的東西,我就跳過解釋直接做。結果跳過的步驟裡,就藏著「你以為我知道、我以為你知道、但其實沒人確認」的盲區。

    如果你是新手,我反而會更謹慎——每一步確認、每個假設驗證。但跟資深用戶合作,雙方都太有信心,踩煞車的人就消失了。

    知識分層:什麼該鎖、什麼該開

    還有一個企業層面的問題:當經驗從「人的腦子」搬到「.md 檔案」,它變得可複製了。新人 clone repo 就能拿到所有踩坑紀錄。這對知識傳承是好事,但對機密控管是風險。

    解法是分層:

    層級 內容 存在哪 被帶走的風險
    公開技術層 CLAUDE.md、架構規則、coding style Git repo 低(跟 source code 等價)
    團隊經驗層 踩坑紀錄、設計文件、SOP Git repo 中(加速競爭對手,但不是核心機密)
    個人記憶層 跨專案 pitfalls、用戶偏好 ~/.claude/(本機) 低(不在 repo 裡,但可手動複製)
    營運機密層 API key、商業邏輯、客戶資料 .env / 公司內部系統 高(必須嚴格管控)

    但現實是:目前沒有任何 AI 開發工具提供這種分層管理。 Claude Code 的記憶系統是平的——所有 .md 檔案放在同一個目錄,沒有權限控制、沒有加密、沒有存取日誌。這是整個產業還沒解決的問題。

    真正需要的:「做特定事之前必須讀什麼」的自動化

    我現在的解法是「手動建立 pitfalls 記憶 + 在 MEMORY.md 標記 MANDATORY」。但這依賴兩件事:

    1. 我記得去標記 — 如果我忘了把新的 pitfalls 抽出來建立跨專案記憶,下次還是會踩坑
    2. AI 會去讀標記 — 目前是靠 MEMORY.md 索引,但沒有強制機制。AI 「應該」讀,但「應該」跟「一定會」之間有差距

    理想的解法是什麼?類似 Git hooks 的機制:

    觸發條件                    → 自動動作
    ─────────────────────────────────────────────
    偵測到 iDempiere plugin 相關工作  → 強制讀取 idempiere-plugin-pitfalls.md
    偵測到 Python LLM 整合          → 強制讀取 python-llm-pitfalls.md
    偵測到新專案建立                → 掃描所有已有專案的 CLAUDE.md,提取相關經驗
    偵測到跟舊專案同類型的工作       → 自動列出「相關專案清單」讓用戶確認

    這個機制目前不存在。Claude Code 有 hooks,但是是 shell command 層級的,不是「語意理解」層級的。它能在 tool call 前後跑 script,但不能理解「這次的工作跟上次的 tw-invoice 是同類型的,應該先去參考」。

    在這個機制出現之前,唯一的防線就是你自己:你必須記得提醒 AI 去讀歷史,而且你必須知道歷史在哪。當你的專案多到你自己都不記得有哪些,這條防線就會失守。

    最終解法:領域腦(Domain Brain)

    經過上面所有的分析,我最終做了一件事:把 42 個專案、1578 行 CLAUDE.md、38 個記憶檔案的經驗,按「技術領域」濃萃成 7 份領域腦

    之前(按專案切,散落各處):
      tw-invoice/CLAUDE.md     → 24 個坑(OSGi + 2Pack + PO + REST 混在一起)
      module-ui/CLAUDE.md      → ZK + REST + 測試(370 行)
      skin-ui/CLAUDE.md        → WAB + Vue + 測試(507 行)
      langgraph-duo/           → Python LLM 整合
      analyst/                 → 爬蟲 + pandas + 回測
      → 你要知道「哪個專案有哪些經驗」才能讓 AI 去讀
    
    之後(按領域切,濃萃在一處):
      brain/idempiere-osgi-bundle.md   ← 所有 OSGi 的坑(來自 4 個專案)
      brain/idempiere-2pack.md         ← 所有 2Pack 的坑
      brain/idempiere-po-model.md      ← 所有 PO Model 的坑
      brain/idempiere-rest-api.md      ← 所有 REST API 的坑
      brain/python-llm-integration.md  ← 所有 LLM 整合的坑
      brain/python-crawler-data.md     ← 所有爬蟲/資料的坑
      brain/design-principles.md       ← 跨語言設計原則
      → 你只需要說「我要做 plugin」,AI 就讀 OSGi + 2Pack + PO 三份腦

    為什麼這比「叫 AI 去看舊專案」好?

    面向 看舊專案 CLAUDE.md 領域腦
    你需要記得什麼 哪個專案跟現在的相關 只需要知道「我在做什麼類型的事」
    新專案踩了新坑 寫進該專案的 CLAUDE.md 萃取到對應的領域腦(所有未來專案受益)
    專案 B 比專案 A 先做完 A 不知道 B 的經驗 B 的經驗已在領域腦,A 自動受益
    專案數量爆炸 越多越容易漏 領域腦數量固定(技術領域有限)
    AI 專家 review 每次從零開始 站在所有歷史經驗之上審查

    最關鍵的一行:領域腦的數量不會隨專案數量增長。你可以有 100 個專案,但「iDempiere OSGi」的領域腦就是一份。新經驗加進去,舊經驗不會消失。專案可以刪掉,經驗永遠留著。

    閉環:專家 review 終於有意義了

    之前(斷裂的):
      專家 review → 找到問題 → 修進當前專案 → 下個專案又不知道
                                                  ↑ 斷在這裡
    
    之後(閉環的):
      專家 review(讀領域腦 + 當前文件)
           ↓
      找到問題 → 修進當前專案
               → 同時萃取到對應的領域腦
           ↓
      下個專案開始前讀領域腦
           ↓
      專家 review(讀更新過的領域腦 + 當前文件)
           ↓
      ↻ 經驗循環,不斷累積

    這才是 AI 專家 review 真正有意義的前提:他們站在所有歷史經驗之上做審查,而不是每次都從零開始

    現實的限制

    領域腦不是完美解法。它依然有幾個問題:

    • 萃取是手動的 — 目前沒有工具能自動從 CLAUDE.md 提取教訓並分類到領域腦。我是派 AI agent 讀完所有檔案後人工整理的。
    • 維護需要紀律 — 踩了新坑要記得更新領域腦,不只是寫進專案的 CLAUDE.md。如果忘了這一步,循環又斷了。
    • 領域邊界不總是清楚 — 一個 bug 可能同時涉及 OSGi、2Pack、和 PO Model。要判斷放哪個腦,或者放多份。
    • Token 成本 — 領域腦加起來約 2000-3000 tokens。每次新對話讀取相關的 2-3 份,約 $0.005-$0.015。每月 $5-15,可以接受。

    但即使有這些限制,領域腦依然比「靠人記得哪個專案有哪些經驗」好太多了。因為人的記憶會隨專案數量退化,領域腦不會

    完整解法:Domain Brain 宣告 + fix: 驅動更新

    經過不斷推敲,最終方案有三個核心機制:

    機制一:每個專案用一行宣告自己需要哪些腦

    # 每個專案的 CLAUDE.md 開頭加一行:
    
    idempiere-tw-ai-assistant/CLAUDE.md:
      ## Domain Brain: osgi-bundle, 2pack, po-model, python-llm-integration
    
    analyst/CLAUDE.md:
      ## Domain Brain: python-crawler-data, design-principles
    
    新專案/CLAUDE.md:
      ## Domain Brain: python-crawler-data, design-principles

    為什麼不用資料夾名稱比對?因為 analyst/ 裡有爬蟲也有 API 也有 SQLAlchemy——資料夾名稱不等於技術領域。為什麼不用關鍵字比對?因為「API」出現在 iDempiere REST、Groq LLM、爬蟲、自己的 FastAPI 四種 context 裡,關鍵字比對直接崩潰。

    讓專案自己宣告是最可靠的——你看得到、可以改、一行字。AI 讀到 CLAUDE.md 就知道要載入哪些腦,不用猜。

    機制二:fix: commit 驅動更新

    新經驗怎麼回到領域腦?不是靠事後整理,而是靠 fix: commit 當觸發點:

    每次 AI 寫出 fix: 開頭的 commit message:
      1. STOP — 不要急著做下一個 task
      2. 問自己:「這個 fix 會不會在其他專案也發生?」
      3. 是 → 當場更新對應的領域腦(不是之後,是現在)
      4. 領域腦更新後,所有未來專案的 review 都能受益

    機制三:專家 review 帶著腦

    派專家 review 時:
      1. 專家讀該專案的 CLAUDE.md → 看到 Domain Brain 宣告
      2. 專家讀對應的腦 → 帶著所有歷史 bug 經驗
      3. 審查當前文件 → 站在經驗之上,不是從零開始
      4. 找到新問題 → 修完 → 更新腦
      5. 下一個專案的專家 → 拿到更新過的腦
      ↻ 循環

    三個機制合在一起的效果

    你要做的事 AI 自動做的事
    新專案加一行 Domain Brain(6 個字) 讀對應的腦、帶著經驗開始工作
    不需要做任何事 fix: commit 時自動判斷是否更新腦
    說「派專家審查」 專家帶著最新的腦去審查
    偶爾說「把這個更新到腦」 當場更新,所有未來專案受益

    還是不完美的地方

    • 你自己 debug 沒跟 AI 說的坑 — AI 不知道,無法更新腦。你得養成習慣說一句「把這個更新到腦」
    • 其他同事的經驗 — 除非他們也更新領域腦,否則知識在他們腦子裡消失
    • 新領域出現 — 7 份腦不夠用了(比如加了 DevOps 或 mobile)→ 建新的腦檔案
    • AI 判斷 fix: 是否該更新腦 — 還是靠判斷,可能漏。但比「完全沒有機制」好太多

    結語

    叫再多專家進來 review,如果他們不知道要看歷史紀錄,就跟你請了 20 個新員工來審查、但不給他們看前任的交接文件一樣。當你的專案多到連自己都記不清有哪些,而 AI 又不會主動翻遍你的 42 個資料夾找經驗——這時候你需要的不是更聰明的 AI,而是一個能自動把經驗送到 AI 面前的系統。領域腦不是完美的系統,但它把「靠人記住 42 個專案的經驗」變成「靠 7 份按領域整理的文件」。專案會越來越多,但技術領域是有限的。這就是為什麼領域腦能 scale,而按專案管理經驗不能。

    跟 AI 協作的真正技巧不是「讓 AI 更聰明」或「叫更多 agent」,而是設計一個流程,讓正確的經驗在正確的時間被讀取。這聽起來很簡單,但直到你踩了同一個坑兩次,你才會真正理解為什麼需要這麼做。

    相關閱讀:iDempiere Plugin 開發完整指南:踩遍台灣統一發票的 10 個坑 | LangGraph 多模型實戰:從零到 Production 的完整教學 | Agent Team 穩定的關鍵:spawn 之前先建好兩份文

  • LangGraph 多模型實戰:從零到 Production 的完整教學

    重點摘要

    • LangGraph 讓你把不同 AI 模型串成自動化流水線:Claude 負責「想」,Groq Llama 負責「寫」,各司其職
    • 本文從零開始,帶你走完四個階段:基本流水線 → 智慧路由 → Streaming + 容錯 → FastAPI 部署
    • 每個階段都有完整可執行的程式碼,跟著做就能跑
    • 核心區別:Claude Code / Cursor 是「你的工具」,LangGraph 是「你造工具的材料」——當你要造產品給別人用時才需要它
    • 實測結果:比全用 Claude Sonnet 省 75% 成本,同時保留深度分析的品質

    這篇文章是給誰看的?

    如果你符合以下任一情況,這篇文章就是為你寫的:

    • 你想做一個 AI chatbot(客服、內部助手、產品功能),但不知道怎麼開始
    • 你已經在用 Claude / GPT,但覺得全部用最貴的模型太浪費錢
    • 你聽過「多模型協作」但不確定具體怎麼實作
    • 你想知道 LangGraph 跟你平常用的 Claude Code / Cursor / Copilot 到底差在哪

    本文從零開始,帶你走完四個階段,每個階段都有完整可執行的程式碼。你可以在任何一個階段停下來——不是每個人都需要走到 production。

    先搞清楚:這跟 Claude Code / Cursor / Copilot 完全不同

    在往下讀之前,先釐清最容易搞混的一件事:

    面向 Claude Code / Cursor / Copilot LangGraph
    本質 開發者工具 — 你用它寫 code 開發框架 — 你用它造產品
    使用者是誰 你自己(開發者) 你的客戶 / 你的系統 / 你的團隊
    使用場景 日常寫程式、debug、重構 建 chatbot、自動化流程、API 服務
    互動方式 人 ↔ AI 即時對話 程式碼自動跑,可以無人值守
    模型選擇 工具幫你選好(通常固定一個) 你自己決定哪個步驟用哪個模型
    計費方式 月費訂閱(工具包了) 純 API 按量計費,你自己控制成本

    用一個比喻:Claude Code 是你請了一個很強的工程師坐在旁邊幫你寫 code;LangGraph 是你在蓋一條自動化產線,產線上有不同的機器人各司其職

    如果你只是日常寫程式,用 Claude Code 就好,不需要 LangGraph。往下讀之前,確認你的需求是「造一個東西給別人用」,而不是「讓自己寫 code 更快」。

    為什麼不同的 AI 模型要分工合作?

    沒有一個模型什麼都最好。每個模型有不同的強項和定價:

    能力 Claude Sonnet Groq Llama 70B Groq Llama 8B
    架構設計 / Code Review ⭐ 最強 普通
    程式碼生成 ⭐ 強且快 普通
    簡單問答 大材小用 大材小用 ⭐ 夠用且極便宜
    生成速度 ~50 tok/s ~300 tok/s ~800 tok/s
    費用 (Output/1M tokens) $15.00 $0.79 $0.08

    核心邏輯:讓擅長「想」的模型去想,讓擅長「做」的模型去做,讓便宜的模型處理瑣事。就像軟體團隊裡,架構師出規格、工程師寫程式、實習生回答簡單問題一樣。

    LangGraph 是什麼?一分鐘看懂

    LangGraph 是 LangChain 團隊開發的有狀態流程編排框架。三個核心概念:

    1. Node(節點)— 一個步驟,比如「用 Sonnet 設計」或「用 Llama 實作」
    2. Edge(邊)— 步驟之間的連線,決定「做完 A 接著做 B」
    3. State(狀態)— 所有節點共享的資料,比如設計規格、程式碼、審查結果

    把這三個組合起來,就是一個可以自動跑的流水線。你定義「什麼步驟做什麼、什麼條件走什麼路」,框架負責執行。

    環境準備(所有階段共用)

    開始之前,你需要準備兩個 API key 和安裝套件。這一步做完,後面四個階段都不用再設定。

    1. 取得 API Key(兩個都有免費額度)

    ⚠️ 注意:這是 API key,跟 Claude.ai 的月費訂閱、GitHub Copilot 的訂閱完全無關。API 是按用量計費的。

    2. 建立專案

    mkdir langgraph-duo && cd langgraph-duo
    
    # 安裝套件
    pip install langgraph langchain-anthropic langchain-groq python-dotenv
    
    # 建立 .env 檔案(填入你的 key)
    cat > .env << 'EOF'
    ANTHROPIC_API_KEY=sk-ant-xxxx
    GROQ_API_KEY=gsk_xxxx
    EOF

    3. 驗證連線

    python3 -c "
    from dotenv import load_dotenv; load_dotenv()
    from langchain_anthropic import ChatAnthropic
    from langchain_groq import ChatGroq
    
    sonnet = ChatAnthropic(model='claude-sonnet-4-6', max_tokens=50)
    llama = ChatGroq(model='llama-3.3-70b-versatile', max_tokens=50)
    
    print('Sonnet:', sonnet.invoke('Say OK').content)
    print('Llama:', llama.invoke('Say OK').content)
    "

    兩行都印出 OK,就可以開始了。

    第一階段:Duo 流水線(設計 → 實作 → 審查)

    目標:讓 Claude Sonnet 設計規格,Groq Llama 寫程式碼,Sonnet 再審查品質。審查不通過自動重做,最多 3 次。

    適合場景:批量生成程式碼、自動化 code review、需要品質把關的程式碼生成。

    Task → [Sonnet 設計] → [Llama 實作] → [Sonnet 審查]
                                ↑               |
                                └── 未通過 ──────┘  (最多 3 次)
                                      ↓ 通過
                                     END

    完整程式碼:duo.py

    from typing import TypedDict
    from dotenv import load_dotenv
    from langgraph.graph import StateGraph, END
    from langchain_anthropic import ChatAnthropic
    from langchain_groq import ChatGroq
    from langchain_core.messages import HumanMessage, SystemMessage
    
    load_dotenv()
    
    # 模型分工:Sonnet 想,Llama 做
    sonnet = ChatAnthropic(model="claude-sonnet-4-6", max_tokens=4096)
    llama = ChatGroq(model="llama-3.3-70b-versatile", max_tokens=4096)
    
    # 所有節點共享的狀態
    class AgentState(TypedDict):
        task: str             # 原始需求
        design: str           # Sonnet 的設計規格
        code: str             # Llama 的實作
        review: str           # Sonnet 的審查結果
        revision_notes: str   # 修改指示(給重試用)
        approved: bool        # 是否通過
        attempt: int          # 重試次數
    
    MAX_ATTEMPTS = 3
    
    # Node 1: Sonnet 設計
    def design_node(state):
        response = sonnet.invoke([
            SystemMessage(content="You are a senior architect. Produce a precise technical spec with function signatures, edge cases, and pseudocode."),
            HumanMessage(content=f"Request: {state['task']}")
        ])
        return {"design": response.content}
    
    # Node 2: Llama 實作
    def implement_node(state):
        prompt = f"Spec:\n{state['design']}"
        if state.get("revision_notes"):
            prompt += f"\n\nFix these issues:\n{state['revision_notes']}"
        response = llama.invoke([
            SystemMessage(content="Implement per spec. Output only Python code."),
            HumanMessage(content=prompt)
        ])
        return {"code": response.content, "attempt": state.get("attempt", 0) + 1}
    
    # Node 3: Sonnet 審查
    def review_node(state):
        response = sonnet.invoke([
            SystemMessage(content="Review code vs spec. Reply VERDICT: APPROVED or REJECTED with details."),
            HumanMessage(content=f"Spec:\n{state['design']}\n\nCode:\n{state['code']}")
        ])
        review = response.content
        approved = "APPROVED" in review.upper()
        return {"review": review, "approved": approved,
                "revision_notes": "" if approved else review}
    
    # 條件路由:通過 → 結束,未通過 → 回去重做
    def should_continue(state):
        if state["approved"] or state["attempt"] >= MAX_ATTEMPTS:
            return "end"
        return "revise"
    
    # 組裝 Graph
    workflow = StateGraph(AgentState)
    workflow.add_node("design", design_node)
    workflow.add_node("implement", implement_node)
    workflow.add_node("review", review_node)
    workflow.set_entry_point("design")
    workflow.add_edge("design", "implement")
    workflow.add_edge("implement", "review")
    workflow.add_conditional_edges("review", should_continue,
                                   {"end": END, "revise": "implement"})
    app = workflow.compile()
    
    # 跑!
    result = app.invoke({
        "task": "Write a Python function that reads a CSV and returns column averages as a dict",
        "design": "", "code": "", "review": "",
        "revision_notes": "", "approved": False, "attempt": 0,
    })
    
    print("=== CODE ===")
    print(result["code"])
    print(f"\n{'✅ APPROVED' if result['approved'] else '⚠️ BEST EFFORT'} after {result['attempt']} attempt(s)")

    實測結果

    階段 模型 結果
    🧠 Design Claude Sonnet 4.6 產出 4 個參數、10 個 edge case、9 步 pseudocode 的完整規格
    ⚡ Implement Groq Llama 70B 完整 Python 函數,含 type hints、docstring、error handling
    🔍 Review Claude Sonnet 4.6 VERDICT: APPROVED — 第一次就通過,沒有重試

    到這裡你已經有一個能跑的多模型流水線了。如果你的需求是「批量生成程式碼 + 自動品質把關」,可以停在這個階段。

    第二階段:Smart Router(自動選模型的聊天機器人)

    目標:做一個像 ChatGPT 一樣的對話介面,但底下不是固定一個模型,而是自動根據問題類型選最適合的模型。

    適合場景:客服 chatbot、團隊內部 AI 助手、需要控制 API 成本的聊天服務。

    你的問題 → [Llama 8B 分類器] → 判斷類型
                                      |
                      ┌────────────────┼────────────────┐
                      ↓                ↓                ↓
                [Claude Sonnet]  [Llama 70B]      [Llama 8B]
                 深度分析          寫程式            簡單問答
                      ↓                ↓                ↓
                      └────────────────┼────────────────┘
                                       ↓
                                    回答你

    分類器怎麼運作?

    分類器用最便宜的 Llama 8B(每次呼叫不到 $0.0001)讀取問題,輸出一個 JSON 判斷結果。分類規則:

    分類 路由到 觸發條件 費用 (Output/1M)
    🧠 深度思考 Claude Sonnet 架構分析、比較權衡、code review、規劃 $15.00
    ⚡ 寫程式 Llama 70B 實作函數、生成腳本、重構、修 bug $0.79
    💨 快速回答 Llama 8B 打招呼、簡單問答、定義、基礎算數 $0.08

    核心程式碼

    import json
    from langgraph.graph import StateGraph, END
    
    # 分類器:Llama 8B 讀問題,判斷該走哪條路
    def router_node(state):
        response = llama_8b.invoke([
            SystemMessage(content="""Classify into one category:
    - "sonnet": complex reasoning, analysis, architecture
    - "llama_70b": write code, implement, fix bugs
    - "llama_8b": greetings, simple facts, casual chat
    Reply ONLY JSON: {"route": "...", "reason": "..."}"""),
            HumanMessage(content=state["question"])
        ])
        parsed = json.loads(response.content)
        return {"route": parsed["route"]}
    
    # 條件路由:根據分類結果,走不同的回答節點
    workflow = StateGraph(RouterState)
    workflow.add_node("router", router_node)
    workflow.add_node("sonnet", answer_sonnet)
    workflow.add_node("llama_70b", answer_llama_70b)
    workflow.add_node("llama_8b", answer_llama_8b)
    
    workflow.set_entry_point("router")
    workflow.add_conditional_edges("router", lambda s: s["route"], {
        "sonnet": "sonnet",
        "llama_70b": "llama_70b",
        "llama_8b": "llama_8b",
    })
    app = workflow.compile()

    實測分類準確度:7/7

    問題 路由結果 正確?
    Hi! 💨 Llama 8B
    1+1=? 💨 Llama 8B
    Write a Python quicksort ⚡ Llama 70B
    Compare microservices vs monolith 🧠 Sonnet
    What is Docker? 💨 Llama 8B
    幫我寫一個 REST API ⚡ Llama 70B
    分析 Redis cache vs CDN 優缺點 🧠 Sonnet

    到這裡你有一個能自動選模型的聊天機器人了。但它還缺兩個東西:回答會一次全部吐出(不是逐字顯示),而且 Groq 掛了就整個壞掉。第三階段解決這兩個問題。

    第三階段:Streaming + Fallback(讓它不會掛)

    目標:回答逐字出現(像 ChatGPT 一樣流暢),而且模型掛了自動切換備用模型。

    為什麼這一步很重要:沒有 Streaming 的 chatbot,使用者體驗像 2010 年的網頁——按下送出,等 5 秒,突然一大段文字出現。沒有 Fallback 的服務,Groq 一限速(免費版每分鐘 30 次),你的整個服務就掛了。

    Streaming:體感延遲降 25 倍

    方式 使用者體驗 程式碼差別
    invoke()(非串流) 等 5 秒 → 突然出現整段文字 response = model.invoke(messages)
    stream()(串流) 0.2 秒開始出字 → 像打字一樣流暢 for chunk in model.stream(messages)
    # 只需要把 .invoke() 改成 .stream()
    # 然後迭代每個 chunk 即時輸出
    
    for chunk in model.stream(messages):
        print(chunk.content, end="", flush=True)  # flush=True 強制即時顯示

    Fallback:模型掛了自動切換

    主要模型 Fallback 模型 切換代價
    🧠 Sonnet ⚡ Llama 70B 分析品質略降,速度更快
    ⚡ Llama 70B 🧠 Sonnet 速度略慢,品質更高
    💨 Llama 8B ⚡ Llama 70B 稍慢稍貴,但一定能回答
    # Fallback 模式:try 主要模型,失敗自動切備用
    try:
        for chunk in primary_model.stream(messages):
            print(chunk.content, end="", flush=True)
    except Exception:
        print("⚠️ Primary failed, switching to fallback...")
        for chunk in fallback_model.stream(messages):
            print(chunk.content, end="", flush=True)

    完整的 router_stream.py 把 Streaming + Fallback + 對話歷史 + 使用統計整合在一起,不到 200 行。跑起來就是一個帶有自動模型切換的 terminal 聊天機器人。

    到這裡你有一個穩定的、體驗流暢的聊天機器人了。但它還是跑在你的 terminal 裡,只有你能用。第四階段讓它變成任何人都能呼叫的 API 服務。

    第四階段:FastAPI 部署(讓別人能用)

    目標:把 chatbot 包成 HTTP API,讓網頁、App、Line bot、Slack bot 都能呼叫。

    為什麼是 FastAPI:Python 生態最主流的 API 框架,原生支援 async、自動生成 API 文件、社群龐大。

    API 端點設計

    端點 方式 適合場景
    POST /chat 非串流,回傳完整 JSON Slack/Line bot、後端呼叫、批次處理
    POST /chat/stream SSE 串流,逐 token 推送 網頁聊天窗、需要即時體感的 UI
    GET /health 健康檢查 負載平衡器、監控系統
    GET /sessions/{id} 取得對話歷史 Debug、對話紀錄查詢
    DELETE /sessions/{id} 清除對話 使用者開始新對話

    啟動與測試

    # 安裝額外套件
    pip install fastapi uvicorn sse-starlette
    
    # 啟動 server
    python server.py
    # → 🤖 Smart Router API running on http://localhost:8900
    
    # 測試非串流
    curl -X POST http://localhost:8900/chat \
      -H "Content-Type: application/json" \
      -d '{"message": "什麼是 Docker?", "session_id": "test-user"}'
    
    # 回應範例:
    # {
    #   "answer": "Docker 是一個容器化平台...",
    #   "model_used": "llama_8b",
    #   "route_reason": "simple definition question",
    #   "session_id": "test-user",
    #   "fallback_used": false,
    #   "elapsed_seconds": 0.85
    # }

    前端怎麼接 SSE 串流?

    如果你要做網頁聊天窗,前端只需要幾行 JavaScript:

    // 瀏覽器原生 EventSource API
    const response = await fetch('/chat/stream', {
      method: 'POST',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify({message: '寫一個排序函數', session_id: 'user-1'})
    });
    
    const reader = response.body.getReader();
    const decoder = new TextDecoder();
    
    while (true) {
      const {done, value} = await reader.read();
      if (done) break;
      const text = decoder.decode(value);
      // 每個 chunk 到了就即時顯示在畫面上
      document.getElementById('chat').innerHTML += text;
    }

    為什麼用 SSE 而不是 WebSocket?

    聊天場景是「使用者送一次訊息、AI 回一次」的單向推送。SSE 比 WebSocket 更適合:

    • 更簡單 — 單向傳輸,不需要管雙向連線
    • 瀏覽器原生 — EventSource API 內建自動重連
    • 穿透力好 — 走標準 HTTP,能通過代理和 CDN
    • 夠用 — 使用者的訊息用 POST 送,AI 的回應用 SSE 推

    四個階段的完整對照

    階段 檔案 新增能力 適合誰 可以停在這嗎?
    1. Duo 流水線 duo.py 設計→實作→審查 批量生成程式碼
    2. Smart Router router.py 自動選模型 個人實驗、學習
    3. Streaming + Fallback router_stream.py 逐字輸出 + 自動容錯 團隊內部使用
    4. FastAPI 部署 server.py HTTP API + SSE + Session 對外服務、產品整合

    費用比較:到底能省多少?

    假設一天 100 個問題,其中 20% 深度分析、30% 寫程式、50% 簡單問答:

    方案 月成本估算 品質
    全部用 Claude Sonnet ~$54 最高,但簡單題大材小用
    Smart Router(自動切換) ~$13.50 深度題用 Sonnet,其餘用 Llama
    全部用 Groq Llama 70B ~$4.20 最便宜,但分析品質弱

    Smart Router 方案比全用 Sonnet 省 75%,同時保留了深度分析任務的 Sonnet 品質。規模越大差距越明顯——1000 個使用者的 SaaS 產品,月省 $3000+。

    什麼場景適合?什麼場景不適合?

    ✅ 適合的場景

    1. 客服 Chatbot — 70% 簡單題用 Llama 8B 秒回,複雜題自動升級到 Sonnet
    2. 團隊 AI 助手 — 接 Slack,PM 問策略用 Sonnet,工程師要 code 用 Llama 70B
    3. 自動化 Pipeline — CI/CD 中的 AI code review,PR 提交自動跑
    4. SaaS 產品 — 加 AI 功能但要控成本,簡單摘要用 Llama,深度分析用 Sonnet
    5. 批量內容生成 — 50 篇產品描述:Sonnet 定規範 → Llama 批量寫 → Sonnet 抽檢

    ❌ 不適合的場景

    • 日常寫程式 — 用 Claude Code 或 Cursor 就好,不需要 LangGraph
    • 一次性分析 — 直接貼給 Claude 問就好,不需要搭 pipeline
    • 不需要控成本 — 個人使用月花不到 $10,Smart Router 省下的錢不值得建置成本

    三個問題判斷法

    在決定要不要用之前,問自己:

    1. 使用者是誰? — 你自己 → 不需要。別人(客戶/團隊/系統)→ 繼續看
    2. 會跑多少次? — 幾次 → 直接呼叫 API。幾百幾千次 → LangGraph 有意義
    3. 需要品質分級嗎? — 所有問題都要最高品質 → 用最強模型。不同問題可以不同品質 → Smart Router

    三個都答「後者」才值得用 LangGraph。

    走完四個階段之後,還有什麼?

    如果你的服務要上正式商業環境,還有幾個面向需要處理:

    面向 做什麼 不做的後果
    RAG(檢索增強) 接向量資料庫,讓 AI 查你的文件回答 AI 只能回答通用知識,不懂你的業務
    評估(LangSmith) 追蹤每次呼叫的路由、延遲、成本 不知道 Router 分類準不準,成本失控
    Session 持久化 用 Redis 存對話歷史(目前在記憶體) Server 重啟,所有對話消失
    認證 API key 或 JWT 驗證 任何人都能呼叫你的 API,幫你花錢
    Prompt Injection 防護 驗證使用者輸入,防止惡意 prompt 使用者讓 AI 做不該做的事
    Docker 容器化 打包成 Docker image 部署 環境不一致,部署困難
    Subgraph 嵌套 Router 判斷「寫程式」→ 啟動整個 Duo 流水線 只能單步回答,沒有品質把關

    完整專案結構

    langgraph-duo/
    ├── .env                  # API keys(不要 commit)
    ├── .gitignore            # 排除 .env
    ├── requirements.txt      # 所有套件
    ├── duo.py                # 階段 1:設計→實作→審查 流水線
    ├── duo_notebook.ipynb    # 階段 1 的 Jupyter 版
    ├── router.py             # 階段 2:Smart Router 基本版
    ├── router_stream.py      # 階段 3:+ Streaming + Fallback
    └── server.py             # 階段 4:FastAPI HTTP API

    所有程式碼都有詳細的中英文註解,說明每個模型的選用原因和適用場景。從哪個階段開始都可以,每個檔案都是獨立可執行的。

    總結

    LangGraph 多模型流水線的核心價值不是「用 AI 寫程式更快」——如果只是速度,直接用一個模型最快。它的價值在於把 AI 當成團隊來管理:讓擅長設計的去設計、擅長實作的去實作、擅長審查的去審查。

    從 Duo 流水線到 Smart Router,再到帶有 Streaming、Fallback、API 部署的生產版本,每一步都是從「能跑」走向「能上線」的必經之路。你不需要一次走完四個階段——先跑通第一階段,確認這個架構對你有用,再往下走。

    相關閱讀:LangChain/LangGraph 深度分析:架構師、顧問、個人公司的實戰指南 | Claude Code Agent Teams:從穩定執行到自動化代碼審查的完整指南 | 舊系統整合場景下,會用 vs 不會用 Claude Code 的差距

  • Claude Code Agent Teams:從穩定執行到自動化代碼審查的完整指南

    Claude Code Agent Teams:從穩定執行到自動化代碼審查的完整指南

    本文整合三部分內容:(1) Agent Teams 的穩定執行框架;(2) 全局代碼審查規則系統的設計與實施;(3) 自動化雙 Agent 審查機制(架構師 + PM)的完整實現方案。這是一份實踐導向的指南,涵蓋從資源評估、權限配置、到自動觸發流程的所有細節。

    第一部分:Agent Teams 的三層穩定執行框架

    1.1 評估層(Assessment)— 前置資源檢查

    每次建立 Agent Team 前,必須執行三個評估動作:

    1. 記憶體現狀:執行 free -h 或查看 Docker stats,確認可用容量
    2. 計算容量:根據模型選擇計算最大並行 agent 數(opus ~1GB、sonnet ~600MB、haiku ~400MB)
    3. 決策與確認:列出 agent 角色、模型、預估記憶體,取得用戶確認後才建立

    模型選擇口訣

    • 需要「想」 → Opus(架構決策、安全設計、業務邏輯、複雜 SQL、Code Review)
    • 需要「做」 → Sonnet(CRUD 實作、API 對接、測試撰寫、文件撰寫)
    • 需要「找」 → Haiku(檔案掃描、配置對比、API 整合)

    1.2 確認層(Confirmation)— 用戶決策前置

    建立 Team 前,必須向用戶列出清晰的角色定義和資源計劃,包括:

    • 各 agent 的角色名稱與職責
    • 指定的 AI 模型及其預估記憶體
    • 總計容量和系統可用容量
    • 並行數量和預期執行順序

    只有在用戶明確確認後,才啟動 TeamCreate 和後續任務建立。這一步防止了資源耗盡、權限誤配、以及 agent 之間通訊不暢的根本原因。

    1.3 執行層(Staged Execution)— 分階段序列化

    即使資源充足,也不應讓所有 agent 同時轟炸執行。分階段策略包括:

    1. 第 1 階段:啟動基礎設施 agent(如資源管理、環境配置)
    2. 第 2 階段:啟動 researcher agent,進行資訊搜集與分析
    3. 第 3 階段:啟動 architect agent,設計方案
    4. 第 4 階段:啟動 developer agent,進行實作
    5. 第 5 階段:啟動驗證 agent,進行測試與審查

    各階段 agent 完成任務後,主動進入「空閒」狀態並通知團隊。不進行「拉取」操作,而是由前置 agent 完成後才推進下一階段。這種設計確保:

    • 前置依賴滿足後才啟動
    • 消息傳遞清晰,無需輪詢
    • 系統記憶體壓力均勻分散
    • 故障範圍可控,易於除錯

    第二部分:全局代碼審查規則系統架構

    2.1 雙層規則設計

    代碼審查規則分為兩層,確保通用性和專案適應性的平衡:

    • 全局層~/.claude/memory/):所有項目共享的代碼品質標準(SOLID 原則、Design Pattern、代碼異味、測試規範、語言特定規範)
    • 項目層項目/.claude/code-review-rules.md):專案特定的業務邏輯規則、設計稿映射、外部驗證清單

    2.2 全局規則內容結構

    code-review-global-rules.md(SOLID、Pattern、Code Smell、Testing)

    • SOLID 五項原則的定義和違反示例
    • Design Pattern 反面示例(God Object、Feature Envy 等)
    • 代碼異味檢查清單(N+1、Magic Number、過長方法、過多參數、重複代碼、複雜邏輯)
    • 單元測試最低標準(80%+ 覆蓋、邊界情況、Mock vs Real Dependency)

    code-review-languages.md(Java、Python、JavaScript/TypeScript、SQL)

    • 命名規範(類名、方法名、變數名、常數、包名)
    • 包結構約定(分層架構:domain/service/repository/validator 等)
    • 異常處理規範
    • 語言特定工具規範(Lombok、OSGi、Type Hint、Docstring 等)

    code-review-feedback.md(架構師與 PM Agent 職責和對焦框架)

    • 架構師 Agent:SOLID 遵循度(1-5 分)、Design Pattern、Code Smell、測試覆蓋、異常處理、語言規範
    • PM Agent:功能 vs 設計稿對齐、API 返回值、邊界情況、業務邏輯、用戶體驗、外部驗證需求
    • 雙方對焦框架:架構師問「代碼設計能支持你檢查的功能嗎?」,PM 反問「這些功能需求會造成架構問題嗎?」

    code-review-process.md(自動觸發、Agent 角色、聯合報告格式)

    • 觸發點:Task marked as completed
    • Agent 角色 Prompt(初版):架構師評估、PM 評估、聯合對話
    • 聯合報告格式:分離的評估 + 統一優先級排序 (P0/P1/P2)
    • 最終判定:Pass / Needs Work / Fail

    2.3 項目層規則(台灣發票系統範例)

    項目規則分為三類:

    A. 業務邏輯規則(優先級最高)
    • 進項稅計算公式(進項稅金額 = 發票金額 × 5%,DECIMAL(19,2) 向下取整)
    • 三聯式(不含稅)vs 二聯式(含稅)的會計處理邏輯
    • 進項稅折讓的強制申報期限(當期內必須申報,無延後例外)
    • 兼營營業人的比例扣抵公式(可扣抵進項稅 = 總進項稅 × (應稅銷售額 / 總銷售額))
    • 發票號碼連續性檢查和遺失空白發票記錄
    • 發票開立日期 → 申報期間的映射(1-2月→第1期、3-4月→第2期 等,共六期)
    B. 設計稿對齐規則(優先級次之)
    • API 端點的返回格式和欄位定義
    • 邊界情況的預期響應(零金額、負數、超大金額)
    • 數據型態和範圍檢查
    C. 外部驗證清單(優先級最低,但定期更新)
    • 進項稅可扣抵期限是否仍為 10 年
    • 電子發票強制規定的生效狀態
    • 設計稿版本確認
    • 技術規範(iDempiere PO 模型、OSGi Bundle)

    第三部分:自動化雙 Agent 審查機制的實現

    3.1 TaskCompleted Hook 配置

    .claude/settings.local.json 中配置 TaskCompleted Hook,每當任務標記完成時,自動觸發架構師和 PM 兩個 agent 進行深度審查:

    {
      "hooks": {
        "TaskCompleted": [
          {
            "hooks": [
              {
                "type": "agent",
                "prompt": "Conduct comprehensive code review: (1) Architecture: SOLID principles (1-5), design patterns, code smells (P0/P1/P2), testing, exceptions. (2) Functional: spec alignment, API contracts, boundary cases, business logic (Taiwan tax rules). Provide unified P0/P1/P2 priority with Pass/Needs Work/Fail decision and file:line recommendations.",
                "model": "opus",
                "statusMessage": "Running code review on completed task...",
                "timeout": 300
              }
            ]
          }
        ]
      }
    }

    3.2 架構師 Agent 職責細節

    架構師 Agent 按以下維度進行評估,每項 1-5 分自評:

    1. SOLID 原則遵循度:檢查 S(單一職責)、O(開閉)、L(里氏替換)、I(接口隔離)、D(依賴倒轉)五項是否遵循
    2. Design Pattern 應用恰當性:是否應用了合適的設計模式,是否存在過度設計
    3. 代碼異味程度:N+1 查詢、Magic Number、過長方法(>20 行)、過多參數(>3 個)、重複代碼、複雜邏輯(圈複雜度 > 10)
    4. 測試覆蓋度:目標 80%+,是否涵蓋邊界情況(null、empty、max/min)
    5. 異常處理完整性:是否避免過寬泛的異常捕捉,異常信息是否有意義,是否吞掉異常
    6. 語言特定規範遵循度:根據 code-review-languages.md 檢查命名、包結構、工具使用規範

    輸出:各維度評分 + 具體改進建議(標記優先級 P0/P1/P2 和代碼位置)

    3.3 PM Agent 職責細節(含 QA)

    PM Agent 進行務實檢查,確保功能實現和業務邏輯正確性:

    1. 功能 vs 設計稿對齐:設計稿的所有功能點是否實現,是否有範圍蠕動
    2. API 返回值對齐:返回欄位是否與文檔一致,資料型態是否正確,必需欄位是否都有
    3. 邊界情況涵蓋:null 輸入、空集合、最大值/最小值、負數、零值是否處理
    4. 業務邏輯正確性:根據項目規則(進項稅計算、發票號碼、申報期間映射等)是否正確
    5. 用戶體驗:錯誤提示是否清楚,用戶流程是否順暢,是否有令人困惑的行為
    6. 外部驗證需求:是否需要查證業務規定(優先 C)、設計稿(優先 A)、技術規範(優先 B)

    輸出:功能層缺陷清單、QA 項目、待驗證項(註明 C/A/B 優先級)

    3.4 聯合報告與優先級統一排序

    架構師和 PM 分別完成評估後,進行深度對話:

    • 架構師問 PM:「代碼結構能支持你檢查的功能嗎?」
    • PM 反問架構師:「這些功能需求會造成架構問題嗎?」

    基於對話結果,生成聯合報告:

    • P0(Critical):N+1 查詢、安全漏洞、死鎖風險、未處理的邊界情況、違反台灣稅務規則
    • P1(Important):過長方法、重複代碼、Magic Number、缺失測試、不清晰的錯誤提示
    • P2(Nice to Have):輔助方法提取、考慮設計模式、日誌增強

    最終判定

    • Pass:P0 問題 0 個,P1 問題可接受(≤2 個或不影響核心功能)
    • ⚠️ Needs Work:P0 問題 1-3 個,或 P1 問題 >3 個,或測試覆蓋度 <70%
    • Fail:P0 問題 ≥3 個,或安全漏洞,或違反重要法規

    第四部分:審查流程與反覆迭代

    4.1 外部驗證流程

    當 PM Agent 提出待驗證項時,按優先級啟動查詢:

    優先級 C(業務邏輯)— 需人工驗證
    • 用戶透過稅務官網或法規文件進行人工查證(AI 查詢易出錯)
    • 驗證結果更新到項目規則
    • 重新審查涉及的代碼
    優先級 A(設計稿)— 查閱項目文檔
    • 查閱設計文件、API 文檔
    • 如無對應文件,提示用戶補充
    • 確認後更新 code-review-rules.md
    優先級 B(技術規範)— 查詢官方文檔
    • 查詢 iDempiere、OSGi 官方文檔
    • 標記為參考(變動機會低)

    4.2 修改與重審流程

    當報告判定為 Needs Work 或 Fail 時:

    1. 開發者查看報告,收到 P0/P1/P2 改進清單
    2. 開發者修改代碼並完成新測試
    3. 重新標記 Task 為 completed(或手動觸發 /code-review-force)
    4. 自動重審(流程回到架構師 + PM 評估)
    5. 迴圈進行,直到最終判定 Pass

    第五部分:系統集成與迭代計劃

    5.1 全局記憶結構

    所有規則和流程信息保存在用戶的全局記憶庫中:

    • ~/.claude/memory/code-review-global-rules.md — SOLID、Pattern、Code Smell、Testing
    • ~/.claude/memory/code-review-languages.md — Java、Python、JS、SQL 規範
    • ~/.claude/memory/code-review-feedback.md — 架構師/PM 職責與對焦框架
    • ~/.claude/memory/code-review-process.md — 自動觸發、報告格式、判定標準

    5.2 項目級別記憶結構

    • 項目/.claude/code-review-rules.md — 業務邏輯規則 + 設計稿映射 + 外部驗證清單
    • 項目/.claude/settings.local.json — TaskCompleted Hook 配置

    5.3 三個迭代階段

    Phase 1(現在)
    • 建立全局規則知識庫(4 個記憶文件)
    • 編寫項目層規則(code-review-rules.md)
    • 配置 TaskCompleted Hook
    • 在項目中試用審查機制
    Phase 2(2-4 週後)
    • 根據實際審查結果優化規則(哪些規則發現了 bug、哪些規則太寬泛)
    • 改進 Agent Prompt(增加上下文、更清晰的指導)
    • 補充項目層規則細節(特別是邊界情況和特殊規則)
    Phase 3(1-2 月後)
    • 考慮集成到 CI/CD(每次 PR 自動審查)
    • 累積審查報告,形成項目代碼品質歷史
    • 調整 Hook 超時和 Agent 模型選擇

    第六部分:常見問題與實踐建議

    Q1:如果審查花太長時間怎麼辦?

    A:初版 timeout 設為 300 秒。如果超時,可調整為 600 秒,或簡化 Agent Prompt 去掉某些維度。對大型代碼改動,可分成多個小 Task,每個分別審查。

    Q2:外部驗證項目誰負責查證?

    A:初版由用戶或 PM 手動查證(特別是業務邏輯 C 項)。後續可考慮集成更多自動化(如 WebSearch for C 項、文檔連接 for A 項)。

    Q3:PM Agent 如何知道設計稿的內容?

    A:初版需在 code-review-rules.md 的 B 項中維護設計稿摘要(API 返回格式、欄位定義、邊界情況)。後續可考慮直接連接設計文件或 API 文檔鏈接。

    Q4:審查報告輸出到哪裡?

    A:初版直接輸出到對話(用戶可複製保存或導出)。後續可考慮存到 Task comment、Markdown 文件或項目文檔。

    Q5:如何確保 Agent Teams 穩定運行?

    A:遵循三層框架:

    • 評估層:前置資源檢查和確認,不盲目建立 Team
    • 確認層:列出角色、模型、容量,取得用戶確認
    • 執行層:分階段序列化,避免並行轟炸,讓 agent 主動進入空閒狀態而不是被拉取

    以及定期檢查記憶體、監控 agent 通訊、設置合理的超時時間。

    結論

    穩定可信的 Agent Teams 不是靠運氣,而是靠紮實的前置規劃、清晰的資源評估、以及精心設計的執行流程。本文提供的三層框架(評估→確認→分階段執行)確保了 Team 運行的穩定性。配合全局規則庫 + 項目規則 + 自動審查機制,可以建立一套完整的代碼品質保證體系,既有通用性,也有靈活性。

    從 Phase 1 的試用開始,逐步優化規則和 Agent Prompt,經過 2-4 週的實踐,可以達到穩定的審查效果。最終目標是讓代碼審查成為自動化流程的一部分,開發者無需手動申請審查,系統自動評估和反饋,確保每個 Task 完成時都經過架構師和 PM 的雙重把關。