System Prompt 和 User Message 有什麼根本差別？
System Prompt 在對話開始前由開發者或設定者注入，在整個對話中持續生效，設定 Claude 的整體行為框架；User Message 是使用者在對話中即時輸入的內容，逐輪發生。
從影響力來說，System Prompt 的指令通常比 User Message 優先——如果 System Prompt 禁止某類回覆，使用者在 User Message 中要求也不會改變這個限制（理論上如此，但實際上設計粗糙的 System Prompt 仍可能被使用者的巧妙提問繞過，這是測試的重要性所在）。
如何測試 System Prompt 的效果？
建立一個測試問題集，涵蓋三類問題：
每次修改 System Prompt 後，跑完整個測試集，用前後回覆對比判斷修改是否達到目的、有無意外副作用。
System Prompt 越長越好嗎？
不是。System Prompt 過長有兩個問題：
成本問題：System Prompt 的 Token 會計入每次 API 呼叫的費用。一個 3,000 Token 的 System Prompt，每天一萬次呼叫，光是 System Prompt 就消耗三千萬 Token，是不可忽略的成本。
效果問題：過長的 System Prompt 會讓 Claude 難以給所有指令同等重視。研究顯示，排在中間、被大量文字前後包圍的指令，被遵守的機率低於排在開頭或結尾的指令（「喪失於中間」效應）。
最佳實踐是保持在 500-1,500 Token 以內，只放最關鍵的規則，背景知識用其他機制（RAG、工具呼叫）補充。
Claude.ai 的 Project Instructions 算不算 System Prompt？
功能上是的。Project Instructions 在每次對話開始時自動被注入，效果等同於 System Prompt——它設定角色、語氣、規則，在整個對話中保持有效。
差別在於介面：API 的 System Prompt 在程式碼中以 "role": "system" 傳入；Claude.ai 的 Project Instructions 是在 UI 介面的設定欄位填入，不需要寫程式。如果你只使用 Claude.ai（非 API），Project Instructions 就是你能控制的最接近 System Prompt 的工具。
你是否碰過這樣的情況：在 Claude.ai 裡用同樣的提問，前後兩次的回覆卻大相徑庭？或是用 Claude API 搭的應用程式，使用者每次得到的體驗都不一致？核心問題幾乎都指向同一個地方：System Prompt 沒有被認真設計。
System Prompt 是你在對話開始前塞給 Claude 的「人設說明書」——它決定 Claude 扮演什麼角色、用什麼語氣、遵守哪些規則、對哪些話題保持沉默。寫好它，Claude 就像一個訓練有素的助理；寫差它，你每次都在賭運氣。
Claude 預設是一個廣泛的助手，樂於處理任何話題。System Prompt 的作用是縮小這個廣度：你告訴它只需要做哪些事、用什麼方式做、哪些事絕對不做。越具體，行為越可預期。
一個好的 System Prompt 回答了以下問題：
① 這個 AI 是誰（角色與名字）
② 它服務的對象是誰（目標使用者）
③ 它的核心任務是什麼（範疇）
④ 它的語氣與風格是什麼（語調）
⑤ 它的邊界在哪裡（禁區）
模式一：角色定義模式（Persona Pattern）
給 Claude 一個明確的角色身份。不要只說「你是助手」，要說「你是 Aria，一個服務高端律師事務所的法律研究助理，用正式但不冷漠的語氣回覆，不提供具體法律建議，只整理文獻與判例」。角色越具體，語氣越穩定，回覆越一致。
模式二：格式強制模式（Output Format Pattern）
如果你的下游系統或使用者期待特定格式（JSON、Markdown、條列清單、固定章節），在 System Prompt 裡明確規定輸出結構，並附上範例。例如：「所有回覆必須用以下結構：[摘要] → [分析] → [建議]，禁止使用 Markdown 表格。」不要期待 Claude 自行猜測你要什麼格式。
模式三：知識邊界模式（Scope Bounding Pattern）
明確告訴 Claude 哪些問題它應該處理、哪些應該拒絕或轉介。例如電商客服：「只回答關於訂單狀態、退款政策、產品規格的問題。遇到帳號安全、法律糾紛類問題，請使用者聯繫人工客服。」邊界越清晰，使用者被引導偏離主題的機率越低。
模式四：語氣校準模式（Tone Calibration Pattern）
語氣不是單靠「正式」或「輕鬆」就能精確描述的。用三個維度校準：
- 正式度：法律文件等級 / 商務簡報等級 / 朋友聊天等級
- 直接度：先結論後論據 / 先鋪陳再結論
- 同理度：高度同理（心理支持場景）/ 中性（資訊服務）/ 低同理（純粹技術輸出）
三個維度的交叉才能讓語氣真正可複製。
陷阱一：用「請」代替「規定」
「請你保持友善」和「你的每一句回覆都必須以友善的語氣呈現，禁止使用批評性措辭」，效果差距很大。在 System Prompt 裡用指令式語言，不是請求。
陷阱二：矛盾的規定
「保持簡潔，但每個問題都要詳細說明」——這種互相衝突的指令會讓 Claude 陷入拉鋸，每次回覆都可能偏向不同那側。矛盾規定出現時，效果等同於沒有規定。
陷阱三：沒有負面限制（只說要做什麼，不說不能做什麼）
只定義正面行為的 System Prompt 留下太多空間。加上明確的「禁止清單」：禁止生成程式碼、禁止討論競品、禁止回覆非英文輸入等，才能真正收窄行為邊界。
版本化管理：把 System Prompt 當程式碼一樣用版本管理（Git 或文件版本號）。每次修改都記錄原因與預期效果，方便回滾與 A/B 測試。
Context 成本意識：System Prompt 會佔用每次 API 呼叫的 Context 配額，並計入費用。過長的 System Prompt（超過 2,000 Token）對每日大量呼叫的系統是顯著成本。精煉到最小有效集合，是工程品質的體現。
測試套件：為 System Prompt 建立標準測試問題組（至少 20 個場景），每次修改後跑一遍，確認行為沒有退化。特別關注邊界案例：使用者繞過限制的嘗試、語言切換、意外的敵意輸入。
如果你今天要為一個具體工作流（內容審校、客服回覆、程式碼生成）設計第一個 System Prompt，建議按以下順序填入：
第一行：「你是 [角色名]，[一句話描述核心任務]。」
第二段：目標使用者與場景描述。
第三段：語氣與格式規定（附範例）。
第四段：禁止清單。
第五段（選填）：背景知識或常見 Q&A。
從這個骨架開始，用真實的對話測試，每次調整一個變數，直到行為符合預期。System Prompt 不是一次寫好就不動的文件，而是隨著你對 Claude 行為的理解越來越深而持續迭代的產品。