multica-ai/andrej-karpathy-skills：四條規則，少一點過度設計

multica-ai/andrej-karpathy-skills 這個名稱很像 Andrej Karpathy 本人發布的工具，其實不是。repo 維護者根據 Karpathy 在 X 上談到的 AI coding agent 問題，把幾項建議整理成一份行為準則。

如果你期待的是新的 coding 工具，這個 repo 沒有 API、腳本或外部服務。主體是一份 67 行的 SKILL.md，把四項 coding guardrails 放進代理的工作流程。它改變的是代理如何動手，不是增加新的執行能力。

它是 Skill，也是一段 Prompt

karpathy-guidelines 的內容是一段 coding agent 行為 Prompt，repo 再用帶有 frontmatter 的 SKILL.md 封裝，補上名稱、用途與觸發情境。

同一套規則在 repo 裡有幾種包裝：

檔案或目錄	用途
`skills/karpathy-guidelines/SKILL.md`	提供給支援 Agent Skills 的工具載入
`CLAUDE.md`	讓 Claude Code 在專案裡持續套用規則
`.claude-plugin/`	提供 Claude Code plugin metadata
`.cursor/rules/karpathy-guidelines.mdc`	讓 Cursor 套用同一套準則
`EXAMPLES.md`	用正反例說明常見錯誤與較好的做法

這些入口共用同一組規則，差別只是 Claude Code、Cursor 或其他 host 如何載入。把它稱為行為型 Skill 已經足夠。

原則	要避免的問題	實際做法
Think Before Coding	默默選一種解讀，方向錯了仍一路做下去	說明會影響結果的假設，遇到不同解讀時呈現取捨，缺少必要資訊才詢問
Simplicity First	為單次需求建立多層抽象、設定系統和未來可能用到的功能	先寫能解決現在問題的最少程式碼，需要時再重構
Surgical Changes	修一個錯誤時順便改格式、註解或鄰近模組	只動和需求直接相關的地方，清掉自己這次變更造成的孤兒程式碼
Goal-Driven Execution	沒有重現、測試或完成條件就開始修改	先定義可觀察的成功標準，再實作並重新驗證

四條規則讀起來都像常識，coding agent 偏偏很常在這些地方失手。短也有短的好處。團隊可以真的讀完每一行，再決定哪些要保留，不必先接受一份上千行、沒有人完整檢查過的指令。

只看「保持簡單」很容易點頭，實際寫程式時仍然可能做過頭。這個 repo 另外準備了九組正反例，把四條規則放進具體情境。

例如，使用者只說「匯出使用者資料」時，代理不該直接假設要匯出所有帳號、固定欄位和某個檔案位置。加入折扣計算也不必立刻建立 strategy pattern、設定物件和多種實作。面對模糊的「修好登入系統」，則要先縮成可驗證的問題，例如改密碼後舊 session 是否失效。

九組例子也不是每一組都可靠。其中「duplicate scores」宣稱 Python 對同分資料的排序不穩定，但 Python 的排序保證 stable，範例測試也沒有真的檢查 tie order。把 EXAMPLES.md 當成討論材料即可，測試本身仍要親自跑過。

設計模式、型別和擴充點本身沒有錯，問題通常是加入得太早。需求還沒出現，複雜度就已經進入程式碼，之後每一次修改都要付維護成本。

如果 coding agent 經常替你做太多決定，或每次修改都帶著大範圍重構，可以把這四條放進專案指令。它也適合剛開始建立 AGENTS.md、CLAUDE.md 或 Cursor rules 的團隊，因為內容短，容易逐條討論和刪改。

不過，它不是每個任務都要完整執行的流程。改一個錯字、調整明確的常數或更新已知版本，不需要先開需求訪談。上游也承認這份準則偏向謹慎，簡單任務仍要靠代理判斷。

若要在 Codex 使用，現階段最直接的做法是把需要的規則手動合併進專案 AGENTS.md。先檢查現有內容；如果已經要求說明假設、保持實作簡單、避免無關變更並驗證結果，就不用再複製一份。截至本文更新日，上游主分支還沒有正式的 AGENTS.md，Codex 支援仍在 PR #164。

Skill	重疊之處	比較適合的情境
Prompt Optimizer Skill	同樣要求先理解需求、守住範圍並驗證結果，另外細分「直接執行、合理假設、必要追問」	想改善代理面對模糊需求時的判斷，而且不限於寫程式
Ponytail	同樣反對過度抽象與 speculative features，另外提供七階梯、強度模式與 plugin hooks	Coding agent 經常重造輪子或為小功能新增 dependency
`tdd`	把最少實作與可驗證迴圈落實成 red、green 的垂直切片	已有明確行為，需要用測試推進實作
`diagnosing-bugs`	要求可否證假設、最小重現和 regression test	處理難以重現的 bug 或效能退化
`code-review`	從 review 角度檢查 scope creep、過度抽象和未驗證變更	實作完成後，檢查 diff 是否符合規格與專案標準

Skill 放在硬碟上，是否計入每次對話的 context，取決於代理怎麼載入。有些工具先讀名稱和 description，符合任務時才載入整份 SKILL.md。即使如此，幾個相近的觸發描述仍可能讓代理選到重複或互相衝突的規則。

我的做法是只保留一份通用行為準則，階段型 Skill 再按任務叫用。需求模糊時用 Prompt Optimizer，實作明確行為時用 tdd，難解錯誤用 diagnosing-bugs，完成後才用 code-review。

andrej-karpathy-skills 比較像一張 67 行的檢查表，不是必裝套件。四條原則若早已寫進 AGENTS.md、CLAUDE.md 或另一份 Skill，把 repo 留在書籤裡就夠了；如果真的缺少其中一條，再補進現有規則，通常比疊上第二套通用指令乾淨。