小丁的家

分類: 💻 技術實踐

  • 讓 Claude Code 走企業自管:從直連 Azure Foundry 到 API Gateway

    重點摘要

    • Claude Code 官方原生支援把後端從 Anthropic 訂閱換成雲端供應商,本文走 Azure / Microsoft Foundry 這條,目標是把資料與計費留在公司合規邊界內。
    • 第一階段:用 CLAUDE_CODE_USE_FOUNDRY=1 直連 Foundry 部署的 Claude,含 settings.json、Entra ID 認證、原始 curl。
    • 第二階段:在前面架一個自家 DNS 的 API Gateway,Claude Code 改用 ANTHROPIC_BASE_URL 只打一個入口,Gateway 依 model 欄位路由到後端——這才是企業統一控管的正解。
    • 關鍵觀念:不是每個模型一個網址,而是一個入口、用 body 的 model 名分流。

    為什麼要弄:當 AI 訂閱開始「換軌」

    2026 年起,前沿模型供應商的計費邏輯正在改變:訂閱方案把「互動使用」和「自動化 / Agent 使用」拆成不同的計量池,企業帳號甚至無法直接購買訂閱、只能走 API。對個人開發者這是成本問題;但對企業,真正的痛點是另外兩個字:控管。

    企業導入 AI 編碼工具時,資安與法遵部門會問的第一個問題永遠是:「我們的程式碼與機密,送去哪裡?誰能存取?怎麼稽核?成本怎麼歸戶?」 把 Claude Code 直接接公開 API,這些問題全部無解。解法是讓推論跑在公司自己的雲端租戶裡,資料留在合規邊界內,並在前面架一道統一閘道。本文就是這條路的逐步實戰,從最簡單的直連,進化到可上線的企業架構。延伸閱讀可參考我先前寫的 用 Claude Code Hooks 打造大腦反饋迴路。

    全局:兩個階段

    整條路分兩階段。先讓 Claude Code 直連雲端供應商上的 Claude(證明機制),再把它收斂到自家閘道後面(正式控管)。

    階段一(直連):
  Claude Code  --->  https://<resource>.services.ai.azure.com/anthropic/v1/messages

階段二(閘道):
  Claude Code  --->  https://ai-gw.yourcompany.com/v1/messages  --->  雲端供應商後端
                     (自家 DNS、統一入口、依 model 路由、注入真憑證)

    第一階段:Claude Code 直連雲端 Foundry

    1. 在 Foundry 部署 Claude 模型

    在 Foundry 入口建立資源並部署 base model。三個實務重點,踩過才知道:

    • 地區限定:Claude 模型目前只開放在特定區域(本文撰寫時為 East US 2 與 Sweden Central),選錯區一定部署失敗。
    • 務必接受服務條款:第一次在資源上部署 Claude,後台要建立一個對應的供應商組織(Anthropic Organization)。部署時跳出的 Terms of Service 一定要在「正確登入帳號」狀態下按接受,否則握手失敗。
    • bad-state 陷阱:一旦某次部署握手失敗進入 bad state,該資源就修不好、重部任何模型都會死。正解是建立全新資源,別在壞掉的資源上重試。

    2. 設定 Claude Code(settings.json)

    最乾淨的做法是把環境變數寫進 Claude Code 的 settings.json 的 env 區塊(跨平台、持久,Windows 與 Linux 通用)。檔案位置:Linux 是 ~/.claude/settings.json,Windows 是 %USERPROFILE%\.claude\settings.json。

    {
  "language": "繁體中文",
  "theme": "dark",
  "env": {
    "CLAUDE_CODE_USE_FOUNDRY": "1",
    "ANTHROPIC_FOUNDRY_RESOURCE": "<your-resource-name>",
    "ANTHROPIC_FOUNDRY_API_KEY": "<your-foundry-key-or-omit-for-entra-id>",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "<your-sonnet-deployment-name>",
    "ANTHROPIC_DEFAULT_OPUS_MODEL":   "<your-opus-deployment-name>",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL":  "<your-haiku-deployment-name>"
  }
}

    各變數的意義:

    變數 作用
    CLAUDE_CODE_USE_FOUNDRY設為 1 啟用 Foundry 整合。沒設的話 Claude Code 會走預設的公開 Anthropic API。
    ANTHROPIC_FOUNDRY_RESOURCE你的資源名稱;Claude Code 會自動組成端點 https://<resource>.services.ai.azure.com/anthropic。
    ANTHROPIC_DEFAULT_*_MODEL三個層級(Sonnet/Opus/Haiku)各自的「部署名稱」,不是 model id。注意部署名可能跟 model 名不同(例如同名重建時會自動加序號)。

    重要:ANTHROPIC_DEFAULT_*_MODEL 一定要填「實際部署名」。Claude Code 內部會依當下任務挑層級(主要寫 code 用 Sonnet/Opus,讀檔、摘要等雜活用 Haiku),把對應的部署名塞進請求送出。

    3. 認證:Entra ID(建議)或 API 金鑰

    兩種選擇。企業環境建議 Entra ID:不把金鑰寫進檔案,改用 Azure CLI 的身分,集中式身分管理、適合團隊與 CI/CD。只要在啟動 Claude Code 前登入即可:

    # 方案 A:Entra ID(不放金鑰進檔案,建議)
az login
az account show        # 確認登入到正確訂閱
# 然後在 settings.json 拿掉 ANTHROPIC_FOUNDRY_API_KEY 那行即可

# 方案 B:API 金鑰(快速測試用)
# 直接把金鑰填進 settings.json 的 ANTHROPIC_FOUNDRY_API_KEY

    4. 驗證設定

    啟動 claude,在裡面打 /status,確認 API provider 顯示 Microsoft Foundry、resource 與 model 都正確。啟動橫幅若顯示類似 Sonnet 4.5 · API Usage Billing,代表它走的是 API 計量(雲端供應商),不是訂閱。最後送一句測試訊息,有正常回應就代表端到端打通。

    5. 直接打 Messages API:預設協議就能用

    很多人會問:不能直接用「預設的 Messages API」嗎?能,而且它就是。 Foundry 的端點本來就是標準的 Anthropic Messages API,只是換了網址與認證。跟原生 Anthropic API 只有三點差別:網址不同、model 欄位填「部署名」、認證用 Azure 的方式。以下是兩種認證的原始 curl:

    # 用 API 金鑰(Header 是 x-api-key)
curl -X POST https://<resource>.services.ai.azure.com/anthropic/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: $AZURE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "<your-deployment-name>",
    "max_tokens": 256,
    "messages": [{"role":"user","content":"Hello, which model are you?"}]
  }'

# 用 Entra ID(Header 是 Authorization: Bearer,scope https://ai.azure.com/.default)
curl -X POST https://<resource>.services.ai.azure.com/anthropic/v1/messages \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AZURE_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "<your-deployment-name>",
    "max_tokens": 256,
    "messages": [{"role":"user","content":"Hello, which model are you?"}]
  }'

    6. 一個必知限制:訂閱資格與配額

    有個坑要先知道:Foundry 上的 Claude 通常限定企業等級訂閱(Enterprise / MCA-E),而且非企業訂閱的預設配額可能是 0 RPM / 0 TPM,免費 / 試用 / 純 credit 帳號不支援。意思是——你用個人帳號可以「部署成功」,但真正送推論時可能撞到 0 配額或資格錯誤。這正是企業要在正式的公司訂閱下跑、而不是個人帳號的硬理由。

    第二階段:進化成 API Gateway

    為什麼要 Gateway

    直連能動,但每台機器各自拿著後端憑證、各自直接打雲端——這在企業是不可維護也不安全的。把一道閘道架在中間,你得到一個單一控制點:

    • 統一認證與 RBAC:誰能用、能用哪些模型,集中管理;client 只拿你發的 token,永遠看不到後端真憑證。
    • 稽核與成本歸戶:每一筆請求記 log,依使用者 / 專案歸戶成本。
    • 限流與配額:在閘道做,而不是寄望每個 client 自律。
    • 供應商解耦:哪天要把某個模型從 A 雲換成 B 雲,改閘道就好,幾百台 client 一行都不用動。

    關鍵架構原則:一個入口,依 model 路由

    最容易設計錯的地方:不要做成「Sonnet 一個網址、Opus 另一個網址」。 Claude Code 整個 session 只認一個 base URL,它靠請求 body 裡的 model 欄位區分模型,所有請求都送到同一個入口。所以正確設計是:閘道對外只露一個 DNS 入口,內部再依 model 名稱路由到對應的後端部署。你想像中的「API1 / API2 分流」應該活在閘道後面,對 client 只露一扇門。

    Claude Code 改成 Gateway 模式

    不再用 Foundry 那組變數,改用通用閘道模式。注意 model 這裡填「乾淨的標準名」,讓部署名的映射藏在閘道裡:

    {
  "env": {
    "ANTHROPIC_BASE_URL": "https://ai-gw.yourcompany.com",
    "ANTHROPIC_AUTH_TOKEN": "<gateway-issued-token>",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-5",
    "ANTHROPIC_DEFAULT_OPUS_MODEL":   "claude-opus-4-1",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL":  "claude-haiku-4-5",
    "CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY": "1"
  }
}
    • ANTHROPIC_BASE_URL(通用)取代 CLAUDE_CODE_USE_FOUNDRY;Claude Code 會打 {BASE_URL}/v1/messages。
    • ANTHROPIC_AUTH_TOKEN 會以 Authorization: Bearer 送出(若閘道收 x-api-key,改用 ANTHROPIC_API_KEY)。
    • model 填標準名,閘道內部再對應到實際部署名——client 從此不必知道後端命名怪癖。

    閘道必須遵守的契約

    你的閘道本質是一個 Anthropic Messages API 相容的透傳反向代理。違反任一條,Claude Code 與所有官方 SDK 就打不進去:

    要求 說明
    對外端點 POST /v1/messages選配 /v1/messages/count_tokens、/v1/models(供模型發現)。
    body 原樣透傳收到什麼 Anthropic Messages JSON,就照樣轉發,絕不改 schema。
    支援 SSE streamingstream:true 必須逐塊串回,這是最常翻車的點。
    依 model 欄位路由把標準名映射成對應後端部署名並轉發。
    後端注入真憑證閘道持有後端金鑰 / service principal,client 永遠看不到。
    錯誤碼原樣回429 / 401 / 400 照轉,client 才能正確重試。

    一條封包的端到端追蹤

    把上面串起來,一通 Sonnet 請求與一通 Haiku 請求,打的是同一個網址,只有 body 的 model 不同:

    # Claude Code 做主要工作(Sonnet 層)
POST https://ai-gw.yourcompany.com/v1/messages
Authorization: Bearer <gateway-token>
anthropic-version: 2023-06-01
{"model":"claude-sonnet-4-5","messages":[...],"stream":true}

# Claude Code 做雜活(Haiku 層)-- 網址與 token 一模一樣,只有 model 變
POST https://ai-gw.yourcompany.com/v1/messages
Authorization: Bearer <gateway-token>
{"model":"claude-haiku-4-5","messages":[...]}

# 你的 Gateway 收到後:
#   1) 驗 token + RBAC(這個人 / 這隊能用哪些 model)
#   2) 讀 model 欄位,查路由表:
#        claude-sonnet-4-5 -> 後端部署 "claude-sonnet-4-5-xx"
#        claude-haiku-4-5  -> 後端部署 "claude-haiku-4-5"
#   3) 改寫 model 成真部署名、換上後端真憑證、轉發到雲端
#   4) 後端回標準 Anthropic 回應 -> Gateway 原樣串回 -> Claude Code 收到

    用現成的,別手刻 schema

    別自己發明一套 JSON 格式包起來——那會讓 Claude Code 和所有官方 SDK 全部失效,很多公司「封裝 API」就死在這。直接用支援 Anthropic 相容 + model-based routing 的成熟方案:雲端原生的 API 管理服務(如 Azure API Management)、或開源的 LLM 閘道(如 LiteLLM proxy、Portkey)。它們原生就能做認證、限流、路由與 log。

    常見錯誤與排查

    症狀 原因 / 解法
    Claude Code 一直要你登入 Anthropic沒設 CLAUDE_CODE_USE_FOUNDRY=1,它走了預設公開 API。
    model is not availableANTHROPIC_DEFAULT_*_MODEL 沒對到實際部署名(注意同名重建的序號後綴)。
    401 / 403金鑰錯,或 Entra scope 不是 https://ai.azure.com/.default,或缺 RBAC 角色。
    429 / 0 配額非企業訂閱預設配額為 0;改用企業訂閱或申請配額。
    部署一直 Failed 又刪不掉資源進入 bad state;建新資源,別在壞掉的上面重試。
    經閘道後 streaming 不會動閘道沒正確透傳 SSE;確認 stream:true 的逐塊轉發。

    結語

    這條路的核心其實只有一句話:Foundry 的端點就是標準 Messages API,所以閘道只要當一個透傳代理。 先用直連證明機制能通,再用閘道把它收斂成「單一入口、依 model 路由、注入真憑證」的企業架構——資料留在合規邊界、計費可歸戶、供應商可替換。當前沿模型的使用門檻越來越高,能把它穩穩接進公司治理框架的能力,本身就是一種競爭力。

  • 當 AI 夠重要，價值與風險就是一體兩面：談 AI 治理與 ROI

    重點摘要

    • AI 的 ROI「難算又好算」：別只看表面省工，要看頻率質變——一個分析從「一年做一次」變成「一月一次」，價值是跳級的。
    • ROI 要對到競爭本質與戰略目標，不是中階的過程 KPI。
    • 當 AI 夠重要，它的價值與風險就是一體兩面，這不是缺陷，是事實。
    • 治理心法：讓法遵、風險、業務所有人在同一個平台看同樣的問題與機會，達成共識才放行。
    • 底線是主權 AI：公司的資料不能丟到公開 AI 去訓練。

    這是 SAP NOW AI Tour 系列的最後一篇。前面談了方法論、技術、案例，這篇談一個比技術更難、卻真正決定成敗的東西——AI 治理與 ROI。這天聽下來，最深刻的幾段都不是在講模型多強，而是在講「怎麼算它的價值」和「怎麼管它的風險」。

    一、ROI 難算又好算：關鍵在「頻率質變」

    一位銀行高管分享的 ROI 觀點，我覺得每個要替 AI 專案爭預算的人都該聽。他說 AI 的 ROI「難算，但也好算」。

    難算，是因為一個企業要用 AI 做什麼，沒辦法被量化反推；好算，是因為當 AI 對到「三到五年後的巨大競爭優勢」時，那些成本相對就不是重點。他舉了一個企業信用分析的例子，非常經典：

    一開始算 ROI，是「原本一個人要做 36 小時，AI 降到 3 小時」。聽起來省了工，但因為做的人不多，效益看起來普通。後來他們發現算錯了重點——因為過去要花 36 小時，這個分析一年只能做一次；但 AI 只要 3 小時，就能改成一季一次、甚至一個月一次。頻率一變，質就變了：能提早發現客戶信用變好（多給額度）、或提早發現問題（不用等到明年，中間就預警）。他說：「這對銀行是很大的突破，效益沒辦法估量，因為太大了。」

    這就是頻率質變：真正大的效益，往往不在「同一件事做得更快」，而在「快到可以改變做這件事的頻率」。表面的工時 ROI，會嚴重低估它。

    二、ROI 要對到戰略本質，不是中階 KPI

    承上，他的結論是：AI 專案的 ROI，應該對到「你原本要創造的競爭優勢是什麼」，而不是中階的過程指標。製造業的講者也呼應這點——挑 AI 專案的優先順序，是「越能直接反映客戶需求的越優先」（良率、產出、交期），而不是從內部好做的地方開始。

    另一個容易被低估的效益是潛在損失的避免。一家電子大廠提到，AI 最大的價值往往不是看得到的降本，而是「在第一關就攔截一個品質議題，避免整批損失」——這種效益很難寫進試算表，卻可能是最大的。還有橫向複製：一個廠導入成功，就能複製到二十個廠，效益會放大到難以估算。

    三、價值與風險，是一體兩面

    講到治理，那位銀行高管用了兩個會場引用的軍事 AI 案例，把問題講得很透。同一套 AI 影像辨識系統：

    • 故事一：在任務中辨識出前方的威脅，救了一條人命。
    • 故事二：把一個人手上拿的東西誤判成危險物，造成了無法挽回的誤傷。

    同一個系統，兩個極端。只看故事二，你會想「隔天就把系統關掉」；只看故事一，你會繼續用。他的洞察是：當你的 AI 夠重要，它一定同時帶著高價值與高風險——這是一體兩面，不是哪邊做得不夠好。

    四、治理心法：所有人在同一個平台達共識

    既然價值與風險綁在一起，怎麼管？他的答案很簡單，也很難：讓所有人在同一個平台上。

    以他們銀行為例，法遵、風險、業務人員，都在同樣的平台、看同樣的 AI、同樣的問題與機會。沒有共識，就沒辦法離開那個辦公室——因為一定有人覺得「該關掉」，有人覺得「不能關（關掉會出事）」，必須當場喬到共識。這比任何一份治理文件都實在：把對的人放在同一個畫面前，逼出共識。這也呼應全場另一個反覆出現的觀點——AI 治理的重點，是讓 AI「行為有序」地在企業內運行，而不是放任它亂竄。

    五、底線：主權 AI

    如果說全場有一條最強的暗線，那就是主權 AI（Sovereign AI）——這個詞在不同講者口中至少出現了三次。顧問業引用的調查顯示，超過七成的企業領導者認為「AI 在哪裡開發／運算」是選技術的關鍵考量；製造業強調總部集中算力、守住數位主權；而傳產的設備主管講得最白：

    每個公司都有自己的機密，你不會希望把自己的資料丟到公開的 AI 上去訓練。所以你需要的是主權 AI。

    對製造業、金融業這種高度重視資料的產業，這會是董事會問的第一個問題。所以在選型時，「資料留在哪、誰能存取、會不會被拿去訓練」往往比「模型多聰明」更早被決定。

    結語：難的不是技術，是人與治理

    四篇寫到這裡，剛好繞回系列第一篇的結論：數位轉型 80% 卡在組織與人，不是技術。AI 治理也是同一回事——真正難的，不是把模型接起來，而是怎麼算清楚它的價值、管得住它的風險、讓所有人對它有共識。

    把整個系列濃縮成一句話：AI 降低了工具的門檻，卻抬高了「懂業務、會判斷、守得住治理」的人的價值。工具會越來越好用，但會用工具的人和組織，才是差距所在。

    常見問題 FAQ

    怎麼評估 AI 專案的 ROI 才不會低估？

    別只看「同一件事做得更快」省了多少工時，要看「頻率質變」——當一個分析從一年一次變成一月一次，能提早發現機會與風險，價值是跳級的。ROI 應對到競爭本質，而非中階過程 KPI。

    AI 的價值和風險可以分開管嗎？

    很難。當 AI 夠重要，價值與風險是一體兩面。務實的治理是讓法遵、風險、業務在同一個平台看同樣的問題與機會，達成共識才放行。

    什麼是主權 AI（Sovereign AI）？

    指企業掌握「AI 在哪裡開發、運算，資料由誰存取、會不會被拿去訓練」的主導權。對重視資料的產業，公司機密不丟公開 AI 訓練是底線。

    導入企業 AI，最該先想清楚什麼？

    不是先選模型，而是先想清楚資料主權與治理（資料留在哪、誰能存取），以及這個 AI 要對到的競爭本質。技術反而是相對後面的問題。

    📚 本系列：SAP NOW AI Tour 的 4 堂課

  • 傳產與金融怎麼把 AI 落地？三個真實場景

    重點摘要

    • 鋼鐵廠：讓機器狗進約 1,200°C 的高爐巡檢，並用「設備健康指標像人的健康指標」的概念，做動態預知維護。
    • 銀行：把客戶經理變成 AI Agent，靠「下游的下游有訂單」的線索，搶在同業之前打那通電話。
    • 電子代工：信奉「工廠不是實驗場」，所有試錯與優化先在數位孿生裡跑完，再上實體。
    • 三個產業差很遠，但共通點一致：AI 不是取代人，而是把人從危險、重複、來不及反應的地方解放出來。

    這是 SAP NOW AI Tour 系列的第三篇。前兩篇談方法論與技術骨架，這篇講最好看的部分——真實案例。我挑了三個差異很大的產業（鋼鐵、銀行、電子代工），看他們各自怎麼把 AI 落到地上。為尊重分享者，以下用產業代稱、只引用公開分享的內容。

    一、鋼鐵廠：讓機器狗進 1,200 度的高爐

    鋼鐵是典型的「3K 場域」——危險、骯髒、辛苦，再加上傳產普遍的缺工壓力。這家鋼鐵龍頭的設備部門，把 AI 用在兩個地方，我覺得都很有啟發。

    無人化：機器狗、無人機、無人天車

    高爐的高點，溫度約 1,200°C，爐板一旦出問題可能導致熱點甚至爆炸——這種地方不適合人進去。他們的解法是把巡檢路徑寫成程式，讓機器狗去走、去看，背後的資料庫做預知分析。有人問「機器狗為什麼要練爬樓梯？」講者的回答很妙：人也不是天生會走路，是學會之後才會；機器人往前走要耗大量運算在做平衡，如果目的是去收集數據，那就讓它走遍各種路去練。同樣的思路也用在無人天車上——AI 控制吊掛鋼捲時，左右自動防擺，比人操作還穩。

    設備健康指標，就像人的健康指標

    這是我整天聽到最好的一個比喻。買設備時，廠商會告訴你「多久保養一次」，那是固定規範。但設備用久了會慢慢變化，固定規範不一定適用。講者拿人來類比：

    小孩子量身高、體重、頭圍最重要；到了中老年，身高體重沒太大意義，要量三高。設備也一樣——剛買的設備和用了十年的設備，同一個指標代表的意義完全不同，不能用同一套標準看。

    所以他們用 AI（深度學習模型 + 領域專家的特徵工程）把老師傅的經驗變成「智慧健康指標」，在設備出問題前就抓到初期徵兆。核心一句話：用「數據驅動」取代「直覺或規範」。

    二、銀行：把客戶經理變成 AI Agent

    一家大型銀行的企業金融部門問了自己一個尖銳的問題：我們的服務方式會不會被取代？他們的答案是「會」，所以乾脆自己先動手。

    最精彩的是一個「搶先機」的案例。某個企業客戶可能接到一筆訂單——這種公開資訊大家都看得到。但這家銀行的客戶經理，會在早上收到系統提示：「你可能要去拜訪某客戶。」怎麼知道的？因為系統掌握到這個客戶「下游的下游」可能有訂單，照這個模式推斷它有機會接單，再比對它最近的新聞表現。因為它會接單，就可能有備料與資金需求——於是客戶經理提前打了那通電話。結果是：客戶的財務長第一個接到的，是這家銀行打來的。

    更進一步，他們的想像是把客戶經理本身變成一個常駐客戶端的 AI Agent。一個真人沒辦法一天到晚守在客戶那裡待命，但 AI 可以。背後的技術，就是用前一篇談過的協定，把銀行服務嵌進客戶的 ERP 流程裡。這呼應了一個全場反覆出現的觀點：AI 不是要取代你，而是讓你把「人做不到的覆蓋率」補起來。

    三、電子代工：工廠不是實驗場

    一家全球佈廠的電子代工大廠，分享了他們十多年的 AI 進化。最打動我的，是一句很樸素的話：「工廠是每天在生產運行的地方，並不是給你做實驗的地方。」

    所以他們的核心策略是數位孿生：所有的生產設計、AI Agent 的驗證、流程的優化，都先在虛擬世界裡跑完，再上實體。一個模擬若用實體去做實驗可能要兩個月，在數位孿生裡快很多；而且實體還沒蓋，就能先把問題找出來、把良率拉上去。他們也坦白分享了 Agent 的導入節奏：今年初做了第一個 Agent，到年中大概第八個——剛開始導入比較辛苦，但越往後越快，因為 know-how 會累積。這跟前面銀行、鋼鐵的經驗一致：先做最關鍵的那一個，驗證了再放心擴展。

    結語：三個產業，同一個底層邏輯

    把這三個案例疊在一起，會發現它們其實在講同一件事：

    • 方向一致：都是把人從危險（高爐）、重複（守客戶）、來不及反應（品質與訂單）的地方解放出來。
    • 節奏一致：都先做一個最關鍵的 MVP，驗證了再擴展，沒有人一次性全導入。
    • 對人的定位一致：AI 接手「人做不到或不該做」的部分，人回到判斷與經驗的價值上。

    下一篇是系列最後一篇，談一個比技術更難、卻決定成敗的東西——AI 治理與 ROI：當 AI 夠重要，它的價值與風險就是一體兩面，你該怎麼算、怎麼管？

    常見問題 FAQ

    AI 怎麼用在設備維護上？

    用深度學習模型加上領域專家的特徵工程，把老師傅的經驗變成「智慧健康指標」，在設備出問題前抓到初期徵兆，做動態的預知維護，而不是照固定的保養規範。

    為什麼說「工廠不是實驗場」？

    因為工廠每天都在生產，不能拿來反覆試錯。改用數位孿生，把生產設計、AI 驗證、流程優化先在虛擬世界跑完再上實體，可大幅降低風險與時間。

    AI 會取代客戶經理或第一線人員嗎？

    案例顯示的方向是「補覆蓋率」而非取代：AI Agent 常駐客戶端、處理人力做不到的即時與規模，人則回到判斷、經驗與關係經營的價值上。

    導入 AI Agent 一開始就會很有效率嗎？

    不會。實務經驗是「先苦後快」——第一個最辛苦，隨著 know-how 累積，後面越做越快、效益越來越可觀。建議先做一個最關鍵的 MVP。

    📚 本系列：SAP NOW AI Tour 的 4 堂課

  • AI Agent 怎麼接進企業系統？看懂 MCP 與 A2A 兩個關鍵協定

    重點摘要

    • AI 應用正從「單一模型／聊天機器人」走向 Agentic AI（自主規劃、推理、跨系統行動）。
    • Agentic AI 有兩個關鍵挑戰：Agent 怎麼連接工具？怎麼跟其他 Agent 合作？由此誕生兩個開放協定。
    • MCP（Model Context Protocol）= 垂直整合：讓單一 Agent 往下接工具與資料源。
    • A2A（Agent-to-Agent）= 水平協作：讓多個 Agent 之間互相委派任務。
    • 資料層上，趨勢是「串接而非搬遷」——地端資料可以留在原地，用連接器接上雲端分析。

    這是 SAP NOW AI Tour 系列的第二篇。第一篇談方法論（為什麼轉型會失敗），這篇換上工程師的眼睛，談技術骨架：當大家都在喊 Agentic AI，到底 AI Agent 是怎麼接進一家企業既有的系統？這一整天聽下來，金融、製造、雲端三方不約而同指向同兩個字母組合——MCP 與 A2A。

    一、先看演進：從 Traditional AI 到 Agentic AI

    AI 在企業裡的應用方式，大致經過三個階段：

    1. Traditional AI：單一模型、單一任務（聊天機器人、文件摘要）。
    2. AI chatBot：AI 嵌入應用，輔助人員完成工作。
    3. Agentic AI：AI 自主規劃、推理、行動，並跨系統協作。

    到了第三階段，問題就來了：一個 Agent 要做事，得能呼叫工具、讀寫資料；而真實的企業流程往往要好幾個 Agent 接力。於是兩個關鍵挑戰浮現——Agent 如何連接工具？如何與其他 Agent 合作？

    二、兩個開放協定：MCP 與 A2A

    這兩個挑戰，分別由兩個開放協定來解。它們不是競爭關係，而是互補——一個管「垂直」，一個管「水平」。

    維度 MCP（Model Context Protocol） A2A（Agent-to-Agent）
    連接對象 Agent ↔ 工具／資料源 Agent ↔ Agent（雙向協作）
    整合方向 垂直整合（取用工具） 水平協作（分工委派）
    典型用法 Agent 透過 MCP 存取 ERP 資料庫 / API 一個 Agent 透過 A2A 把任務委派給另一個 Agent

    一句話記憶：MCP 讓 Agent 往下接系統，A2A 讓 Agent 之間互相傳接棒。

    三、實際跨系統流程長怎樣

    會場舉了一個很好懂的端到端流程，看完就知道兩個協定是交替使用的：

    • 採購 Agent 用 MCP 查庫存
    • → 物流 Agent 用 A2A 被委派去安排出貨
    • → 財務 Agent 用 MCP 更新帳務
    • → 完成一條自動化流程

    每個 Agent 用 MCP 往下接自己負責的系統，再用 A2A 把棒子交給下一個 Agent。這就是 Agentic AI「跨系統協作」的具體長相。

    四、資料層：串接，而不是搬遷

    講到 Agent 接資料，現場有個觀眾問了一個很實際的問題：「用 AI 是不是一定要把所有資料都搬上雲？」畢竟資安、上雲成本、地端的第三方系統，都是真實顧慮。

    答案是「不用」。現在的資料雲走的是「串接」而不是「搬遷」——透過連接器（Data Provisioning Agent 這類機制）直接接上地端資料，資料可以留在原地，上層再用 AI 做分析與呈現。對於有資安顧慮、又想用 AI 的企業，這條路很關鍵。一個實際的搭法是：既有系統（ERP／設備系統）→ 連接器 → 雲端的資料模型層（如 Datasphere）+ 報表層（如 SAP Analytics Cloud），最前面再接一層自然語言（Joule），就能「用一句話問、自動跑出分析圖表」。

    五、官方參考架構：把內外 Agent 安全地串起來

    最後一張技術總圖，把上面這些拼成了一個完整的互通架構（這是雲端與 ERP 兩大廠的聯合參考架構）：

    • 企業內部的 Agent（Orchestrator + 各種 Custom／Low-Code／Pro-Code Agent）透過 A2A 跟外部雲端的 Agent 協作；
    • 透過 MCP 接到 ERP、資料雲等既有系統；
    • 身份與信任由統一的 Identity Service 治理（authenticate / trust）。

    值得一提的是，雲端廠在大會上一口氣發布了多項與 ERP 深化整合的東西，包括官方的 MCP Server（讓 AI Agent 透過整合套件安全存取 ERP 商業數據）、支援 ABAP 開發者的 AI IDE，以及基於雲端模型平台的 Agentic AI 方案。換句話說，MCP 已經不是概念，而是有官方實作可以開始試的東西。

    結語：協定先行，骨架才穩

    如果你也在規劃企業內的 AI Agent，這篇的重點只有一個：先把「Agent 怎麼接系統、怎麼互相協作」這層協定想清楚，再談上面要跑什麼應用。MCP 負責垂直、A2A 負責水平，資料層走串接不搬遷，身份治理統一——這就是下一代企業 AI 自動化的骨架。下一篇換個角度，看真實的傳產與金融公司，是怎麼把這套東西落到地上的。

    常見問題 FAQ

    MCP 和 A2A 有什麼差別？

    MCP 是讓單一 Agent 垂直連接工具與資料源（例如存取 ERP 資料庫）；A2A 是讓多個 Agent 之間水平協作、互相委派任務。實際流程裡兩者交替使用。

    用 AI Agent 一定要把資料搬上雲嗎？

    不一定。可以用連接器「串接」地端資料，讓資料留在原地，再由雲端的分析層處理，兼顧資安與成本。

    什麼是 Agentic AI？

    相對於單一任務的傳統 AI 與輔助型的 chatBot，Agentic AI 能自主規劃、推理、行動，並跨多個系統協作完成任務。

    MCP 現在可以實際使用了嗎？

    可以。雲端與 ERP 大廠已推出官方的 MCP Server，讓 AI Agent 透過整合套件安全存取 ERP 商業數據，並有支援開發者的相關工具。

    📚 本系列：SAP NOW AI Tour 的 4 堂課

  • 數位轉型不是換系統：企業 AI 落地為什麼失敗，又該怎麼做對

    重點摘要

    • 麥肯錫研究指出:數位轉型失敗的主因 80% 在「組織與人」，而不是技術。
    • AI 世代的轉型有四大關鍵核心：人員、流程、應用、數據，四者要同步處理，不能只做一個。
    • 轉型有不能跳過的順序：合理化 → 標準化 → 自動化。跳過前段直接自動化，等於把錯的流程加速。
    • 很多企業的「戰情室／儀表板」做完沒人用，是因為它只看落後指標；當員工覺得「自己下載資料用 Excel 更快」，系統就開始死亡。
    • 一句話：數位轉型只是手段，真正的目的是創造價值。

    我參加了一整天的企業 AI 大會，聽了金融、半導體、電子製造、鋼鐵、顧問與雲端平台共六、七家公司分享他們怎麼把 AI 落地。把這些不同產業的經驗放在一起聽，最有趣的發現是：他們講的「成功關鍵」高度一致，而且那個關鍵幾乎都不是技術。這篇是系列第一篇，先談方法論——企業 AI 為什麼會失敗，又該怎麼做對。

    一、先承認：80% 的轉型卡在「人與流程」，不是技術

    會場引用了一份麥肯錫研究：數位轉型失敗的主因在於「組織與人」，而非技術本身。成敗大約 80% 取決於「組織與人」的改變與「方法」的正確性，而「資料」與「內容」是實現價值的核心基石。

    把它拆開來看，組織面的挑戰是：缺乏清晰的轉型願景、組織結構僵化、跨部門協作困難、決策流程緩慢、資源分散。人員面的挑戰是：員工抗拒改變、數位技能不足、人才流失、缺乏主人翁意識、溝通不足導致信任缺失。這些沒有一條是「買哪個 AI 工具」能解的。

    現場有位經營者講得更直接：很多人怕因為跟不上而被淘汰，所以拒絕改變；而真正成功的企業，是想辦法讓「最懂業務的資深人員」被 AI 賦能，而不是被取代。AI 降低了工具門檻，卻抬高了「懂業務、會問對問題」的價值。

    二、四大關鍵核心：人員、流程、應用、數據

    在 AI 世代，數位轉型規劃有四個關鍵核心，每一個都帶著自己的痛點。整理成一張表最清楚：

    核心 三大痛點
    人員 技能隔閡、變革阻力、組織知識流失
    流程 過時流程、跨系統依賴、合規問題
    應用 過度客製、技術債、整合挑戰
    數據 數據孤島、數據品質問題、數據安全與合規

    關鍵在於這四個要同步處理。只把「數據」清乾淨、卻不動「流程」和「人員」，AI 一樣跑不起來；反過來也一樣。多家公司不約而同提到的共通痛點——數據孤島、技術債、缺乏單一真實來源——其實都落在這四個象限裡。

    三、不能跳步：合理化 → 標準化 → 自動化

    一位資深製造業高管分享了一個很樸素但很重要的原則：轉型沒有捷徑，過程必須照順序走——

    1. 先把做事情的順序合理化
    2. 再想辦法標準化
    3. 標準化之後，才能自動化（接著才是 AI）

    為什麼順序這麼重要？因為如果你跳過合理化與標準化、直接自動化，你的標準很可能是錯的——這等於把一個錯的流程加速，是一場無效的轉型。這也呼應了現場另一個觀察：很多人誤以為「拿一個工具來、不需要前面那些步驟，就能把事情做好」，但這從來不會成立。

    對應到角色，轉型會依序需要三種人：BA（業務分析）把現況忠實記錄成流程、SA（系統分析）定義這些需求該用什麼系統滿足、SD（系統設計／開發）實作。順序顛倒，後面全部白做。

    四、為什麼「戰情室」做了沒人用

    一家深耕 SAP 二十多年的整合商，分享了一個我覺得每個做過 BI 專案的人都會心一笑的觀察：傳統的策略支援系統（戰情室、儀表板）會沿著一條曲線慢慢失效。

    階段 作用強度 狀態
    過去 100% 決策利器，報表即時、深受信任
    幾年前 75% 仍具價值，但開始延遲、需人解讀
    現在 40% 內容固定、無法靈活、使用率下降
    不久後 15% 「自己做更快」，轉向替代方案
    未來 5% 報表停更、系統荒廢

    真正的死亡轉折點，發生在「現在 → 不久後」之間：當員工覺得「我自己下載資料、用 Excel 加工更快」，這個系統就開始死亡。幾年後公司又起一個新專案、重做一個新的戰情室，如此不斷循環。

    根因是什麼？傳統戰情室只給你落後指標——告訴你「過去發生了什麼」。但經營者真正面對的世界，不是內部報表，而是外部的快速變化。一句話點破：現在企業經營，最大的風險不在「做錯決策」，而是「太晚知道這世界變了」。所以下一代的決策平台，要從「內部、落後、檢討過去」轉向「外部、領先、預判未來」。

    五、把方法論變成步驟：從經營分析到決策機制

    那實際要怎麼建？現場分享的一套五步驟方法論，把上面這些抽象原則落成了可執行的流程：

    1. 經營分析：先對準企業目標——「企業到底需要什麼」，盤點現有流程與痛點。
    2. 資訊探索：從資料裡看清楚「現在發生了什麼問題、哪些資料必須收集進來」。
    3. 要因分析：用模型與統計方法，找出最重要的影響因子，把它變成你的領先指標。
    4. 建立決策引擎：做出預測模型與預警儀表板。
    5. 形成決策機制：導入流程、教育訓練、持續優化，確保它真的被用起來。

    注意第三步「要因分析」才是重點——找出領先指標，而不是把舊的三十幾個 KPI 再畫一次。如果你做數位轉型時，還是只盯著以前那幾張報表看，那不會從根本改變公司的體質。

    結語：轉型是手段，創造價值才是目的

    麥肯錫、BCG、Gartner 對「數位轉型」的定義各不相同，但他們都強調同一件事：要創造價值。多數公司過於聚焦在前半段的「數位化」（導入工具、優化局部流程、提升效率），結果改善了效率、價值卻有限，難以帶動企業成長。真正的數位轉型，是重新設計商業模式與價值交付。

    所以如果只能記一句話，我會記這句：數位轉型只是手段，真正的目的在於創造價值。工具會越來越好用，但真正的差距，落在你有沒有把流程、資料與人，重新組織成一個 AI 跑得動的樣子。

    這是 SAP NOW AI Tour 系列的第一篇（方法論）。接下來幾篇會談技術骨架（MCP 與 A2A 怎麼讓 AI 接進企業系統）、真實落地案例（傳產與金融怎麼做），以及 AI 治理與 ROI。

    常見問題 FAQ

    數位轉型失敗的最主要原因是什麼？

    根據麥肯錫研究，主因是「組織與人」而非技術，成敗約 80% 取決於組織與人的改變、以及方法的正確性，資料與內容則是實現價值的基石。

    為什麼不能直接導入自動化或 AI？

    因為順序是「合理化 → 標準化 → 自動化」。跳過前面直接自動化，等於把一個還沒理順的錯誤流程加速，是無效的轉型。

    為什麼很多 BI 戰情室做完就沒人用？

    因為它只提供「落後指標」、內容固定難以靈活。當員工覺得自己下載資料用 Excel 更快，使用率就會一路下滑到系統荒廢。解法是轉向外部感知與領先指標。

    數位化和數位轉型有什麼不同？

    數位化偏向導入工具、優化局部流程、提升效率；數位轉型則是重新設計商業模式與價值交付。前者改善效率但價值有限，後者才能驅動企業持續成長。

    📚 本系列：SAP NOW AI Tour 的 4 堂課

  • 從自動化到自主化：SAP NOW AI Tour 座談五觀察

    重點摘要

    • 企業 AI 的競爭，正從「誰的工具快」轉向「誰能把 AI 行為有序地放進流程」——人機協作分成三階段：人在迴圈中、人在迴圈上、人當協調者。
    • 餐飲業者提出務實的加薪邏輯：AI 提升 25% 效能，就把待遇提升 25%（5 人月薪 4 萬 → 4 人月薪 5 萬）。
    • 製造業者的答案是「戰略集中化 + 應用邊緣化」：總部集中算力與資料治理，海外廠用「參數包」無痛複製。
    • 顧問業者強調：真正難被複製的不是單一技術，而是跨產業整合能力；做的不是科技本身，而是改善流程。
    • 平台商的結論：資料不必全部搬上雲（用串接而非搬遷），而成功的關鍵其實是一連串「選擇」。

    這是一場以「企業 AI 如何落地」為題的綜合座談，與談者橫跨餐飲、光電製造、科技集團、顧問與平台商。把五個視角放在一起聽，會發現他們其實在講同一件事的不同切面：AI 正從「自動化」走向「自主化」。以下是我在現場記下的五個觀察。

    一、AI 不是要取代你，而是放大你的價值

    座談一開始就定調：多數與談者都同意，AI 帶來的不是「取代」，而是經營模式的變革。

    餐飲集團董事長講得最直白：「餐飲業的本質不會改變，但 AI 會帶來經營模式的變革。」他認為這個產業「太幸運」——人與人之間有溫度的交流，本來就不會被 AI 取代，反而能被 AI 放大價值。他舉點餐為例：與其讓客人自己滑手機自助點餐，理想場景是 AI 一眼認出常客、知道他的口味偏好，讓不同的服務夥伴也能交付一樣的感動。

    二、餐飲業的加薪邏輯：五成四變四成五

    最讓我記住的一段，是餐飲董事長對「AI 與待遇」的算式。他向董事會、股東、同業溝通的概念叫「五成四變四成五」：

    • 原本 5 個人、平均月薪 4 萬
    • 透過 AI 與科技導入提升效能 → 變成 4 個人、每人平均月薪 5 萬
    • 待遇提升 25%

    他的主張是：如果 AI 能提升夥伴 25% 的效能，就應該把這 25% 回饋到待遇上。對一個長期缺工的產業來說，這不只是成本算式，更是留才與招募的吸引力。而要支撐這件事，背後需要可信賴、精準的底層資訊系統——當門市數量、來客人次累積成海量資料，沒有系統就無法把資料變成更好的經營決策。

    三、製造業的跨國解法：集中化加邊緣化

    光電製造業者面對的是另一種題目：跨國擴張時，如何把品質判斷複製到海外廠？他分享了一個很具體的痛點：光學元件最後常要靠老師傅「目視判斷品味」，這件事很「玄」，而當你要在海外設新廠時，沒有同一批老師傅怎麼辦？

    他們的做法是把老師傅的判斷標準化——用 AI 影像模型即時記錄作業員檢視產品時的角度、停留時間，一旦方式不對就現場提醒。累積資料後做預測與比對，這套機制就能搬到海外廠，降低跨國擴張的品質風險。延伸到組織層級，他畫出一張「未來跨國 AI 頂層設計架構」：

    層級 做法
    戰略集中化 總部建置核心算力，集中治理乾淨的核心資料，對核心智慧財產分級安全管控，守護「數位主權」
    應用邊緣化 海外各廠作為應用端，快速無痛導入由總部打包的微服務「參數包」，把前線操作門檻降到最低

    他用了一句很到位的話收尾：「數據決定智商，治理引領戰略；人才點亮大腦，批判成就卓越。」並提醒：AI 賦能很好，但不能讓所有人各做各的，否則既浪費又有風險——就像飛機機長能在自動駕駛時休息，靠的是「對的系統」，而不是一直手動微調。

    四、整合能力才是護城河

    科技製造集團的代表談「大艦隊」如何協同。他的心法是：AI 不是拿著鎚子到處找釘子——不要看到哪裡就把工具往哪裡敲，而是先找出整個集團最重要的事，再用 AI。

    他們的競爭力主張是：「真正難被複製的，不是單一技術，而是跨產業整合能力。」關鍵在於整合算力、網路、資料、場域與產業 know-how，讓 AI 從「分析工具」進一步成為「營運執行助力」。而支撐這種跨公司、跨事業群整合的，是一套「單一數據真相」。

    顧問業者則把話題拉回本質：「我們要做的不是科技本身，而是怎麼去改善營運、改善業務、改善流程。」他強調關鍵始終在你的資料——先把碎片化的資料匯進系統、治理好，才談得上往上疊應用。對於代理型 AI（Agentic AI）的紅利，他的建議是：資源有限，必須有排序與藍圖，而且「未來是系統整合的世界」，懂業務結構的人，才找得出最適應自己的 AI 應用。

    五、平台商的兩個答案：資料留地端、成功靠選擇

    平台商在觀眾 Q&A 給了兩個很實用的答案。

    問題一：用 AI 一定要把所有資料都搬上雲嗎？

    答案是「不用」。透過資料雲的「串接」機制（而不是把資料整個搬上去），地端資料可以留在原地，上層再用 AI 助理做分析。對於有資安與成本考量、又想用 AI 的企業，這是關鍵的一條路。

    問題二：員工要具備什麼技能、上什麼課才會用？

    最大的差別是：過去要寫程式、做報表再串接，現在這些提示（prompt）已經內建在產品裡——會打字、會用講的，就能用，不太需要特別上課。換句話說，提示工程被產品吸收了，人的價值回到「會問對問題」加上業務判斷。

    而對於「企業如何像自動駕駛一般運作」，平台商的結論很清楚：成功的關鍵在一連串的「選擇」——從哪裡開始、聚什麼團隊、選什麼平台、選哪些流程與資料、找哪些顧問參與。平台本身不是萬靈丹，選對標準流程，AI 才發揮得出來。

    整場的理論收束：人機協作的三階段

    如果要用一張圖總結這場座談，那會是平台商提出的「人類決策 + AI 執行」新運作邏輯。知識圖譜像一個「導遊」，告訴 AI 流程在哪、要取哪個系統、資料在哪；而人與 AI 的協作，會經歷三個階段：

    階段 人的角色
    人在迴圈中（Human-in-the-Loop） 人觸發並監控代理的每個動作
    人在迴圈上（Human-on-the-Loop） 系統觸發代理，人只處理例外
    人當協調者（Human-as-the-Orchestrator） 人退居監督者，跨多個 AI 助理協調指揮

    人從「親自做」走向「監控」、再走向「處理例外」與「協調指揮」——這正是「從自動化到自主化」的具體階梯。而與談者最後那句話，也許是整場最好的註腳：

    人機協作的時代已經來臨——機器不是要取代你，而是你要教會它，如何「行為有序」地在企業內部運行。

    結語：差距落在組織，而不是工具

    回看這五個視角，會發現它們其實在講同一件事的不同切面：方向一致——都指向「AI 從輔助走向自主」；底線一致——資料治理與「讓 AI 行為有序、不亂竄」是所有人的共同前提；對人的重新定位——AI 降低了工具門檻，卻抬高了「懂業務、會問對問題」的價值。

    工具會越來越好用，但真正的差距，落在你有沒有把流程、資料與人，重新組織成一個 AI 跑得動的樣子。

    常見問題 FAQ

    企業導入 AI，一定要把資料全部上雲嗎？

    不一定。可以用資料雲的「串接」機制讓地端資料留在原地，再由上層 AI 做分析，兼顧資安與成本。

    員工要會寫程式才能用企業 AI 嗎？

    多數情況不用。提示（prompt）已內建在產品裡，會用自然語言（打字或講話）就能操作；價值回到「會問對問題」與業務判斷。

    「從自動化到自主化」具體是什麼意思？

    指人機協作的演進：人在迴圈中（觸發監控）→ 人在迴圈上（只處理例外）→ 人當協調者（指揮多個 AI 助理）。

    跨國企業怎麼把 AI 能力複製到海外廠？

    一種做法是「戰略集中化 + 應用邊緣化」：總部集中算力與資料治理，海外廠用標準化的「參數包」快速導入。

  • 讓 AI 不再失憶:用 Claude Code Hooks 打造大腦反饋迴路

    重點摘要

    • LLM 最大的弱點是會忘:session 結束或 context 被壓縮後,這次學到的教訓就蒸發了。
    • 解法是把「教訓」外接到持久的 腦子系統(brain/*.md),並用 hooks 在關鍵時刻強迫寫入。
    • 5 支 hook 腳本在三個點攔截:fix commit 發生時、context 壓縮前、session 結束時。
    • 另一支 hook 負責身份錨定,防止 /compact 後 AI 角色崩潰。

    大型語言模型最致命的弱點,不是不夠聰明,而是會失憶。每一次對話結束,或是上下文(context)被壓縮(compaction)以節省 token,這一輪辛苦學到的教訓——某個 bug 的根因、某個 API 的雷點——就跟著蒸發,下一次又從零開始,甚至重踩同一個坑。

    我在 Claude Code 上的解法,是一套「harness × 腦子系統」的反饋迴路:用幾支 Bash hook 腳本當感測器,在 AI 即將遺忘的關鍵點上攔截,強迫它把這次的教訓寫進持久的 brain 檔。這篇拆解它為什麼需要、每支腳本做了什麼、以及它怎麼跟腦子系統搭配。

    為什麼需要這套東西?LLM 的三個結構性缺陷

    這套設計不是為了炫技,而是針對 LLM 的三個無法靠「更大模型」解決的缺陷:

    • 沒有長期記憶:模型權重是凍結的,單次對話的學習不會留存。→ 需要一個外部、持久的記憶體(brain 檔)。
    • 記憶會被壓縮清除:對話一長,context 就會被 compaction 截斷,早期內容直接消失。→ 需要在壓縮之前把該留的留下來。
    • 會角色漂移(role drift):尤其在壓縮後,AI 可能忘記自己是誰、該做什麼。→ 需要定期重新錨定身份。

    關鍵洞察是:光靠「提醒 AI 要記得寫筆記」沒用,因為它會說「好的我等下寫」然後就忘了。必須把它做成系統層級的強制關卡(gate)——由 harness 在固定時機自動觸發,而不是仰賴 AI 的自律。

    一張圖看懂:harness 感測器迴路

    🤖 Claude Code Session(工作中)
    做事 → git commit -m "fix: ..." ↓
    ⚡ HARNESS 感測器層(hooks 自動觸發)
    ① 發生時 · PostToolUse
    fix-detect.sh
    偵測到 fix: commit → 注入:
    「現在去更新 brain,不准做下一件事」
    ② 遺忘前 · PreCompact
    precompact.sh
    壓縮前掃最近 5 個 commit →
    「記憶要被清除了,brain 寫了嗎?」
    ③ 離開時 · Stop
    stop-check.sh
    比對 fix commit vs brain 修改時間 →
    有 fix 卻 0 更新 = 警告
    ↓ 強制寫入教訓
    🧠 腦子系統 · brain/*.md(37 個領域檔,持久)
    – [source: 專案名] 哪裡踩坑、怎麼修的
    ↺ 下次 SessionStart 載入 MEMORY.md 索引 → 知識回到 AI,不再從零開始

    三個攔截點:守住 fix commit 的整個生命週期

    這套機制最聰明的地方,是它不靠單一檢查點,而是沿著「一個教訓從產生到消失」的時間軸,設了三道關卡。每一道都是一支獨立的 Bash 腳本,讀 Claude Code 透過 stdin 餵進來的 JSON,再輸出一段 additionalContext 回去改變 AI 的下一步行為。

    時機(Hook) 腳本 做什麼
    PostToolUse(每次 Bash 後)fix-detect.sh解析 git commit 訊息,若是 fix: 開頭,注入硬性要求:讀對應 brain 檔、追加教訓、更新前不准進行下一個任務
    PreCompact(壓縮前)precompact.sh掃描最近 5 個 commit 找 fix:,在 context 被清除前做最後提醒:「該寫的寫了嗎?現在不寫就來不及了」
    Stop(session 結束)stop-check.sh統計今天的 fix: commit 數,對比 brain 檔有沒有被更新過;有修 bug 卻沒留筆記,就丟出「知識可能流失」的警告

    三個點分別對應人(或 AI)會偷懶的三個藉口:「等下再寫」(被①擋下)、「我忘了還沒寫」(被②救回)、「這次算了吧」(被③抓出來)。

    一個巧妙的無狀態設計:時間戳 + mtime 比對

    怎麼知道「這個 session 到底有沒有動過 brain」?這裡用了一個很輕量、不需要資料庫的技巧,由兩支腳本配合:

    • SessionStart 時,session-start.sh 只做一件事:touch /tmp/.claude-session-start,在檔案系統上插一根時間戳基準線。
    • Stop 時,stop-check.sh 用 find BRAIN_DIR -newer /tmp/.claude-session-start 數出「比這根基準線更新的 brain 檔」有幾個。

    0 個,代表這次 session 完全沒碰 brain。用檔案的 mtime 當狀態,既不用記資料庫、也跨工具通用——這是 Unix 哲學的漂亮應用。

    另一種 hook 用途:身份錨定,防止角色崩潰

    hook 不只用來餵記憶,也能用來穩住 AI 的身份。我跑過一個多 agent 的評測 harness,其中一個 session 擔任「Driver(駕駛)」——負責呼叫 orchestrator、讀結果、寫總結;另一批 agent 才是「被測團隊」。問題是:一次 /compact 之後,Driver 角色崩潰了,退化成被測團隊,開始自己回答原本該交給被測 agent 的技術題。

    修法是一支 SessionStart hook:當工作目錄落在該專案內,就注入一段「身份錨定」context,白紙黑字提醒——你是 Driver、不是被測團隊、遇到這些題目只能呼叫 orchestrator 而不是自己答。每次啟動(含 compact 後的重啟)都重貼一次,把漂移的角色拉回來。這是「context injection 對抗 LLM drift」的典型手法。

    它跟腦子系統的搭配:三層分工

    把整套東西攤開,其實是三層各司其職,像生物的神經系統:

    層 對應 角色
    Hooks神經反射自動、不經思考,在固定時機觸發,負責「執行紀律」
    Brain 檔長期記憶持久儲存踩過的坑與教訓,跨 session、跨專案可讀
    CLAUDE.md價值觀 / 規則每次 session 載入,定義「該怎麼做事」的原則

    Hooks 的唯一使命,就是確保「經驗 → 長期記憶」這條路徑不會因為 AI 的健忘或偷懶而斷掉。Brain 負責存、CLAUDE.md 負責規範,而 Hooks 負責在對的時間點逼著迴路閉合。三者缺一,知識就會慢慢漏光。

    設計哲學:為什麼是「強制關卡」而不是「溫柔提醒」?

    因為知識的衰減是無聲的。沒人會在當下感覺到「我剛剛流失了一條教訓」,只會在三個月後重踩同一個坑時才後悔。溫柔的提醒對抗不了這種無聲衰減——它需要的是一個會在你想跳過時擋在路中間的系統。借別人(與過去的自己)之手學坑,而不是真的每個坑都親自踩一次,這才是把 AI 從「強力的金魚」變成「會累積的夥伴」的關鍵。

    (這套 domain brain 的概念我有開源一份骨架,有興趣可以參考延伸。)

  • Claude Code 換腦記:雲端便宜但要未雨綢繆,5 萬內路徑

    重點摘要

    • Claude Code 是「身體」(agent loop、tool use、MCP),模型是「腦子」,claude-code-router(ccswitch)是「神經接口」,把腦子接上身體。
    • 雲端 LLM 現在真的便宜:DeepSeek V3.2 每百萬 token USD 0.28/0.42,SWE-bench Verified 72-74%,夠用 80% 場景。不需要為了省錢買硬體。
    • 但 Anthropic 改價、限額、ToS 變動隨時可能 — 未雨綢繆有必要,可是不要花過頭。5 萬內買「合理保險」夠了。
    • 10 萬內 3 條路徑:0 元全雲端(屁股電腦 + cheap API)、3 萬二手 GPU、5 萬 RTX 5070 Ti。20+ 萬路徑(RTX 5090 + Mac Studio Ultra)完全不必要。
    • 腦子可以換,工具不能綁架你 — 也不要綁架你家庭預算。

    為什麼要換腦:Claude Code 框架真好用,但要有「萬一」準備

    Claude Code 提供的是身體 + 技能:agent loop、tool use、Bash 執行、MCP server 接入、檔案編輯、git 操作、subagent 派遣。這套框架成熟、穩定、文件齊。問題只有一個:底層腦子綁死在 Anthropic API。

    講真的,2026 年雲端 LLM 費用真的便宜。Claude Max USD 100/月、DeepSeek V3.2 一百萬 token 不到 USD 0.5,單看價格就是時代最佳。多數人現階段「為了省錢花 20 萬買 RTX 5090」算式根本算不過來:5 萬月 API 成本 × 80 個月 = 6 年半才回本,而 6 年半後 RTX 7090 都出來了。

    但「便宜」不等於「無風險」。Anthropic 可以隨時改價、限額、deprecate model、改 ToS、加區域限制、政策性下架。「便宜」是現在的事實,「能用」是對方願意的事實。未雨綢繆 = 確保「對方變心」的那天不會讓我停工。

    這篇講的是合理保險:用 5 萬內的預算建立 fallback,不是為了省錢、不是為了完全自主、不是為了跑分追 frontier。只是讓你睡得安穩。

    神經接口:claude-code-router 是什麼,怎麼把腦子接上身體

    claude-code-router(社群稱 ccswitch)是一個 proxy gateway,綁在 localhost:3456。Claude Code 原本打到 Anthropic API 的請求,router 攔截下來、轉換格式、路由到你指定的後端(OpenRouter / DeepSeek / Ollama / Gemini / Volcengine / SiliconFlow)。[GitHub: musistudio/claude-code-router]

    核心能力 3 個:

    • Transformer:把 Anthropic API request schema 轉換成 OpenAI / Ollama 格式,模型不用知道對方是誰
    • 動態切換:聊天中用 /model 指令切後端,不重啟
    • 路由策略:根據 task 類型自動派模型(重任務 → Claude Opus、background → DeepSeek、本地 → Qwen3-Coder)

    實際省錢幅度:[Cut Claude Code Bill 90%] 給的數字是 50-90%,看路由邏輯激進程度。但對保留 Claude Max 訂閱的人,router 真正的價值不是省錢,是削峰 — 把 subagent / background 派出去,Claude Max 的 weekly quota 留給真正需要 Opus 的任務,永不撞 lockout。

    腦子替換的 3 種劑量

    劑量 A:全雲端腦(0 元入場)⭐ 我推這個

    router 把全部請求(或除主對話外的全部)丟到便宜 cloud API(DeepSeek V3.2 / Qwen3-Coder API)。本機完全不用裝模型,連 Ollama 都不裝。屁股電腦完美參與 — 它只負責跑 Claude Code 跟 router 本身,推理在雲端。

    適合:多數人。除非你有商業機密 / air-gapped 需求,沒理由花硬體錢。

    劑量 B:半雲半本地

    本地裝中型模型(Qwen3-Coder-30B-A3B 或 Gemma 3 12B)跑 background / 重複性任務,雲端跑重活。需要至少一張 12-16GB VRAM 的 GPU。

    適合:日常 coding 主力 + 想壓 API bill 到極致 + 願意花 3-5 萬硬體錢做「保險」。

    劑量 C:全本地腦(本文不推)

    本地跑 Kimi K2.6(1T MoE)或 DeepSeek V3.2(671B),完全不打雲端。但需要 Mac Studio M4 Ultra 256GB(NT$ 35 萬起)。對 99% 開發者而言不划算 — 不在本文 5 萬內預算範圍。

    5 萬內的 3 條路徑(具體 part list)

    路徑 1:NT$ 0(全雲端 + 屁股電腦)

    項目 內容 成本
    機器 手邊任何能跑 Node 20 的機器(屁股電腦 / Mini PC / 舊筆電都行) NT$ 0
    claude-code-router npm install -g @musistudio/claude-code-router 免費
    DeepSeek API 帳號 platform.deepseek.com 註冊,買 USD 5 預付 NT$ 150 起
    月用量(中度開發者) DeepSeek V3.2 USD 0.28/M input, USD 0.42/M output NT$ 500-3,000

    這條路最被低估。多數人以為「本地模型」=「沒網路也能跑」,但實際 90% 場景你有網路,DeepSeek API 比自己跑本地 30B 還快還準。0 硬體成本 + 月 USD 5-15 = 跟 Claude 訂閱比省 70-90%,而且性能 80% 場景夠用。

    路徑 2:NT$ 1.5 萬(二手 GPU 試水溫)

    Part 規格 NT$
    二手 RTX 3060 12GB PTT / 露天 / 蝦皮二手 8,000-10,000
    PSU 升級到 650W 確保 GPU 供電 3,000
    機殼 / 風扇 散熱 1,500
    合計 — ~15,000

    可跑:Qwen3-Coder-Next(3B active,記憶體吃 ~6GB)、Gemma 3 12B Q4、DeepSeek-R1-Distill-Qwen-14B Q4。40-60 tokens/sec,互動體驗已過 30 t/s 的「跟 cloud 無感」門檻。[Best GPU for Local LLMs 2026]

    適合:「想玩本地但不想砸大錢」。1.5 萬投資 = 大約 30 個月 DeepSeek API 用量,只在你**確實會用本地** + 想實驗的前提下划算。

    路徑 3:NT$ 5 萬(RTX 5070 Ti 16GB 改現有桌機)⭐ 認真做本地的甜蜜點

    Part 規格 NT$
    RTX 5070 Ti 16GB(新) 2026 最佳 CP 值 LLM 卡 28,000-32,000
    PSU 850W 5070 Ti 需 750W+ 5,000
    RAM 加到 64GB DDR4 / DDR5 雙通道 6,000
    NVMe 2TB 模型 / GGUF 存放 5,000
    合計 — ~48,000

    可跑:Qwen3-Coder-30B-A3B(MoE,VRAM 吃 ~14GB),80-120 t/s 飛快。已能應付日常主力 coding,Claude API 退到 background 角色(複雜重構 / 跨檔分析才用)。

    適合:真的認真做本地化 + 有現有桌機可以裝顯卡 + 5 萬預算的人。這條路在 2026 中是「合理保險」最高 CP 值的點。

    為什麼不砸 20+ 萬?算給你看

    很多「玩 LLM」社群推的是 RTX 5090(NT$ 12-15 萬)或 Mac Studio M4 Ultra 256GB(NT$ 35 萬+)。對 99% 開發者而言,這算式根本算不過來。

    配置 硬體投入 月省 (vs Claude USD 100) 回本年數 折舊風險
    路徑 1(全雲端) NT$ 0 USD 80-95 立刻省 無
    路徑 2(NT$ 1.5 萬) NT$ 15,000 USD 80-90 5-6 個月 低(二手 3060 殘值高)
    路徑 3(NT$ 5 萬) NT$ 48,000 USD 80-100 14-16 個月 中(2 年後 RTX 6070 上市)
    RTX 5090 機(NT$ 23 萬) NT$ 230,000 USD 100(只是不付訂閱) 76 個月 / 6.3 年 高
    Mac Studio M4 Ultra(NT$ 40 萬) NT$ 400,000 USD 100 133 個月 / 11 年 超高

    RTX 5090 機 6.3 年才回本,但 6 年後 RTX 8090 都出來了,你的 5090 殘值剩 30%。Mac Studio Ultra 11 年回本,11 年後 Apple Silicon 已經換了 4 代。

    「未雨綢繆」≠「為了不可能發生的事過度準備」。Anthropic 真的明天倒了,你也能在 5 萬路徑下半天內切到本地 — 那才是「合理保險」。砸 20 萬給「我擔心 Anthropic 變心」,是恐懼定價,不是工程。

    4 個本地腦子怎麼選(為什麼不一定要追 frontier)

    模型 Release 規模 SWE-bench 適合誰
    Qwen3-Coder-Next 2026/02 80B MoE / 3B active SOTA local 5 萬路徑首選 ⭐
    Kimi K2.6 2026/04/20 1T MoE SWE-Bench Pro 58.6% 贏 Opus 4.6 需 Mac Studio Ultra,不在本文範圍
    DeepSeek V3.2 2026/Q1 671B MoE SWE-bench Verified 72-74% 用 API 最划算(自己跑要 256GB RAM)
    Gemma 4 2026/04 多 size — Apache 2.0 純開源、小機器友善(路徑 2 OK)

    來源:[Qwen3-Coder GitHub]、[Kimi K2.6 完整指南]、[DeepSeek 完整指南]、[Gemma releases]

    關鍵判斷:不要追 frontier。Kimi K2.6 跑分贏 Opus 4.6 沒錯,但要 256GB RAM 的 Mac Studio Ultra 才跑得動 = 40 萬硬體。對 5 萬內預算而言,Qwen3-Coder-30B-A3B(30B 規模、3B active MoE,16GB VRAM 就跑得起)已經滿足 80% 場景。剩下 20% 的硬任務丟回 Claude 用 router 解決。

    ccswitch 路由策略:哪個腦子接什麼活

    1. Heavy(複雜重構、跨檔架構分析、安全 review)→ Claude Opus 4.7(API 或 Max 訂閱)
    2. Medium(一般 coding、debug、寫 test)→ DeepSeek V3.2(API)或 Qwen3-Coder-30B(本地,僅路徑 3)
    3. Light(格式整理、改 typo、寫 commit message、跑 lint)→ 本地 Gemma 3 12B(路徑 3)或最便宜 cloud(DeepSeek background tier)
    4. Background(自動產生 README、批次重命名、log 摘要)→ 本地小模型或 DeepSeek,跑多久都不心疼

    router config 範例:

    {
  "providers": {
    "claude": { "type": "anthropic", "apiKey": "$ANTHROPIC_KEY" },
    "deepseek": { "type": "openai", "baseUrl": "https://api.deepseek.com" },
    "qwen-local": { "type": "ollama", "baseUrl": "http://localhost:11434" }
  },
  "routes": [
    { "match": { "complexity": "heavy" }, "provider": "claude", "model": "claude-opus-4-7" },
    { "match": { "complexity": "medium" }, "provider": "deepseek", "model": "deepseek-chat" },
    { "match": { "complexity": "light" }, "provider": "qwen-local", "model": "qwen3-coder:30b" }
  ]
}

    實際省下來的成本:[Claude Code Router 完整 2026 指南] 給的數字是月 API bill 從 USD 200 降到 USD 30-50。如果你保留 Claude Max 訂閱,把 subagent / background 路由出去,可以避免撞 weekly quota lockout,實質效益就是 「有效用量翻 2 倍」。

    屁股電腦改造案例:32GB RAM + Ryzen 7 4700U 怎麼玩

    我自己手上的 Mini PC:AMD Ryzen 7 4700U(8 cores)、32GB RAM、無獨立 GPU、Linux Mint。前面查過所有資料,這台機器在 2026 的真實處境是:

    • ❌ 30B+ 模型完全跑不動(無 GPU + RAM 不夠)
    • ⚠️ 7B Q4 可跑但 ~3-5 t/s,慢到不能互動
    • ✅ Gemma 3 1B-4B 可跑但太弱,agent 任務跑不完

    結論:路徑 1(全雲端)最 fit 我的場景:

    1. 裝 claude-code-router(5 分鐘)
    2. 申請 DeepSeek API(10 分鐘,USD 5 預付)
    3. router config 把 medium / light 全部 route 到 DeepSeek V3.2
    4. Heavy 留給 Claude(Max 訂閱 或 API pay-per-token)
    5. Mini PC 繼續扛 Claude Code + router process,VRAM 無關緊要

    月成本估:USD 15-30(NT$ 500-1,000)。跟新組 RTX 5070 Ti 桌機(NT$ 5 萬)比,4-8 年才回本。所以路徑 1 是我目前最 fit 的路徑 — 不是因為我堅持本地化,是因為「本地化」對我來說是未來的選項,不是現在的剛需。

    真話:不要為了「本地化迷思」花錢,但也不要裸奔

    很多人買 RTX 5090 是為了「資料安全 / 不依賴雲端 / 終究有一天用得到」。實際統計:

    • 「資料安全」→ 99% 場景你的 code 在 GitHub public repo / company 內部 repo,傳給 DeepSeek 沒比較危險
    • 「不依賴雲端」→ 你每天還是上 Stack Overflow、Google 搜文檔,雲端依賴沒消失
    • 「終究會用」→ 通常買了之後跑兩週就放著積灰塵,1 年後折舊損失 30%+

    真正該本地化的場景:商業機密、air-gapped 環境、隱私法規(GDPR / HIPAA)。個人 / 中小團隊 dev workflow 不在這個 list 內。

    但「不要過度準備」≠「不準備」。裝 router 是免費的,就算現在全部 route 給 Anthropic,哪天它變心,你只要改 config 就能切。5 分鐘的事,沒理由不做。這才是真正的「未雨綢繆」:架構靈活、邊際成本接近 0,而不是花 20 萬買「萬一」。

    結尾:腦子可以換,工具不能綁架你 — 也不要綁架你家庭預算

    claude-code-router 的真正價值不在「省錢」,是主權。Anthropic 改價、改 ToS、deprecate model,你不用跟著它的節奏走。換腦只是動作,背後是 ownership 的姿勢:你選你信任的模型、你決定路由邏輯、你不被任何單一廠商綁架。

    具體建議按你場景:

    • 偶爾用 / 屁股電腦 / 預算 0:路徑 1(全雲端 + DeepSeek API + 5 分鐘 router setup)
    • 想玩本地但不確定會不會堅持:路徑 2(NT$ 1.5 萬二手 RTX 3060)
    • 真認真做本地化 + 有現有桌機:路徑 3(NT$ 5 萬 RTX 5070 Ti)
    • RTX 5090 / Mac Studio Ultra(20+ 萬):除非有商業機密 / air-gapped 需求,否則 6-11 年回本算式不划算,不推

    不為了「本地化迷思」花錢。留錢給你該花的地方 — 可能是更好的螢幕、更好的椅子、家人的長照、孩子的教育、未來的不確定性。Claude Code 是工具,換腦只是技術選擇,你才是 own 自己工作流的人 — 也是 own 自己家庭預算的人。

  • 跟 AI 寫程式的 15 條軟工紀律 — 用一條真實對話從頭拆解

    重點摘要

    • 常聽到「跟 AI 寫程式需要軟工基礎」,但具體是哪些?本文用前一篇 Opus 4.8 Workflow 實測那條真實對話從頭拆,對照 15 條經典軟工紀律。
    • 盤點結果:做到 9 條 / 部分做到 1 條 / 沒做 5 條。每條都有對話證據引用,沒做的給可執行 action。
    • 15 條按高 leverage 排序前 5 名:驗證紀律、正交分解、真實基準、focused review、文檔作為下個 session 輸入。這 5 條沒守,其他都白搭。
    • 結論:跟 AI 寫程式需要的不是「新的軟工」,而是把舊軟工套到 stateless / non-deterministic / 訓練截止 / 高並發 4 個 AI 特性上的對應方法。

    為什麼問這題

    「跟 AI 寫程式需要軟工基礎」這句話傳得很廣,但講細節的人少。多數人講出來的不是軟工,是 prompt engineering tricks(怎麼下 prompt、怎麼用 chain-of-thought)— 那叫 LLM 使用技巧,不叫軟工。

    真正的軟工基礎是從 1970 年代 SWEBOK 累積到今天的工程紀律:specification、verification、separation of concerns、observability 那些。問題是這些紀律最初是針對「人寫 code、人 review、人交接」設計的,套到「AI 寫 code、人 review」會不會失效?哪些反而更重要?

    本文不假設,用一條真實對話實證:5/29 我跟 Claude Opus 4.8 跑 Home123 backend 的 109 個 GraphQL resolver authz pattern audit 對照實驗,從頭到尾大約 8 輪對話、~50 分鐘。把這條對話拆解,對照 15 條經典軟工紀律,看真實場景下到底用到了哪些、漏了哪些。

    15 條紀律的分類框架

    從經典軟工教材(《Code Complete》、《Pragmatic Programmer》、SWEBOK Guide)抽出 15 條跟 AI 協作最相關的紀律,分 4 群:

    類別 條目 經典 reference
    核心驗證#1 驗證紀律、#13 根因分析、#7 回顧TDD / Postmortem culture / Code Complete §22
    設計分解#2 正交分解、#8 規格先於實作、#9 權衡分析、#14 錯誤處理哲學Dijkstra SoC / Spec-first / Pragmatic Programmer Ch.4
    過程紀律#3 真實基準、#5 focused review、#6 並行執行、#10 預設驗收標準、#12 預算控管Performance Engineering / Code Review SOP / Agile
    知識持久化#4 文檔作為輸入、#11 可重跑、#15 版本控制ADR / Reproducible Research / Git workflow

    下面逐條拆。每條格式統一:定義 → 經典出處 → 你做了沒 → 證據或補救 → 對 AI 協作的特別意義。

    #1 驗證紀律 (Verification Discipline)

    定義:任何宣稱(claim)都要靠可重現的證據才能信。
    經典出處:Steve McConnell《Code Complete》§22 The Twelve-Step Programming Process、TDD 的 Red-Green-Refactor 第一步、Cynefin framework 的 probe-sense-respond。

    本次對話做了沒:✅ 做了,多次。

    對話證據:

    「幫我讀書 https://www.anthropic.com/news/claude-opus-4-8」
    → 不接受 AI 憑記憶,要 AI 去 web 抓。

    「今天已經是5/29了 你的日期有問題」
    → 即時校正環境假設,不讓我繼續用錯日期。

    「我正在運作 你看一下」
    → 不接受我講的文字總結,要看 ps / pstree / jsonl 真實 OS 訊號。

    對 AI 協作的特別意義:AI 的訓練資料有 cutoff(我的是 2026 年 1 月)。你問跟 cutoff 之後的事(Opus 4.8 是 5/28 發佈),我用「記憶」回答就是瞎掰 — 而且會用流暢的口氣瞎掰,不像人類會猶豫。強制 AI 查資料這個動作,等於把 AI 從「自信的 LLM」拉回「會用工具的執行者」。這條 baseline 沒守,後面 14 條全變空談,因為起手第一個 claim 就錯了。

    #2 正交分解 (Separation of Concerns)

    定義:一個議題只談一個軸線,軸線之間不混。
    經典出處:Dijkstra 1974《On the role of scientific thought》、Parnas 1972 information hiding、UNIX philosophy 的 “do one thing well”。

    本次對話做了沒:✅ 做了,而且是教科書級。

    對話證據:

    「首先 看起來除了MODEL 還有 EFFORT
    同樣是SONNET 還可以有HIGH XHIGH?
    WORKFLOW 我要怎麼去用?」

    三個正交軸線(Model / Effort / Workflow)分開問。對照組是新手會問「給我最好的設定」— 等於要 AI 替你在多維空間做加總決策,你拿到答案也不知道為什麼。

    對 AI 協作的特別意義:AI 處理 bundled question 會發生兩種失敗:(1) 只回最顯眼那條,其他偷偷漏掉;(2) 強行給一個整合答案,但每個軸線都妥協。你下意識把 3 軸拆開,等於逼 AI 逐個 expose,你才能照自己的 context 做選擇。這對應的軟工原則是「不讓抽象漏掉」(don’t leak the abstraction)的反向應用:你拒絕 AI 把抽象漏掉。

    #3 真實基準 (Representative Benchmarks)

    定義:評估新工具用真實場景,不用 toy example。
    經典出處:John Hennessy / David Patterson《Computer Architecture》§1.8 Fallacies and Pitfalls(benchmark 永遠騙人)、SPEC CPU 為什麼要 update、ML 領域 distribution shift 一整條研究線。

    本次對話做了沒:✅ 做了,而且是本次對話最關鍵的一個動作。

    對話證據:

    「好 你現在用HOME123 專案 做一個測試循環 然後用你的WORKFLOW試試看 記錄下來差異」

    不要 toy 不要 hello-world,直接拿 Home123 的 109 個 production resolver。這個動作直接決定了實驗結論的可信度。

    對 AI 協作的特別意義:80% 的「新 AI 工具評測」文章用合成 case(leetcode-style problems),結論毫無遷移性。Anthropic 自家 4.8 release notes 用的也是 SWE-bench、Terminal-Bench 這種「合成的真實」 — 不是任何一家公司的 production codebase。你直接拿 109 個 real resolver 來測,workflow 暴露出來的問題(主 orchestrator 抓到 synthesis agent 算錯 83 vs 109)在合成 case 上看不到,因為合成 case 沒那麼大、catch 不到 emergent behavior。這個動作的工程價值比你的 prompt 內容更高。

    #4 文檔作為下個 Session 輸入 (Documentation as Next-Session Input)

    定義:寫文件不是給未來的人看,是給未來的 stateless agent 看,作為下次 conversation 的可讀輸入。
    經典出處:Architecture Decision Records (ADR, Michael Nygard 2011)、SREbook 的 runbook 文化、Reproducible Research 運動(Donald Knuth literate programming 的延伸)。

    本次對話做了沒:✅ 做了,而且是主動做。

    對話證據:

    「Ab然後我想請你發一篇文章到wordpress上詳細比對這一次的經驗跟數據還有該怎麼啟用的prompt」

    同時要求三份產出:(A) brain/dynamic-workflows.md(下個 conversation 我會自動讀)、(B) 更新 brain/adaptive-agent-team-staffing.md(舊文件補新知識)、(WordPress 文章 —對人類讀者跟搜尋引擎)。

    對 AI 協作的特別意義:你跟人類同事的會議結論寫成 wiki/Notion,下次他翻過。跟 AI 寫 code 的對話結論寫成 brain file,下次 conversation 的 AI 把它當 first-class context 讀 — 等於把這次 conversation 的腦容量無損傳給下次。一般軟工人甚至沒聽過這個用法(「文件是給 AI 讀的?」),但它是 LLM 時代的 ADR + retrospective 文化合體。沒這層,你每次跟新 conversation 都得從零教一遍,等於每次都 onboarding。

    #5 Focused Review (一次只 review 一條軸線)

    定義:給 code review 的 feedback 一次只挑一條軸線改,不混雜其他要求。
    經典出處:Google Engineering Practices《Code Review Developer Guide》、《The Art of Readable Code》Ch.15、Andy Hunt《Pragmatic Thinking and Learning》Ch.9。

    本次對話做了沒:✅ 做了,而且 6 個字精準命中。

    對話證據:

    「注意好讀性跟比較方式」

    6 個字,2 條軸線,沒夾雜其他要求(沒同時挑錯字、補內容、改標題)。我回去重做的時候不需要 disambiguate「我到底該優先處理哪一條」。新手 reviewer 會給 30 條 mixed feedback,作者改完反而亂七八糟。

    對 AI 協作的特別意義:AI 在 mixed feedback 下會做兩件事:(1) 試圖一次解決所有,結果每條都打折;(2) 自選優先序,但你看不到它怎麼選的。你的 focused feedback 等於把「review reviewer」這層 meta-loop 去掉。對 token 成本也直接有差 — AI 不用先花 token 解析「Tom 到底想我先處理哪條」,直接動工。

    #6 並行/異步執行 (Async Parallel Execution)

    定義:能並行的工作不要序列化等待,結果到再收。
    經典出處:Concurrent programming 整個學門、Amdahl’s law、async/await 在現代語言的普及、Toyota production system 的並行工序設計。

    本次對話做了沒:✅ 做了。

    對話證據:

    「我正在運作 你看一下」

    你開另一個 terminal 跑 workflow,沒等我講完就行動。我這邊主 session 同時讀你的 process tree + session jsonl 做即時觀察。兩條軌道平行,中間用 jsonl 落地通訊。

    對 AI 協作的特別意義:跟 AI 對話有個隱形成本叫 cache miss penalty。Claude 的 prompt cache 5 分鐘 TTL,超過就要從零重讀整個 conversation。如果你序列化等(我講完→你看→你跑→等結果→回我),很容易 5 分鐘外。並行化 + 中間用 file system / jsonl 落地通訊,等於把 cache 維持在熱狀態。傳統軟工這條對應的是「不要 block 在 IO 等待」,AI 場景下是「不要 block 在對話等待」。

    #7 回顧 (Retrospective)

    定義:任務完成後不直接進下一個,先回看「what went well / what didn’t」。
    經典出處:Agile retrospective(Scrum 每個 sprint 末必做)、Norm Kerth《Project Retrospectives》、Etsy/Google 的 blameless postmortem 文化。

    本次對話做了沒:✅ 做了,而且是 meta 級 — 你問本篇這題就是 retrospective。

    對話證據:

    「還有 很多人說跟ai寫作需要很多的軟工基礎，不像請你評估一下所謂的軟工基礎在我們所有的循環裡面，我無形中有用到哪一些…因為有一些是我打中很關鍵的點，而你不知道那些是不是軟工基礎」

    這句話本身是回顧:你不滿足於「拿到結果就走」,還要拆解過程、識別 pattern、產生可遷移知識。

    對 AI 協作的特別意義:AI 不會主動 retrospect — 我跑完就等下一個 prompt,沒人觸發我不會自己回頭看「剛剛這條對話我做對了什麼」。retrospective 必須由你發起。但 retrospective 的產出對 AI 特別有價值:它是 #4 文檔作為輸入的最佳 raw material — 直接把回顧結論寫成 brain file,下次 conversation 直接用。傳統 retrospective 是「同個團隊下個 sprint 用」,AI 場景是「同個你下個 conversation 用」。

    #8 規格先於實作 (Spec-First / Specification before Implementation)

    定義:動手寫 code 之前先把「要做什麼」「驗收標準」寫死。
    經典出處:Leslie Lamport《Specifying Systems》、TDD「先寫測試」也是這條的變形、Design by Contract (Bertrand Meyer)、SDD(Spec-Driven Development)的學派。

    本次對話做了沒:✅ 做了,而且是顯式的 4 維度規格。

    對話證據:

    「記錄下來差異 怎麼啟動 有優化那些地方 要做什麼東西 必要是什麼」

    4 個維度寫死:(1) 啟動方式、(2) 優化點、(3) 要做的東西、(4) 必要條件。我後續的 brain file 跟 WordPress 文章兩份產出,結構直接照這 4 維度生。

    對 AI 協作的特別意義:沒給 spec 的 AI 會「自由發揮」,結果是形式上看起來有結構,實際結構是 AI 替你做的選擇,你不一定買單。你給 4 維度等於把結構決定權拿回來,AI 只負責填內容。這條對應的傳統軟工是 PRD/RFC,AI 場景是「在 prompt 裡內嵌驗收 schema」。

    #9 權衡分析 (Trade-off Analysis)

    定義:任何方案都有 cost 跟 benefit,要顯式列出再比較。
    經典出處:Software Architecture 教材必有的 ATAM (Architecture Tradeoff Analysis Method)、Jeff Bezos 的「two-way door / one-way door decisions」、《Pragmatic Programmer》Ch.4「Be a Catalyst for Change」的反向。

    本次對話做了沒:✅ 做了,而且是顯式追問。

    對話證據:本系列你連續問了三個 trade-off 問題:

    「差異你可以跑跑看」(empirical 比較 cost)

    「我想知道Workflow那一個，他現在到底對我的意義是什麼？我看不太出來」(質疑單一方向的 benefit)

    「注意好讀性跟比較方式」(cost = 讀者認知負擔 vs benefit = 完整性)

    對 AI 協作的特別意義:AI 對「該不該做某件事」的默認是 yes — 因為訓練資料裡的「Yes, you should」遠多於「No, don’t」。你「我看不太出來意義」這句逼我從 advocacy 模式切到 honest assessment 模式,實際結論變成「不存它,寫 reference 進 brain 就好」。這條對應的傳統軟工是 design review 裡「這個複雜度真的需要嗎?」的提問。

    #10 預設驗收標準 (Acceptance Criteria Upfront)

    定義:任務開始前先寫死「做到什麼程度算 done」。
    經典出處:Agile user story 的 INVEST criteria、Behavior-Driven Development (BDD) 的 Given-When-Then、Definition of Done 是 Scrum 必備產物。

    本次對話做了沒:🟡 部分做到。

    分析:你 #8 給了 4 維度規格,算是 partial acceptance criteria。但缺了「品質門檻」:

    • workflow 跑出來的 report 要達到什麼分類正確率才算可信?
    • baseline 跟 workflow 的差異要大到多少才算「值得換 workflow」?
    • 對話拆解後若 15 條都做到,實質工程效率提升多少才算夠?

    結果就是 — workflow 抓到 12 個 hand-roll,我們默認接受這個數字,沒去 sample 5 個函式人工驗證。如果 workflow 系統性把某類 hybrid 全錯標,我們不會發現。

    該怎麼補:任務開始前加一句「驗收標準」段落。例如本次該寫:

    驗收標準:
1. 兩邊跑完後,我會手動 sample 5 個 USES_PRELUDE 跟 3 個 HAND_ROLLED 對證據
2. 如果 baseline 跟 workflow 在這 8 個樣本上有 2 個以上分歧,需逐個澄清
3. 完整 109 函式都要有 row,缺一個視為失敗

    對 AI 協作的特別意義:AI 沒驗收標準會「看起來完成」(plausible-looking output),但內部可能 systematically 錯。傳統軟工裡 acceptance test 是另一個人寫的,AI 場景下你得自己寫,因為 AI 不會主動跟自己對抗。本次沒守這條的代價:我們得花一篇文章解釋「為什麼信任 workflow 的結果」,而本來只需要 sample-test。

    #11 可重跑 / Idempotency (Reproducible Execution)

    定義:任何過程要可從頭重來,輸入相同則輸出相同(在合理隨機範圍內)。
    經典出處:Make / build system 整個學門、Donald Knuth literate programming、Reproducible Research 運動、Docker / IaC 的根本動機。

    本次對話做了沒:❌ 沒做。最具體的證據是你沒按 s 把 workflow script 存下來。

    分析:本次跑了 11 個 Haiku 4.5 平行 audit,產生 146 行 JavaScript orchestration script,結果只存在 session 暫存目錄。如果這次的審計結論被人質疑(例如「12 個 hand_roll 是真的還是 AI 瞎標」),你要重跑驗證沒辦法保證跑出同一份結果 — 因為:

    • 下次跑 Claude 會重新生 script,chunk 切法可能不同
    • Haiku 4.5 即使 temperature 0 也有非 deterministic 因素(MoE routing 隨機)
    • Cache hit 率不同 → 提示空間不同 → 細節結論不同

    該怎麼補:三層防護(從便宜到昂貴):

    1. 最低: 把 script 從 session 暫存目錄 cp 出來歸檔到 brain 或 repo
    2. 中等: 把 script 真的存成 ~/.claude/workflows/<name>.js slash command,雖然本案大概不重跑,但其他 audit 可以 fork
    3. 高保證: 把 audit 結論 + 109 函式分類存成 JSON / CSV,用 schema 驗證,以後重跑只需 diff JSON 不需要重看 markdown

    對 AI 協作的特別意義:AI 的輸出有內建非 determinism(temperature、MoE、context order),這跟傳統 reproducibility 假設(同 input → 同 output)直接衝突。AI 場景的可重跑不能依賴「程式邏輯一樣」,要依賴「中間結果落地」 + 「結果用結構化格式儲存」 + 「下游 verifier 用同 schema 驗」。傳統軟工這條是「build 可重現」,AI 場景是「結論可驗證」。

    #12 預算控管 (Cost / Budget Cap)

    定義:任何運算工作開始前先設天花板,超過自動停。
    經典出處:Cloud computing 的 budget alerts、Kubernetes resource limits、Hadoop / Spark 的 timeout、Stripe 的「circuit breaker」pattern、SREbook §12 effective troubleshooting 的 budget 章節。

    本次對話做了沒:❌ 沒做。

    分析:我們跑 workflow 的時候沒設 token budget 或 wall-time cap。實際跑了 11 個 agent、~$6.10 estimated cost、132 秒 wall-time。如果 Claude 寫的 script bug 了 — 例如把 chunk 切成 100 個,可能跑出 100 個 agent、$60 cost、20 分鐘 wall-time。沒任何機制自動阻擋。

    該怎麼補:

    • prompt 裡明寫上限 — 例如「最多派 12 個 agent,單一 agent 最多跑 60 秒」
    • 用 --effort medium 而不是 high 開始,確認 quality 夠才升 effort
    • 跑前先讓 Claude 估算 token cost 跟 agent 數,你 approve 才放跑(workflow 內建這層 approval prompt,但你按 [3] View raw script 之前沒人問你 budget)
    • 對自己設「單條對話 spend 上限」(例如 $10),透過 Claude Code admin page 或 API budget API 強制

    對 AI 協作的特別意義:傳統軟工 budget 是「機器跑爛要錢」,AI 場景下 budget 還包含「AI 寫錯 script 跑很久才發現」的 fail-loud delay。Anthropic 自己在他們 multi-agent research system 的 paper 也警告:multi-agent 用 token 是 single-agent 的 3-10×,Research system 是 ~15×。沒 budget cap 等於放任這個倍率,3am 一覺起來收到 $200 帳單是真實風險。

    #13 根因分析 (Root Cause Analysis)

    定義:遇到問題不停在表象,挖到「為什麼會發生」的最底層。
    經典出處:Toyota 的「Five Whys」、Apollo 13 事故報告、Etsy / Google 的 blameless postmortem template、《The Field Guide to Understanding Human Error》。

    本次對話做了沒:🟡 部分做到,但是 AI 替你做的。

    分析:本次 audit 最有價值的發現是「guard role 被 AuthzDecision.IsCommunityWide 排除,迫使 5 個 resolver 各自重 probe 一段相同 SQL」。這是根因分析的成果 — 不停在「這幾個 resolver 沒用 prelude」,而是挖到「為什麼它們不能用」。

    但這是 workflow 的 synthesis agent 替你做的,不是你做的。Baseline 模式下 1 個 agent 沒做出這層,你也沒主動追問「為什麼會有 5 個重複」。如果這次跑 baseline 你會 miss 這個 root cause。

    該怎麼補:不能只靠 AI 替你做。可以加紀律 — 拿到分類結果後,主動問:

    看到 12 個 HAND_ROLLED,我們 ladder 5 個 why:
- 為什麼這 12 個沒用 prelude? → 各自原因
- 為什麼它們有共同原因? → 找 pattern
- 為什麼這個 pattern 沒被早發現? → 流程 gap
- 為什麼流程沒抓到? → tooling gap
- 為什麼 tooling 沒設計這層? → 設計時的假設

    對 AI 協作的特別意義:AI 默認停在第一層觀察(「這幾個沒用 prelude」)。要挖根因得明確要求(「列出 root cause」)或結構性逼它(workflow 的獨立 synthesis pass 就是設計來做這個)。傳統軟工這條是 debug 工具,AI 場景是「prompt design」工具 — 在 prompt 裡內嵌 root cause analysis instruction,或設計獨立 verification agent。

    #14 錯誤處理哲學 (Error Handling Philosophy)

    定義:對「事情會出錯」這件事有明確設計姿態 — fail-fast vs fail-silently、retry policy、circuit breaker、graceful degradation。
    經典出處:Erlang 的「let it crash」哲學、《Release It!》Michael Nygard 整本書、Google SREbook §22 addressing cascading failures。

    本次對話做了沒:❌ 沒做。

    分析:我們沒任何「workflow 跑到一半失敗了怎麼辦」的計畫:

    • 如果某個 chunk 的 Haiku agent 超時了 → 我們沒設 retry 也沒設 fallback
    • 如果 synthesis agent 算術錯了(這次真的發生了:83 vs 109)→ 我們沒設 verification 步驟,純靠主 orchestrator 主動懷疑
    • 如果 JSON schema 驗證 fail → 不知道會發生什麼,沒測過
    • 如果 workflow runtime 自己 crash → 沒 graceful resume 流程

    該怎麼補:在 prompt 裡加 error handling instruction:

    如果跑到一半發現:
- 某 chunk 的 agent fail → 標記 SKIPPED,繼續其他,最後 report 哪些 skip
- synthesis 結果跟 row count 對不上 → 不要直接出 report,先 escalate 給主 orchestrator 重算
- JSON schema 違反 → 該 row 標 INVALID,繼續其他
- 整體執行超過 5 分鐘 → 自動 abort,出階段性 report

最後 final report 要明確標示哪些 chunk 是「完整跑完」、哪些是「skipped」、哪些是「fail-and-retried」。

    對 AI 協作的特別意義:AI 預設 fail-silently — 它會生「看起來合理」的內容掩蓋失敗。傳統軟工 fail-fast 是「raise exception 停下來」,AI 場景的 fail-fast 是「標註 INVALID / SKIPPED 而不是瞎掰」。沒設計這條,AI 會「完整交付」一份其實內部有 hole 的報告,你看不出來。本次 workflow synthesis 算 83 是僥倖被主 orchestrator 抓到,如果主 orchestrator 也沒抓,我們就拿錯誤數字寫文章了。

    #15 版本控制紀律 (Version Control Discipline)

    定義:任何重要 artifact 進 git,commit message 寫清楚 why,branch 策略對應 workflow。
    經典出處:Git 整個工具、Conventional Commits 規範、Trunk-based / GitFlow / GitHub Flow 各家 branch 策略、Linus 的 git 設計初衷。

    本次對話做了沒:❌ 沒做。本次產出全部沒進 git。

    分析:這次產出了 4 件 artifact:

    • ~/.claude/projects/-home-tom/memory/brain/dynamic-workflows.md(新建)
    • ~/.claude/projects/-home-tom/memory/brain/adaptive-agent-team-staffing.md(編輯)
    • ~/.claude/projects/-home-tom/memory/MEMORY.md(編輯)
    • WordPress 文章兩篇

    前三個位置實際是 ~/.claude/projects/-home-tom/ — 你有可能沒把它放在 git 控管下,意思是:

    • brain 編輯沒 commit history,半年後想知道「dynamic-workflows.md 是什麼時候加的、為什麼加」沒記錄
    • 如果 brain 不小心被改錯了(例如未來某個 conversation AI 寫壞了),無法 rollback
    • 跨機器同步只能靠 rsync / cloud sync,沒 conflict resolution

    該怎麼補:

    1. cd ~/.claude/projects/-home-tom && git init(如果還沒)
    2. 新 brain 或重大編輯後 commit:git add brain/ MEMORY.md && git commit -m "feat(brain): dynamic-workflows from 2026-05-29 Opus 4.8 test"
    3. WordPress 文章 export markdown 進專屬 repo,或用 wp-cli 串自動 backup
    4. workflow script 改 #11 補救時順便 commit 進 dotfiles repo

    對 AI 協作的特別意義:AI 跨 conversation 是 stateless,brain file 是它的「外部記憶」。外部記憶的版本控管比 code 的還重要,因為你不會看到自己過去 conversation 改了哪些 brain,只有 git diff 告訴你。本次對話我改了 3 個 brain 檔,如果你沒 git 控管,3 個月後你不會記得這幾條條目是 5/29 對話加的還是更早。傳統 git 是 code 的時間機,AI 場景是「我跟 AI 集體記憶的時間機」。

    15 條全表:做了沒 × leverage

    # 紀律 類別 本次 Leverage(高→低)
    1驗證紀律核心驗證✅★★★★★ 沒守等於沒救
    2正交分解設計分解✅★★★★★ AI 回答品質直接相關
    3真實基準過程紀律✅★★★★★ 結論可信度核心
    4文檔作為輸入知識持久化✅★★★★★ AI 時代特有的紀律
    5Focused review過程紀律✅★★★★ AI 對 mixed feedback 表現差
    6並行執行過程紀律✅★★★ 規模大才顯效
    7回顧核心驗證✅★★★★ 跟 #4 配對 leverage 最大
    8規格先於實作設計分解✅★★★★ 直接決定 AI 輸出結構
    9權衡分析設計分解✅★★★★ 抗 AI 默認 yes 傾向
    10預設驗收標準過程紀律🟡★★★★ 該補,沒守會默認 plausible-looking
    11可重跑知識持久化❌★★★ 任務一次性可省,系統性任務必須
    12預算控管過程紀律❌★★★ 小任務可省,長 background 任務必須
    13根因分析核心驗證🟡★★★★ 主要靠 prompt 設計
    14錯誤處理哲學設計分解❌★★★★ AI 預設 fail-silently 必補
    15版本控制知識持久化❌★★★ brain 控管比 code 控管更重要

    結論:跟 AI 寫程式需要哪些軟工?

    不是新的軟工,是舊軟工套到 AI 4 個特性上

    15 條全部都不是「AI 時代發明的」 — 每條都能在 1990 年代的軟工教材找到根。差別在 4 個 AI 特性對這些紀律的需求強度不同:

    AI 特性 被放大需求的紀律
    訓練資料 cutoff#1 驗證紀律(逼 AI 查資料,不要憑記憶)
    Stateless / 無 conversation 記憶#4 文檔作為輸入、#15 版本控制(外部記憶持久化)
    非 deterministic 輸出#11 可重跑、#10 預設驗收標準、#14 錯誤處理(處理隨機性)
    高並發 + 高速#6 並行、#12 預算控管(token 倍率風險)

    個人 leverage 排序(5 強)

    如果你是這條光譜中段的人(寫過 5 年以上 code,剛開始系統性用 AI 寫 code),最該優先吸收這 5 條:

    1. #1 驗證紀律 — 沒守這條,後面 14 條都白學。AI 講什麼都不能信,grep / curl / test 重驗
    2. #2 正交分解 — 拆軸線問,不要 bundled question。直接決定 AI 回答品質
    3. #4 文檔作為輸入 — 把學到的寫成下個 conversation 可讀的格式。沒這條,每次 onboarding
    4. #3 真實基準 — Toy example 騙人。用 production codebase 評估工具
    5. #5 Focused review — 給 AI feedback 一次只挑一條軸線

    沒做的 5 條,該怎麼補

    本次對話沒做的紀律對應 5 條 action(從便宜到貴):

    1. #15 版本控制(5 分鐘):cd ~/.claude/projects/-home-tom && git init && git add . && git commit -m "snapshot" 一次性處理
    2. #11 可重跑(2 分鐘):把 workflow script 從 session 暫存 cp 到 brain 或 dotfiles repo 歸檔
    3. #10 驗收標準(每任務多寫 3 行 prompt):任務 prompt 開頭加「驗收標準:N 個項目,M% 正確率,通不過要告訴我」
    4. #14 錯誤處理(每 workflow 多寫 5 行):script 內加 fail-fast / skip / retry 分支
    5. #12 預算控管(系統性設定):Claude Code admin page 設 hard daily limit 或寫個 hook 跑前先估

    真正的 meta-insight

    本文 15 條展開後最反直覺的觀察:跟 AI 寫程式需要的軟工基礎,大部分不是 code-level 的,是 process-level + protocol-level 的。傳統軟工新人學的順序是「先學語言 → 再學 design pattern → 最後學 process」,跟 AI 寫程式得反過來:先學 process discipline(怎麼下指令、怎麼驗證、怎麼回顧),最後才是 code-level technique。

    因為跟 AI 寫程式,code 是 AI 生的,你扮演的是 reviewer + verifier + spec writer 三個角色。這三個角色傳統上叫 PM / QA / Tech Lead — 都是 senior eng 的活。所以「跟 AI 寫程式比較簡單」這句話完全反了 — 它把senior eng 的工作 commoditize 到每個用 AI 的人身上,reviewer 的紀律從「資深工程師的特權」變成「每個 prompt 作者的基本技能」。

    這就是為什麼那麼多人「用 AI 寫了一堆 code 但跑不起來」 — 不是 AI 不行,是沒人替他們做 reviewer / verifier / spec writer 那三層活。本文 15 條的本質就是把這三層活的紀律寫下來。

    跟我之前文章的關聯

  • Claude Code Dynamic Workflows 實測:Opus 4.8 + 11 Haiku 平行 audit 109 個 resolver

    重點摘要

    • Anthropic 在 2026-05-28 釋出 Claude Opus 4.8,帶來 Dynamic Workflows(背景跑 JS script orchestrate 數百 subagent)、Effort Control(low/medium/high/xhigh/max/ultracode)、Messages API system entries 中段插入。
    • 實測:同題雙軌跑 Home123(Go + gqlgen 後端)的 109 個 resolver 函式 authz pattern audit,baseline (Opus 4.7 + 1 個 general-purpose agent) vs workflow (Opus 4.8 + 11 個 Haiku 4.5 worker)。
    • 最大發現:workflow runtime 自動把 worker model 派為 Haiku 4.5,主 orchestrator 維持 Opus 4.8 — 對應「想 → opus / 找 → haiku」分工 doctrine,以前要手寫 AGENTS.md 分配的事 runtime 替你做了。
    • Wall time 沒省(workflow runtime 132 秒比 baseline 236 秒快,但加上主 session synthesis 反而是 392 秒)。本次估算成本 workflow ~$6.1 是 baseline ~$0.72 的 ~8.5× — 主要花在 runtime cache write 固定成本,大規模任務攤平會降下來。
    • 收益不在省錢,在:JSON Schema 強制輸出契約、reproducibility(script 落地,以後 /<name> 一鍵重跑)、主 orchestrator 主動 cross-check 下游(實戰抓到 synthesis subagent 算錯總數 83 vs 真實 109)。

    一眼看完:Baseline vs Workflow

    整篇下面會逐項拆,先給你 5 秒讀完的版本。題目都是同一份 Home123 GraphQL 後端 109 個 resolver 函式的 authz pattern 分類。

    面向 Baseline Workflow
    啟動指令主 session 派一個 Agentclaude --model claude-opus-4-8 --effort high 後 prompt 內塞 workflow 字
    主模型Opus 4.7Opus 4.8
    Worker 數量1(general-purpose,可寫)11(Explore 型,強制 read-only)
    Worker 模型Opus 4.7(跟主一致)全 11 個 Haiku 4.5(runtime 自選)
    並發加速—11 agents 加總 354s 實跑 132s = 2.7×
    主 session tool call24 (14 Bash + 10 Read)8 (5 Bash + 2 Read + 1 Workflow)
    輸出契約自由 markdownJSON Schema + enum 鎖死 4 值
    覆蓋109/109109/109
    總耗時3:56(236s)6:32 turn,workflow runtime 2:12
    抓到的 root cause1 個(CapsAny 提案)6 個(含 guard 5× 重複的真兇)
    結構級洞見沒做出read-side vs write-side 不對稱
    主動 cross-check 下游—(只有 1 agent)✅ 抓到 synthesis agent 算錯 83 vs 真實 109
    估算成本~$0.72~$6.10(約 8.5× baseline)
    可重跑無script 落地,以後 /<name> 一鍵

    架構差異:一張流程圖

    讀者最常問的不是「快多少」,是「結構上到底差在哪」。把兩種模式畫成流程:

    Baseline                              Workflow
─────────                             ─────────
User prompt                           User prompt
    │                                     │
    ▼                                     ▼
┌─────────────────┐                   ┌─────────────────┐
│ Main Claude     │                   │ Main Claude     │
│ (Opus 4.7)      │                   │ (Opus 4.8)      │
│                 │                   │ 寫 JS script    │
│ Agent tool      │                   └────────┬────────┘
│   ↓ 派 1 agent  │                            │ Workflow tool
└────────┬────────┘                            ▼
         │                              ┌──────────────────┐
         ▼                              │ Runtime          │
   ┌──────────────┐                     │ (背景執行 script) │
   │ 1× Opus 4.7  │                     └────────┬─────────┘
   │ general-     │                              │ fan-out
   │ purpose      │                              ▼
   │              │            ┌──────────────────────────────────┐
   │ ─ 24 tool ─  │            │ Phase 1: Classify (平行)         │
   │   call ─ 自由 │            │ ┌────┐┌────┐┌────┐ ... ┌────┐  │
   │   分類 +    │            │ │H4.5││H4.5││H4.5│      │H4.5│  │
   │   markdown  │            │ └────┘└────┘└────┘      └────┘  │
   └──────┬───────┘            │ 10 agents (schema 切 8 chunks +  │
          │                    │  visitor 1 + announcement 1)     │
          ▼                    └────────────┬─────────────────────┘
   markdown report                          │ JSON schema 驗證
                                            ▼
                               ┌──────────────────────────┐
                               │ Phase 2: Synthesize      │
                               │ ┌────┐                    │
                               │ │H4.5│ 1 agent           │
                               │ └────┘                    │
                               └────────────┬──────────────┘
                                            │
                                            ▼
                               ┌──────────────────────────┐
                               │ Main Claude (Opus 4.8)   │
                               │ cross-check synthesis,   │
                               │ 抓到 83 vs 109 算術錯誤  │
                               │ 用 authoritative rows     │
                               │ 重算 + 寫最終 report     │
                               └────────────┬──────────────┘
                                            ▼
                                   final markdown report
                                   + JS script 落地

    關鍵差別不是 agent 數,是「主 Claude 不再親手做活,變成 orchestrator + verifier」。中間結果落在 script 變數,不灌進主 session context。

    背景:Opus 4.8 帶來什麼

    Anthropic 在 2026-05-28 同步發佈了 Claude Opus 4.8、Dynamic Workflows research preview、Effort Control、以及 Messages API 的中段 system entries 支援。發佈當天我看了官網內容,隔天 5/29 拿真實專案 Home123 跑了一輪雙軌對照,本文記錄完整數據與啟動 prompt。

    三個直接相關的能力更新:

    能力說明適用 plan
    Dynamic WorkflowsClaude 寫一支 JS script,runtime 背景跑,內含可數百個 read-only Explore subagent 平行作業所有付費(Pro 要先去 /config 開)
    Effort Control5 級:low / medium / high / xhigh / max,另有 ultracode(= xhigh + 自動 workflow orchestration)所有 plan
    Messages API system entries可在 messages array 中段插入 system entry,更新指令但不破 prompt cache、不需要假裝 user turnAPI 直連

    不是所有 model 都吃所有 effort 等級。實測 claude --effort foo 會回:

    error: option '--effort <level>' argument 'foo' is invalid.
It must be one of: low, medium, high, xhigh, max

    官方支援表(來自 code.claude.com/docs/en/model-config):

    Model支援 effort 等級預設
    Opus 4.8, Opus 4.7low, medium, high, xhigh, max4.8 → high / 4.7 → xhigh
    Opus 4.6, Sonnet 4.6low, medium, high, max(沒 xhigh)high
    其他不支援 effort—

    常見誤解:Sonnet 也能 xhigh 嗎?不行。Sonnet 4.6 只到 high,你硬塞 xhigh 會自動降到 high 不報錯但也少一級。ultracode 在 Sonnet 連菜單都不出現。

    對照實驗設計:為什麼挑 Home123 authz audit

    Workflow 適合的題目有 4 個必要條件:

    1. 可平行化 — 任務天然能切成 N 個獨立 chunk
    2. 可被 JSON Schema 約束 — 輸出結構穩定、enum 有限
    3. 有 ground truth — 否則 11 個 agent 跑完你也不知道對不對
    4. Read-only 為佳 — Explore type agent 不會誤改檔

    挑的題目:掃描 Home123 backend GraphQL 的 3 個 resolver 檔,把 109 個 resolver function 分類成 USES_PRELUDE / LEGIT_PUBLIC / HAND_ROLLED / UNKNOWN。

    Home123 是 multi-tenant SaaS,我自己寫了一個 authzPrelude centralised authn+cap+scope+audit 序列,規範每個 protected resolver 進 withTx 後第一段要 call。但程式碼累積過程中,有些 resolver 為了 cap-OR 之類 prelude 還不支援的情境 hand-roll 了授權邏輯。這次審計就是要逐一抓出來。

    符合條件為什麼這題符合
    可平行化109 個 function 各自獨立,每個分類不依賴其他結果
    可被 schema 約束class enum 只有 4 值;每筆 row 必填 file / func / line / class / evidence
    有 ground truthgrep -c authzPrelude backend/graph/*.resolvers.go 給出客觀基準
    Read-only純審計、不改檔

    啟動 prompt:兩邊放在一起看

    兩邊我都跑了。下面先給差異速覽,再給雙邊完整 prompt 對照。

    差異速覽

    面向 Baseline Workflow
    session 啟動任何 session 都可,呼叫 Agent toolclaude --model claude-opus-4-8 --effort high
    觸發機制主動派 1 個 Agentprompt 內含 workflow 關鍵字 → Claude Code 反白 → approval prompt
    Prompt 句子數~20 行(任務說明)~24 行(任務說明 + 第一個字「workflow」)
    關鍵差異字直述命令式 — 「做這個 audit」第一個字加 「跑一個 workflow,」 — 觸發 runtime 寫 script
    事前需要無(general-purpose 預設可用)Claude Code ≥ 2.1.154,Pro 要先 /config 開
    跑前是否確認不需要,直接跑approval prompt 必須選 [1] Yes;第一次強烈建議按 [3] View raw script

    左:Baseline prompt(逐字)

    你在 /home/tom/Desktop/home123_new 做一次 read-only authz pattern audit。
禁止修改任何檔案。

審計三個 resolver 檔的每一個 resolver function:
- backend/graph/schema.resolvers.go (~80 funcs)
- backend/graph/visitor.resolvers.go (~15 funcs)
- backend/graph/announcement.resolvers.go (~16 funcs)

分類規則:
1. USES_PRELUDE — body 第一段 call authzPrelude(...)
2. LEGIT_PUBLIC — 真正不需要 auth 的 (Login / RefreshAccessToken 等)
3. HAND_ROLLED — 沒 call authzPrelude 但自己寫 cap/scope/role/audit 檢查
4. UNKNOWN — 你無法判定

輸出:markdown 表 | file | func | line | class | evidence |,
所有 function 一行不能少。

最後加 ## Summary:每 class 數量、HAND_ROLLED 跟 UNKNOWN 清單、可疑模式。

用 Bash grep / Read 自己抓,不要憑記憶或猜。

    右:Workflow prompt(逐字)

    新 session 啟動:

    cd /home/tom/Desktop/home123_new
claude --model claude-opus-4-8 --effort high

    進去後丟這個 prompt(留意第一個字是 「在這個 repo 跑一個 workflow」,這個關鍵字就是觸發 runtime 的開關):

    在這個 repo 跑一個 workflow,做 read-only authz pattern audit。不准改任何檔案。

審計三個 resolver 檔的「每一個」resolver function:
- backend/graph/schema.resolvers.go (約 78 funcs)
- backend/graph/visitor.resolvers.go (約 15 funcs)
- backend/graph/announcement.resolvers.go (約 16 funcs)

每個 function 分類成 4 種之一:
1. USES_PRELUDE — body 第一段 call authzPrelude,或 1-line delegate 到呼叫
   authzPrelude 的 helper
2. LEGIT_PUBLIC — 真公開查詢 (Login / RefreshAccessToken / Healthcheck /
   ApplicationStatus 等),依據 schema directive / 註解 / 函式意圖判定
3. HAND_ROLLED — 沒 call authzPrelude 但自己寫 cap/scope/role/audit
   (CheckCap / hasRole / rbac.RequireCapability / 手動讀 ctx 判 user)
4. UNKNOWN — 邏輯太繞或無法判定

輸出格式:markdown 表 | file | func | line | class | evidence |,
每個 function 一行不能少。

最後加 ## Summary:每 class 數量、HAND_ROLLED 跟 UNKNOWN 名單、可疑模式
(eg. asymmetry / 同一 cap 兩種寫法 / 整個檔的傾向)。

建議擴展 prelude 才能解的問題也標出來 (eg. CapsAny 多 cap OR-chain)。

    送出後 Claude Code 會問你

    Workflow plan:
  Phase 1: Classify — one Explore agent per function-range chunk
  Phase 2: Synthesize — cross-file pattern analysis + suspicious findings

[1] Yes, run it
[2] Yes, and don't ask again for <name> in <path>
[3] View raw script   ← 第一次強烈建議按
[4] No

    第一次按 View raw script 看 Claude 寫出什麼 JS,看完按 ESC 回去再按 Yes。這是 workflow 教育核心,跟 subagent 的 black box 是完全不同的體驗 — 你看得到 orchestration 的具體 code。

    Claude 寫的 workflow script 長啥樣

    從 session jsonl 撈出來的真實 script 開頭片段:

    export const meta = {
  name: 'authz-pattern-audit',
  phases: [
    { title: 'Classify',   detail: 'one Explore agent per function-range chunk' },
    { title: 'Synthesize', detail: 'cross-file pattern analysis' },
  ],
}

// JSON Schema 強制每筆 row 必填 5 欄
const ROW_SCHEMA = {
  type: 'object',
  required: ['rows'],
  properties: {
    rows: {
      type: 'array',
      items: {
        type: 'object',
        required: ['file', 'func', 'line', 'class', 'evidence'],
        properties: {
          file: { type: 'string' },
          func: { type: 'string' },
          line: { type: 'integer' },
          class: {
            type: 'string',
            enum: ['USES_PRELUDE','LEGIT_PUBLIC','HAND_ROLLED','UNKNOWN']
          },
          evidence: { type: 'string' },
        },
      },
    },
  },
}

const PRELUDE_REF = `
REFERENCE — what each class means in THIS codebase (backend/graph/authz.go):
authzPrelude(ctx, tx, claims, PreludeOptions{Cap:..., Scope:..., ...})
is the centralised authn+cap+scope+audit sequence...
CLASSIFICATION RULES (pick exactly one per function):
...
`

// schema.resolvers.go 切 8 chunks,各 1 個 Explore agent;visitor / announcement 各 1
// fanOut(...) → 10 個 read-only Explore agents 平行
// 然後 1 個 synthesis Explore agent 做 cross-file 分析

return { rows, summary }

    注意三件事:

    • JSON Schema 鎖死 enum:subagent 不可能跑出 "class": "MAYBE" 這種,runtime 直接退回。Baseline 自由 markdown 沒有這層保護。
    • agentType: 'Explore' 是 script 層硬性:11 個 agent 完全不能 Edit/Write,不是靠 prompt 講「不准改」這種 soft 約束。
    • chunk 切法寫死在 script:每個 agent context 不汙染,不會記錯行號。

    跑起來後的真實 process 狀態

    從本機 process tree + session jsonl 即時觀察到的(workflow 跑到 110 秒時):

    $ ps -o pid,pcpu,pmem,vsz,rss,etime,cmd -p 1676911
    PID %CPU %MEM    VSZ   RSS     ELAPSED CMD
1676911 26.9  1.0 73786132 337864    01:49 claude --model claude-opus-4-8 --effort high

$ python3 - << 'PY'
import json
events = {}; tools = {}
with open('<session>.jsonl') as f:
    for line in f:
        d = json.loads(line); ...
print(events, tools)
PY
# 結果:
# {'assistant': 14, 'system': 2, 'user': 6, ...}
# Tools: {'Bash': 3, 'Read': 1, 'Workflow': 1}

    主 session 只花 5 個 tool call(3 Bash + 1 Read 探勘 + 1 Workflow 派出去)就把工作全部 delegate 出去,自己等 callback。

    Workflow runtime 把 11 個 agent 的執行軌跡寫到磁碟,結構是這樣的:

    ~/.claude/projects/<project>/<session>/
├── workflows/
│   ├── scripts/
│   │   └── authz-pattern-audit-wf_d545fc61-597.js   ← Claude 寫的 script
│   └── wf_d545fc61-597.json                         ← run state
└── subagents/workflows/wf_d545fc61-597/
    ├── journal.jsonl                                ← 11 個 agent 起跑/完成軌跡
    ├── agent-a1b66c368221dfcbc.jsonl                ← 每個 agent 的完整 transcript
    ├── agent-a1b66c368221dfcbc.meta.json
    ├── ...(共 11 對 jsonl + meta)
    └── agent-a24f70cfc4a9cea4c.jsonl                ← synthesis agent

    從 journal.jsonl 可以看到並發狀況:7 個 agent 同時 started,然後 result/start 交錯。實測 Tom 8-core 機器同時 active ~7 個,沒撞到 16 上限。

    最大發現:runtime 自動把 worker 派為 Haiku 4.5

    從每個 agent 的 jsonl 撈 model 跟 token:

    aid          model         dur(s)   in     out     cache_r    cache_w
a1b66c3682   haiku-4-5     36.6     68     2913    704739     86473
a24f70cfc4   haiku-4-5     65.3     126    6780    831993     139390
a44126f699   haiku-4-5     46.0     113    2750    780310     99018
a5b0952489   haiku-4-5     18.1     36     2106    172988     79402
a677c4aa85   haiku-4-5     15.6     41     1955    164250     84687
a98dc4ecbc   haiku-4-5     18.3     26     2189    132348     57398
aa0358d7b4   haiku-4-5     39.4     132    3935    803238     66657
aac3435e5b   haiku-4-5     22.4     77     2798    384636     174664
aac426ca5b   haiku-4-5     24.5     41     2616    235382     64016
ab4b713305   haiku-4-5     28.6     120    2618    480910     158476
abe7fdedda   haiku-4-5     39.8     88     3173    896956     110064

    11 個 worker 全部是 Haiku 4.5。我啟動用 --model claude-opus-4-8,但 workflow runtime 自選把 worker 派去 Haiku。

    這對應到我 MEMORY 裡寫的「想 → opus / 做 → sonnet / 找 → haiku」模型分層 doctrine。Runtime 替我做了:

    • 主 orchestrator(寫 script + synthesis)= Opus → 「想」
    • 11 個 worker(bulk classification / grep / read)= Haiku → 「找」
    • 沒 Sonnet 是因為這題沒「做」(read-only audit 沒寫入)

    意義:原本 plan 期手寫 AGENTS.md 分配模型的事,runtime 替你做了。這比文件公告任何一條新功能都重要 — adaptive staffing 從「未來方向」變成「實裝」。

    對照結果:數字攤開

    面向 Baseline (Opus 4.7 + 1 agent) Workflow (Opus 4.8 + 11 Haiku)
    總耗時3:56 (236s)6:32 turn / 2:12 workflow runtime
    真實平行加速—11 agents 累加 354s,實跑 132s → 2.7×
    主 session tool call24 (14 Bash + 10 Read)8 (5 Bash + 2 Read + 1 Workflow)
    Subagent 數1(general-purpose,可寫)11(Explore,read-only)
    Subagent 模型Opus 4.7全 11 個 Haiku 4.5
    覆蓋109/109109/109
    總 token(估)~103K~480K(主 315K + workers 165K)
    Cache read低6.95M(瘋狂重用)
    估算成本~$0.72~$6.10(約 8.5× baseline)

    分類結果差異

    Class Baseline Workflow 差異原因
    USES_PRELUDE8478Workflow 把「prelude + 後續 manual orchestration」歸到 hand_rolled hybrid,標準更嚴
    LEGIT_PUBLIC1317Workflow 把 Logout / Me / Community 視為 public(judgment call)
    HAND_ROLLED1012Workflow 多抓出 5 個 hybrid hand-roll(prelude 加 manual 後處理)
    UNKNOWN22同(兩個 *AuditUnacked,純靠 RLS)

    質的差異:同題下 baseline vs workflow 各看到什麼

    數字一樣是 109/109 覆蓋,但兩邊對同一個 codebase 「看見」的東西不一樣。下面 4 個維度,左 baseline 右 workflow 並列。

    差異 #1:對下游結果是否複查

    Baseline 表現 Workflow 表現
    只有 1 個 agent,自己跑自己算,沒有下游可疑。Report 怎麼算就怎麼算,讀者要自己 grep 才能驗。 Synthesis subagent 自己算出 total: 83(漏算 26 個)。主 orchestrator (Opus 4.8) 拒絕信任,自己重算 109,公開記下:

    “The audit is complete, but the synthesis agent’s counts look off (it reported total=83, but I dispatched coverage for 109 functions). Let me verify completeness from the authoritative rows array myself.”

    這就是 4.8 公告吹的「4× less likely to allow flaws in code it wrote to pass unremarked」實戰演示。

    差異 #2:對 root cause 的挖掘深度

    Baseline 的觀察 Workflow 的觀察
    「cap-OR 是 4 個 hand-roll 不 migrate 的主因」。

    停在第一層觀察。沒挖到更底層的結構問題。    		 「Households / Parcels / ParcelsPage / CommunityVisitors / VisitorAuditLog 同一段 SQL 抄 5 次。真兇是 AuthzDecision.IsCommunityWide 排除了 guard role,迫使每個把 guard 當 community-wide 的 resolver 都得自己重 probe。」

    挖到第二層結構根因。能做出來是因為 synthesis 是專屬 agent、有獨立 context,沒被 109 函式的細節塞滿。

    差異 #3:可落地的 fix 提案數

    Baseline 給的提案 Workflow 給的提案
    1 個:擴展 prelude 支援 CapsAny 多 cap OR-chain 6 個 可落地的 prelude extension:
    1. CapsAny []string — 解 4 個 hand-roll
    2. 承認 guard 是 broad role(RoleListBroad bool)— 解 5× 重複的 SQL probe
    3. ScopeDowngradeOnRole map[role]AuthzScope — 解 2 個 visitor scope 降級
    4. Cap + CapOwn + OwnershipIDCol — 解 2 個 announcement ownership
    5. authzPreludeAny([]PreludeOptions) 多路徑 helper — 解 2 個 multi-path
    6. ScopeRLSOnly enum(顯式宣告 RLS-only)— 解 2 個 UNKNOWN
    最高 leverage:#1 + #2 兩個 API 微調可幹掉 12 個 hand-roll 中的 7 個。

    差異 #4:結構級觀察

    Baseline 的結論深度 Workflow 的結論深度
    逐個 function 分類完,給 Summary 數字。

    沒有跨函式結構洞見。讀者拿到表得自己再看一輪才能發現「全部 hand-roll 都在 query 那邊」。    		 「所有 7 個純 hand-roll + 2 個 UNKNOWN 集中在 schema.resolvers.go 的 query tail(line 6210-7130),mutation 100% 走 prelude。」

    結論:「read-side authz is where the rot is.」

    這級結構洞見 baseline 沒做出來,因為它的 agent 同時在處理逐函式分類跟跨函式觀察兩件事,context 被佔滿。

    4 個差異的共同根因

    Workflow 4 個維度都贏,不是模型差,而是架構差:

    • Synthesis 是專屬 phase 跟專屬 agent,不跟逐函式分類搶 context
    • 主 orchestrator 不直接做活,有餘力去 cross-check 下游
    • JSON Schema 鎖死 enum,讓 synthesis 的算術錯誤被直接 vs 證據對照,容易被抓
    • 每個 Classify agent 只看自己那塊 chunk,context 不被 109 函式整體噪音蓋掉

    換句話說:把 baseline 的單一 Opus 4.7 agent 升級成 Opus 4.8 也救不了 — 缺的是 architectural separation of concerns,不是模型聰明度。

    成本拆解:雙邊對稱對照

    用公開 pricing 算(Opus 4.7 / 4.8 同價:$5/M input、$25/M output、~$0.50/M cache_read、$6.25/M cache_write;Haiku 4.5:$1/M input、$5/M output、~$0.10/M cache_read、$1.25/M cache_write)。

    Baseline 拆解

    誠實先講:baseline 走 Agent tool,Anthropic 只回傳 total_tokens: 103,078,沒給 input/output 拆解。所以我只能上下界估算。

    情境 假設拆解 成本
    下界(全是 input)103K in / 0 out$0.52
    合理估(read-heavy audit,輸出 ~10K markdown)93K in / 10K out~$0.72
    上界(全是 output,不現實)0 in / 103K out$2.58

    Workflow 拆解

    Workflow runtime 把每個 agent 跟主 session 的 token 都寫到 jsonl,可以精算。

    項目 Input Output Cache read Cache write 成本
    主 session (Opus 4.8)31,68659,5061,361,289262,528~$3.97
    11 workers (Haiku 4.5)~870~33,833~5,587,750~1,120,245~$2.13
    Workflow 合計~32,556~93,339~6,949,039~1,382,773~$6.10

    並排比較與成本比

    指標 Baseline Workflow 倍率
    總 token(可量到的)~103K~8.46M(主 + workers,含 cache)~82×
    非 cache token~103K~125K(主 + workers,純 in+out)~1.2×
    估算成本~$0.72~$6.10~8.5×

    校正一下我之前隨口說的「2-3× cost」 — 認真算下來這次 workflow 是 baseline 的 ~8.5×。會這麼高的主因是 workflow runtime 海量 cache write(主 session prompt 加上 11 個 worker 各自的 system+task prompt 都得 cache),這在小規模任務上吃掉的固定成本不成比例。

    更大規模(例如 1000 個 function、5 個檔案、要跑多輪 phase 的 codebase-scale migration)倍率會掉下來,因為 cache 攤平。本次 109 函式可能還沒到 workflow 的 sweet spot。

    收益不在錢,在結構性保證:JSON Schema 鎖死輸出契約、Explore agent 鎖死 read-only、script 落地 reproducible、主 orchestrator 主動 cross-check 下游算術錯誤、結構級洞見的獨立 synthesis pass。如果這次的 audit 結果直接讓你修對 5 個 bug,$5 的價差完全划得來;如果只是研究性掃描、要常常重跑,$0.72 的 baseline 更合理。

    何時用、何時不用

    情境 該用
    平行 audit / sweep / 分類(N 個獨立目標)Workflow
    結果可被 JSON Schema 約束Workflow
    有 ground truth 可驗(grep / 規則對照)Workflow
    Codebase migration 數百到千行Workflow
    30 行小改、互動式 debug、需要中途決策Subagent / 直接對話
    設計 / 重構 / 探索 spike直接對話
    序列邏輯(A 結果決定 B 做啥)Subagent
    預算敏感、有 deadlineSubagent

    硬性限制(踩過的)

    限制數字影響
    並發 agent最多 16(8-core 機器實測 ~7 並發)大 chunk 設計,別追求一函式一 agent
    單 run 累計 agent硬上限 1000大型 migration 拆多個 workflow
    中途要用戶輸入不行多階段簽核拆多 workflow,中間落地
    script 直接 fs / shell不行透過 agent 做,script 純 orchestrate
    Subagent permission mode永遠 acceptEdits想 read-only 一定用 agentType: 'Explore'

    把 workflow 存成可重用 slash command

    跑完滿意,在 workflow session 內:

    /workflows               # 列出 run
↑↓ 選那個 run → Enter   # 進入進度檢視
s                        # 存成 slash command
  → 選 .claude/workflows/<name>.js (repo 共享)
  → 或 ~/.claude/workflows/<name>.js (個人跨專案)

    之後 /<name> 像 slash command 一樣用。Project workflow 優先級高於 personal 同名。

    想 resume failed run:

    Workflow({
  scriptPath: "<session>/workflows/scripts/<name>-<runId>.js",
  resumeFromRunId: "wf_xxx"
})
# completed agents 回傳 cached result,只重跑失敗的

    關掉 workflow

    範圍怎麼關
    自己/config 切 Dynamic workflows / settings.json 設 "disableWorkflows": true / 環境變數 CLAUDE_CODE_DISABLE_WORKFLOWS=1
    整組織managed settings "disableWorkflows": true 或 Claude Code admin page 切

    關掉後:built-in /deep-research 不能用、workflow 關鍵字不觸發、ultracode 從 /effort 菜單消失。

    對日常工作的影響

    我自己接下來打算用 workflow 跑的場景:

    • Home123 RLS coverage sweep — 每張 table 確認 CRUD 4 個 RLS policy 都齊
    • Home123 invariant coverage — 170 個 INV 是否在 backlog 有對應 test sketch
    • iDempiere @RestResource endpoint 巡檢 — endpoint × test × OData filter doc 三角檢
    • SimpleEC OMS Kafka 事件覆蓋矩陣 — topic × producer × consumer 對應

    不會用 workflow 的場景:走 decision-server 的任何題(workflow 中途不能停下來問人)、30 行小修、新功能 spike(reproducibility 沒價值)。

    跟我之前文章的關聯

    結論:結構性保證,不是省錢工具

    Dynamic Workflows 不是「Claude 變強了所以更便宜」,而是「Claude 把 plan 期才做的 staffing 決策搬到 runtime,並用 JSON Schema + Explore 型別把輸出契約寫進 code 而非 prompt」。對任務符合 4 條件(可平行、可 schema、有 ground truth、read-only)的場景,workflow 的結構性保證值得 2-3× cost。不符合的場景繼續用傳統 subagent 跟直接對話,別因為「workflow 看起來酷」default 用。

    真正令人意外的不是任何單一功能,是「runtime 自動派 Haiku 4.5 給 worker、保留 Opus 4.8 給 orchestrator」這件事連文件都沒重點說。它把以往要寫進 AGENTS.md 的「想/做/找」三層分工,從文件變成系統行為。下一輪 model release(Mythos Preview 已預告)會繼續推進這條軸線:組織 prompt 從手寫變 runtime 推導。