別做一個什麼都會的 AI：拆成節點，用固定格式交接

處理複雜任務時，新手最常見的直覺是：把整件事丟給一個最強的模型，「幫我做一套客服分類加自動回覆系統」，然後等成品。

這種「整包進、整包出」的做法，第一次可能還行，上線之後是災難。因為你看不見中間發生了什麼：哪一步呼叫了什麼、哪一段開始跑偏、幻覺是在分類時產生的還是寫信時產生的。產出不對，你找不到下手的地方，只能重寫整個提示詞。那不是修，是再抽一次籤。

Anthropic 那篇「Building effective agents」給的建議是：從最簡單的做法開始，只在明確有幫助時才加複雜度。而他們整理出來的幾種「加複雜度」的方式，核心都是同一件事——把大任務拆成小節點，節點之間用結構化的資料交接。

拆成單一職責的節點

以「處理客戶來信」為例，不要讓一個 AI 同時分類、查資料、寫信、做品管。拆成四個節點：

拆開之後你得到的東西叫局部可修復性。系統把「抱怨信」誤判成「功能諮詢」，你不用動寫信的提示詞、不用動檢索邏輯，只改分類節點。品管一直放行錯的東西，只換品管節點的清單或模型。這在整包模式裡做不到。

Anthropic 把這類拆法分成幾種：prompt chaining（節點一個接一個，每步可以插檢查）、routing（先分類再送到對應的專用節點）、parallelization（幾個節點同時跑，結果彙整）、orchestrator-workers（一個主控動態決定拆成哪些子任務、派給工人）、evaluator-optimizer（一個產出、一個評估，來回到過關）。客服例子用的是前兩種。多數日常工作用前兩種就夠，後三種等你真的需要再說。

節點之間用固定欄位交接，不靠心電感應

拆開之後的下一個問題：節點之間怎麼接？

答案不是「上一個 AI 把它想的講給下一個聽」，那等於把整段對話貼過去，交接單那篇會講這樣為什麼接不住。答案是固定欄位的結構化資料，通常是 JSON。分類節點結束時，必須吐出這樣的東西，不多不少：

{ "category": "finance",
  "priority": "high",
  "needs_clarification": false }

撰寫節點讀這三個欄位決定語氣和速度，它不需要知道分類節點是怎麼想的、猶豫過什麼。欄位是合約：上游保證吐出這幾格，下游只依賴這幾格。合約定了，兩邊就可以各自改、各自換模型、各自測試，互不影響。

有個實務細節值得先講：欄位要少，而且每一格要有允許值的清單。priority 只能是 high、medium、low，不能讓上游自由發揮寫「蠻急的」。允許值寫死，下游才能用程式驗證，驗不過就在交接處擋下，而不是流到最後才發現。

順帶區分一件事。Matt Pocock 的 to-tickets（動工前先被拷問那篇）是把功能切成一張張走得完的票，這篇是把流程切成一個個節點。兩個是不同的軸，一張票裡面可能包含好幾個節點，一個節點也可能服務好幾張票。

動手做

有一件事目前是整包丟給 AI 的，讓它幫你拆節點、定合約：

下面是我目前整包交給 AI 的一件事。請幫我拆成流水線：
1. 節點：每個節點只做一件事，寫出「輸入什麼、輸出什麼、用什麼標準判斷做完了」。目標三到五個節點，不要更多。
2. 交接合約：每兩個相鄰節點之間，定義一個 JSON 格式，欄位越少越好，每個欄位列出允許值（枚舉）或格式（日期、數字範圍）。
3. 檢查點：哪些交接處該加程式驗證（欄位缺漏、值不在允許範圍就擋下）。
4. 最後告訴我：如果第一版出錯，最可能是哪個節點，我該先看哪裡。
不要開始執行，只輸出設計。
這件事：（貼上）

節點拆好了、想接成自動流程的，找方法有AI 工作流程設計。

拆對了的樣子：每個節點你都能用一句話說出它只做什麼；節點之間的 JSON 你能整個列出來，而且每格有允許值；出錯時你能說「是分類節點的問題」，而不是「AI 又不行了」；你曾經只換掉一個節點的模型（例如分類用便宜的），其他節點沒動。

想體驗差別的話，拿你上一次「整包」的產出，試著指出它是在哪一步出錯的。指不出來，那就是整包模式的代價。

整包模式出錯時你找不到下手處，拆節點，哪裡壞改哪裡。多數工作用「串接」和「先分類再分派」兩種模式就夠。節點之間用固定欄位的 JSON 交接，欄位少、每格有允許值。欄位是合約，合約定了，兩邊才能各自改、各自換模型。

站內延伸

• 交接時該傳什麼、不該傳什麼 → 交接單
• 哪一段該由腳本、AI、還是人決定 → 誰當總指揮
• 流水線的實作 → 找方法AI 工作流程設計

來源： Anthropic：Building effective agents（五種模式的定義、「從簡單開始、只在有幫助時加複雜度」）。客服四節點與「欄位是合約」的說法是我自己的整理。