為什麼想查這個
2026-04-17，vault 剛搭起來第三天，我把 andrej-karpathy-skills 的四個行為原則寫進 CLAUDE.md 和每個 skill。原因很直接：LLM 執行 skill 時總會「順手多做一點」，例如看到格式不統一就整份重寫。
五月重寫 CLAUDE.md 時，四原則整段搬到 vault 裡一頁獨立的 Karpathy 四原則，CLAUDE.md 只留一行指標：
執行任何 skill 前先看 karpathy-guidelines（4 原則：行動前陳述理解／最小化／手術式修改／目標驅動驗證）。
半年下來，CLAUDE.md 又長出很多規則。這次把上游 repo 的 EXAMPLES.md 九個範例拿出來，一個一個對照現在這份 CLAUDE.md：那行指標以外，四原則到底有沒有落成具體規則。
查到什麼
上游的四原則與九個範例
上游的出發點是 Karpathy 在 X 上對 LLM 寫程式的抱怨（原貼文）：替你做了錯的假設然後一路跑下去、把 100 行能解決的事寫成 1000 行、順手改動與任務無關的程式。四原則各自對一類毛病：
| 原則 | 一句話 |
|---|---|
| Think Before Coding（行動前陳述理解） | 不假設、不藏起困惑、把取捨攤開 |
| Simplicity First（最小化） | 寫出解決問題的最少程式碼，不放臆測性的東西 |
| Surgical Changes（手術式修改） | 只碰非碰不可的地方；每一行改動都要能追溯到請求 |
| Goal-Driven Execution（目標驅動驗證） | 定義成功標準，迴圈到驗證通過為止 |
EXAMPLES.md 每條原則配二到三個範例，都是程式情境。以下逐一對照。CLAUDE.md 的引文照原文。
1. 隱藏的假設：匯出使用者資料
上游：LLM 自行決定範圍、檔案位置、欄位、CSV 格式。該先問範圍、交付方式、敏感欄位、資料量。
CLAUDE.md：最接近的是把「敏感資料」這一題直接寫死答案，不留給模型假設：
vault 含
finance/（真實資產數字）與personal/，永遠不可轉公開。
personal/ 另外標明「私人紀錄，不入 wiki 流」。其他假設（範圍、位置）靠的是那一行四原則指標，和各 skill 動手前的「行動前陳述」。
2. 多種解讀：讓搜尋變快
上游：LLM 挑了一種「快」的意思就動手。該列出幾種解讀，問要哪個。
CLAUDE.md：這一題的作法跟上游相反。遇到「這頁該放 engineer 還是 ideas」這種多解讀，CLAUDE.md 不叫模型問，而是給預設值：
engineer vs ideas 是預設值，不是分類學：概念頁預設進
ideas……判不出來就 ideas——……放錯之後搬一次即可，花時間裁決歸屬才是實際損失。
Inbox 分類也一樣：「不確定 → 讀內容判斷域」。可逆、搬一次就好的決定，用預設值取代提問。
3. 過度抽象：計算折扣
上游：為一個百分比計算建類別階層與設定檔。該寫一個函式，真的有多種折扣再加結構。
CLAUDE.md：域的結構規則幾乎就是這條的翻版，「從最小結構開始按需長大」：
域為頂層資料夾，從最小結構開始按需長大。……raw/ 不到 5 檔不建 wiki/。
開頂層域也要有門檻（預期高頻寫入、對外公開、累積 > 10 個 wiki 或 > 20 個 raw／logs，任一成立才開），否則留在 others/，而且「others/ 是單一扁平雜項域……不在其下開子域」。
4. 臆測性功能：儲存偏好設定
上游：加了沒人要的驗證、快取、通知選項。該只做被要求的事。
CLAUDE.md：有三處在擋「多做」：
- 管線推進：產出型 skill 收尾時提議下一步，「提議即可，不強制執行」
- Hub 策展頁：「新開 hub 需 tag 探勘數據支持（跨 ≥ 2 域的主題叢），維持少量」
- 根目錄：「一次性腳本、分析報告、依賴檔……在 vault 外執行，產出物完成即刪（hook 會擋）」
5. 順手重構：修空 email 造成的崩潰
上游：修 bug 時順手重寫整段驗證、改註解。該只改處理空 email 的那幾行。
CLAUDE.md：用「不准動」的明文擋：
- log：「一律 append 到當月檔檔尾……不回頭改舊月檔」
/note-enrich：「原文一字不改自成一塊」；「策展 wiki 頁不就地寫」/wiki-build --promote：「原文不改，只用 vault 補 sources／連結」
6. 風格漂移：上傳功能加 logging
上游：加 logging 時順便改引號、加型別提示、重排格式。該照原檔風格。
CLAUDE.md：格式寫成固定規格，部分交給機器鎖：
- 各域 index 的條目格式固定為「頁面連結 — 一行摘要」，摘要取自 frontmatter
summary - Log 格式固定，operation 只能是列舉的十一種
- 「換行由
.gitattributes鎖定：LF 入庫，.ps1／.bat／.cmd用 CRLF」 - hooks 會擋下「wiki 頁缺
title/summary/tags/date」
7. 模糊 vs 可驗證：修好認證
上游：泛泛計畫就動手，沒有成功標準。該先鎖定具體問題，寫失敗測試再修。
CLAUDE.md：本身沒有寫成功標準，標準放在各 skill 的末尾。CLAUDE.md 寫的是驗收關卡：
不開 auto-commit——「commit 前先看 diff」是主要審閱關卡。
以及 /vault-maintain 的「--apply 修安全項、重跑 lint 驗證（刪除類另經 reviewer）」。
8. 多步驟要分段驗證：加 rate limiting
上游：一次塞進所有功能，沒有驗證步驟。該拆成可各自檢查的增量階段。
CLAUDE.md：工作流本身就是分段的：
- 每個 session 在 worktree 裡改，收尾開 PR，「回報 PR 連結後停，由使用者 merge」
- 推之前「本機先併 main……確認無 conflict marker」
- 兩段式工作：triage 產出 review 等人填，「第一段只
git push -u origin HEAD、先不開 PR」，下次 session 接著做完才開 PR
9. 先重現再修：同分排序不穩定
上游：沒先重現 bug 就改排序邏輯。該先寫一個會失敗的測試，確認它失敗，再修。
CLAUDE.md：沒有對應的規則。vault 是內容不是程式，沒有測試；最接近的一句只是叫人把錯誤當真：
讀檔報
EUNKNOWN／The cloud operation is invalid要當真的錯誤查。
這句說的是「別把錯誤解釋掉」，沒有說「先重現」。
對照結果
| 範例 | 原則 | CLAUDE.md 裡的對應 |
|---|---|---|
| 1 匯出資料 | 陳述理解 | 敏感資料寫死答案（finance／personal 永不公開）；其餘靠四原則指標 |
| 2 讓搜尋變快 | 陳述理解 | 反過來：可逆的多解讀給預設值，不問 |
| 3 計算折扣 | 最小化 | 域結構按需長大、建 wiki／開頂層域有門檻 |
| 4 儲存偏好 | 最小化 | 管線只提議、hub 要數據、一次性產物不留 |
| 5 空 email | 手術式 | log append-only、原文一字不改 |
| 6 加 logging | 手術式 | 格式規格固定，換行與 frontmatter 由機器鎖 |
| 7 修好認證 | 目標驅動 | 成功標準在 skill；CLAUDE.md 只寫 diff 審閱關卡 |
| 8 rate limiting | 目標驅動 | worktree → 本機併 main → PR → 人 merge；兩段式工作 |
| 9 同分排序 | 目標驅動 | 沒有對應 |
跟我的關係
九個範例裡有八個在 CLAUDE.md 找得到具體規則，而且這些規則大多不是用四原則的字眼寫的。我之前整理 vault 演進時的結論是：護欄是長出來的。四原則是軟約束，hooks 是硬約束，worktree 是結構隔離，每一層都是前一層擋不住某類錯誤時才加上去。
目標驅動驗證那一條，我在整理多 agent 編排時寫過：它還是要我人工 review wiki 品質，這就是還沒下放的監督成本。這次對照也一樣，第 7、8 個範例在 CLAUDE.md 裡最後都停在「人看 diff、人按 merge」。