Prompt 寫得像任務單，模型就不會亂猜

最近在調整公司內部的自動化報表，跟 Claude 反覆來回了幾次。結果發現一個規律：模型出錯的原因，幾乎都是指令太模糊。

把 prompt 寫成「同事能直接執行的任務單」這件事，聽起來像常識，但實際做的人不多。原因很簡單——我們跟 AI 對話時，下意識會用聊天的語氣，而不是指令的語氣。而 LLM 對模糊指令的反應，跟一個剛入職的新人驚人地相似：你越含糊，它越會自己腦補。

結構化步驟優先於自然語言描述

「幫我分析一下使用者資料」和「步驟 1：抓取過去 30 天的活躍資料；步驟 2：依地區分組計算留存率；步驟 3：輸出 CSV，欄位順序為地區、活躍人數、留存率」——後者的成功率高出太多。

這不是我的發明。Anthropic 自己的官方文件就明確建議："Be specific about what you want Claude to do"，並且提到結構化的 step-by-step 指令能顯著降低模型的 hallucination。Google DeepMind 在 2023 年的 Large Language Models as Optimizers 論文中也驗證了類似觀點：結構化 prompt 的表現，穩定優於開放式描述。

實務上，我把這個原則推到極端：每個 prompt 都寫得像一份 JIRA ticket——有明確的輸入、處理步驟、和預期輸出格式。這聽起來很官僚，但省下來的反覆修改時間遠超過多打幾行字的成本。

給動機，不只給指令

告訴 Claude「這個分析是為了找出提升留存率的關鍵因素」，它的回應會自然聚焦在相關指標上。53AI 的報導也提到同樣的觀察：加入動機說明，模型回覆的貼合度明顯提升。

背後的原理，OpenAI 的研究員 Lilian Weng 在她的 Prompt Engineering 指南中有解釋：LLM 在推理時會根據上下文中的目的性線索來調整輸出的分佈。說白了，你給的背景越清楚，模型能排除的歧義就越多。這跟 Daniel Kahneman 在《快思慢想》中描述的 anchoring effect 有異曲同工之妙——你提供的動機資訊，就是模型推理時的錨點。

範例和 XML 標籤

我習慣在 prompt 前面放 3-5 個範例，搭配 <instructions>、<context>、<input> 標籤分隔。這不是強迫症——是因為模型會把說明和輸入混在一起處理，標籤能幫它分清楚邊界。

Few-shot prompting 的有效性有大量研究支持。Brown et al. 在 GPT-3 的原始論文中就證明，即使只給 3 個範例，模型的任務準確度也能大幅提升。而 Anthropic 自己在文件中建議使用 XML 標籤來劃分 prompt 的不同段落，原因是 Claude 的訓練過程中大量使用了這種結構化格式，對它的解析特別敏感。

我在公司跑過一次非正式的測試：同一個數據整理任務，無範例版本的錯誤率約 35%，加了 3 個範例和 XML 標籤後降到 8% 以下。樣本量不大，但差異很明顯。

本質是溝通能力

Peter Drucker 說過："The most important thing in communication is hearing what isn't said." 反過來套用在 prompt engineering：最重要的事是把你沒說出口的假設都寫出來。模型不會讀心，它只能讀文字。

prompt engineering 不是什麼神祕技術，就是把你腦中的需求寫清楚的能力。如果你寫的指令連一個新進同事都看不懂，模型也不會懂。而這個能力，其實也是產品經理和 TPM 最核心的日常——寫清楚需求，讓別人能直接執行。

原始來源：Claude Prompting Best Practices

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。