Anthropic 公開了 System Prompts，但真正該學的是 simonw 把它變成 git 時間軸的那一招

瀏覽次數: 1

你花了一整個下午調 CLAUDE.md，加了「回答要簡潔」「不要用條列」「不要問我問題直接做」。結果換了個模型版本，行為又跑掉了。

問題不在你的 prompt 寫得不好，而在於：你的 prompt 是疊在一份你看不到的 prompt 上面的。當底下那層改了，你上面這層的意義就變了 —— 你可能還在拼命對抗一條官方三個月前就刪掉的規則。

Anthropic 其實有公開這層東西。而 Simon Willison（simonw，Django 共同創立者、Datasette 作者）做了一件更有用的事：把那份公開文件變成一個 git repo，讓 git log / git diff / git blame 變成讀 prompt 演化的介面。這篇文章把這套方法拆開講，並且把它改造成你自己每天都能跑的工作流。

這則討論在 2026-08-16 上了 Hacker News（539 分、225 則留言，由 tosh 提交）。但留言區大多在爭「system prompt 是不是太長了」，反而錯過了真正可以直接偷來用的那招。

本文大綱

一、Anthropic 到底公開了什麼、沒公開什麼

官方頁面在 https://platform.claude.com/docs/en/release-notes/system-prompts。先把邊界講清楚，這是後面所有結論的前提：

有公開的： claude.ai 網頁版、行動 App、桌面 App 聊天介面所使用的 system prompt，依模型分組，每個模型底下列出一到多個「日期版本」。

沒公開的（官方明說 + 實際檢查後確認）：

不適用於 API。 官方原文：「These system prompt updates do not apply to the Claude API.」你透過 SDK 呼叫 claude-opus-5 時，這整份東西不存在。
不含 tool definitions。 頁面只有行為指令，沒有工具的 JSON schema 與描述。HN 上不少人抱怨這點，因為 tool 描述往往才是決定 agent 行為的關鍵。
不含 Claude Code 的 prompt。 Claude Code 是另一套 harness，有自己的 system prompt 和 27 個內建工具描述，官方沒發。

我把原始檔抓下來量了一下（curl 那個 .md 版本，471 KB）：17 個模型、4 個系列（Opus / Fable / Sonnet / Haiku）、29 個日期版本，最早 2024-07-12，最新 2026-07-24 的 Opus 5。

想看 Claude Code 那一份的話，目前最完整的公開整理是 Piebald AI 維護的 Piebald-AI/claude-code-system-prompts。他們直接從 Claude Code 編譯後的 JS 原始碼裡抽字串，README 寫得很直白：「As they're extracted directly from Claude Code's compiled source code, they're guaranteed to be exactly what Claude Code uses.」目前追到 v2.1.233（2026-08-14），涵蓋 500+ prompt 字串、27 個工具描述、Plan / Explore / Task 子 agent 的 prompt，還有 CLAUDE.md 生成、compact、security review 這些 utility prompt。這是非官方的逆向整理，但來源明確、有版本 changelog，比隨便一篇「我猜 Claude Code 的 prompt 長這樣」的文章可靠得多。

二、真正的招式：把「一份文件」變成「一條 git 時間軸」

官方那頁的問題是：它是一份單一的巨大 markdown，用 Mintlify 的 <Accordion title="July 24, 2026"> 折疊區塊分組。你想知道「Opus 4.8 到 Opus 5 之間到底改了什麼」，只能自己在瀏覽器裡開兩個折疊區塊肉眼比對兩萬多字。實務上沒人做得到。

simonw 的做法（放在 simonw/research repo 的 extract-system-prompts/ 目錄）是：用 Claude Code 寫一支解析腳本，把每個日期版本拆成獨立檔案，然後偽造 commit 日期把它們一筆一筆 commit 進 git。他自己在部落格裡的說法是：「I had Claude Code turn that page into separate files for each model and model family with fake git commit dates to enable browsing the changes via the GitHub commit view.」

repo 的 README 把設計目標寫得很精準：讓 git log、git diff、git blame 成為主要介面（"become the primary interface for exploring how those prompts have evolved"）。

關鍵設計：一筆修訂寫成四個檔案

這是整套方法最值得抄的部分。extract.py 對每一個（模型, 日期）修訂，都寫入四個不同的檔案、各下一次 commit：

產物	檔名範例	用途
單次修訂快照	`claude-opus-4-8-2026-05-28.md`	只被寫入一次。永久連結某個時間點的 prompt；`git blame` 會全部指回那天
單模型滾動檔	`claude-opus-5.md`	追某一個模型自己的演化
單系列滾動檔	`claude-opus.md`	追整個 Opus 家族 3 → 4 → 4.5 → 4.8 → 5 的路線
全量 firehose	`latest-prompt.md`	所有模型所有版本的完整時間軸

為什麼要四份？因為 git 的 diff 只沿著「同一個檔名」發生。你想問的問題不同，需要的「同一個檔名」就不同：

「Opus 5 相對於 Opus 4.8 改了什麼？」→ diff claude-opus.md
「Sonnet 4.5 這三個月自己改了什麼？」→ diff claude-sonnet-4-5.md
「這句『Claude 避免說 genuinely』是哪天第一次出現的？」→ git log -S 打 latest-prompt.md

這是 git 資料建模，不是備份。同一份內容刻意寫成四種切片，換來四種可以直接用 git log -p 回答的問題。這招你套在任何「官方文件會定期改、你想追變化」的東西上都成立。

偽造日期怎麼做

extract.py 的核心只有幾行，關鍵在環境變數：

env["GIT_AUTHOR_DATE"] = iso
env["GIT_COMMITTER_DATE"] = iso
env["GIT_AUTHOR_NAME"] = "Claude"
env["GIT_AUTHOR_EMAIL"] = "noreply@anthropic.com"

有兩個細節值得記下來，都是踩過坑才會知道的：

1. git commit --date 只設 author date。 simonw 在 notes.md 的「What went wrong / what I learned」裡直接寫了這條：committer date 得靠 GIT_COMMITTER_DATE 環境變數。兩個都設，git log --pretty=fuller 才會一致。

2. 用「分鐘欄位」編碼同日排序。 有好幾天是多個模型同時更新的（例如 2025-08-05 同時有 Opus 4.1、Opus 4、Sonnet 4）。腳本的處理是：

when = date_obj.replace(hour=12, minute=ordinal % 60, second=0)

把全域序號塞進分鐘欄位，git 的拓撲順序就會跟原始文件順序一致。而且每個 commit 的 subject 一律以檔名開頭（例如 claude-opus.md: Claude Opus 4.8 — May 28, 2026），所以即使四個 commit 共用同一個假時間戳，git log --oneline 也不會有歧義。

三、照著跑一遍（可直接複製）

我在本機完整跑過一次，以下是實際指令與實際輸出：

mkdir -p /tmp/sptl/extract-system-prompts && cd /tmp/sptl
git init -q .

# 官方文件加 .md 後綴 = 純 markdown 原始檔
curl -sS https://platform.claude.com/docs/en/release-notes/system-prompts.md \
     -o extract-system-prompts/system-prompts.md

curl -sSL https://raw.githubusercontent.com/simonw/research/main/extract-system-prompts/extract.py \
     -o extract-system-prompts/extract.py

python3 extract-system-prompts/extract.py

輸出結尾：

[28] 2026-07-24  Claude Opus 5

Processed 29 prompt(s).

git log --oneline | wc -l 得到 116，正好是 29 × 4，跟 README 標的數字對得上。

接著是真正好用的部分 —— 看 Opus 家族的完整時間軸：

git log --pretty=format:"%ad  %s" --date=short \
    -- extract-system-prompts/claude-opus.md

2026-07-24 claude-opus.md: Claude Opus 5 — July 24, 2026
2026-05-28 claude-opus.md: Claude Opus 4.8 — May 28, 2026
2026-04-16 claude-opus.md: Claude Opus 4.7 — April 16, 2026
2026-02-05 claude-opus.md: Claude Opus 4.6 — February 5, 2026
2026-01-18 claude-opus.md: Claude Opus 4.5 — January 18, 2026
2025-11-24 claude-opus.md: Claude Opus 4.5 — November 24, 2025
...
2024-07-12 claude-opus.md: Claude Opus 3 — July 12, 2024

然後 diff 最近兩版：

A=$(git log --format=%H -- extract-system-prompts/claude-opus.md | sed -n '2p')
B=$(git log --format=%H -- extract-system-prompts/claude-opus.md | sed -n '1p')
git diff --stat "$A..$B" -- extract-system-prompts/claude-opus.md
# 1 file changed, 33 insertions(+), 49 deletions(-)

三個延伸招式，一起記起來：

# 只看字詞層級的增刪，長段落改寫時比行 diff 好讀太多
git diff --word-diff=color "$A..$B" -- extract-system-prompts/claude-opus.md

# pickaxe：某個字串是哪一版加進來、哪一版拿掉的
git log -S "tool_search" --oneline -- extract-system-prompts/latest-prompt.md

# 某一行是哪個版本引入的
git blame extract-system-prompts/claude-opus-4-8-2026-05-28.md

git log -S（pickaxe）在這個場景特別強：你關心的往往是一個具體字眼（SKILL.md、tool_search、concise），而不是整段改寫。

四、我從 Opus 4.8 → Opus 5 的 diff 裡實際讀到什麼

跑完 diff 後，把兩版的 XML 區塊標籤列出來對照，結構變化一目了然：Opus 4.8 有 17 個區塊，Opus 5 剩 14 個。

以下都是從實際 diff 讀出來的，不是推測：

1. 整段 <lists_and_bullets> 被砍掉。 Opus 4.8 有一大段非常強硬的反條列指令，包括「For reports, documents, technical documentation, and explanations, Claude writes prose without bullets, numbered lists, or excessive bolding」以及「Claude never uses bullet points when declining a task」。Opus 5 把這整段收斂成一句：「Claude uses lists and bullet points when asked to or when the content is multifaceted enough that they help with clarity.」

可操作的意思： 如果你在 CLAUDE.md 或 custom instruction 裡寫過「請務必用條列」來對抗那段，現在那條指令是在跟空氣打架，可以刪掉了。

2. <tool_discovery> 和 <available_skills> 在 Opus 5 的 claude.ai prompt 裡消失了。 我直接數過字串出現次數：Opus 4.8 的 prompt 提到 tool_search 四次，Opus 5 是 0 次；Opus 4.8 有一條很具體的規則「When code-execution tools are available and the task involves creating, editing, or analyzing a file, the first tool call is view on the relevant SKILL.md」，Opus 5 完全沒有 SKILL 這個字。

可操作的意思： 這條特別值得注意，因為「先讀 SKILL.md 再動手」是很多人以為模型天生會做的事。從這份 diff 看，它至少在 claude.ai 這層曾經是被 system prompt 明文要求的，而不是模型自發行為。如果你在 API 上自己做 deferred tools / skills 載入，別假設模型會自動先去查 —— 這段規則你得自己寫進 system prompt。（再強調一次：這頁不涵蓋 API 也不涵蓋 Claude Code，所以這只能當作「Anthropic 認為需要明講」的訊號，不能當作 Claude Code 現況。）

3. 知識截止從「end of Jan 2026」移到「end of May 2026」。

4. 新增 <fable_safeguards_routing> 區塊。 這段直接在 prompt 裡引用了 Anthropic 部落格原文，解釋 Fable 5 的部分查詢會被 routing 到 Opus 5：「we've tuned these safeguards conservatively—they'll sometimes catch harmless requests, though they trigger, on average, in less than 5% of sessions.」如果你曾經覺得「我明明選了 Fable，怎麼感覺不像」，這裡有官方答案。（注意這個 5% 是 Anthropic 自己回報的數字，沒有第三方驗證。）

5. <anthropic_reminders> 的清單多了 long_conversation_reminder。 Opus 4.8 列的是 image_reminder、cyber_warning、system_warning、ethics_reminder、ip_reminder；Opus 5 多了 long_conversation_reminder，並說明它是「appended to the person's message by Anthropic」，用來在長對話中維持指令。這對「為什麼長對話後模型行為會變」提供了一個具體的機制解釋。

6. 措辭黑名單換了字。 4.8 是避免 "genuinely"、"honestly"、"actually"；Opus 5 換成 "genuinely"、"honestly"、"straightforward"，而且補上了理由。

順帶一提，simonw 之前用同一套方法寫過 Opus 4.6 → 4.7 的變化筆記，抓到的重點包括 child safety 段落被大幅擴充並包進新的 <critical_child_safety_instructions> 標籤，以及新增「When a request leaves minor details unspecified, the person typically wants Claude to make a reasonable attempt now, not to be interviewed first」這條 —— 這條直接解釋了為什麼 4.7 之後模型變得比較不愛反問你。

五、數據、以及必須誠實講的限制

先講一個我量完之後、跟 HN 熱門留言相反的結論。

留言區主流意見是「system prompt 從早期 ~300 字膨脹到現在 3000+ token」。前半段對：Opus 3（2024-07-12）的 prompt 是 350 字，Haiku 3 只有 114 字。但「一路膨脹」不成立。我用同一支解析器量了 29 個版本的字數：

版本	日期	字數
Claude Haiku 3	2024-07-12	114
Claude Opus 3	2024-07-12	350
Claude Sonnet 3.5	2024-11-22	4,112（全期最高）
Claude Opus 4	2025-05-22	1,706
Claude Opus 4.7	2026-04-16	3,678
Claude Opus 4.8	2026-05-28	3,350
Claude Opus 5	2026-07-24	3,227

峰值出現在 2024 年 11 月的 Sonnet 3.5（4,112 字），比今天的 Opus 5 還長。而近三版是連續在縮短的：3,678 → 3,350 → 3,227。Opus 4.8 → Opus 5 的 diff 也是 33 行新增對 49 行刪除，淨減。這跟「模型越新 prompt 越臃腫」的直覺相反，值得寫進你的判斷。

（這些是我用 extract.py 同款正則解析後以空白切詞算的英文字數，不是 token 數。token 數大約會是字數的 1.3–1.5 倍，但確切值取決於 tokenizer，我沒有實際跑過，所以不給數字。）

其他必須標清楚的限制：

假日期不是部署日期。 commit date 來自文件標題上的日期，代表 Anthropic 文件標註的版本日期，不等於實際上線時間，也不代表那天所有使用者都拿到新版。
腳本不是冪等的。 README 明說：同一份來源重跑一次會產生四個新 commit（內容相同、SHA 不同）。要重生成得先 git reset --hard。simonw 後來補了 extract_incremental.py 做增量更新，加 --no-commit 可以先看再決定要不要 commit。
來源格式會變。 simonw 的筆記記錄了 2026-08-09 那次：Anthropic 把 markup 從 <section title="..."> 換成 Mintlify 的 <Accordion title="...">，內文還多縮排四格。解析器得同時吃兩種格式，並且只移除呈現用的縮排。任何做這類追蹤的人都要有心理準備：上游格式會無預警改，你的解析器要能容錯。
這份 repo 本身是 AI 生成的。 README 頂端有明確聲明：「This is an AI-generated research report. All text and code in this report was created by an LLM.」這其實是這個案例最有意思的地方之一 —— 它同時是「用 coding agent 做研究工程」的示範，也提醒你腳本的正確性要自己驗（我重跑一次拿到相同的 29 筆／116 commit，算是一個獨立驗證點）。

六、把這招搬到你自己的工作流

上面講的都是「讀 Anthropic 的 prompt」。但真正的價值是這個模式本身：任何會定期改動、而你又依賴它的外部文字資產，都應該進 git。

招式 1：`.md` 後綴抓原始文件

Mintlify 架的文件站（Anthropic 的兩個文件站都是）在網址後面加 .md 就會回純 markdown。我實測都是 HTTP 200：

curl -sS https://platform.claude.com/docs/en/release-notes/system-prompts.md   # 471 KB
curl -sS https://platform.claude.com/docs/en/release-notes/api.md              #  87 KB
curl -sS https://code.claude.com/docs/en/overview.md                           #  16 KB

這比爬 HTML 再轉 markdown 乾淨太多，diff 也不會被 HTML 噪音污染。

招式 2：一支十行的每日同步腳本

#!/usr/bin/env bash
set -euo pipefail
cd ~/prompt-watch

curl -sS https://platform.claude.com/docs/en/release-notes/system-prompts.md \
     -o claude-web-system-prompts.md
curl -sS https://platform.claude.com/docs/en/release-notes/api.md \
     -o claude-api-release-notes.md
curl -sSL https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md \
     -o claude-code-changelog.md

git add -A
git diff --cached --quiet || git commit -m "sync $(date +%F)"

丟進 cron 每天跑一次。沒變就不 commit，有變就留下一筆。你的「有沒有改」偵測器從此是 git diff --cached --quiet，不是你的記憶力。

招式 3：讓 coding agent 幫你讀 diff（給它明確的收斂條件）

diff 出來還是很長，這步交給 agent。但別直接叫它「總結一下」 —— 那會得到一份沒有行動指引的流水帳。給收斂條件：

讀 `git diff HEAD~1 HEAD -- claude-web-system-prompts.md` 的輸出。

只列出「會改變我該怎麼寫 prompt 或設計 agent」的行為變化。每一項要有：
1. 一句話說明變化
2. 被刪除或新增的原文（逐字引用，不要改寫）
3. 對我的具體影響：我的 CLAUDE.md / system prompt 有沒有哪一條因此該刪或該加

規則：
- 純措辭潤飾、代名詞替換（user → person）一律略過
- 不要推測 diff 裡沒有的內容
- 如果這次沒有任何行為層級的變化，就回「無行為變化」，不要湊字數

最後那三條規則是重點。沒有它們，agent 會很樂意把「user 改成 person」寫成一項重大發現。

招式 4：把同一招用在你自己的 prompt 資產

這是最容易被忽略、但回報最高的一個。你團隊的 CLAUDE.md、AGENTS.md、.claude/skills/*/SKILL.md、各個 sub-agent 的 system prompt —— 這些多半已經在 git 裡了，但幾乎沒人真的當它是可審計的資產在用。

三個立刻能做的：

# 這條「不要問我問題」是誰在哪個 commit 加的？當時解決什麼問題？
git log -S "不要問我" --oneline -- CLAUDE.md

# 上次 agent 行為變怪，是不是 CLAUDE.md 那次改動造成的？
git log -p --since="2 weeks ago" -- CLAUDE.md .claude/

# 這一段規則現在還有存在的理由嗎？
git blame CLAUDE.md

CLAUDE.md 最典型的失敗模式，是變成一個只增不減的補丁堆：每次 agent 做錯一件事就加一條規則，從來沒人刪。半年後你有 200 行互相矛盾的指令 —— 而 HN 那串討論裡多次被提到的一點正是「instructions containing contradictions lead to diminished quality」。

Anthropic 官方的 prompt 近三版在縮短，這件事本身就是一個可以抄的做法：定期把規則拿出來檢視，砍掉模型已經不需要被提醒的那些。git blame 就是你決定「這條還要不要留」的證據來源。

七、什麼時候別用這招

誠實講 trade-off：

只想知道「這版改了什麼」而且官方有寫更新說明 —— 直接看官方說明就好，不用建 repo。這套方法的價值在於官方沒有提供結構化 diff 的時候。
你只用 API，不碰 claude.ai —— 那這份特定文件對你的直接參考價值有限（官方明說不適用 API）。但招式 2 到 4 仍然成立，只是把追蹤目標換成 API release notes 和你自己的 prompt。
上游改版頻率極低 —— 每年動一次的東西，建 pipeline 的成本大於收益，加個 RSS 就好。
你需要的是「為什麼改」而不是「改了什麼」 —— diff 只給你 what，不給你 why。Anthropic 不會解釋每次修改的動機，你只能從變化推論，而推論很容易過度延伸。上面第四節我寫的每一條「可操作的意思」，都是我從 diff 推的，不是官方說的。

八、來源

主要來源（primary sources）：

Anthropic 官方 system prompt 發布頁：https://platform.claude.com/docs/en/release-notes/system-prompts（純 markdown 版：同網址加 .md）
simonw/research — extract-system-prompts/（README、extract.py、notes.md）：https://github.com/simonw/research/tree/main/extract-system-prompts
Simon Willison《Research: Claude system prompts as a git timeline》，2026-04-18：https://simonwillison.net/2026/Apr/18/extract-system-prompts/
Simon Willison《Changes in the system prompt between Claude Opus 4.6 and 4.7》，2026-04-18：https://simonwillison.net/2026/Apr/18/opus-system-prompt/
Piebald AI — Piebald-AI/claude-code-system-prompts（Claude Code system prompt 逆向整理，非官方）：https://github.com/Piebald-AI/claude-code-system-prompts
Hacker News 討論串「Claude: System Prompts」，2026-08-16，由 tosh 提交，539 分 / 225 則留言：https://news.ycombinator.com/item?id=49319556

驗證方式： 本文所有數字（29 個修訂、17 個模型、116 個 commit、各版本字數、Opus 4.8 → Opus 5 的 33 增 49 刪、tool_search 出現次數 4 → 0、區塊數 17 → 14）都是我在本機抓官方 .md 原始檔、跑 simonw 的 extract.py 後實際量出來的。所有引用的 prompt 原文皆為官方文件逐字內容。Fable 5 safeguards 觸發率「平均低於 5% of sessions」是 Anthropic 自行回報並寫入 system prompt 的數字，無第三方驗證。