開發者線

先講為什麼要學這個。你在聊天視窗裡跟 Claude 一來一回，是「人在操作」；一次只能處理一件事，而且要有人坐在那裡。API 的意義是：你寫一段程式碼，裡面包含「呼叫 Claude」這個動作，然後這段程式碼可以被排程每天自動跑、可以接在你的客服後台後面、可以一秒鐘被觸發幾百次。舉例：絲萬萬每天進來上百則客戶訊息，如果用聊天視窗一則一則貼進去分類，要一個人做一整個早上；用 API，你寫一次「把訊息丟給 Claude，請它回傳分類」的程式，之後每則訊息自動跑完，人只需要看結果。這就是「從對話框畢業」的真正意義。

技術上，呼叫 Claude 就是對它的伺服器發一個 HTTP 請求（網路上程式互相溝通的標準方式），內容主要是一個 messages 陣列。每一則訊息長這樣：{ role: "user", content: "幫我分類這則訊息" }。Claude 回你的也是一則訊息，role 是 assistant。要做多輪對話（讓 Claude 記得前面講過什麼），你就把整段歷史——user、assistant、user……——照順序全部再送一次。這裡有個關鍵觀念：API 本身沒有記憶，每次呼叫都是全新的，「記憶」是你自己把歷史帶上去做出來的。

system prompt 是另一個獨立欄位，專門放「Claude 的身分與規矩」，例如「你是牙醫診所的預約助理，語氣親切，只回答看診相關問題，不確定就請對方留電話」。它跟一般 messages 分開，好處是這些規矩會穩定套用在整段對話，不會被使用者的訊息淹沒。這是你把「公司規矩」寫進系統最重要的地方。另外幾個常用參數：max_tokens 限制回應長度（token 是 AI 計算文字的單位，大約 1 個中文字約等於 1 到 2 個 token）；temperature 控制發散程度（0 最穩定、適合分類與抽取；高一點適合寫文案發想）；stop_sequences 讓 Claude 遇到指定字串就停。

選模型是最直接影響成本的決定。Claude 家族大致分三檔：Haiku 最快最便宜，適合「量大但單純」的任務，像客服訊息分類、標籤標註；Sonnet 是均衡主力，日常大多數工作用它；Opus 最強、也最貴，留給需要多步推理、複雜判斷的任務。中小企業最常犯的錯是全部用最貴的模型燒錢——正確做法是先用便宜的試，品質不夠再往上升。最後，streaming 適合有真人在等回應的場景（像即時客服機器人），讓文字邊生成邊顯示，體感快很多；如果是背景自動跑的批次任務（像半夜生報表），沒人在看，就不需要串流。

先講痛點。Claude 本質是個「文字生成器」——它靠訓練資料學會語言，但它不知道你公司此刻庫存剩幾件、不知道這張訂單的狀態、也沒辦法真的把一封 email 寄出去。官方課程用一個很好懂的例子：Claude 不擅長算大數字，你問它 1984135 乘以 9343116，它可能算錯。與其硬要它算，不如給它一個「計算機工具」，讓它把數字交給你的程式算，再拿正確答案回去。同樣道理搬到生意上：與其讓 Claude 憑空「猜」庫存，不如給它一個「查庫存工具」，它需要時就呼叫，你的程式去資料庫查真數字回傳。這樣 Claude 的回答才會是即時、正確、能負責的。

技術核心是 tool schema——一份給 Claude 看的工具說明書。每個工具要寫三塊：name（工具名，如 get_stock）、description（自然語言說明它做什麼、什麼情況該用它——這塊寫得好不好，直接決定 Claude 會不會在對的時機呼叫它，要當成寫給新同事的操作說明來寫）、input_schema（用 JSON Schema 描述它需要哪些參數，例如「產品編號，字串，必填」）。你把這些工具清單連同使用者的問題一起送給 Claude。

接下來是那個一定要記住的四步流程。第一步，你在請求裡帶上工具清單。第二步，Claude 判斷這題需不需要用工具、要用哪個、該帶什麼參數——如果要用，它回傳的 stop_reason 會是 tool_use，並附上工具名和它填好的參數（例如 get_stock，產品編號=A123）。第三步，你的程式看到 tool_use，就去實際執行——真的連資料庫查 A123 的庫存。第四步，你把查到的結果（例如「剩 12 件」）用一則 tool_result 訊息送回去，Claude 拿到後才組出給客戶看的最終回答（「A123 目前庫存 12 件，可以馬上出貨」）。這一來一回可能發生好幾輪，直到 Claude 不再需要工具、給出最終答案。

兩個進階觀念。第一，tool choice（工具選擇）可以控制 Claude 用工具的方式：預設 auto（它自己判斷要不要用）；也可以強制它一定要用某個工具，這在「我就是要它輸出結構化資料」的場景很有用——例如逼它把客訴一律整理成 {類別, 情緒, 急迫度} 的固定格式，這招常被拿來做結構化輸出。第二，你可以一次給它多個工具（查庫存、查物流、寄通知），它會依對話需要，一步步串起來用。最後務必記住那條安全線：Claude 永遠只是「說」要呼叫哪個工具，真正的執行是你的程式。所以危險動作（刪資料、付款、寄信給客戶）你都可以在自己的程式裡加確認、加權限控管——決定權始終在你這邊。

先講這解決什麼生意問題。假設絲萬萬有幾百份東西：報價原則、產品規格、常見客訴的標準回覆、公司政策。新人問「A 方案含不含後續維護？」，你希望有個機器人能秒答。但你不能把幾百份文件全部塞進每一次 prompt——太長、太貴，而且模型能一次讀的量（context window，上下文視窗）有上限。RAG 的聰明之處是：不要每次都給它全部，而是每次只找出跟這個問題最相關的那幾段，再交給 Claude。這樣又省又準，還能附上「這答案出自哪份文件第幾段」，讓人可以查證。

流程第一步是 chunking（切塊）：把長文件切成一段一段（例如每 300 到 500 字一塊，段落之間稍微重疊避免切斷語意）。為什麼要切？因為檢索與餵給模型都以「塊」為單位，塊太大會夾帶無關內容、太小又會斷章取義，切得好壞直接影響品質。第二步 embedding（做向量）：用一個 embedding 模型把每一塊文字轉成一長串數字（向量）。這串數字的魔法在於——意思接近的文字，數字也會接近。所以「維護費用」和「後續保養收費」就算用字不同，向量也會靠很近。把所有塊的向量存進向量資料庫（如 Pinecone、pgvector、Chroma），就完成了索引。

第三步是使用者提問時的檢索：把問題也轉成向量，去資料庫裡找「數字最接近」的前幾塊（例如取最相關的 3 到 5 塊）。這叫向量檢索，強在能跨越用詞差異抓語意。但它不是萬能——遇到精確的料號、型號、法條編號、人名，字面比對的 BM25/關鍵字檢索反而更準（你搜「A123」就是要一字不差的 A123，不是「語意接近」的東西）。所以成熟的系統常把兩種併用（稱為 hybrid search，混合檢索），再視需要加一層 rerank（重新排序）把最相關的往前挑。第四、五步就回到你熟悉的地方：把檢索到的幾塊文字，連同使用者問題，組成一個 prompt 餵給 Claude，並在 system prompt 交代「只根據我給你的資料回答，資料裡沒有就說不知道，並附出處」——這句話是壓制幻覺的關鍵。

最後也是最重要的判斷：不是每件事都需要 RAG。RAG 有它的建置與維護成本（要切塊、要跑 embedding、要顧向量資料庫）。判斷準則：資料量大（幾十份以上）、會經常變動、需要引用出處、或內容多到塞不進 prompt——這些情況用 RAG。反過來，如果你的「知識」只是一頁固定的公司規則、幾百字而已，直接寫進 system prompt 就好，硬套 RAG 是過度工程。中小企業常見的甜蜜點是：把「常被重複問、但答案就散在幾份內部文件裡」的東西做成 RAG 問答機器人——這正好呼應公司內部的 Majordomo 思路，用機器回答重複問題，人只處理例外。

先講為什麼非做不可。你在聊天視窗把一個客服分類 prompt 試了五、六次，覺得「嗯，很準」，就上線了。問題是：真實客戶一天丟進來的訊息有幾百種講法——有人打錯字、有人中英夾雜、有人一則訊息問三件事。你手動試的那幾題根本蓋不到。結果就是上線後默默錯一堆，你還不知道，直到客戶抱怨。eval 的精神就是把「憑感覺」換成「有一張考卷、有分數」。這在你要把 AI 功能當成產品、對客戶或老闆負責時，是不可跳過的一步。

eval 的第一塊是測試集——一批「輸入加期望輸出」的題目。輸入要盡量涵蓋真實世界的多樣性：正常的、刁鑽的、模稜兩可的、會出錯的邊界案例都要放進去。期望輸出可以是明確的標準答案（這則訊息應該分類為「退款」），也可以是一組評分標準（好的回覆應該：有同理心、給出下一步、不超過三句）。這份測試集一開始不用大，二三十題有代表性的，就比你隨手試五次強太多；之後每次線上出包，就把那個案例補進測試集，讓考卷越來越貼近現實。

第二塊是怎麼打分，官方課程分成兩大類。第一類 code-based grading（程式打分）：當答案能用程式客觀判斷對錯時用。例如分類任務——Claude 回「退款」，你的標準答案也是「退款」，程式比對相等就得分；或檢查輸出是不是合法 JSON、有沒有包含必要欄位、字數有沒有超標。這類又快又便宜又客觀，能用就用。第二類 model-based grading（模型打分，也叫 LLM as judge）：當答案沒有唯一正解時用——像「這封客訴回覆寫得好不好」沒有標準答案，你就寫一份評分準則，請另一個 Claude 當評審，依準則給分（例如語氣 1 到 5 分、有沒有答到重點 1 到 5 分）。用機器當評審，才能規模化評估幾百題主觀品質。

第三塊是怎麼用進日常。eval 不是上線前跑一次就丟，而是變成你的迴歸測試（regression test）：每次你調 prompt、換模型（例如想從 Sonnet 降到便宜的 Haiku 省錢）、或加新功能，都先讓整份測試集跑一遍，比較分數。分數上升代表改對了；掉了代表你改壞了、該回退。這樣你做每個決定都有數據撐腰，而不是「感覺新版好像比較好」。工具方面，除了自己寫腳本，官方課程也介紹用 Promptfoo 這類現成評估框架，它能同時支援程式打分與模型打分、一鍵比較不同 prompt 或模型的成績，中小企業想快速起步很好用。一句話總結：沒有 eval 的 AI 功能，等於沒測試就上線的軟體——能動，但你不知道它什麼時候會壞。

先把兩個詞講清楚，因為市場上被講得很玄。workflow（工作流）是：你這個工程師事先把「先做 A、再做 B、遇到這種情況走 C」的流程圖畫好、寫死在程式裡，AI 只在每一格負責它擅長的判斷或生成。agent（代理）是：你不畫流程圖，只告訴 AI「目標是什麼」跟「你有哪些工具」，讓它自己決定先做什麼、看到結果後再決定下一步，像個會自己想辦法的員工。Anthropic 官方在《Building Effective Agents》講得很直白：兩者沒有高下，是可控性與彈性的取捨——workflow 好預測、好除錯、成本可算；agent 有彈性但比較難預測、也比較貴。

workflow 有三種最實用的樣式，中小企業幾乎都在這裡解決。第一 prompt chaining（串接）：把一個大任務拆成一串固定步驟，前一步的輸出當後一步的輸入。例如自動生月報：第一步請 Claude 從原始數據抓出重點，第二步把重點寫成敘述，第三步潤稿成老闆看得懂的語氣——每步單純、好檢查。第二 routing（分流）：先用一個 Claude 把輸入分類，再送去對應的專門處理。例如客服訊息進來，先分成「退款／技術問題／一般詢問」，再各自走不同的回覆 prompt——比用一個萬能 prompt 硬扛所有情況準得多。第三 parallelization（並行）：把可以同時做的事拆開一起跑再彙整，例如要同時檢查一份合約的「金額、期限、違約條款」三個面向，三路並行再合併，又快又不互相干擾。

那什麼時候才真的需要 agent？當任務步驟數不固定、需要臨場判斷時。例如「幫我查清楚這位客戶為什麼上個月沒續約」——可能要先查 CRM，看到線索再去翻客服紀錄，發現是物流問題再去查訂單……你事先根本不知道要幾步、走哪條路。這種開放式任務就適合給 agent：給它查詢工具、給它目標，讓它自己一邊做一邊決定下一步，用了工具、看了結果、判斷還沒達成就繼續，直到搞定。代價是它比較難預測、可能繞路、token 花得多，所以你要設好上限（最多幾步）跟安全邊界（哪些動作要人確認）。

最後是這一站最重要、也最省你錢的一句話：能用 workflow 解決的，就不要用 agent。官方明確建議：先找最簡單能解決問題的方案，只有在簡單方案真的不夠時，才增加複雜度。很多中小企業一聽到「AI agent」就想做一個全自主、什麼都能幹的機器人，結果又貴又不穩、還很難除錯。實際上你盤點會發現，八成的自動化需求——每天生報表、客服分流、詢價自動回、把資料從 A 系統搬到 B 系統——步驟其實是固定的，一條寫死的 workflow 就搞定，既好預測又便宜。把 agent 留給那些真的沒辦法事先規劃路線的開放任務。判斷順序永遠是：能不能不用 AI（純程式）？不行，能不能一個 prompt 解決？不行，能不能用固定 workflow？真的都不行，才上 agent。