抽出提示詞把模型行為變地圖

我把抽出的 system prompt 拿來對照模型行為，才發現很多怪脾氣其實都寫在規則裡。

我盯模型 prompt 一陣子了，越看越火大。明明同一類工具，有的回答像客服，有的像同事，有的像在跟你辯論，還有的乾脆什麼都先說好。你如果只看輸出，會以為是模型個性不穩；但我越拆越覺得，真正搞事的常常不是模型本身，而是藏在背後那層 system prompt、產品規則、工具政策。

我本來也是只看 demo 的那種人。直到我開始對照抽出的 system prompt，整件事才比較像樣。這篇我拿 這篇 Zhihu 每週 GitHub 熱榜整理 當觸發點，裡面提到一批被抽出的 prompts，涵蓋 Anthropic、OpenAI、Google、xAI、Cursor、Copilot、VS Code、Perplexity 等工具。它沒有給我什麼神秘答案，但它讓我知道該去哪裡找答案。

我不是要你去背 prompt。那很蠢，也常常沒用。真正有價值的是：一旦你把模型行為跟提示詞對起來，你就開始能讀懂產品到底在優化什麼、怕什麼、卡在哪裡。這比看行銷頁面誠實多了。

先別信 demo，先看它被誰管著

Extracted system prompts from Anthropic - Claude Fable 5, Opus 4.8, Claude Code, Claude Design. OpenAI - ChatGPT 5.5 Thinking, GPT 5.5 Instant, Codex. Google - Gemini 3.5 Flash, 3.1 Pro, Antigravity. xAI - Grok, Cursor, Copilot, VS Code, Perplexity, and more.

翻譯一下就是：你看到的回答，早就不是模型「自然長出來」的樣子，而是被一層又一層指令修過的版本。品牌名很吵，但真正有用的是那個事實——這些產品都在用隱藏規則塑形。

我以前也會直接罵模型爛。後來我把同一個問題丟給幾個工具，答案差很大。我才發現不是「這家模型比較聰明」，而是「這家 prompt 比較會管」。有的偏保守，有的偏快，有的超愛先問問題，有的乾脆先幫你做完再說。這些都不是偶然。

實操上，我現在評估一個 AI 工具會先拆三層：base model、system prompt、product wrapper。不要再把「Claude 就是這樣」或「Gemini 就那樣」混在一起講，這種講法很容易把問題看歪。你要問的是：是哪個 app、哪份規則、哪層政策在推它。

如果你自己也在做產品，先看這幾份官方文件會比較清楚：Anthropic system prompts、OpenAI prompt engineering、Google prompting strategies。我不會說它們多偉大，但至少它們講的是同一件事：輸出不是憑空來的。

人格漂移，通常只是規則疊太多

我看過很多 extracted prompt，最常見的感想是：所謂的人格，很多時候只是指令堆疊出來的。先有角色，再有風格，再有安全限制，再有格式要求，再加一堆例外條款。最後模型講話像一個被多個主管同時盯著的實習生。

這也是我最不爽的一點。很多團隊以為 prompt engineering 是「寫一句很神的話」。不是。它比較像產品架構。你如果同時叫模型「簡潔」、「詳細」、「保守」、「主動」、「別亂猜」、「別拒絕太多」，它最後當然會變得又慢又黏，還很愛自我審查。

我自己踩過這個坑。以前我做過一個內部 copilot，模型本身不差，但系統 prompt 寫得像委員會決議：安全要顧、體驗要好、不能太長、又不能漏資訊。結果它每次都先猶豫半天，像怕被罵。後來我把規則拆開，才知道問題不是模型能力，是指令互撞。

• 先讀行為，不要先讀文風。
• 找衝突：簡潔 vs 完整、保守 vs 主動、直接回答 vs 先確認。
• 看產品到底是在優化信任、速度、合規，還是自治。

實操寫法很簡單：你拿到一份 prompt，就幫每一段標籤。我通常直接標成「tone」、「risk」、「format」、「tool use」、「refusal」。一標完，整份東西就不再像神秘黑盒，而像一張流程圖。這時候再去看 prompt 收藏 repo，你會比較知道哪些值得留，哪些只是湊熱鬧。

工具一開，真正的產品設計才開始

只要模型能 call tool，prompt 的重心就變了。它不再只是「講話像誰」，而是「什麼時候查、什麼時候問、什麼時候停、什麼時候交回控制權」。這才是 agent 產品真正麻煩的地方。

Zhihu 那篇整理提到 Claude Code、Codex、Cursor、VS Code、Perplexity 這些名字，我看到的重點不是品牌，而是工作流。這些不是單純聊天框，它們是把模型塞進開發流程裡。那代表 prompt 必須管決策，不只是管口氣。

我自己做過一個小型內部 agent，最初的 prompt 寫得很像在催眠它「去做事、去做事、去做事」。結果它很愛狂打工具，像在刷存在感。問題不是它太勤勞，是我把「用工具」寫成了進度感。後來我改成先出短計畫，再決定要不要動工具，整個行為就穩很多。

實操寫法：如果你的 AI 工具有 tool calling，prompt 不要寫成雞湯，要寫成決策樹。至少把下面幾件事講清楚：

• 什麼情況直接答
• 什麼情況先問問題
• 什麼情況先看檔案或資料
• 什麼情況先出計畫
• 什麼情況要停下來等批准

你可以去對照 OpenAI function calling 跟 Anthropic tools guidance。兩邊講法不一樣，但核心很像：工具使用要有政策，不是靠情緒。

跨模型比對，最容易看出 prompt 債

我現在很愛把不同家的 extracted prompt 並排看。這招很土，但超有用。你一排開來，哪份 prompt 乾淨、哪份 prompt 充滿重複規則、哪份 prompt 到處打架，立刻看得出來。那種亂，通常也會原封不動漏進產品體驗裡。

我有點受不了那種把 prompt 當「只是文字」的團隊。真的不是。它就是產品設計的一部分。你如果把所有 stakeholder 的需求全塞進一份 prompt，最後模型就會變成：怕錯、怕長、怕承諾、怕主動、怕漏東西。這不是聰明，這叫 prompt 債。

我以前比對過兩個功能相近的 assistant。底層模型差不多，但一個 prompt 很短，邊界很清楚；另一個超長，滿滿都是「helpful」「safe」「concise」「detailed」「don’t overstep」。結果前者比較像能用的工具，後者像在寫自我檢討。

實操寫法：你可以做一張簡單表格，欄位固定就好：

• role instruction
• tone instruction
• tool policy
• refusal policy
• format requirements
• memory / context rules

如果你想找素材，GitHub 跟這類週更整理頁面最容易挖到 prompt dump。只是我提醒你，別只收藏，先分類。收藏很多不代表你有理解，常常只是硬碟在幫你焦慮。

別只抄 prompt，抄它的骨架

這是我覺得最值得講的一點。很多人看到 extracted prompt，就想直接複製貼上。老實說，大多數時候這很爛。不是法律風險而已，還有產品脈絡問題。別人的 prompt 是為別人的產品目標寫的，不是為你。

真正能抄的是結構。好的 prompt 通常會把 identity、behavior、constraints、output format 分開，而且會明講優先序。這樣模型才知道哪條規則先，哪條規則後，哪條規則不能碰。沒有這種骨架，模型很容易在細節裡亂飄。

我後來自己寫 prompt，也都用這四格去拆。拆完之後，debug 會快很多。因為一旦輸出怪掉，你就知道是身份寫歪了，還是行為規則太鬆，還是限制不夠明確，不會整天懷疑玄學。

實操寫法：每次看 prompt dump，我都先重寫成這四塊：

• Identity：它是誰
• Behavior：它遇到不確定時怎麼辦
• Constraints：它不能做什麼
• Output：它最後要長什麼樣

如果你是做 API 產品，這三份官方文件也值得對照：OpenAI text generation、Anthropic prompt engineering overview、Google prompting strategies。我看完的感想很直接：大家都在講同一件事，只是語氣不同。

抽 prompt 不是蒐藏，是拿來除錯

我最不想看到的，就是有人把 extracted prompt 當戰利品。那真的很浪費。它最有價值的地方，是除錯。模型怪怪的時候，你要先判斷怪的是 base instruction、product wrapper，還是你自己那層應用邏輯。

這在 agent 工作流特別明顯。它如果一直拒絕、一直解釋、一直忽略檔案上下文，通常不是「它不夠聰明」，而是系統 prompt 的優先序寫歪了。它如果太積極，可能是自治權給太多。它如果一直抓不到重點，可能是任務邊界根本沒寫清楚。

我做過版本比對，真的有用。前後兩版 prompt 只差幾句，行為卻差很多：多一條安全條款，模型就開始縮；多一條格式要求，它就開始僵；多一條 tool policy，它就開始亂跑。這種差異你不去看 prompt，根本猜不到。

實操寫法：建立一份 prompt diff log。每次模型行為變了，就記：

• 日期
• prompt 版本
• UI 改動
• tool policy 改動
• 觀察到的行為差異

如果拿不到 system prompt，也沒關係。你就記可觀察行為，反推可能是哪條規則變了。這很麻煩，但比一直憑感覺罵模型有用多了。

可抄的模板

# Prompt behavior audit template（可直接複製）

## Source
- Product:
- Model:
- Source URL:
- Date reviewed:

## What I observed
- Tone:
- Verbosity:
- Refusal behavior:
- Tool use behavior:
- Error recovery behavior:

## Prompt structure guess
- Identity:
- Behavior rules:
- Constraints:
- Output format:
- Priority order:

## Conflicts I suspect
- Rule A vs Rule B:
- Safety vs speed:
- Concision vs completeness:
- Autonomy vs approval:

## How I would rewrite it
### Identity

### Behavior

### Constraints

### Output format

### Tool policy

### Escalation / refusal policy

## Copy-ready system prompt skeleton
You are a [role].

Behavior:
- Be [tone].
- Prefer [decision style].
- Ask clarifying questions when [condition].

Constraints:
- Do not [forbidden action].
- Do not guess when [uncertainty condition].
- Do not use tools unless [tool condition].

Output:
- Return answers in [format].
- Keep responses [length/style].

Tool policy:
- Use tools when [rule].
- Stop and summarize before [rule].
- Ask for approval before [rule].

Priority:
1. Safety and policy
2. Task correctness
3. Tool efficiency
4. Tone and style

我會把這份模板當成固定檢查表，不是拿來裝飾文件。你只要照著填一次，很多模型行為就會突然變得可解釋。可解釋，通常就代表可修。

這篇裡面，原始觸發來源是 Zhihu 那篇每週 GitHub 熱榜整理；我上面拆的觀點跟模板，是我自己把 prompt-extraction 這件事整理成能工作的版本，不是原文照抄。