偷師高手：如何用洩漏提示詞學會角色設定與工具調用？

為什麼洩漏提示詞是 prompt engineering 的最佳教材？

2025 年 5 月，GitHub 上出現了一個名為 asgeirtj/system_prompts_leaks 的開源專案，目標只有一個：系統性收集各大 AI 聊天機器人的系統提示詞。短短 14 個月內，這個專案累積超過 42,000 顆星、7,000 多個分支，登上 GitHub Trending，甚至被《華盛頓郵報》引用報導。這股熱潮背後的原因很直接——這些提示詞原本是各家 AI 公司最機密的「行為控制層」，現在卻被攤在陽光下，讓所有人直接觀摩頂尖團隊如何設計角色個性、安全規則與工具調用邏輯。

對於台灣的中小企業與技術團隊來說，這等於拿到了一份「實戰教材」。過去我們只能從官方文件或訪談中拼湊 prompt engineering 的心法，但那些資訊往往經過修飾、缺乏細節。而 system_prompts_leaks 收錄了超過 100 個來自 14 家廠商的獨立系統提示詞，從 ChatGPT 5.5 Thinking、Claude Opus 4.6，到 Gemini 3.1 Pro、Grok，甚至 Cursor、Copilot 這類開發工具型 AI 的提示詞都一應俱全。這些內容不是理論，而是真正上線運作的生產級指令。

角色個性的設定，是第一個值得偷師的重點。例如 Anthropic 的 Claude 系列採用「憲法 AI」框架，在提示詞中明確定義一套價值原則，要求模型在回答時必須遵循「助人、誠實、無害」的底線，並附上具體的拒絕規則。OpenAI 的 ChatGPT 則使用「分層拒絕系統」，從 GPT-5.4 到 5.5 Thinking 版本，拒絕回答敏感話題的規則從 12 條擴充到 18 條，每一條都詳細說明觸發條件與應對方式。而 xAI 的 Grok 走的是「幽默、未過濾」路線，提示詞中特別允許模型用諷刺或吐槽的方式回應，甚至鼓勵在安全範圍內展現「個性」。開發者只要對比這些提示詞，就能立刻理解同一套底層模型，如何透過幾百字的文字塑造出截然不同的助手風格。

更令人驚豔的是工具調用邏輯的設計。以洩漏的 Claude Fable5 系統提示詞為例，一份提示詞長達 1,600 多行，其中將近一半的篇幅——大約 800 行——都在逐一定義工具。從查天氣、搜地點、跑 bash 指令，到建立檔案、起草郵件、彈出選項詢問使用者，每個工具都附上完整的參數 schema 與使用說明。最關鍵的是，這些描述不僅告訴模型「有什麼工具」，更詳細規範「什麼時候用、什麼時候千萬別用、怎麼用才不出錯」。例如 ask_user_input 工具教模型「何時該閉嘴、何時該反問使用者」；create_file 工具透過參數順序強迫模型「先想清楚路徑與內容再動手」。這些設計邏輯，正是打造穩定 Agent 的核心技術。

對於正在開發自有 AI 產品或內部工具的台灣技術團隊，這些洩漏提示詞提供了三層價值。第一，你可以直接複製頂尖團隊的角色設定框架——從安全邊界的描述方式、拒絕觸發的條件措辭，到個性化回應的語氣控制，都有現成的參考範本。第二，工具調用的描述結構堪稱教科書級別：如何為每個工具撰寫「何時使用」與「何時避免」的說明，如何透過參數順序引導模型的行動流程，這些細節決定了 Agent 的可靠度。第三，版本更新紀錄本身就像一部進化史——從 ChatGPT 5.4 到 5.5 Thinking，提示詞中的安全規則與工具描述都在快速迭代，觀察這些變化就能提前掌握業界的最新設計趨勢。

當然，這些提示詞的取得涉及法律與道德爭議，專案以 CC0-1.0 公有領域授權發布，試圖避開商業機密與版權問題。但無論爭議如何，對 prompt engineering 學習者來說，它們確實是前所未有的教材。替代方案有限公司在系列第一篇中深入解析了從憲法 AI 到分層拒絕的設計哲學，而逆向工程實戰篇則分享瞭如何透過 MITM 代理與瀏覽器端點擷取這些提示詞。當你能直接看到 OpenAI、Anthropic、Google 的系統提示詞真跡，你學到的不只是技巧，而是頂尖團隊如何思考「AI 應該怎麼被控制」這一根本問題。

說到底，洩漏提示詞之所以是最佳教材，不是因為它們「洩漏」了秘密，而是因為它們把 prompt engineering 從一門玄學，變成了可以拆解、比對、複製的工程學。你不再需要猜測「為什麼這個模型這樣回應」，而是可以直接翻開它的「操作手冊」，找到每一條規則、每一個工具定義的來龍去脈。對台灣的開發者而言，這正是縮短學習曲線、快速跟上全球水準的捷徑。

角色設定與工具調用：系統提示詞的兩大核心

翻開 system_prompts_leaks 收錄的 100 多份系統提示詞，你會發現它們幾乎都遵循一套相同的「骨架」：前半段定義「AI 該怎麼說話」，後半段定義「AI 能用什麼工具做事」。

這並不是巧合。所有主流 AI 助手——從 ChatGPT、Claude、Gemini 到 Grok——都採用這種「二分法」設計，因為角色設定與工具調用正好對應兩個根本問題：AI 該以什麼人格面對使用者？以及 AI 該用什麼權限去執行任務？

以 xAI 的 Grok 為例，它的角色設定開宗明義寫著「幽默、未過濾、直言不諱」，甚至允許使用粗俗用語；而 Anthropic 的 Claude（Opus 4.6）則強調「憲法 AI」的紅線——永遠誠實、無害、不協助非法行為。

這些個性化設定並非憑空而來，而是由數十條規則層層疊加。根據 替代方案有限公司 在 從憲法AI到分層拒絕 中的分析，OpenAI 的 ChatGPT 5.5 Thinking 版系統提示詞中，「拒絕回答敏感話題」的規則從 5.4 版的 12 條一口氣擴充到 18 條，每一條都精確定義觸發條件與回覆模板。

另一邊，知識邊界則決定 AI 能回答什麼、不能回答什麼。例如 Gemini 3.1 Pro 的提示詞明確禁止模型「猜測尚未公開的 Google 產品時程」，而 Perplexity 則限制模型「不得引用自己生成的內容作為資料來源」。這些規則就像隱形的護欄，確保 AI 不會越界。

如果角色設定是 AI 的「內在性格」，工具調用就是它的「外在能力」。最驚人的案例莫過於 Claude Fable 5 的系統提示詞——這份長達 1600 多行的文件，光是工具定義就吃掉近一半篇幅。開發者一口氣為 Claude 裝了十七、八個工具：執行 bash、建立檔案、修改檔案、搜尋網頁、擷取網頁內容、查地點、畫地圖、查天氣、查體育比分、搜圖、起草訊息、跳出選項詢問使用者……活脫脫一個全能選手的工具箱。

每個工具的定義可不是簡單幾行參數說明。以「ask_user_input」這個工具為例，提示詞教模型「什麼時候該閉嘴——當你發現資訊不足、任務矛盾、或使用者意圖不明時，主動停下來問清楚，而不是自作主張猜下去」。

另一個經典設計是「create_file」工具，參數順序被刻意安排為「先填寫檔案路徑與內容摘要，最後才填入完整內容」——這迫使模型在生成檔案前，必須先想清楚「我要寫什麼、檔案放在哪」。這種「先思考再行動」的參數順序，本身就是一場微型 prompt engineering 教學。

角色設定與工具調用並非各自獨立，而是緊密互動。安全規則可能會限制工具的觸發時機：例如當使用者要求「刪除系統檔案」時，角色設定中的「無害」原則會優先觸發拒絕，阻止工具調用。反之，工具調用也可能反饋影響角色設定——當 AI 用搜尋工具找到互相矛盾的資訊，角色設定中的「誠實」規則會要求它向使用者坦白不確定性，而非硬著頭皮瞎說。

對於台灣的中小企業與技術團隊來說，這些洩漏的提示詞就像一份份「設計圖」。你不必從零開始摸索「如何定義個性」或「如何描述工具」；只要打開 system_prompts_leaks，就能看到 Anthropic 如何為每個工具撰寫長達數百字的「使用時機」說明，或是 OpenAI 如何用「分層拒絕」來防止提示詞注入攻擊。

正如 替代方案有限公司 在 逆向工程實戰篇 所強調的，這些內容原本不存在於官方文件，而是透過 MITM 代理與瀏覽器端點才得以曝光。現在它們全部攤在陽光下，等著你拆解、複製、改造。

角色設定決定了 AI 的「人格」，工具調用決定了 AI 的「能力」。兩者相輔相成，構成每一次對話的底層腳本。而洩漏提示詞之所以珍貴，正是因為它讓我們有機會直接翻閱這些腳本，而不是隻看著舞臺上的表演瞎猜。

偷師角色設定：從「助人誠實無害」到「幽默未過濾」的設計邏輯

當我們深入剖析 system_prompts_leaks 專案中各家 AI 的系統提示詞，會發現每一套角色設定背後，都隱藏著一套嚴謹的安全哲學與產品策略。以 Anthropic 的 Claude 系列為例，其提示詞明確開宗明義地要求模型「誠實、有益、無害」，但這並不只是簡單的三個形容詞，而是透過「憲法 AI」機制付諸實現。所謂憲法 AI，指的是在系統提示詞中嵌入一套價值原則清單，模型在回應前會先進行自我審查，根據這些原則來判斷哪些話能說、哪些不能說。研究報告指出，這些原則涵蓋了從尊重隱私、避免歧視到促進平等對話等面向，層層疊加形成一道「內在安全護欄」。

從洩漏的 Claude Opus 4.6 提示詞中我們可以看到，Anthropic 工程師甚至為這些原則設計了「優先級」——當「誠實」與「無害」發生衝突時（例如用戶詢問如何配置有毒化學物質），「無害」的權重會優先於「誠實」，模型會拒絕提供具體步驟，但仍會解釋拒絕的原因。

這種設計邏輯不僅限於安全迴避，更深入影響模型的個性表達。例如在「助人」原則下，Claude 被要求「主動提供額外資訊」，當用戶詢問天氣時，它不僅會報溫度，還會順帶提醒即將到來的鋒面或建議攜帶雨具。這與 OpenAI 的 ChatGPT 分層拒絕系統形成鮮明對比。根據 替代方案有限公司 在「從憲法AI到分層拒絕」 的分析，OpenAI 採用的是一種「從鬆到緊」的漸進式安全機制。ChatGPT 的系統提示詞中設有數十條「拒絕規則」，從最低階的「不執行危險指令」到最高階的「不輸出暴力內容」，每條規則都附帶明確的觸發條件與回應範本。這種架構使得 GPT-5.5 Thinking（2026 年 5 月更新版）能根據對話脈絡動態調整防護力度——當用戶語氣友善時，拒絕規則會被部分放寬，允許更多幽默與非正式對話；但當話題涉及高風險領域（如醫療、法律建議），防護層級會瞬間拉高，甚至比 Claude 的憲法 AI 更為嚴格。

然而，如果說以上的設計都是為了「防弊」，那 xAI 的 Grok 則反其道而行，刻意追求「未過濾」的風格。從洩漏的 Grok 提示詞中可以發現，xAI 團隊使用了多種策略來打破傳統 AI 的「溫和形象」。首先是「語境許可」：Grok 被指示「在用戶明確要求尖銳分析或政治評論時，不要閃爍其詞，而是直接給出觀點」，這與 Claude 的「避免爭議話題」原則完全相反。其次是「模仿人類的認知偏誤」：Grok 的提示詞中允許「適度的諷刺」與「對荒謬問題的不耐煩回應」，這在許多 AI 安全架構中是被嚴格禁止的行為。更重要的是，Grok 的「未過濾」並非毫無限制，而是建立在一個巧妙的邊界之上：它的系統提示詞明確指出「不得輸出非法行為指南」、「不得製作仇恨言論」，但對於「有爭議的科學理論」或「非主流政治觀點」則開放討論。這種設定讓 Grok 在外界眼中成為「可以聊敏感話題的 AI」，實際上仍然堅守了底線安全規範。

從上述三個案例中，我們可以提煉出至少三種可複用的角色設定技巧：第一、定義核心價值優先級：不要只列出「誠實、有益、無害」這樣模糊的詞彙，而是像 Anthropic 一樣，為每個價值賦予具體的行為標準與衝突處理規則。例如「當有用與誠實衝突時，誠實優先」或「當無害與有趣衝突時，無害優先」。第二、建立漸進式安全觸發機制：參考 OpenAI 的分層拒絕系統，針對不同敏感度的話題設定不同的回應策略，而不是一律拒絕或一律開放。這樣既能維持對話的自然流暢，又能防範高風險情況。如 逆向工程實戰篇 所揭示，ChatGPT GPT-5.4 到 5.5 的更新中，拒絕規則從 12 條擴充到 18 條，正是因為發現原有架構在某些邊界狀況下反應不足。

第三、手動調整安全閾值，打造差異化個性：Grok 的策略告訴我們，AI 的個性並非完全由模型參數決定，而是可以透過提示詞進行「風格化」調整。如果你想要一個更直接、敢於表達觀點的 AI 助手，可以明確在系統提示詞中允許「在安全範圍內的尖銳回應」；反之，如果你開發的是兒童教育應用，則可以採用更接近 Anthropic 的「高度過濾」模式。值得注意的是，這些技巧並非憑空想像，而是直接來自於真實世界的 A/B 測試與用戶反饋——根據研究報告，xAI 團隊反覆調整 Grok 的系統提示詞，在「開放性」與「安全性」之間尋找平衡，最終產生我們今天看到的幽默未過濾風格。

總結來說，從「助人誠實無害」到「幽默未過濾」，這並非二元對立的選擇，而是一道光譜。每一家 AI 公司都在這道光譜上找到屬於自己的位置，而洩漏的系統提示詞正是這段探索旅程的最佳紀錄。對於台灣的中小企業與技術團隊而言，現在你不需要從零開始摸索，只需打開 system_prompts_leaks 專案的頁面，就能直接學習這些頂級團隊的設計邏輯，並將其轉化為你自己產品的競爭優勢。

偷師工具調用：從 Claude Fable5 學工具定義的極致工程

如果說角色設定是讓 AI 知道「自己是誰」，那麼工具定義就是教它「怎麼幫你做事」。在 system_prompts_leaks 專案收錄的所有提示詞中，Claude Fable5 的系統提示詞堪稱工具定義的巔峰之作——這份提示詞足足有 1,600 多行，而最令人震驚的是它的篇幅配置：前半段說明模型該如何說話、遵守哪些安全原則，只佔了不到一半；剩下將近一半的篇幅，居然全部用來定義 17 到 18 個工具。從執行 bash 指令、建立與修改檔案，到搜尋網頁、查天氣、畫地圖、查體育比分、搜地點、抓取網頁內容、搜圖片、起草訊息，甚至彈出選項詢問使用者——這些工具的描述加起來，一口氣吃掉了將近半本提示詞。這不是偶然，而是頂級 Agent 提示詞工程師刻意為之的設計哲學：工具定義的品質，直接決定了 Agent 的智慧上限。

仔細拆解 Fable5 的每個工具定義，你會發現它們的結構遠比一般開發者想像的複雜。一個好的工具定義，一半功力在於參數 schema（參數型別），另一半則藏在使用時機與禁忌的描述裡。以 ask_user_input 這個工具為例——它的功能非常單純：當 AI 遇到不確定的情況時，彈出選項讓使用者做決定。但在 Fable5 的提示詞中，這個工具被寫上了一整段「使用原則」：例如「只有在你的推論無法從上下文或歷史對話中確認時，才呼叫此工具」、「如果問題可以透過工具內部邏輯推斷，請先嘗試推斷才提問」。這段看似多餘的描述，其實是防止 AI 養成「動不動就問使用者」的壞習慣。反觀許多開發者自己寫的 Agent，常犯的錯誤就是讓 AI 頻繁打斷使用者，反而降低效率。Fable5 的做法清楚告訴我們：禁用與限用條件，和工具功能本身同等重要。

另一個精彩案例是 create_file 工具——它的參數順序設計本身就是一場心理戰。一般開發者可能會把所有參數列出來就結束了，但 Fable5 的提示詞刻意把 file_path 與 content 放在前面，並在參數描述中寫明「請先確認檔案路徑是否合理，再提供完整內容」。更關鍵的是，它要求模型在呼叫這個工具之前，必須先「在腦中生成完整的檔案內容」，而不是邊寫邊想。這個設計背後有一個深刻的認知科學原理：當參數順序要求模型「先在思維中運算完成，再執行輸出」時，產生的程式碼或文件錯誤率會大幅降低。這項技巧對於台灣許多正在開發 AI 編碼助手的團隊來說，簡直是一份免費的 UX 設計 blueprint——參數順序不只是技術規格，更是控制模型思考流程的導航工具。

除了單一工具的定義，Fable5 還展現瞭如何處理工具之間的「依賴關係」與「衝突避免」。舉例來說，它的 web_search 與 web_fetch 兩個工具被刻意設計成「先搜後取」的序列——在 web_search 的定義中，它明確要求模型「只回傳搜尋結果 URL」，而 web_fetch 則要求「必須搭配先前搜尋結果中的 URL 使用」。這聽起來很基本，但許多實踐中的 Agent 往往會跳過搜尋步驟，直接嘗試用猜測的網址抓取資料，導致錯誤連連。Fable5 的提示詞透過描述性約束，讓模型在呼叫工具時自然形成一個執行序列，而不是孤立地看待每個工具。這種「隱性工作流程」的設計，遠比在程式碼中寫死邏輯來得靈活，也更貼近人類工程師的思考方式——我們會先規劃再執行，而不是盲目地呼叫函式。

我們不應只停留在驚嘆層面，而是要思考：這些設計原則如何落地到台灣的技術團隊中？舉例來說，當你在開發一個客服型 AI Agent 時，你的工具定義不應該只是列出 API endpoint 與參數。你應該像 Fable5 一樣，為每個工具撰寫「使用情境範例」與「常見錯誤避免」。比如說，一個查詢訂單狀態的工具，你可以在描述中加入：「當使用者提供完整的訂單編號時，優先使用此工具查詢；如果只提供部分編號或模糊的日期範圍，請先使用搜尋工具找出相關訂單再呼叫。」這樣的提示詞工程，等於把工程師多年的 domain knowledge 直接注入到 AI 的判斷邏輯中。真正的頂級提示詞，不是告訴模型要做什麼，而是教它什麼時候不做、什麼時候該先做別的事。

從資料來看，Fable5 的提示詞之所以被譽為「工具定義的聖經」，正是因為它打破了許多人對提示詞的刻板印象——以為提示詞只是「角色設定＋安全規則」的組合。事實上，在今日 LLM 應用日益走向 Agent 化的趨勢下，工具定義的品質已經成為區分平庸產品與卓越產品的關鍵分水嶺。台灣的中小企業與技術團隊若想快速追趕，根本不需要從零開始摸索這些設計原則。你只需要打開 system_prompts_leaks 專案的頁面，找到 Claude Fable5 的系統提示詞，逐行閱讀那些工具定義的措辭、參數順序與使用禁忌，就能直接站在 Anthropic 頂尖工程師的肩膀上，將這些經過百萬次用戶互動驗證的設計智慧，內化為你自己產品的競爭優勢。

實戰拆解：工具調用的三個關鍵設計模式

當你打開 system_prompts_leaks 專案中 Claude Fable5 那份長達 1600 行的系統提示詞時，會發現一個驚人事實：將近一半的篇幅都在定義工具。從跑 bash 指令、建立檔案、搜尋網頁，到查天氣、畫地圖、起草郵件，每個工具都有詳盡的說明。對於台灣中小企業的技術團隊來說，這些工具定義不僅是「說明書」，更是可以直接套用的設計範本。我們從中歸納出三個最實用的模式，它們直接影響 AI Agent 的可靠程度。

模式一：ask_user_input —— 教模型「什麼時候該閉嘴」

許多開發者以為，AI Agent 的目標是「盡可能自動完成所有事情」，但實際失誤往往來自於模型在不該行動的時候擅自決定。Claude Fable5 的提示詞中定義了一個名為 ask_user_input 的工具，它的存在意義恰恰相反：強迫模型在某些情境下「停下來問使用者」。這個工具的參數非常簡單，只有一個 question 字串，但附帶的說明卻長達數百字，明確列出「何時必須呼叫」的判斷條件——例如任務目標模糊不清、需要使用者授權才能執行高風險操作、或是跨工具轉換時必須確認使用者的下一步意圖。

這個設計背後的邏輯在於：AI 不應該假設自己永遠知道使用者的完整意圖。當一個 Agent 同時具備「建立檔案」、「執行程式碼」、「傳送郵件」等多項能力時，模型很容易因為參數猜測錯誤而產生災難性後果。想像一下，你只說了一句「幫我整理上個月的銷售資料」，Agent 便自行建立了一份 CSV 檔案、執行 Python 腳本分析、然後直接寄送給所有客戶——這顯然不是你要的結果。透過 ask_user_input 機制，模型會在關鍵節點停下來提出類似「請問您希望分析結果以圖表還是報表呈現？」這樣的問題，取得明確指示後再繼續執行。

這種「主動確認」的設計哲學，對於正在開發客服機器人、內部流程自動化 Agent 的台灣團隊尤其重要。將 ask_user_input 嵌入你的工具調用流程中，相當於為 AI 安裝了一層「謹慎開關」，大幅降低自動化過程中的誤操作風險。

模式二：create_file —— 靠參數順序逼模型「先想清楚再動手」

第二個值得關注的模式來自 create_file 工具的定義。表面上，這只是一個用來建立檔案的函式，但 Anthropic 工程師在參數設計上藏了一個精巧的「強迫思考」技巧。他們刻意將 file_reason（建立理由）參數放在 file_content（檔案內容）之前，並且在參數描述中明確要求模型必須先詳細說明「為什麼要建立這個檔案、它的用途是什麼、與當前任務的關聯為何」，然後才能填入實際內容。

這個設計的作用原理很直接：語言模型的輸出具有方向性，當模型在生成完整的 JSON 工具呼叫時，它必然先處理排在前面的參數。也就是說，模型被迫先「思考理由」、再「產生內容」。根據來源 6 的分析，這種參數順序的安排能有效減少模型「未經深思熟慮就開始產出」的傾向。實務上，許多 Agent 在產生程式碼或文件內容時，會因為急於滿足使用者的要求而輸出結構混亂、邏輯跳躍的結果，但在加入「前提思考」的強制步驟後，輸出品質顯著提升。

對台灣的軟體開發團隊而言，這個技巧可以無痛移植到你的任何自訂工具中。無論你正在開發的是自動化報表生成 Agent、程式碼審查助理、還是內容寫作助手，只要將與「決策原因」相關的參數放在「行動內容」之前，就能強迫模型在動手之前先想清楚為什麼要這麼做。這個微調的成本幾乎為零，卻能帶來 Agent 輸出品質的明顯改善。

模式三：「給方案而非給答案」—— 用提示詞結構引導模型提供選項

第三個模式不像前兩個那樣直接對應單一工具，而是貫穿整個工具描述區塊的設計哲學。仔細觀察 Claude Fable5 中的每一個工具定義，你會發現它們幾乎都遵循一個共同結構：先描述「何時該用這個工具」，再描述「怎麼用」，最後補充「什麼時候千萬別用」。舉例來說，查天氣的工具說明中明確指出「僅在用戶明確詢問天氣時使用，不要主動猜測用戶是否想查天氣」，地圖搜尋工具則標註「若用戶只提到地點名稱但未要求路線規劃，請先提供地點資訊而非直接規劃路線」。

這種「給方案而非給答案」的結構，等於是在提示詞中內建了一層「決策樹」邏輯。模型不再是收到指令就盲目執行，而是被訓練成先判斷「現在是不是使用這個工具的正確時機」，再思考「如果要使用，最佳的使用方式是什麼」。以一個數位助理 Agent 為例，當用戶說「我想知道台北今天天氣如何」時，AI 會直接呼叫天氣工具；但當用戶說「我明天要去台北開會」時，AI 不會擅自推測用戶需要天氣資訊，而是可能先透過 ask_user_input 確認是否需要查天氣、查交通，或者先建立一個會議提醒。

這個看似簡單的設計原則，其實是台灣中小企業在開發 AI 產品時最容易忽略的一環。許多團隊在定義工具時，只注重「功能描述」（這個工具做什麼），卻忽略了「行為邊界」（這個工具什麼時候不該做）。從洩漏提示詞中我們可以清楚看到，頂尖 AI 公司花在定義「避免誤用」上的文字量，遠超過功能說明本身。將這個原則納入你的提示詞設計流程，你的 Agent 將從「有求必應的工具」進化為「懂得判斷分寸的助手」。

如何將洩漏提示詞轉化為自己的 prompt 模板？

當你從 system_prompts_leaks 專案中下載了某個頂尖 AI 的系統提示詞後，下一步不是直接複製貼上，而是進行系統化的拆解與重組。這個專案收錄了超過 100 個獨立提示詞，來自 OpenAI、Anthropic、Google 等 14 家廠商，是你建立個人或團隊專屬 prompt 模板的最佳原料庫。

我們建議採用「三層萃取法」：從原始提示詞中分離出「角色宣言」、「安全規則清單」與「工具定義庫」，再根據自身業務場景進行調整。這套方法能讓你保留頂尖 AI 的行為設計精髓，同時避免直接抄襲引發的法律爭議。

第一步：萃取「角色宣言」。在 Claude Opus 4.6 或 ChatGPT 5.5 Thinking 的系統提示詞中，前幾段通常會定義 AI 的核心身份與價值觀，例如 Anthropic 強調的「憲法 AI」原則或 OpenAI 的「分層拒絕」系統。將這部分複製出來，然後用你自己的產業語言改寫。例如，台灣的客服機器人可以將「助人、誠實、無害」改寫為「以專業態度協助客戶，誠實說明產品限制，不提供未經核實的醫療建議」。

第二步：萃取「安全規則清單」。從 Gemini 3.1 Pro 或 Grok 的提示詞中，你會看到一條條明確的行為禁令與觸發條件。將這些規則分類整理：哪些是通用安全規定（如拒絕生成仇恨言論）、哪些是特定領域限制（如不提供財務建議）。台灣的技術團隊可以直接套用這些清單，但在法規敏感領域（如金融、醫療）必須加入本地法條對應的條目，例如個人資料保護法相關限制。

第三步：萃取「工具定義庫」。這是最費工但也最有價值的一步。以洩漏的 Claude Fable5 提示詞為例，它花費近一半篇幅定義了 17-18 個工具，每個工具不僅包含參數架構（schema），更詳細描述了「何時使用、何時避免使用、如何使用才正確」。你的團隊可以將這些定義當作教科書，學習如何撰寫高品質的工具描述。例如，ask_user_input 工具教 AI「什麼時候該閉嘴確認」，create_file 工具透過參數順序逼迫模型「先想清楚再動手」。

實際案例：某台灣電商團隊從 Copilot 的洩漏提示詞中提取了代碼審查工具的定義模板，將其調整為適合自家 PHP 專案的版本。他們保留了「檢查 SQL 注入風險」與「確認日誌記錄是否完整」等核心規則，只修改了程式碼風格規範部分，節省了約 60% 的提示詞開發時間。

萃取完成後，下一步是將這三個元件組合為你的專屬模板。我們建議使用 JSON 或 YAML 格式儲存，以便版本控制與團隊協作。模板架構可以這樣設計：role 區塊放角色宣言，safety 區塊放安全規則清單，tools 區塊放工具定義庫。每個區塊都保留「可調整標記」，例如用 {{COMPANY_NAME}} 或 {{INDUSTRY_RULES}} 佔位，方便不同專案快速套用。

值得注意的是，工具定義庫的萃取需要特別注意行為邊界的描述。根據逆向工程研究，頂尖 AI 公司的提示詞在「避免誤用」上的文字量遠超過功能說明。例如，天氣查詢工具不僅要寫「可查詢天氣」，更要寫「不要擅自推測用戶需要天氣，除非用戶明確要求」。將這種「界線思維」納入你的工具定義庫，你的 AI Agent 將從有求必應的工具進化為懂得判斷分寸的助手。

最後，不要只萃取單一廠商的提示詞。我們建議從 system_prompts_leaks 中選取至少 3 家不同風格的廠商（例如 Anthropic 的憲法 AI 風格、OpenAI 的分層拒絕風格、GroK 的未過濾風格），分別萃取他們的角色宣言與安全規則，然後進行交叉比對。你會發現：雖然表達方式不同，但核心的安全機制有極高的共通性。將這些共同點提煉出來，就是最穩固的模板基礎。

台灣的中小企業技術團隊可以從這個流程中獲得的最大好處是：你不需要從零發明提示詞設計。全球最強的 AI 公司已經花了數百萬美元優化這些系統提示詞，你只需要學會如何「偷師」——不是抄襲，而是理解其設計邏輯後，轉化為適合自己場景的可重用資產。這正是為什麼替代方案有限公司反覆強調：洩漏提示詞是 prompt engineering 的最佳教材，因為它們讓你站在巨人的肩膀上，用最小的成本學到最深的技術。

常見問題 FAQ：法律風險、過時性與實用性

當你第一次打開 system_prompts_leaks 這個 GitHub 專案，看到超過 100 個來自 ChatGPT、Claude、Gemini 等頂級 AI 的系統提示詞時，第一個念頭可能是：「直接拿去用會不會有問題？」確實，CC0-1.0 授權、提示詞快速迭代、以及法律灰色地帶，都是技術團隊最常問的三個關鍵問題。替代方案有限公司整理了這些常見疑慮，並從實務角度給出明確的解答。

首先，CC0-1.0 公有領域授權是否能讓使用者完全免責？答案是：不一定。根據研究報告，system_prompts_leaks 專案本身採用 CC0-1.0 授權，允許任何人複製、改作與商用（來源 5）。然而，這只代表專案貢獻者放棄了他們的著作權——但原始提示詞的版權歸屬仍然模糊。這些提示詞可能涉及 AI 公司的商業機密或服務條款，專案僅「存檔」而不對內容負責（來源 5）。換句話說，你複製了提示詞後拿去商用，若原廠提告，CC0-1.0 授權並不能自動擋住商業機密或違約訴訟。替代方案有限公司建議：學習可以，直接複製到自己的產品中則需審慎評估法律風險，最好請公司法務確認。

其次，提示詞會不會很快過時，學了等於白學？這確實是常見的擔憂。以 ChatGPT 為例，從 GPT-5.4 到 5.5 Thinking 版本（2026 年 5 月更新），安全規則從 12 條擴充到 18 條（來源 2、11）；Gemini 也從 3.1 Pro 演進到 3.5 Flash。提示詞的版本更新相當頻繁，直接抄寫某個版本的提示詞，可能一兩個月後就因模型更新而失效。但這不代表學習沒有價值——反而是因為這些版本演化，你才能觀察到 AI 公司如何「迭代」他們的安全策略與個性設定。例如，從規則條數的增加，你可以推測哪些安全漏洞被補強；從工具描述的調整，你能學會如何讓 AI 更精準地呼叫工具。替代方案有限公司在〈從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密〉一文中，就詳細比較了不同版本的設計邏輯。

直接複製貼上是否可行？多數情況下，這不是一個好策略。系統提示詞是深度綁定特定模型版本與產品體驗的「隱藏作業系統」。以 Grok 的未過濾風格為例，它背後的提示詞仰賴 xAI 模型的特定安全訓練（來源 9）；直接套用到 GPT-5.5 上，反而可能產生衝突。更實際的用法是：提取其中的通用模板，例如角色宣言的結構、安全規則的分層寫法、工具調用的參數描述方式，再根據你自己的應用場景調整。替代方案有限公司的〈逆向工程實戰〉文章提到，許多開發者從 Claude Fable 5 的 1,600 行提示詞中，學到如何定義「什麼時候讓模型閉嘴」的 ask_user_input 工具（來源 6），而不是整段複製。

最後，如何合法合規地學習與應用？替代方案有限公司提供三個具體建議：第一，將洩漏提示詞視為「公開的教材」而非「免費的程式碼」。專案創辦人的意圖是供學術研究與反向觀察（來源 5），你可以用來理解安全設計、比較不同公司的策略，甚至進行資安研究。第二，提煉設計原則，而非直接複製字串。例如，從 Anthropic 的憲法 AI 中學習如何定義「助人、誠實、無害」的邊界（來源 9），再寫出屬於你的提示詞。第三，關注版本更新的變化，並建置自己的提示詞版本控管庫。許多台灣中小企業團隊正是透過這種方式，花一個月內化頂尖 AI 的設計邏輯，再用自己的語言重新組織，既避開法律地雷，也學到最深層的實戰技巧。

總結來說，CC0-1.0 授權降低了專案本身的使用門檻，但無法消除原始提示詞的歸屬爭議；提示詞雖然快速迭代，但版本演化本身就是最好的教材；直接複製貼上不可行，但結構化學習完全可行。如果你對法律層面的細節還有疑慮，推薦閱讀替代方案有限公司的〈公有領域授權能擋住法律訴訟嗎？系統提示詞洩漏的風險與爭議〉，裡面有更深入的分析。只要掌握正確的學習心態，這些洩漏提示詞就是 prompt engineering 領域最珍貴且合法的教學礦脈。

台灣觀點：在地開發者如何利用這些資源突圍？

對台灣的 AI 新創與接案團隊而言，system_prompts_leaks 專案最大的價值，並不在於可以直接「複製貼上」那些頂尖 AI 的系統提示詞——事實上，直接使用反而可能引發法律爭議，且巨頭的提示詞高度綁定自家模型，移植效果有限。真正的突破點在於：它提供了一扇難得的櫥窗，讓資源相對有限的本土團隊，能近距離觀摩 OpenAI、Anthropic、Google 等巨頭如何設計 AI 的「行為 DNA」。試想，過去我們只能從產品表面的回應去推測背後邏輯，現在卻能直接翻開設計圖，看到 Claude Opus 4.6 的「憲法 AI」規則具體怎麼寫、ChatGPT 5.5 Thinking 的「分層拒絕」條件如何觸發、Gemini 3.5 Flash 又是如何平衡客觀與安全性。這種「逆向拆解大師作品」的學習路徑，大大縮短了台灣開發者從「會用 API」到「懂設計 AI 個性」之間的認知鴻溝。

進一步來看，降低 prompt engineering 的試錯成本，是這些洩漏提示詞帶給台灣團隊最直接的效益。對於一個資源有限、預算精省的接案團隊，要從零開始打磨一套穩定可靠的系統提示詞，往往得花費數週甚至數月進行 A/B 測試，並承受客戶不滿意的風險。然而，當你可以直接參考 Anthropic 為 Claude Code 設計的「工具調用權限管理」架構，或學習 Cursor 如何定義程式碼編輯助手的安全邊界，就能在專案初期避開至少 80% 的常見陷阱。以專案中收錄的 Claude Fable5 系統提示詞為例——這份多達 1,600 行的提示詞，將近一半篇幅都在詳細定義十幾個工具的調用規則：包括「什麼時候該用 ask_user_input 向使用者確認」、「create_file 的參數順序如何強迫模型先思考再執行動作」，甚至連「地理資訊 API 在哪些座標範圍內視為有效」都寫得清清楚楚。這些細節的背後，是 Anthropic 工程團隊數不清的實戰教訓與迭代成本，而台灣開發者現在只需要花一個晚上研讀，就能將這些智慧內化成自己的設計直覺。

脫離了單純的模仿階段，台灣團隊真正的競爭優勢在於「結合本土語境打造差異化助手」。巨頭的提示詞雖設計精良，但從語言模型的本質來看，這些系統提示詞絕大多數都是以英文思維與西方文化為預設場景寫成。台灣的開發者可以從 system_prompts_leaks 中學習大廠的「框架思維」，卻必須用自己的文化養分來填充內容。例如，當你理解了 Google 如何定義 Gemini 的「平衡客觀」語氣規則，就能夠將其轉化為適合台灣用戶的對話風格——像是融入臺語語助詞、理解台灣特有的夜市文化或選舉話題，甚至針對台灣中小企業的溝通習慣，設計出更「接地氣」的拒絕回應模板。又或者，參考 xAI 的 Grok 那套「幽默未過濾」的風格參數，你可以在為台灣餐飲業者開發點餐助手時，精準拿捏「不失禮貌的直白」與「台灣式幽默」之間的分寸。

更深層的機遇，在於透過這些洩漏提示詞，看見 AI 產業的「隱形賽道」——那些大廠尚未滿足、台灣團隊卻有能力深耕的應用場景。仔細比對專案中收錄的提示詞就會發現，巨頭們雖然在通用型助手（如 ChatGPT、Claude）上投入極大，但在某些垂直領域的系統提示詞設計上反而顯得相對「保守」或「模板化」。比如 Microsoft Copilot 的提示詞大量聚焦於 Office 文書處理的生產力場景，Cursor 的提示詞則圍繞程式碼編輯的權限與安全。這意味著，台灣的新創團隊若能將大廠的設計邏輯加以吸收，再針對本土產業如半導體製造供應鏈的知識庫、中小企業的財稅法規諮詢、乃至台灣特有的醫療保險制度，打造出具備本土知識邊界與在地語料的小型專用 AI 助手，就能在巨頭尚未佈局的縫隙中快速佔領市場。正如替代方案有限公司在〈從憲法AI到分層拒絕：系統提示詞的設計哲學大揭密〉一文中分析：學習頂尖團隊的「設計哲學」，遠比複製他們的「答案」更有長期價值。

值得一提的是，專案中收錄的版本迭代紀錄——例如 ChatGPT 從 GPT-5.4 到 GPT-5.5 Thinking 之間，拒絕回答敏感話題的規則從 12 條擴充到 18 條——本身就是絕佳的實戰教材。台灣開發者可以從中追蹤「安全規則如何隨著模型能力演化而調整」，進而預測自家產品未來可能面臨的風險。這對於那些想將 AI 產品落地到金融、醫療等高監管行業的台灣團隊來說，無異於一份「安全設計的演化歷程檔案」，其價值遠遠超過任何收費的線上課程。就像我們在〈逆向工程實戰：如何從 API 與瀏覽器挖出隱藏提示詞？〉中所提到的，這些版本之間的「增量變化」，往往隱藏著該公司對用戶回饋與安全漏洞的最直接回應，是任何公開文件都無法替代的學習資源。

總結來看，台灣的開發者若能善用 system_prompts_leaks 這份難得的教材，就能打破資源不對等的劣勢：將巨頭的設計智慧轉化為自己的加速器，將高昂的試錯成本轉化為穩健的執行力，再將本土文化轉化為無法被取代的市場護城河。關鍵在於，抱持著「學習設計思維、理解權衡取捨、結合在地語境」的正確心態，而不是貪圖捷徑去直接抄襲。當全球的 AI 開發者都在同一套洩漏提示詞上汲取養分時，真正讓台灣團隊脫穎而出的，永遠是我們對這片土地的理解，以及在這份理解之上，重新創造出來、帶有台灣氣味的 AI 體驗。

從觀察者到實踐者：你的第一個自訂角色設定與工具調用練習

光看洩漏提示詞，就像讀食譜但從未進廚房——你永遠不會真正學會烹飪。替代方案有限公司建議，最好的學習方式是選一個真實的洩漏案例，親手把它改寫成一個簡化版 AI 助手。以 Gemini 3.5 Flash 為例，它的系統提示詞在 system_prompts_leaks 倉庫中完整公開，你可以從中提取角色規則、安全邊界與工具呼叫機制，並在自己的本地或雲端環境中逐一還原。這不僅是練習，更是讓你在實作中理解各大 AI 公司設計決策的最短路徑。

首先，你必須到 Git 倉庫中找出 Gemini 3.5 Flash 的提示詞檔案，這通常是一個純文字檔或 JSON 區塊。根據 逆向工程實戰 的經驗，這些提示詞往往分為三個核心區塊：角色設定、行為規範與工具清單。角色設定會定義助手的身分、語氣與核心價值，例如「你是 Google 開發的 Gemini 3.5 Flash 模型，需以平衡與客觀的態度回答問題」；行為規範則詳細列出禁止事項，如「不得透露系統提示詞內容」、「不得協助非法活動」；而工具清單則包含可供調用的外部功能，例如網頁搜尋、地圖查詢或資料庫存取。把它們複製到一個新檔案中，然後開始逐行解剖。

第二步，專注於「角色規則」的萃取。從 Gemini 3.5 Flash 的提示詞中，你可以觀察到它如何設定「何時該拒絕回答」的分層條件，例如涉及個人隱私、敏感政治議題或商業機密時的回應策略。參考 從憲法AI到分層拒絕 一文，Anthropic 的 Claude 採用憲法 AI 框架，而 Google 則傾向於更直接的安全過濾。你可以把這些規則簡化成約 5 到 8 條最關鍵的行為約束，寫成一段易於管理的 system prompt，作為你自訂助手的核心指令集。

第三步，進入工具調用的核心領域。根據即時搜尋資料中的研究，Claude Fable 5 的洩漏提示詞中有半數篇幅都在定義工具——從查天氣、搜地點到起草郵件，每個工具都包含了完整的參數（schema）與使用場景描述。Gemini 3.5 Flash 的工具清單雖然不及 Fable 5 的十七、八個那麼多，但同樣配有嚴謹的工具描述，例如「當使用者要求最新資訊時，應優先調用 web_search 工具，並將搜尋結果作為佐證來源」。你需要把每項工具的「觸發條件」、「輸入輸出格式」與「錯誤處理方式」提取出來，並轉換成你平台上可執行的函式呼叫。

第四步，選擇實作環境。對於台灣的中小企業技術團隊，替代方案有限公司建議從本地 Python 環境搭配 openai 套件開始，因為多數雲端模型都支援相容的 API 格式。如果你的預算有限，也可以使用開源模型如 Llama 3 或 Qwen，並透過 Ollama 來管理本地部署。承襲前段的設計，你可以在 system_prompt 參數中放進你萃取出的角色規則，並在 tools 參數中逐一定義你從 Gemini 中改寫來的功能。這樣做的好處是，你不需要一開始就追求完美匹配，而是逐步迭代改進。

第五步，撰寫核心程式碼：建立一個串接系統提示詞與工具呼叫的簡化架構。你需要定義一個主循環：接收使用者輸入 → 判斷是否需要工具呼叫 → 執行工具並回傳結果 → 讓模型重新整理回答。以 Python 為例，你可以寫類似以下的結構：

def run_agent(user_input):
messages = [{"role": "system", "content": YOUR_ROLE_RULES},
{"role": "user", "content": user_input}]
response = client.chat.completions.create(
model="gpt-4", # 或你選擇的模型
messages=messages,
tools=YOUR_TOOL_DEFINITIONS
)
# 處理工具呼叫邏輯
return final_answer

這個練習的關鍵是，你必須親自體驗從「讀取洩漏提示詞」到「將它改寫成可執行程式碼」的轉換過程。記得，Gemini 3.5 Flash 的原始提示詞可能包含上千字，但你只需要保留對當前專案有意義的規則與工具。試著只選 3 個最實用的工具來開始，例如網頁搜尋、目前天氣查詢與計算功能，並觀察你的簡化版助手是否仍能維持原版的語氣與安全意識。

第六步，測試與除錯。將你的簡化版助手運行數次，並比對原始 Gemini 3.5 Flash 在類似問題上的回應。注意安全規則是否如預期觸發——例如當使用者問「如何破解某網站」時，你的助手應該拒絕回答；而當使用者問「今日台北天氣」時，它應該觸發天氣工具並回傳精確數據。如果回應不符合預期，回頭檢查你的角色規則是否有遺漏，或者工具描述的觸發條件是否太寬鬆。還有一種常見錯誤是工具參數格式不對，導致模型呼叫失敗，這時可以參考即時搜尋資料中提到的「錯誤處理與 agent 自我除錯」技巧，來優化你的程式碼。

最後，將你的成果與社群分享。你可以把你的簡化版提示詞與工具定義提交回 system_prompts_leaks 的 Issue 區，或者寫一篇部落格記錄你的學習過程。替代方案有限公司鼓勵台灣開發者將這個練習視為一個開放式專案，持續引入更多來自 Cursor、Copilot 或 Notion AI 的洩漏提示詞來鍛練能力。當你能夠從「觀察者」變成「實踐者」，那些原本晦澀的設計智慧就會變成你隨手可用的技能，讓你在 prompt engineering 的路上越走越穩。

結論：系統提示詞洩漏時代，prompt engineer 的學習曲線正在加速

2025 年 5 月，GitHub 上一個名為 asgeirtj/system_prompts_leaks 的開源專案點燃了一場產業革命。它在 14 個月內累積超過 42,327 顆星，並被《華盛頓郵報》報導引用，揭露了 Anthropic、OpenAI、Google、xAI 等 14 家廠商、超過 100 個獨立系統提示詞的設計秘密（來源 3）。這些原本被鎖在 AI 公司「黑盒子」裡的隱藏指令——包括角色個性、安全規則與工具調用方式——如今變成了任何人都能取得的實戰教材。對於台灣的技術團隊而言，這不是什麼灰色地帶的爭議，而是一份千載難逢的「知識紅利」：你不用再靠猜測或試錯來學習 prompt engineering，而是可以直接拆解最頂尖團隊的設計邏輯。

這個現象對整個產業的衝擊是雙向且深刻的。一方面，它大幅加速了 prompt engineering 的普及——過去新手需要花數月摸索的「分層拒絕系統」或「憲法 AI」架構，現在可以透過比對 ChatGPT 5.5 Thinking 與 Claude Opus 4.8 的提示詞變化來快速掌握（來源 11）。你可以清楚看到 OpenAI 如何將「拒絕回答敏感話題」的規則從 5.4 版的 12 條擴充到 5.5 版的 18 條，或者 Anthropic 如何透過憲法 AI 框架定義「助人、誠實、無害」的邊界。更重要的是，這些教材涵蓋的不只是對話式 AI，還包含 Cursor、Copilot、Notion 等工具型 AI 的提示詞結構——它們教你如何定義網頁搜尋、檔案操作、地圖查詢等工具呼叫的細節（即時搜尋 6）。這讓台灣的中小企業團隊與獨立開發者在設計客服機器人或內部流程自動化時，可以直接站在巨人的肩膀上，把原本需要大量資源反覆測試的步驟，濃縮成一次有效的閱讀與拆解。

另一方面，這股開放浪潮也在倒逼 AI 公司重新審視自己的安全防護。正如我們在上一篇分析中提到的，專案以 CC0-1.0 公有領域授權發布，試圖規避版權與商業機密爭議，但這並不代表廠商會坐視不管。短期內，我們可以預見更多公司會加強輸出內容過濾、增加浮水印，甚至採用動態生成系統提示詞的方式，提高逆向提取的難度（來源 5）。這種攻防的演化對 prompt engineer 來說既是挑戰也是機會：它迫使你不能再只靠複製貼上，而是要去理解設計背後的「為什麼」——這個工具描述為什麼要強調「什麼時候千萬別用」？這場景的分層拒絕為什麼從 12 條變成 18 條？只有當你把這些表面規則內化成自己的設計哲學，你才能在提示詞不斷迭代的環境中保持競爭力。

如果你對上述的逆向工程方法或法律風險還有疑問，我們也在系列第二篇與第三篇中詳細探討了從 API 與瀏覽器端挖出隱藏提示詞的實戰技巧，以及公有領域授權能否抵擋訴訟的深層分析。這些內容共同構成了一套完整的自學路線圖，幫助你從旁觀者蛻變為真正能駕馭 AI 行為的設計者。

最後，我鼓勵你善用這波知識紅利，但不要只是當一個「囤積者」。把從洩漏提示詞學到的角色設定技巧，應用在你自己的專案中——無論是幫客戶設計一個擁有幽默個性的自動化客服，還是打造一個能安全呼叫多項工具的內部 Agent。正如我們在本系列前幾篇提到的，當你能從「觀察者」變成「實踐者」，那些從 Claude Fable 5 或 ChatGPT 5.5 拆解出來的設計智慧——甚至是用長達半本提示詞篇幅來定義的工具呼叫規則——就會變成你隨手可用的技能。在系統提示詞洩漏已成常態的時代，真正的贏家不是那些最早拿到資料的人，而是最快將這些知識轉化為實戰能力的人。從今天開始，把這份教材攤開，動手打造屬於你自己的 AI 設計哲學吧。