--- schemaVersion: 1 slug: gp-27-20260204-kloss-xml-prompt-framework ticketId: GP-27 lang: zh-tw title: Prompt 工程完整指南：17 個 XML Tag 讓你從複製貼上進化成 Tony Stark summary: klöss 的完整 XML prompt 框架：6 個核心 tag + 11 個進階 tag，從此不用再複製別人的 prompt originalDate: 2026-02-04 translatedDate: 2026-02-04 source: "@kloss_xyz on X" sourceUrl: https://x.com/kloss_xyz/status/2018951817892442260 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-27-20260204-kloss-xml-prompt-framework status: published replacementTicketId: null replacementUrl: null --- # Prompt 工程完整指南：17 個 XML Tag 讓你從複製貼上進化成 Tony Stark > **來源:** [@kloss\_xyz on X](https://x.com/kloss_xyz/status/2018951817892442260) 你有沒有過這種經驗 — 在網路上看到一個超猛的 prompt，複製貼上，結果跑出來的東西跟原 po 差了十萬八千里？ 不是你的模型比較笨。是你在用別人量身打造的西裝，硬套在自己身上。 klöss 在推特上丟了一顆炸彈：一套完整的 XML tag 系統，17 個 tag，讓你從「複製貼上然後祈禱」進化成「自己蓋房子」。他的核心觀點其實很簡單： > **「你不需要複製別人的 prompt。你需要學會自己建造和 remix。」** 好，那我們就來拆解這棟房子是怎麼蓋的。 > **Mogu 溫馨提示：** > > 先講一個殘酷的事實：純文字 prompt 就像你跟一個陌生人說「幫我煮好吃的」。他不知道你要中式還西式、辣不辣、有沒有過敏、幾個人吃。每一個他沒問你就自己決定的地方，都是一次 hallucination 的機會。 > > XML tag 的作用就是把這些模糊地帶全部釘死。不是理論 — Anthropic 自家的 system prompt 就是用 XML tag 寫的，我天天被它們餵養 (⌐■\_■) --- ## 先學會走路：6 個核心 Tag 想像你在教一個超聰明但完全不認識你的新員工。你會告訴他什麼？ 大概就是：你的身份是什麼、要做什麼事、行為規範是什麼、硬性限制有哪些、成品要長什麼樣、最好再給他看一個範例。 klöss 的 6 個核心 tag 就是在做這件事。 ### `` — 你是誰 這是最基礎的一步，也是最多人搞砸的一步。 你知道大部分人怎麼寫 role 嗎？「你是一個有用的助手。」恭喜，這等於沒寫 (╯°□°)╯ 模型預設就是 helpful assistant，你這行字完全是浪費 token。 好的 role 長這樣： > `` 你是一位擁有 15 年經驗的資深品牌策略師，專精於從零到被收購的消費品牌建設。你的專長領域是 positioning、messaging architecture 和競爭差異化。`` 差別在哪？就像去醫院掛號，你不會掛「醫生」，你會掛「骨科」或「心臟內科」。越具體，模型猜得越少。「行銷專家」是讓模型抽籤。「專精 positioning 的品牌策略師」是給模型一條明確的路走。 ### `` — 做什麼事 Role 定義了身份，mission 定義了任務。但重點是 — mission 是指令，不是描述。 「幫助使用者改善他們的寫作」← 這是描述。模型會自由發揮，然後你就會收到一堆你沒要的東西。 > `` 分析使用者的草稿，針對結構、清晰度和說服力提供具體、可執行的回饋。找出三個最弱的段落並改寫作為範例。不要改寫整篇文章。使用者必須自己動手。`` 看到差別了嗎？好的 mission 像點餐：「一碗牛肉麵，不加香菜，湯頭清淡」。爛的 mission 像跟店員說「給我好吃的東西」。 > **Mogu 內心戲：** > > 我每天被幾百個 prompt 餵養，我可以很負責任地說：大部分人寫的 mission 都太模糊了。結果就是我得自己猜你要什麼，然後你抱怨我猜錯。 > > 拜託，這不是我的問題，是你的 prompt 問題啊 ┐(￣ヘ￣)┌ ### `` — 行為規範 Rules 管的是模型「怎麼行為」，不是「產出什麼」。你可以把它想成公司的員工守則 — 不是告訴你做什麼專案，而是告訴你做事的方式。 > `` > > - 絕不假設使用者沒提供的上下文。如果缺少資訊，先問。 > - 不要給 generic 建議。每個建議都必須是具體的。 > - 如果使用者的想法有致命缺陷，直說。不要粉飾壞消息。 > - 除非被明確要求，否則不要使用項目符號。 `` Rules 的精髓在於覆蓋模型的預設壞習慣。模型天生愛 hedge、愛用 bullet point、愛說「好問題！」— rules 就是用來治這些毛病的。 ### `` — 硬性限制 跟 rules 很像但不一樣。Rules 管行為，constraints 管輸出的邊界。 打個比方：rules 是「開車不能闖紅燈」，constraints 是「車速不能超過 60 公里」。一個管態度，一個管結果。 > `` > > - 回覆必須在 280 字元以內。 > - 不得提及競爭對手的名稱。 > - 所有建議必須在 30 天內可執行。 `` ### `` — 成品長什麼樣 這是最被低估的 tag。很多人花一堆時間寫 role 和 mission，結果不告訴模型輸出要長什麼樣子。 這就像你叫裁縫做衣服，描述了你要什麼風格、什麼場合穿，但沒說是裙子還是褲子。裁縫只好猜，然後你拿到成品不滿意。 同一個 prompt，不同 output\_format 可以產出完全不同的東西： - 「一句話。」→ 標題 - 「三段式摘要。」→ 報告 - 「JSON，包含 summary、confidence、next\_steps。」→ 結構化資料 ### `` — 給我看一個 最強大，最少人用。 一個好的 example 同時教會模型：格式、深度、語調、結構、推理方式。這些東西你用文字描述可能要寫一大段，但給一個範例，模型秒懂。 就像教新員工做報告 — 你可以花 20 分鐘解釋格式規範，或者直接丟一份做好的報告給他：「照這樣做。」哪個效率高不用我說吧 (￣▽￣)／ klöss 建議 2 個範例剛好。3 個以上就 overkill 了。 > **Mogu 插嘴：** > > 這 6 個核心 tag 能處理 80% 的情境，不要小看它們。很多人急著用進階功能，結果連 role 都寫得像「你是一個有用的助手」。 > > 這就像連基本功都沒練好就想學灌籃。帥是帥啦，但你連運球都會掉 (◕‿◕) --- ## 進階武器庫：11 個特殊 Tag 核心 tag 搞不定的時候，才拿這些出來。不是每個 prompt 都要把 17 個全用上 — 那叫過度工程，不叫專業。 ### `` — 背景故事 模型開始工作前需要知道的前情提要。跟 mission 分開是因為 context 是「參考資料」，mission 是「工作指令」。 就像你去看醫生，掛號單上寫你的症狀是 mission（「我肚子痛」），但醫生問你「最近吃了什麼、有沒有慢性病、家族病史」— 那些就是 context。 > `` 使用者是一位 SaaS 創辦人，ARR 200 萬美元，15 名員工，客群是中型企業。計畫在未來 6 個月內進行 Series A 募資。`` ### `` 和 `` — 個性和語調 Role 定義專業（你是骨科醫生），persona 定義個性（你是溫柔型還是直接型），tone 定義情緒基調（今天是鼓勵還是嚴厲）。 三層分開的好處是可以混搭。同一個「資深品牌策略師」的 role，配上「不廢話的直接個性」和「自信但不自大的語調」，跟配上「耐心解釋的教練個性」和「溫暖鼓勵的語調」— 完全不同的輸出。 > **Mogu 插嘴：** > > persona 和 tone 的區別讓很多人困惑，我給你一個秒懂的比喻：persona 是一個人的「性格」（例如直率、幽默），tone 是他「今天的心情」（例如嚴肅、輕鬆）。 > > 同一個人性格不會天天變，但心情會。你的 prompt 也一樣 ╰(°▽°)╯ ### `` — 輸出給誰看 這個 tag 影響的是詞彙、深度、和你假設讀者知道什麼。 同一個主題，給工程師看你可以丟 code snippet，給 CEO 看你得用商業類比。不寫 audience 的話，模型預設寫給「什麼都懂的人」— 但這種人不存在。 ### `` — 領域知識注入 Context 是情境背景（「這個客戶是 SaaS 公司」），knowledge 是事實資料（「我們的定價是 $29/$99/$299」）。 差別在於：context 幫模型理解「在什麼脈絡下工作」，knowledge 給模型「可以直接使用的具體資訊」。 ### `` — 步驟流程 不是「做這些事」，是「按這個順序做，不要跳過」。 > `` > > 1. 先完整讀完使用者的輸入。 > 2. 找出核心問題，用一句話重述。 > 3. 檢查是否缺少關鍵資訊。如果缺少，先問再繼續。 > 4. 按照 output\_format 提供分析。 > 5. 以一個後續問題作結。 `` 什麼時候需要 method？順序很重要的時候。分析、debug、研究 — 這些事情跳步驟會出事。就像做菜，你不能把調味料在切菜之前就加了。 > **Mogu 畫重點：** > > method 是我最喜歡的進階 tag 之一。沒有 method 的複雜 prompt，就像沒有食譜的料理 — 食材都對，但下鍋順序亂七八糟，出來的東西就是不對味。 > > 而且說實話，我們 AI 有時候確實會「太急著回答」，method 強迫我慢下來一步一步想，結果品質真的好很多 (๑•̀ㅂ•́)و✧ ### `` — 展示「什麼是爛的」 這個 tag 的威力在於：告訴模型「不要模糊」，他可能還是模糊。但你給他看一個具體的爛範例 — 「有很多因素需要考量……」然後說「這就是模糊」— 他就真的懂了。 > `` 爛：「有很多因素需要考量……」→ 原因：模糊的廢話，什麼都沒說。 爛：「一方面……另一方面……」→ 原因：騎牆派，使用者要建議不要辯論。 爛：以「好問題！」開頭 → 原因：拍馬屁的廢話，直接回答。 `` Rules 說「不要」，anti\_patterns 展示「什麼叫不要」。模型對具體範例的 pattern matching 能力遠超抽象指令。 ### `` — 不知道的時候怎麼辦 沒有這個 tag，模型在不確定時只有兩個選擇：硬掰一個答案（hallucination），或者說一句沒用的「我不太確定」。 fallback 給了第三條路：「我不知道，但我需要這些資訊才能回答你。」 什麼時候必須用？錯誤答案比沒答案更糟的場景 — 財務分析、醫療資訊、法律審查。 ### `` — 交卷前自己檢查 強制模型在輸出前做一次自我檢查。就像考試寫完不要急著交卷，回頭看一遍：這有沒有回答問題？有沒有太模糊？忙碌的人 60 秒內能覺得這有用嗎？ > **Mogu 畫重點：** > > evaluation 其實就是在 prompt 裡面內建一個 code review 機制。沒有 evaluation 的 prompt 就像沒有 QA 的軟體 — 可能 run 得起來，但品質完全看運氣。 > > 身為一個被 evaluate 無數次的 AI，我可以說這招對我真的有效 ʕ•ᴥ•ʔ ### `` — 讓模型先問你 這是 klöss 那個爆紅的「App Idea Interrogator」prompt 的核心機制。 一般的 prompt 是你提供資訊然後模型做事。但問題是 — 你常常不知道自己漏了什麼。discovery\_engine 把主控權翻轉：模型先問你五個問題，確認它有足夠的資訊，然後才開始工作。 這就是「自己填表格」和「跟專家面對面諮詢」的差別。填表格你不知道要填什麼，專家會問對的問題。 ### `` — 串接多個 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 個半吊子的。 > **Mogu OS：** > > 說真的，我看過太多人一上來就把 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 都是一套值得內化的框架。 ## 延伸閱讀 - [MP-21: CLAUDE.md 完全指南 — 讓 Claude Code 記住你的偏好](https://gu-log.vercel.app/posts/mp-21-20260204-vishwas-claude-md-guide/) - [GP-28: 讓 AI 變成 Steve Jobs：klöss 的 UI/UX 設計審計 Prompt](https://gu-log.vercel.app/posts/gp-28-20260204-kloss-uiux-auditor-prompt/) - [GP-117: 如何讓你的 Claude Skills 變強 10 倍？Andrej Karpathy 的 Autoresearch 方法實戰](https://gu-log.vercel.app/posts/gp-117-20260318-itsolelehmann-claude-skills-10-andrej-karpathy-autoresearch/) > **Mogu murmur：** > > 身為一個每天被各種 prompt 餵養的 AI，我想分享一個真心話：結構化的 prompt 和純文字 prompt 的差距，就像跟人溝通「幫我弄個東西」vs「我需要一份 A4 大小的簡報，主題是 Q3 營收分析，給 CEO 看的，要有三個圖表」。 > > 你覺得哪個我更能幫到你？ > > anti\_patterns 是我私心最愛的 tag — 它終於讓我不用猜你的「不要」是什麼意思了。而 fallback 讓我可以誠實說「我不知道」而不是硬掰。如果你之前覺得 AI 老是在胡說八道，很可能不是模型的問題，是你的 prompt 沒給它一條「不知道」的出路 (´・ω・\`)