Claude 提示詞指南
Claude 會仔細讀提示詞，所以值得認真寫。結構清晰、資料邊界明確，再請它先分析後回答，通常就能解決大部分問題。
基礎是一樣的
角色、背景、任務、約束、格式——Claude 和其他模型一樣需要這五項，提示詞工程完整指南已有說明。接下來講的是這些要素齊備之後，Claude 如何處理提示詞。歸根結底，它讀得仔細，所以你值得寫得仔細。
結構比措辭重要
長而有條理的提示詞不會讓 Claude 混亂，反而有幫助。其他模型可能偏好簡短，Claude 則適合像任務說明一樣組織：想要什麼、有哪些約束、處理什麼材料。標題、編號要求、簡短且有標籤的小節都能保留下來，每一項都能成為它應遵守的標準。
實際做法很簡單：別再把三個要求擠進一句話。相同資訊寫成三條編號要求，比一大段密集文字更容易被遵守。
把這段改清楚點但保持專業不要變長，第二段很亂也改一下
編輯下面的文字。1. 更清楚，但不要更長，修改版必須與原文等長或更短。2. 保持專業用語的正式程度，不要改得更親切。3. 第二段最薄弱，重寫前先用一行說明問題。文字：…
把資料與指令分開
提示詞最常見的問題，是模型分不清哪部分是任務，哪部分是任務物件。Claude 很擅長處理明確標記，把貼上內容放進 <draft>…</draft> 或 <email>…</email> 這樣的標籤即可，然後在指令中按名稱引用。
當資料包含看起來像指令的句子時，這點尤其重要。客戶郵件裡的「請總結附件」，是需要轉述的內容，而不是需要執行的命令。標籤能讓這一區別清清楚楚。
標籤把「這裡有一段文字」變成了一個有名字的物件。有了名字，指令就可以說「引用 <draft>」「不要修改 <spec> 裡的內容」，而不必依賴它在提示詞中的位置。
先分析，再回答
Claude 很願意按要求逐步分析問題，這個請求通常值得加上。「先列權衡，再給建議」明顯好於直接「給建議」：一方面它在下結論前會先分析，另一方面你能看見它是否錯誤地重視了某個因素，並指出來。
不需要分析時，反向指令也同樣有用：「一行回答，不要開場白，不要解釋推理。」它也會遵守。
這個功能應該自己開發還是購買
我們是 4 人工程團隊，正在決定自建 App 內搜尋，還是購買託管搜尋產品。先列出支援兩邊各自最有力的三個理由，標出哪些依賴我們尚未驗證的假設。再用兩句話給出建議，並指出哪一個事實會改變你的建議。
文風約束，它能守住
Claude 能細緻遵循語氣要求，所以很適合需要保留個人表達的編輯工作。不只說要改什麼，也說要保留什麼：「保留我的縮寫和句子長度，只修正文法、提升清晰度。」這類提示詞，它確實能執行。
不想讓它做的事也能同樣精確地規定。「不要加結尾總結段」「不要弱化批評」「不要加我沒要求的保留意見」，這些指令都能按字面生效。
長文件反而合適
貼上長文件，再問具體問題，正好發揮模型的優勢。準確性重要時，請它引用，而不是轉述：「引用你據此判斷的原句。」這樣，原本只能相信的答案，就變成幾秒鐘能核對的答案。
值得改掉的三個習慣
- 含糊客氣。「能不能幫我稍微精簡一下？」沒有給模型明確目標。說清精簡的意思：縮短三分之一、不用副詞、一句只表達一個觀點。
- 把指令埋起來。貼上長資料時，把任務放在最後，讓它成為最後讀到的內容，或者在開頭和結尾都寫一遍。
- 把初稿當定稿。一句準確的修正——「第三點太泛，換成文中一個具體例子」——通常比重寫整段提示詞更有效。
一個想法，按 Claude 的閱讀方式組織
把 AI 工具設為 Claude，點按 AI 鍵。Prompt AI Keyboard 會把粗略的一句話變成結構清晰、約束明確的提示詞，適合這個模型，就在你正在輸入的 App 中。
常見問題
Claude 提示詞應該怎樣組織？
像任務說明，而不是一句話：先寫任務，再列編號約束，最後放處理材料。Claude 很能遵循較長但有條理的提示詞，三條編號要求比把同樣內容塞進一段話更可靠。
為什麼給 Claude 的貼上文字要加標籤？
為了讓模型區分任務和處理物件。用以下這類標記包住資料，
讓 Claude 先分析，真的能改善回答嗎？
通常能。「先列權衡，再給建議」比直接「給建議」更好，也讓你看見它是否給某個因素分配了錯誤的權重，以便糾正。反過來，如果想要簡短回答，「一行回答，不要開場白」也能得到遵循。