為什麼「你是一個專業的 XX」這種寫法幾乎沒用，Claude 不是應該理解這個角色的意思嗎？
Claude 確實理解「行銷顧問」「文案編輯」這些詞的一般意義，這正是問題所在——因為 Claude 已經知道了，所以再說一次職稱不會增加任何新資訊。System Prompt 真正的價值在於補上 Claude「不可能自己猜到」的部分：你這個具體情境下的判斷標準是什麼、你在意哪些細節、輸出格式要長怎樣。職稱本身是一個範圍很廣的類別，同一個職稱底下可能有無數種不同的實際做法。
可以把職稱想像成「這個資料夾的名字」，而具體的判斷準則才是「資料夾裡實際的檔案」。只寫資料夾名字，Claude 只能靠自己對這個類別的一般理解去猜測裡面該有什麼；把實際的判斷規則寫進去，才是真正在提供內容。
除了審查文案，這個「寫出具體判斷準則」的方法還能用在哪些常見的日常任務上？
這套思路可以套用在任何「Claude 需要按某種標準做判斷或篩選」的任務上。例如整理會議記錄時，與其寫「幫我整理成重點摘要」，可以寫「按決議事項、待辦任務（含負責人與期限）、需要進一步討論的爭議點，這三類分別整理，凡是沒有明確負責人的待辦事項要特別標記出來」；回覆客服信件時，與其寫「用友善的語氣回覆」，可以寫「先重述客戶的問題確認理解正確，再給出具體解法，若解法需要客戶提供更多資訊，最後一段清楚列出需要客戶補充的項目」。
共通的模式是：把「一個籠統的形容詞或職稱」拆解成「幾個具體、可以逐項檢查的規則」。這個拆解過程本身，就是在幫 Claude 補齊它原本猜不到的那部分資訊。
判斷準則要寫到多細？會不會寫太多細節，反而讓 Claude 綁手綁腳失去彈性？
這是一個實際的取捨，判準是看任務本身的性質：如果任務有明確、不容出錯的標準流程（例如固定格式的資料驗證、必須照特定順序執行的步驟），就值得把準則寫得非常具體，甚至精確到「用哪個詞、按什麼順序」；但如果任務本身需要視情境彈性判斷（例如文案的語氣要不要活潑，取決於這次是寫給哪個受眾），把每個細節都寫死反而會讓 Claude 沒辦法根據上下文做出更好的判斷。
實務上可以把判準準則想像成一個光譜：一端是「開放原野」，任務本身容錯度高、多種做法都算成功，這時候給大方向、讓 Claude 自行判斷細節；另一端是「懸崖邊的窄橋」，任務容錯度低、只有一種正確做法，這時候該把每一步都寫清楚，不留模糊空間。判斷自己的任務落在光譜的哪個位置，再決定準則要寫多細，比一律追求「越詳細越好」更有效率。
如果我現在手上已經有一份寫得很籠統的 System Prompt，該怎麼一步步改成具體版本，而不是整份重寫？
不需要整份重寫，比較有效率的做法是先找出這份 Prompt 目前產出的結果裡，哪些地方讓你覺得「不太符合我要的」，針對這些落差回推「Claude 少了什麼判斷依據，才會做出這個選擇」。舉例來說，如果你發現 Claude 審查文案時漏掉了誇大用詞沒有標記，代表原本的 Prompt 裡完全沒提到「要檢查誇大用詞」這件事，那就把這條規則單獨補進去，而不是整份重寫。
實務上這是一個漸進累積的過程：每次發現輸出結果不符合預期，就回頭問「這是因為 Claude 少了什麼具體的判斷準則」，把答案補進 Prompt 裡，用個幾次之後，原本籠統的角色描述會自然被一條條具體規則取代。這個方法比一開始就想寫出完美版本更實際，因為很多該補的細節，往往是實際用過幾次、看到具體落差之後才會浮現出來的。
大多數人第一次寫 System Prompt，都會寫出類似「你是一個專業的行銷顧問，請幫我解答行銷相關問題」這樣的句子。這句話不算錯，但它幾乎沒有提供任何 Claude 原本不知道的資訊——Claude 本來就知道行銷顧問大概會做什麼，這句話沒有讓 Claude 的回答變得更準確、更貼近你實際需要的樣子。
一個真正有用的角色設定，靠的不是「職稱」，而是「這個角色在具體情境下會做的判斷」。以下用一個實際案例，示範怎麼把一句空泛的角色描述，改寫成能實際影響輸出品質的 System Prompt。
假設你需要 Claude 幫忙審查產品文案。空泛版本可能寫成：「你是一個資深文案編輯，請幫我審查以下文案」。這句話對 Claude 的實際幫助有限，因為「資深文案編輯」在不同公司、不同產品、不同受眾底下，審查標準可能完全不同。
更有效的寫法是把「這個角色實際會怎麼判斷」寫清楚：
範例 System Prompt：
「你負責審查電商產品文案，審查時依序檢查三件事：第一，文案裡的每一個功能描述是否有具體數字支撐（例如『續航力提升』要改成『續航力提升 40%』這種可驗證的寫法）；第二，是否用了『最』『第一』這類需要額外舉證的絕對化用詞，若有請標記出來；第三，文案結尾是否清楚傳達下一步行動（購買、加入購物車、了解更多）。針對每一點，先指出原文哪裡有問題，再給出具體修改後的版本，不要只給抽象建議。」
這個版本沒有用任何「厲害」的形容詞來描述角色本身，但它明確定義了三個具體的檢查項目、每個項目要抓的問題型態，以及輸出格式的要求（先指問題、再給修改版本，不要只給抽象建議）。這些資訊才是 Claude 原本不知道、需要你提供的部分。
寫完一句角色設定後，可以用這個測試問自己：「如果把這句話拿掉，Claude 的回答會不會變得不一樣？」如果答案是「不會有太大差別」，代表這句話大概率只是在描述職稱，沒有提供實際的判斷依據；如果答案是「會，因為少了這句話 Claude 就不知道該用什麼標準審查」，代表這句話真正發揮了作用。
下次要寫 System Prompt 時，先別急著想「這個角色聽起來要多專業」，改成先問自己：「如果我要向一個完全不了解這個領域、但邏輯能力很強的人交代這件事，我需要告訴他哪些具體的判斷規則？」把這些規則寫進 System Prompt 裡，通常會比堆砌形容詞更快得到你要的結果。這個原則不只適用在文案審查，任何需要「照特定標準做判斷」的任務——程式碼審查、資料分析、客服回覆——都適用同一套思路：具體的判斷準則,永遠比空泛的職稱描述有用。