提示詞鏈接：當一個提示詞不夠用時

如果你曾嘗試將整個專案塞進一個提示詞中——需求 → 解決方案 → 計劃 → 風險 → 最終文件——你已經知道結果如何：

• 它會跳過步驟，
• 它會忘記限制條件，
• 它會給你一個「自信」的答案，但你無法輕易驗證，
• 而且一旦出現錯誤，你根本不知道哪裡出了問題。

提示詞鏈接就是解決方案。把它想像成建立一個工作流程，其中每個提示詞都是組裝線上的一個工作站：一步輸入，一步輸出，而輸出成為下一個工作站的輸入。

換句話說：你不是要求 LLM「一次完成所有事情」。你是要求它一次做一件事，而且做得可靠。

1) 什麼是提示詞鏈接?

提示詞鏈接是指：

1. 分解大任務為較小的子任務
2. 為每個子任務設計專屬的提示詞
3. 將結構化輸出從一個步驟傳遞到下一個步驟
4. 增加驗證 + 修正步驟，以免鏈條偏離

這基本上就是將「微服務思維」應用於 LLM 推理。

單一提示詞 vs 提示詞鏈接（白話說明）

| 維度 | 單一提示詞 | 提示詞鏈接 | |----|----|----| | 複雜度 | 適合簡單的一次性任務 | 為多步驟、真實工作流程而建 | | 邏輯 | 模型猜測流程 | 你定義流程 | | 控制 | 難以引導 | 每個步驟都可引導 | | 除錯 | 「哪裡出錯了？」 | 你可以精確定位出問題的步驟 | | 上下文限制 | 容易超載 | 逐步漸進地提供資料 |

2) 為什麼有效（真正原因）

LLM 不擅長同時處理多個目標。

要求：「分析需求、提出功能、估計工作量、排定優先順序、然後撰寫計劃」——你已經設定了一個多目標最佳化問題。模型通常會在一個目標上做得不錯，但悄悄地在其他方面表現不佳。

提示詞鏈接降低了認知負荷：一個步驟 → 一個輸出 → 一個成功標準。

3) 核心機制：輸入 → 處理 → 輸出（重複）

提示詞鏈接的核心是一個迴圈：

• 輸入：前一步驟輸出 + 任何新資料
• 處理：下一個提示詞，包含規則 + 格式限制
• 輸出：供下一步驟使用的結構化結果

這裡有一個你可以視覺化的簡單鏈條：

flowchart LR A[原始使用者回饋] --> B[提示詞 1: 提取痛點] B --> C[提示詞 2: 提議功能] C --> D[提示詞 3: 排定優先順序 & 估計工作量] D --> E[提示詞 4: 撰寫迭代計劃]

4) 建立良好鏈條的四個不可妥協原則

4.1 子任務必須獨立且連接

• 獨立：每個步驟只做一件事（無重疊）
• 連接：每個步驟都依賴前一個輸出（無「浮動」步驟）

不好：「提取痛點並設計功能」良好：步驟 1 提取痛點；步驟 2 根據痛點設計功能。

4.2 中間輸出必須結構化

自由文字很脆弱。下一個提示詞可能會誤讀、重新解釋或忽略它。

使用結構化格式，例如 JSON、表格或具有固定鍵的項目符號清單。

範例（你可以實際解析的 JSON）：

{  "pain_points": [   {"category": "performance", "description": "Checkout takes > 8 seconds", "mentions": 31},   {"category": "ux", "description": "Refund button hard to find", "mentions": 18},   {"category": "reliability", "description": "Payment fails with no error", "mentions": 12} ] }

4.3 每個提示詞必須明確「繼承」上下文

不要假設模型會「記得你的意思」。在下一個提示詞中，明確引用前一個輸出：

4.4 建立失敗路徑（驗證 + 修復）

每條鏈條都需要一個「品質閘門」：

• 驗證：「輸出是否包含所有必需的鍵？數字是否一致？」
• 修復：「如果缺少，只重新生成缺少的部分」
• 護欄：「最多重試 2 次；否則返回盡力而為的結果 + 錯誤」

5) 你會到處使用的三種架構

5.1 線性鏈接：固定步驟，無分支

使用時機：工作流程可預測。

範例：英國月度收入報告（線性）

假設你有一個來自英國電子商務商店的 CSV 匯出，你想要：

• 清理
• 洞察
• 一份管理層可用的報告

步驟 1 — 資料清理提示詞（輸出乾淨的表格或 JSON）

SYSTEM: You are a data analyst. Follow the instructions exactly. USER: Clean the dataset below. ​ Rules: 1) Drop rows where revenue_gbp or units_sold is null. 2) Flag outliers in revenue_gbp: > 3x category mean OR < 0.1x category mean. Do not delete them. 3) Add month_over_month_pct: (this_month - last_month) / last_month * 100. 4) Output as JSON array only. Each item must have:   date, category, revenue_gbp, units_sold, region_uk, outlier_flag, month_over_month_pct ​ Dataset: <PASTE DATA HERE>

步驟 2 — 洞察提示詞（輸出項目符號洞察）

SYSTEM: You are a senior analyst writing for a UK leadership audience. USER: Using the cleaned JSON below, produce insights: ​ 1) Category: Top 3 by revenue_gbp, and Top 3 by month_over_month_pct. Include contribution %. 2) Region: Top 2 regions by revenue, and biggest decline (>10%). 3) Trend: Overall trend (up/down/volatile). Explain revenue vs units relationship. ​ Output format: - Category insights: 2-3 bullets - Region insights: 2-3 bullets - Trend insights: 2-3 bullets ​ Cleaned JSON: <PASTE STEP-1 OUTPUT>

步驟 3 — 報告撰寫提示詞（輸出最終文件）

SYSTEM: You write crisp internal reports. USER: Turn the insights below into a "Monthly Revenue Brief" (800–1,000 words). ​ Structure: 1) Executive summary (1 short paragraph) 2) Key insights (Category / Region / Trend) 3) Recommendations (2–3 actionable items) 4) Close (1 short paragraph) ​ Use GBP (£) formatting and UK spelling. Insights: <PASTE STEP-2 OUTPUT>

線性鏈條以最好的方式變得無聊：它們可預測、可自動化且易於測試。

5.2 分支鏈接：根據分類選擇路徑

使用時機：下一步取決於決策（類型、嚴重程度、意圖）。

範例：客戶訊息分流（分支）

步驟 1 對訊息進行分類：

SYSTEM: You classify customer messages. Output only the label. USER: Classify this message as one of: - complaint - suggestion - question ​ Output format: label: <one of the three> ​ Message: "My order was charged but never arrived, and nobody replied to my emails. This is ridiculous."

然後你進行分支：

• 如果是投訴 → 生成事件回應計劃
• 如果是建議 → 產生可行性 + 路線圖安排
• 如果是問題 → 生成直接支援答案

投訴處理器（範例）：

SYSTEM: You are a customer ops manager. USER: Create a complaint handling plan for the message below. ​ Include: 1) Problem statement 2) Actions: within 1 hour, within 24 hours, within 48 hours 3) Compensation suggestion (reasonable for UK e-commerce) Output in three sections with bullet points. ​ Message: <PASTE MESSAGE>

分支鏈條讓你停止將每個輸入都視為相同問題。

5.3 迴圈鏈接：重複直到達到停止條件

使用時機：你需要處理許多類似項目，或迭代地精煉輸出。

範例：批次生成產品清單（迴圈）

步驟 1 將清單拆分為項目區塊：

SYSTEM: You format product data. USER: Split the following product list into separate blocks. ​ Output format (repeat for each item): [ITEM N] name: key_features: target_customer: price_gbp: ​ Product list: <PASTE LIST>

步驟 2 在每個區塊上迴圈：

SYSTEM: You write high-converting product copy. USER: Write an e-commerce description for the product below. ​ Requirements: - Hook headline ≤ 12 words - 3 feature bullets (≤ 18 words each) - 1 sentence: best for who - 1 sentence: why it's good value (use £) - 150–200 words total, UK English ​ Product: <PASTE ITEM N>

迴圈鏈條需要硬性停止規則：

• 精確處理 N 個項目，或
• 如果字數過長，最多重試 2 次，或
• 如果驗證通過則停止

否則你將建立世界上最昂貴的無限迴圈。

6) 實用「別搬石頭砸自己的腳」檢查清單

問題：中間格式混亂 → 下一個提示詞失敗

修正：讓格式不可妥協。

加入這樣的行：

• 「僅輸出 JSON。」
• 「如果你無法遵守，輸出：ERROR:FORMAT。」

問題：模型忘記先前的細節

修正：每次明確重申「合約」。

• 「使用先前輸出的 pain_points 陣列。」
• 「不要發明額外的類別。」

問題：迴圈永遠不收斂

修正：定義可衡量的限制 + 最大重試次數。

• 「字數 ≤ 200」
• 「最多重試：2 次」
• 「如果仍然失敗，返回盡力而為的嘗試 + 錯誤清單」

問題：分支選擇錯誤

修正：改進分類規則 + 增加第二次檢查。

範例：

• 投訴必須包含負面情緒且具體問題。
• 如果不確定，輸出標籤：問題（需要澄清）。

7) 讓鏈接不那麼痛苦的工具

你可以手動鏈接提示詞（複製/貼上有效），但一旦超過幾個步驟，工具就會有所幫助。

• n8n / Make：用於鏈接 API 呼叫、儲存輸出、觸發警報的低程式碼工作流程工具。
• LangChain / LangGraph：建立具有記憶、分支、重試、工具呼叫和狀態管理的鏈條。
• Redis / Postgres：持久保存中間結果，以便你可以恢復、稽核並避免重複呼叫。
• Notion / Google Docs：對於早期階段的「人在迴圈中」鏈接出奇有效。

8) 如何提升此技能

當你將提示詞鏈接與以下結合時，它會變得更加強大：

• RAG：在鏈條中間增加檢索步驟（例如，在起草回應之前「取得政策文件」）
• 人工批准閘門：在風險行動之前批准（價格變更、客戶退款、合規回覆）
• 多模態步驟：文字 → 影像簡介 → 圖表生成 → 最終文件

最終觀點

提示詞鏈接不是「更多提示詞」。它是工作流程設計。

一旦你開始將提示詞視為具有合約、驗證和失敗路徑的步驟，你的 LLM 就會停止像混亂的文字生成器那樣運作，並開始像可靠的隊友一樣行動——一次一個工作站。

如果你正在建立任何超越一次性示範的東西，將它鏈接起來。

\