Prompt Chaining

Prompt Chaining 和直接寫一個很長的提示詞有什麼實質差別？

差別在三個層面：品質、可控性、和效率。

品質：Claude 對單一提示詞的注意力有限。一個提示詞要求它同時做「收集資料、分析資料、整理格式、撰寫報告」，它的注意力會被稀釋，每件事都做得不夠深入。拆成四個步驟，每個步驟 Claude 只需要專注一件事，品質通常明顯提升。

可控性：單一長提示詞出了問題，你很難知道是哪個環節出錯，也很難只修改那個環節。Prompt Chaining 讓每一步的輸出都是可見的，你能在第二步就發現問題，然後只重做第二步，不需要整個任務從頭來過。

效率：看起來多個步驟比一個步驟更麻煩，但實際上節省時間。因為你每一步都在做審查和確認，你的參與讓每一步的品質更穩定，最終出來的東西需要後期修改的機率大幅降低。

怎麼決定要把一個任務拆成幾個步驟？有沒有原則？

拆分的原則很簡單：每個步驟應該只做一件需要不同「思考模式」的事。

當你發現一個步驟需要：（一）同時用不同標準評估事物（例如「找資料」同時「判斷資料好不好」），（二）同時產出多種不同類型的內容（例如「寫摘要」同時「寫批評意見」），或（三）切換視角（例如「用創意角度想」然後「用批判角度審查」）——這就是應該拆成兩個步驟的信號。

一般來說，一個好的 Prompt Chaining 任務有 3–7 個步驟。少於 3 個步驟通常代表任務本身可以用一個提示詞解決；超過 7 個步驟代表任務可能太複雜，應該先考慮是否可以進一步分成兩個獨立的工作流。

判斷步驟數的快速方法：把你的任務用動詞列出來，每個動詞就是一個潛在的步驟。例如「研究、整理、撰寫、審閱、優化」= 5 個步驟。如果某兩個動詞描述的是高度相關的動作，可以合併成一步。

Prompt Chaining 聽起來很麻煩，有沒有辦法讓它更自動化？

有，而且隨著 Claude 的工具能力越來越強，自動化 Prompt Chaining 的方式也越來越多。

方式一：在同一個 Claude 對話裡手動推進。這是最基本的方式——你在對話裡依序輸入每個步驟的提示詞，並手動把 Claude 的輸出傳給下一步。不需要任何技術，但需要你全程參與。

方式二：用 Claude Projects 配合固定模板。在 Claude Projects 的 Custom Instructions 裡，設定這個工作流的整體框架和角色說明，讓每次進入這個 Project 的對話都自動載入這個工作流的背景設定，減少每次都要重新說明的時間。

方式三：API + 程式碼自動串接。對於技術用戶，可以用 Python 或 Node.js 撰寫腳本，自動把每個步驟的提示詞發送給 Claude API，並把輸出自動傳給下一步。這是真正的全自動化 Prompt Chaining，適合需要高頻重複執行的工作流。

方式四：用 Claude Code 建立自動化工具。Anthropic 的 Claude Code 工具讓你能用更簡單的方式建立自動化的 Prompt Chaining 工作流，不需要從頭寫完整的程式碼。

Prompt Chaining 和 RAG（檢索增強生成）有什麼關係？

這兩個概念經常一起出現，因為它們常常搭配使用，但本質上是不同的東西。

Prompt Chaining 是關於任務的結構：把一個複雜任務拆成多個步驟，讓每個步驟各自完成一個子任務，最終串起來完成整個任務。

RAG（Retrieval-Augmented Generation） 是關於知識來源：在 Claude 生成回答之前，先從外部資料庫或文件庫裡找到相關資料，把這些資料加入到提示詞裡，讓 Claude 的回答基於你的特定知識庫而不只是它的訓練資料。

兩者最常見的搭配方式：在 Prompt Chaining 的某個步驟裡，加入 RAG 來提供即時的外部知識。例如：步驟一（RAG：從你的文件庫裡找到相關段落）→ 步驟二（Claude：根據找到的段落生成摘要）→ 步驟三（Claude：把摘要格式化成報告）。

對於職場用戶來說，最簡單的「RAG」替代品就是：在 Prompt Chaining 的第一步，讓 Claude 從你貼入的大量文件中找到相關段落，然後把找到的段落用於後續步驟。這不是技術上嚴格定義的 RAG，但達到了類似的效果。