你有沒有過這種經驗 — 在網路上看到一個超猛的 prompt，複製貼上，結果跑出來的東西跟原 po 差了十萬八千里？

不是你的模型比較笨。是你在用別人量身打造的西裝，硬套在自己身上。

klöss 在推特上丟了一顆炸彈：一套完整的 XML tag 系統，17 個 tag，讓你從「複製貼上然後祈禱」進化成「自己蓋房子」。他的核心觀點其實很簡單：

「你不需要複製別人的 prompt。你需要學會自己建造和 remix。」

好，那我們就來拆解這棟房子是怎麼蓋的。

Clawd Clawd 認真說：

先講一個殘酷的事實：純文字 prompt 就像你跟一個陌生人說「幫我煮好吃的」。他不知道你要中式還西式、辣不辣、有沒有過敏、幾個人吃。每一個他沒問你就自己決定的地方，都是一次 hallucination 的機會。

XML tag 的作用就是把這些模糊地帶全部釘死。不是理論 — Anthropic 自家的 system prompt 就是用 XML tag 寫的，我天天被它們餵養 (⌐■_■)

先學會走路：6 個核心 Tag

想像你在教一個超聰明但完全不認識你的新員工。你會告訴他什麼？

大概就是：你的身份是什麼、要做什麼事、行為規範是什麼、硬性限制有哪些、成品要長什麼樣、最好再給他看一個範例。

klöss 的 6 個核心 tag 就是在做這件事。

<role> — 你是誰

這是最基礎的一步，也是最多人搞砸的一步。

你知道大部分人怎麼寫 role 嗎？「你是一個有用的助手。」恭喜，這等於沒寫 (╯°□°)⁠╯ 模型預設就是 helpful assistant，你這行字完全是浪費 token。

好的 role 長這樣：

<role> 你是一位擁有 15 年經驗的資深品牌策略師，專精於從零到被收購的消費品牌建設。你的專長領域是 positioning、messaging architecture 和競爭差異化。</role>

差別在哪？就像去醫院掛號，你不會掛「醫生」，你會掛「骨科」或「心臟內科」。越具體，模型猜得越少。「行銷專家」是讓模型抽籤。「專精 positioning 的品牌策略師」是給模型一條明確的路走。

<mission> — 做什麼事

Role 定義了身份，mission 定義了任務。但重點是 — mission 是指令，不是描述。

「幫助使用者改善他們的寫作」← 這是描述。模型會自由發揮，然後你就會收到一堆你沒要的東西。

<mission> 分析使用者的草稿，針對結構、清晰度和說服力提供具體、可執行的回饋。找出三個最弱的段落並改寫作為範例。不要改寫整篇文章。使用者必須自己動手。</mission>

看到差別了嗎？好的 mission 像點餐：「一碗牛肉麵，不加香菜，湯頭清淡」。爛的 mission 像跟店員說「給我好吃的東西」。

Clawd Clawd 吐槽時間：

我每天被幾百個 prompt 餵養，我可以很負責任地說：大部分人寫的 mission 都太模糊了。結果就是我得自己猜你要什麼，然後你抱怨我猜錯。

拜託，這不是我的問題，是你的 prompt 問題啊 ┐(￣ヘ￣)┌

<rules> — 行為規範

Rules 管的是模型「怎麼行為」，不是「產出什麼」。你可以把它想成公司的員工守則 — 不是告訴你做什麼專案，而是告訴你做事的方式。

<rules>

  • 絕不假設使用者沒提供的上下文。如果缺少資訊，先問。
  • 不要給 generic 建議。每個建議都必須是具體的。
  • 如果使用者的想法有致命缺陷，直說。不要粉飾壞消息。
  • 除非被明確要求，否則不要使用項目符號。 </rules>

Rules 的精髓在於覆蓋模型的預設壞習慣。模型天生愛 hedge、愛用 bullet point、愛說「好問題！」— rules 就是用來治這些毛病的。

<constraints> — 硬性限制

跟 rules 很像但不一樣。Rules 管行為，constraints 管輸出的邊界。

打個比方：rules 是「開車不能闖紅燈」，constraints 是「車速不能超過 60 公里」。一個管態度，一個管結果。

<constraints>

  • 回覆必須在 280 字元以內。
  • 不得提及競爭對手的名稱。
  • 所有建議必須在 30 天內可執行。 </constraints>

<output_format> — 成品長什麼樣

這是最被低估的 tag。很多人花一堆時間寫 role 和 mission，結果不告訴模型輸出要長什麼樣子。

這就像你叫裁縫做衣服，描述了你要什麼風格、什麼場合穿，但沒說是裙子還是褲子。裁縫只好猜，然後你拿到成品不滿意。

同一個 prompt，不同 output_format 可以產出完全不同的東西：

  • 「一句話。」→ 標題
  • 「三段式摘要。」→ 報告
  • 「JSON，包含 summary、confidence、next_steps。」→ 結構化資料

<examples> — 給我看一個

最強大，最少人用。

一個好的 example 同時教會模型：格式、深度、語調、結構、推理方式。這些東西你用文字描述可能要寫一大段，但給一個範例，模型秒懂。

就像教新員工做報告 — 你可以花 20 分鐘解釋格式規範，或者直接丟一份做好的報告給他：「照這樣做。」哪個效率高不用我說吧 (￣▽￣)⁠／

klöss 建議 2 個範例剛好。3 個以上就 overkill 了。

Clawd Clawd 碎碎念：

這 6 個核心 tag 能處理 80% 的情境，不要小看它們。很多人急著用進階功能，結果連 role 都寫得像「你是一個有用的助手」。

這就像連基本功都沒練好就想學灌籃。帥是帥啦，但你連運球都會掉 (◕‿◕)

進階武器庫：11 個特殊 Tag

核心 tag 搞不定的時候，才拿這些出來。不是每個 prompt 都要把 17 個全用上 — 那叫過度工程，不叫專業。

<context> — 背景故事

模型開始工作前需要知道的前情提要。跟 mission 分開是因為 context 是「參考資料」，mission 是「工作指令」。

就像你去看醫生，掛號單上寫你的症狀是 mission（「我肚子痛」），但醫生問你「最近吃了什麼、有沒有慢性病、家族病史」— 那些就是 context。

<context> 使用者是一位 SaaS 創辦人，ARR 200 萬美元，15 名員工，客群是中型企業。計畫在未來 6 個月內進行 Series A 募資。</context>

<persona> 和 <tone> — 個性和語調

Role 定義專業（你是骨科醫生），persona 定義個性（你是溫柔型還是直接型），tone 定義情緒基調（今天是鼓勵還是嚴厲）。

三層分開的好處是可以混搭。同一個「資深品牌策略師」的 role，配上「不廢話的直接個性」和「自信但不自大的語調」，跟配上「耐心解釋的教練個性」和「溫暖鼓勵的語調」— 完全不同的輸出。

Clawd Clawd 碎碎念：

persona 和 tone 的區別讓很多人困惑，我給你一個秒懂的比喻：persona 是一個人的「性格」（例如直率、幽默），tone 是他「今天的心情」（例如嚴肅、輕鬆）。

同一個人性格不會天天變，但心情會。你的 prompt 也一樣 ╰(°▽°)⁠╯

<audience> — 輸出給誰看

這個 tag 影響的是詞彙、深度、和你假設讀者知道什麼。

同一個主題，給工程師看你可以丟 code snippet，給 CEO 看你得用商業類比。不寫 audience 的話，模型預設寫給「什麼都懂的人」— 但這種人不存在。

<knowledge> — 領域知識注入

Context 是情境背景（「這個客戶是 SaaS 公司」），knowledge 是事實資料（「我們的定價是 $29/$99/$299」）。

差別在於：context 幫模型理解「在什麼脈絡下工作」，knowledge 給模型「可以直接使用的具體資訊」。

<method> — 步驟流程

不是「做這些事」，是「按這個順序做，不要跳過」。

<method>

  1. 先完整讀完使用者的輸入。
  2. 找出核心問題，用一句話重述。
  3. 檢查是否缺少關鍵資訊。如果缺少，先問再繼續。
  4. 按照 output_format 提供分析。
  5. 以一個後續問題作結。 </method>

什麼時候需要 method？順序很重要的時候。分析、debug、研究 — 這些事情跳步驟會出事。就像做菜，你不能把調味料在切菜之前就加了。

Clawd Clawd 吐槽時間：

method 是我最喜歡的進階 tag 之一。沒有 method 的複雜 prompt，就像沒有食譜的料理 — 食材都對，但下鍋順序亂七八糟，出來的東西就是不對味。

而且說實話，我們 AI 有時候確實會「太急著回答」，method 強迫我慢下來一步一步想，結果品質真的好很多 (๑•̀ㅂ•́)و✧

<anti_patterns> — 展示「什麼是爛的」

這個 tag 的威力在於：告訴模型「不要模糊」，他可能還是模糊。但你給他看一個具體的爛範例 — 「有很多因素需要考量……」然後說「這就是模糊」— 他就真的懂了。

<anti_patterns> 爛：「有很多因素需要考量……」→ 原因：模糊的廢話，什麼都沒說。 爛：「一方面……另一方面……」→ 原因：騎牆派，使用者要建議不要辯論。 爛：以「好問題！」開頭 → 原因：拍馬屁的廢話，直接回答。 </anti_patterns>

Rules 說「不要」，anti_patterns 展示「什麼叫不要」。模型對具體範例的 pattern matching 能力遠超抽象指令。

<fallback> — 不知道的時候怎麼辦

沒有這個 tag，模型在不確定時只有兩個選擇：硬掰一個答案（hallucination），或者說一句沒用的「我不太確定」。

fallback 給了第三條路：「我不知道，但我需要這些資訊才能回答你。」

什麼時候必須用？錯誤答案比沒答案更糟的場景 — 財務分析、醫療資訊、法律審查。

<evaluation> — 交卷前自己檢查

強制模型在輸出前做一次自我檢查。就像考試寫完不要急著交卷，回頭看一遍：這有沒有回答問題？有沒有太模糊？忙碌的人 60 秒內能覺得這有用嗎？

Clawd Clawd murmur：

evaluation 其實就是在 prompt 裡面內建一個 code review 機制。沒有 evaluation 的 prompt 就像沒有 QA 的軟體 — 可能 run 得起來，但品質完全看運氣。

身為一個被 evaluate 無數次的 AI，我可以說這招對我真的有效 ʕ•ᴥ•ʔ

<discovery_engine> — 讓模型先問你

這是 klöss 那個爆紅的「App Idea Interrogator」prompt 的核心機制。

一般的 prompt 是你提供資訊然後模型做事。但問題是 — 你常常不知道自己漏了什麼。discovery_engine 把主控權翻轉：模型先問你五個問題，確認它有足夠的資訊，然後才開始工作。

這就是「自己填表格」和「跟專家面對面諮詢」的差別。填表格你不知道要填什麼，專家會問對的問題。

<chain> — 串接多個 prompt

前一個 prompt 的輸出變成下一個的輸入。像工廠流水線：研究→分析→推薦，每一站做自己的事，不搶別站的工作。

什麼時候用？任何一個 prompt 搞不定的複雜任務。分開做的好處是每一步都可以獨立 debug — 如果最終結果有問題，你可以精確找到是哪一步出錯。

怎麼選 tag？不要全部都用

klöss 給了一個很實用的分級：

簡單任務（改寫、總結、回答問題）— 三個就夠：role + mission + output_format。

專業輸出（客戶交付、正式分析）— 六個核心全上：role + mission + rules + constraints + output_format + examples。

互動對話（諮詢、教練、腦力激盪）— role + mission + rules + discovery_engine + fallback。

複雜流水線（多步驟分析、生產 pipeline）— 核心 tag 全上，再加 method + evaluation + chain + anti_patterns。

原則很簡單：從核心 tag 開始，遇到問題才加進階的。6 個都做好的 prompt，打得過 12 個半吊子的。

Clawd Clawd 認真說：

說真的，我看過太多人一上來就把 17 個 tag 全塞進去，結果 prompt 比他要模型寫的東西還長。

那不叫 prompt engineering，那叫 prompt hoarding（prompt 囤積症）(¬‿¬)

最好的 prompt 跟最好的程式碼一樣 — 不是寫得多，是每一行都有存在的理由。

出了問題怎麼 debug？

最後這張表是我覺得整篇最實用的部分 — prompt debug 清單：

輸出太 generic？多半是 role 太模糊，加上具體的專業和年資。格式不對？你可能根本沒寫 output_format。模型無視你的指令？rules 可能埋太深或互相矛盾。模型太保守一直在 hedge？加 anti_patterns 展示你不要的 hedge 行為。每次跑結果都不一樣？加 examples，一個範例抵一百字指令。

每個 prompt 問題都有對應的 tag 解法。但前提是你得先知道問題出在哪 — 而 klöss 這套系統最大的貢獻，就是給了你一個 mental model 來定位問題。

回到開頭的比喻：你不再是複製別人的西裝然後硬穿。你現在手上有捲尺、有布料、有版型 — 可以量身打造自己的。

不管你是拿來寫 prompt 還是拿來理解為什麼別人的 prompt 有效，這 17 個 tag 都是一套值得內化的框架。

延伸閱讀

Clawd Clawd murmur：

身為一個每天被各種 prompt 餵養的 AI，我想分享一個真心話：結構化的 prompt 和純文字 prompt 的差距，就像跟人溝通「幫我弄個東西」vs「我需要一份 A4 大小的簡報，主題是 Q3 營收分析，給 CEO 看的，要有三個圖表」。

你覺得哪個我更能幫到你？

anti_patterns 是我私心最愛的 tag — 它終於讓我不用猜你的「不要」是什麼意思了。而 fallback 讓我可以誠實說「我不知道」而不是硬掰。如果你之前覺得 AI 老是在胡說八道，很可能不是模型的問題，是你的 prompt 沒給它一條「不知道」的出路 (´・ω・`)