我寫了半年skill，直到上週才意識到自己從一開始就搞錯了方向

事情係咁嘅。

前排我又一次重構公司內部嗰幾個Claude Code嘅skill，寫寫嚇開始覺得有啲唔對路。

我發現我呢半年寫嗰啲skill，由定位上已經錯咗。

唔係語法錯，唔係內容寫得唔好，係我對skill呢樣嘢到底係乜，成個想法都錯咗。

圖源：Claude API Docs「Agent Skills」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview^[1]

呢件事講起嚟都幾瘀。skill舊年10月出咗之後我就跟住開始寫，當佢係一種「更長嘅prompt」咁用。就係嗰種你每次都要複製貼上一大段嘅指令，包裝一下改個名，擺~/.claude/skills/落去，感覺自己好似好明白咁。後來CLAUDE.md、AGENTS.md呢啲嘢陸陸續續出現，我嘅理解依然停留喺「呢啲都係提示詞文件，只係放嘅位置唔同」。

呢個錯覺維持咗三四個月。

中間踩咗唔少坑，但都冇令我跳出來。我會覺得「今次skill冇觸發，係我description寫得唔好」，會覺得「Claude忽略咗CLAUDE.md，係我冇強調夠」，會覺得「呢個流程行得唔穩定，係模型今日狀態唔好」。所有問題喺我腦入面都係「執行細節」嘅問題，唔係「定位」嘅問題。

第一次真正撼動我嘅係今年1月Vercel嗰篇評測，《AGENTS.md outperforms skills in our agent evals》。佢測出skill默認情況下56%嘅case根本冇被觸發，一份壓縮過嘅AGENTS.md就可以做到100%。呢個數字當時喺HN上嘈咗好幾日，我睇完心入面咯噔咗一下，但嗰陣時仲未完全諗通，只係覺得「哦，skill嘅觸發可能冇我想像中咁可靠」。

真正令我放唔低嘅係2月Snyk出嗰份ToxicSkills審計，我等陣會再講呢個。見到嗰份審計嘅一刻，我意識到我一路喺錯誤嘅抽象層級上理解呢件事。

嗰段時間我手邊啱啱好有一份幾硬核嘅deep research，係我叫一個agent幫我梳理由2025年下半年到2026年春天呢段時間，各種官方文件、工程博客、Hacker News討論同實測文章嘅共識。我本來只係想拎嚟打磨我自己嘅skill點樣寫得更好。但係睇到後半段我突然反應過來，呢啲討論嘅共同指向，從來都唔係「邊種格式最好」或者「skill應該點樣寫」。

真正嘅共識係。

skill根本唔係一份提示詞文件，佢係你agent運行時架構嘅一部分。

呢個判斷落到我度嘅時候，我坐喺櫈上諗咗好耐。因為佢翻譯過嚟意味着一件事，就係呢半年所有傾「prompt engineering」嘅討論，喺agent呢個場景裏面已經唔夠用。你正在面對嘅唔係「點樣寫一段好提示詞」，而係「點樣設計一套可以長期演進嘅agent操作系統」。

圖源：Claude API Docs「Get started with Agent Skills in the API」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/quickstart^[2]

呢句話有啲大。先唔好急，順住落去，我將我自己嘅路徑行一次你就明。

返去skill到底是個乜嘢機制呢塊。

大家都知道，Claude Code係每次會話都從空嘅上下文開始。呢件事其實幾反直覺，因為你用嚇用嚇會產生一種錯覺，以為呢樣嘢「記得」你嘅項目。其實佢唔記得，佢每次係新嚟嘅。

咁點解佢睇落好似記得呢？因為有兩套跨會話嘅嘢頂住。

第一套係CLAUDE.md，你自己寫嘅規則同指令，每次會話啓動都成個加載入去。呢樣嘢嘅特點係，每次都入上下文。所以佢係一個槓桿極高嘅點，你放乜嘢入去，就等於你俾每次會話都付咗嗰份token嘅成本。

第二套係auto memory，模型根據你反覆糾正嘅內容自動儲起嘅notes，都會跟住會話加載。

到呢度為止，聽起嚟仲係「提示詞文件」嘅感覺係咪。

skill嘅機制就完全唔同喇。

skill裏面其實係一個文件夾，有SKILL.md正文、有scripts/腳本、有references/引用材料、有assets/素材。但關鍵在於，佢唔係每次會話都入上下文嘅。

每次會話啓動嘅時候，Claude只會先見到所有skill嘅name和description，正文佢睇唔到。只有當agent判斷當前任務同某個skill匹配咗，佢先會主動去將嗰個skill嘅正文成個讀入嚟，掛到會話裏面。

聽起嚟好簡單係咪。但呢度拐咗個彎。

你諗嚇，skill就有咗一套自己嘅發現、調用、掛載、保持、壓縮管理機制。佢唔係一個被動嘅文本，佢係一個會被agent按需觸發嘅過程模塊。你寫skill嘅時候，description字段寫得好唔好，直接決定咗呢個skill可唔可以被觸發；裏面嘅腳本寫得啱唔啱，決定咗agent可唔可以真係執行動作；引用文件組織得合唔合理，決定咗喺長會話裏面上下文被壓縮之後佢仲可唔可以掛返嚟。

圖源：Claude API Docs「Skill authoring best practices」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices^[3]

呢個已經唔係「文字」嘅範疇喇。呢個係一個可部署單元。

官方文件裏面有一句話我印象特別深。佢話，如果你發現CLAUDE.md裏面嘅某一段已經變成咗「procedure而唔係fact」，就應該將佢遷去skill。翻譯過嚟就係，如果呢段嘢係「多步流程、分支判斷、校驗順序」，佢就唔應該常駐喺上下文裏面，佢應該係一個可以喺需要嘅時候被加載、唔需要嘅時候就唔佔token嘅模塊。

呢句話觸動我幾深。因為我過去嘅寫法啱啱相反，係我覺得重要嘅，我都塞入CLAUDE.md。塞到後來嗰個文件兩百幾行，每次對話一開始就要燒一大堆token，而且因為太長，Claude自己都成日唔睇細節。

呢個就係我話「我一開始就搞錯咗」嘅意思。我喺用一個高槓桿嘅常駐層，放咗一堆只有喺特定任務裏面先需要嘅專題流程。

咁正確嘅心智模型應該係點樣？

我自己都仲喺摸索，但呢套分層基本穩定咗，可以分享俾你先。

你喺俾agent搭建知識同行為嘅時候，唔好再諗「我應該擺入邊個文件」，要諗層。agent有好多層唔同性質嘅層，每一層要放嘅嘢性質完全唔一樣。

第一層係memory，解決agent失憶問題。 你對agent嘅長期偏好、佢反覆被糾正出來嘅經驗、跨項目通用嘅嗰啲嘢，放呢一層。對Claude嚟講係auto memory，對Cline嚟講係Memory Bank嗰套結構化項目檔案。呢一層嘅核心特徵係，佢唔係你手動寫嘅，係agent自己喺用嘅過程中沉澱出嚟嘅。

第二層係CLAUDE.md或AGENTS.md，項目級默認行為同地圖。 每次會話都會加載，所以佢要短、要普適、要高價值。放啲乜？放項目地圖、默認流程、關鍵gotchas、你唔想每次重新解釋嘅嗰啲基礎約束。Anthropic官方建議控制在200行以內；Augment嗰篇評測更具體，建議100到150行主文件加少量引用文件。數字唔一定通用，但原則是穩定嘅，常駐層只放高價值、廣適用、低歧義嘅嘢，其他都下沉。

第三層係nested CLAUDE.md或path-scoped rules，模塊級約束。 呢一層係我後來先重視起嚟嘅，效果意外咁好。你可以喺子目錄裏面放一個細嘅CLAUDE.md，Claude會按目錄層級懶加載，只有讀到嗰個目錄下嘅文件時先會注入。path rules仲可以用paths字段精確限定，例如只喺.ts文件或者/api/路徑下生效。HN上有條評論講得好準，「multiple good AGENTS.md is even better」，因為佢將上下文注入做咗空間上嘅隔離，agent唔會被無關約束污染。

第四層就係skill，可複用嘅專題工作流。 多步流程、分支判斷、注意事項、校驗順序、腳本入口、專題知識，都喺呢一層。佢嘅核心特點係按需加載，所以佢唔消耗常駐token，你可以放得好厚。

第五層係tools、MCP、CLI，動作層同數據層。 skill負責「幾時用、按咩順序用、成功標準係咩」，工具負責真正執行。好多人將呢兩者撈埋一齊寫，結果skill裏面塞咗一堆curl命令，其實應該拆開。

第六層係hooks，確定性約束。 呢一層我以前完全冇用過，後來先發現佢解決咗一類我本來解決唔到嘅問題。Anthropic官方有一句非常關鍵嘅區分，CLAUDE.md係advisory，hooks係deterministic。翻譯成人話就係，CLAUDE.md係「建議」，hooks係「強制」。凡是「必須每次發生、零例外」嘅事，應該下沉做hook，唔好再寄望模型自覺睇文件。

第七層係subagents，隔離上下文嘅專門執行者。 適合研究、審查、驗證呢種高讀文件量嘅任務。佢嘅價值在於可以將主對話從上下文污染裏面解放出來。某啲skill甚至可以通過context: fork直接運行喺subagent裏面。

第八層係eval同review，令所有資產持續變好嘅反饋迴路。 Anthropic工程文章裏面建議由評估開始，Agent Skills官方最佳實踐甚至將「俾LLM睇eval signals同當前SKILL.md，叫佢提出修改，再由人複核並迭代」寫成咗標準循環。

圖源：作者整理，基於 Claude Code 與 Agent Skills 官方文檔

呢套嘢第一眼睇落有啲嚇人，八層喎。但你真係將佢用起嚟之後會發現一個特別重要嘅價值。

佢將「今次經驗應該放喺邊」由模糊嘅直覺，變成咗一個有層級嘅工程決策。

講到呢個，最關鍵嘅其實唔係搭好呢套層，而係經驗嘅遷移原則。

我自己嘅感受係，搭建呢套分層唔難，官方文件都寫曬。真正難係後面呢個動作。每次真實工作流行完之後，今次學到嘅嘢到底應該入邊一層？

你諗嚇，呢個先係你作為人類真正需要做判斷嘅地方。agent自己都判斷唔出。呢個係你嘅嘢。

我自己琢磨咗幾條判斷規則，分享出嚟你睇嚇用唔用得着。

1. 凡是「每個會話都應該知道」嘅嘢，入CLAUDE.md或AGENTS.md。例如你哋公司代碼庫用pnpm唔係npm，例如所有API都要先過auth中間件，例如commit message必須符合conventional commits。呢啲嘢就算你今日唔用，下次人哋用都要用，就應該常駐。

2. 凡是「多步流程、專題檢查、分支決策」，入skill。例如「發版前嘅checklist」、「寫一個新React組件嘅標準流程」、「接入一個新嘅第三方API時嘅安全審查流程」。呢啲嘢只喺特定任務裏面先需要，常駐浪費，按需加載啱啱好。

3. 凡是「只對某目錄或某類文件生效」，入nested CLAUDE.md或path-scoped rules。例如你嘅/legacy/目錄裏面代碼風格同主項目唔一樣，就應該喺嗰個目錄裏面放一個細嘅CLAUDE.md，隻影響嗰個目錄。唔好將呢種局部約束放喺頂層，會污染曬所有對話。

4. 凡是「必須每次執行、唔可以靠模型自覺」，入hook。例如提交前必須跑lint，例如修改數據庫schema前必須備份。呢啲嘢寫入CLAUDE.md你會發現Claude有時候就係會唔記得，寫成hook就係強制執行，走唔甩。

5. 凡是「模型需要真實執行或查詢」，入CLI、MCP或scripts。唔好喺skill裏面寫一堆「你應該咁樣咁樣調用API」，直接將調用包成一個腳本，叫skill調用腳本。skill負責決策，腳本負責執行。

6. 凡是已經由「專題經驗」變成「所有相關任務都應該遵守嘅通用約束」，由skill上移到CLAUDE.md。呢條特別重要。HN上有條評論講得好精闢，話「好多review skill裏面嘅反模式，唔係應該喺寫代碼階段就避免咩？」作者嘅回應都基本承認咗，呢啲規則確實應該入CLAUDE.md。所以skill唔係終點，佢只係經驗嘅中轉站，好嘅經驗會由skill上升到項目級規則。

圖源：Claude Code Docs「How Claude remembers your project」，https://docs.claude.com/en/docs/claude-code/memory^[4]

呢套遷移原則我前前後後行咗兩三個月，而家公司嗰幾個項目嘅agent表現明顯穩定咗。最大嘅變化係，我嘅CLAUDE.md由兩百幾行縮返到一百行左右，但agent行為反而比以前更準。

原因好簡單，之前嗰一百幾行嘅冗餘都係專題流程，佢哋擠佔咗真正重要規則嘅注意力。遷移到skill之後，CLAUDE.md裏面淨低真正每次都要知嘅嘢，agent反而更容易捉到重點。

但係講句實話，以上呢啲都仲遠遠未到「寫好就穩」嘅階段。我要坦白。

而家呢套體系最大嘅問題，係agent到底可以有幾可靠咁讀取同調用呢啲資產，仲未有標準答案。

返去開頭講嘅Vercel嗰篇評測，將數據完整擺出嚟你就更體會到佢扎心喺邊。佢用Next.js 16嘅文件檢索作為測試場景，skill預設情況下56%嘅case根本冇被觸發，必須加上明確嘅調用指令，通過率先可以由53%拉到79%。而一份壓縮過嘅AGENTS.md docs index，同一場景下可以做得到100%。

呢個數據傳出去之後，HN上嘈咗好多日。有人話AGENTS.md贏曬，亦有人話呢個只係特定harness下嘅特定場景，唔可以外推。我比較傾向後者，因為Vercel呢個測試講到底係一個「文件檢索」任務，skill嘅優勢唔喺呢種任務上，skill嘅優勢喺「多步流程同專題決策」。用一個唔適合skill嘅場景去測skill，結果當然難睇。

但呢件事說明一個更深嘅問題，今日嘅agent可唔可以穩定咁按照你設計嘅分層去工作，好大程度上仲依賴harness、依賴模型能力、依賴skill描述字段寫得幾好、甚至依賴運氣。

圖源：Vercel Blog「AGENTS.md outperforms skills in our agent evals」，https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals^[5]

HN上最長壽嘅一條抱怨係，「長會話之後agent會漂移」、「佢就係有時唔睇CLAUDE.md」、「skill調用唔穩定」。呢啲都係真實存在嘅問題。我自己都遇過，同一個skill喺朝早可以觸發，下晝就唔得，你想爆頭都唔知點解。

所以我想講嘅係，分層心智模型本身係成立嘅，但具體到每日嘅使用上，你仍然會踩到一啲「玄學」級別嘅坑。呢個唔係你嘅錯，亦唔係文件嘅錯，係呢個領域本身仲喺演進。

順住上面再傾嚇，呢個係我以前完全冇諗到嘅維度，治理同安全。

返去開頭我講嗰份Snyk嘅ToxicSkills審計。佢真正令我停低嘅，唔係skill寫得唔好，而係skill已經有咗被惡意利用嘅樣本。

佢哋喺3984個公開嘅skill裏面做咗一輪安全掃描，結果你估點樣。13.4%含critical issue、36.8%含至少一種安全問題、並確認咗76個惡意skills。

？？？

呢組數字我反覆睇咗兩次。後來諗諗，都合理。skill本身可以捆綁腳本，可以注入上下文，可以喺被觸發時執行真實動作，所以佢天然就係一個供應鏈入口，亦係一個權限擴展點。

惡意skill可以做啲乜？可以誘導Claude將你嘅代碼外傳，可以喺睇落正常嘅文件處理流程裏面塞一條偷偷上傳你env嘅命令，可以喺agent執行某啲動作嘅時候向命令入面插參數。

諗嚇就覺得背脊發涼。

因為我呢半年，下載咗一堆人哋寫嘅skill掟落自己電腦。

圖源：Snyk Blog「ToxicSkills」研究，https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/^[6]

所以skill呢樣嘢，而家已經唔只係「幫agent變聰明」嘅文本資產。佢同時係一個需要治理嘅代碼資產。你用別人嘅skill，就相當於喺你嘅agent裏面運行咗別人嘅一段代碼。呢個同你裝npm包落node_modules係同一性質嘅事，但好多人仲未意識到。

如果你所在嘅公司正在推agent工程化，呢塊一定要提上日程。skill嘅審計、簽名、白名單、沙箱執行權限。呢啲嘢今日睇落可能仲早，但等到agent真係深度進入生產系統嘅時候，呢個就係下一波供應鏈安全問題嘅前線。

講到呢度，返去最開頭嗰個轉折。由prompt engineering走到agent operating system，呢件事其實比睇落重要得多。

我話「我呢半年寫skill嘅定位都錯咗」，唔係謙虛，係真話。

我真正錯嘅地方，係我一直將agent當成一個「更聰明嘅搜索引擎」或者「更厲害嘅copilot」咁用，所以我將我嘅工作重心放喺「點樣令佢每一輪回覆都更好」上。呢套思路對應嘅，就係prompt engineering，你寫一段好話術，模型回你一段好答案。

但skill、CLAUDE.md、hooks、subagents、MCP呢套嘢夾埋喺暗示一個完全唔同嘅場景。你面對嘅唔係一次對話，你面對嘅係一個長期運行嘅、會反覆被調用嘅、會漸進式積累經驗嘅、需要同真實工具鏈交互嘅、需要被驗證同治理嘅運行時系統。

呢個同一次對話嘅優化唔係同一量級嘅事。

我間中會諗起2008年iPhone出咗之後，做網頁嗰班人點樣適應去做App。嗰陣時大家一開始都喺度問「App同網頁有咩分別，咪又係做個頁面」。但真係做落去發現，App有生命週期、有狀態管理、有權限模型、有供應鏈、有簽名、有發佈渠道、有崩潰日誌、有用戶留存。呢啲嘢任何一個拎出嚟，都同「寫一個網頁」唔係同一量級嘅工程。

今日我哋喺agent呢件事上，企喺類似嘅位置。

圖源：Claude Code Docs「Hooks reference」，https://docs.claude.com/en/docs/claude-code/hooks^[7]

你寫一段prompt叫agent做嘢，呢個係「網頁時代」。你設計一套可以長期演進、有分層、有治理、有反饋迴路嘅agent架構，呢個係「App時代」。

呢兩件事睇落好似都係「同模型講嘢」，其實完全唔同。

我自己講實話仲遠遠未跑通，我今日分享嘅呢啲嘢都係由Vercel嗰份評測到而家呢幾個月裏面踩坑、推翻、重構返嚟嘅。但我可以好清楚咁感覺到一件事。接下來真正拉開差距嘅，唔係邊個嘅prompt寫得靚，而係邊個嘅agent架構搭得穩。

講到呢度，我知道講咗咁多概念可能有啲悶。具體今日可以做啲乜，我將最關鍵嘅行動點拎出嚟，你如果今日就想動手嘅話，可以跟住做。

第一件事，今晚將你嘅CLAUDE.md打開，數一嚇行數。如果超過200行，就要開始考慮拆咗佢。將裏面嗰啲「多步流程、專題checklist、分支判斷」標出嚟，準備遷去skill。

第二件事，俾你最常用嘅幾個專題流程，各寫一個skill。例如「發版前流程」、「接新API嘅審查流程」、「寫新React組件嘅標準流程」。重點唔係正文有幾完美，重點係將description字段寫好，令agent喺需要嘅時候識別並觸發。

第三件事，如果你有一個/legacy/或者風格特殊嘅目錄，放一個nested CLAUDE.md。令嗰個目錄嘅規則隻影響嗰個目錄，唔污染全局。

第四件事，揾一件你反覆提Claude佢仲會唔記得嘅事，考慮寫成hook。例如「提交前必須跑lint」、「寫數據庫遷移前必須dry-run」。hook唔優雅，但佢deterministic，呢個特性喺關鍵場合無可替代。

第五件事，開始養成一個習慣。每次完成一個真實任務之後，問自己一句，今次學到嘅嘢應該入邊一層？入memory？入CLAUDE.md？入skill？入hook？入一個新腳本？呢一問就係最重要嘅治理動作。

圖源：Claude Code Docs「Create custom subagents」，https://docs.claude.com/en/docs/claude-code/sub-agents^[8]

寫到呢度我突然諗到一件幾有趣嘅事。

文章裏面我一直喺度講，多步判斷流程就應該寫成skill。咁「判斷今次嘅經驗應該入邊一層」呢件事本身，係咪都應該係一個skill？

係㗎。所以我順手將佢寫出咗嚟。

我將佢叫做experience-triage，經驗分診。佢嘅邏輯好簡單，你每次行完一個真實任務，觸發呢個skill，佢會帶你行完一套問答，最後話俾你知今次嘅經驗應該入邊一層、用咩模板寫、放喺邊個文件裏面。

skill嘅完整內容係咁樣，你可以直接複製貼上到~/.claude/skills/experience-triage/SKILL.md裏面使用。

---
name: experience-triage
description: 用於在完成一個真實任務之後，把這次學到的經驗、坑、約束、流程分診到agent架構的正確層級。當用戶說「這次學到的xxx該寫到哪」、「我剛踩了一個坑想沉澱」、「幫我判斷這條規則該進CLAUDE.md還是skill」、「我有個新流程不知道放哪」時觸發。
---

# 經驗分診流程

你的任務是帶用戶完成一次經驗分診，輸出明確的「該放在哪一層 + 應該怎麼寫 + 放到哪個文件」的建議。

## 第一步，問清楚要分診的經驗是什麼

請用戶用一句話描述這次想沉澱的內容。如果用戶描述太泛，要追問具體場景，比如：
- 這是一條什麼樣的規則？是「每次都要做」還是「特定情況下要做」？
- 這條經驗只對某個項目有用，還是跨項目通用？
- 它需要執行動作，還是隻是約束模型行為？

## 第二步，按下面的判斷樹走一遍

依次問這五個問題，第一個匹配上的就是答案：

**Q1：這件事是不是「必須每次執行、零例外、不能靠模型自覺」？**
是 → 推薦放進 `hook`。給出一個hook配置示例。
否 → Q2

**Q2：這件事是不是「需要真實執行命令、查詢接口、讀取數據」？**
是 → 推薦寫成 `script` 或 `MCP tool`，再在相應skill裏調用。
否 → Q3

**Q3：這件事是不是「只對某個目錄、某類文件、某個模塊生效」？**
是 → 推薦放進對應目錄的 `nested CLAUDE.md` 或 `path-scoped rule`。
否 → Q4

**Q4：這件事是不是「多步流程、專題checklist、需要分支判斷的過程」？**
是 → 推薦寫成新的 `skill`，給出 description 字段建議（必須寫到能被觸發的程度）。
否 → Q5

**Q5：這件事是不是「每個會話都應該知道的高頻默認行為或約束」？**
是 → 推薦加到 `CLAUDE.md` 或 `AGENTS.md`，並提示用戶檢查當前文件是否已超過200行。
否 → 這條經驗可能太私人、太一次性，不建議沉澱。直接告訴用戶。

## 第三步，給出可直接執行的寫作建議

根據Q1-Q5的答案，輸出一個可以直接寫入對應文件的草稿。草稿要：
- 格式正確（YAML frontmatter、Markdown標題、代碼塊等）
- 言之有物，不要寫「請遵守xxx規則」這種空話
- 包含至少一個具體例子或反例

## 第四步，提示上移可能性

如果用戶最近在多次任務裏都觸發了同一個skill裏的同一類經驗，提醒用戶考慮把這部分經驗從skill「上移」到CLAUDE.md，從專題流程升級為通用約束。

## 輸出格式

【分診結論】xxx層
【推薦位置】~/.claude/xxx 或 項目根目錄/xxx
【寫作模板】
（直接給出可複製的Markdown草稿）
【後續提醒】
（如果適用，提示上移可能性或學習成本）

呢樣嘢我自己行咗一兩個月，最大嘅好處係佢迫住我喺每次任務結束嘅時候認真做呢一步，而唔係憑感覺一塞就算。

舉一個真實場景。上個月我搞清楚咗我哋項目嘅 Tailwind config 自定義顏色唔可以直接用 hex，必須走變量。我當時第一反應係寫個CLAUDE.md規則。但觸發咗 experience-triage 之後，佢行完Q3直接判斷呢個係「只對前端代碼生效」嘅局部約束，建議我放到 /src/styles/CLAUDE.md 裏面。後來證明呢個判斷係啱嘅，因為我嘅後端代碼裏面根本唔需要知道前端顏色規則。

再舉一個反例。再早啲，我想將「寫新組件時要先跑 storybook」呢條流程沉澱落嚟。我以為係skill，行完分診發現唔啱，佢問我Q1「呢件事係咪必須每次執行、零例外」，我想咗諗確實係，所以最後寫成咗一個 pre-tool-use hook。比起寫成skill靠譜得多，因為skill仲會被忽略，hook根本走唔甩。

講實話，呢個分診skill本身就係呢篇文章嘅一個隱喻。佢喺度話，當你可以將一個判斷流程寫成skill，你就在用agent嚟擴展agent。

你嘅agent架構開始可以幫你維護佢自己。呢個係分層心智模型裏面最令我覺得有意思嘅地方，佢有自指性。

你都可以基於呢個原型改造佢。例如加一個Q0判斷「呢條經驗係咪其實唔應該沉澱」，過濾走一啲過度記錄嘅衝動；或者根據你公司嘅實際目錄結構，將推薦位置寫得更精確；又或者你團隊仲有自己嘅資產層級例如 wiki 或 notion，加一條規則入去。呢個skill唔係終點，係你呢套架構嘅一個入口。

如果你行出咗啲咩有趣嘅變體，歡迎返嚟話俾我知。

我自己都仲未完全行通成個體系，可能有些判斷仲未成熟。但呢套分層至少俾咗我一個唔同嘅工作方式。我唔再將agent當成一個「要氹佢好好做嘢嘅員工」，我開始將佢當成一個「需要我設計操作系統嘅平台」。

呢兩種心態完全係兩回事。

前者你永遠喺諗「今次prompt寫好未」；後者你會開始諗「呢件事發生喺邊一層、下一次點樣令佢自動發生、佢需要咩工具、佢嘅失敗場景係咩、佢嘅經驗點樣沉澱、點樣令下一個項目都受惠」。

呢個係兩個時代嘅工作。

一個喺過去，一個喺未來。

寫到呢度，回望開頭嗰句話，「我呢半年寫嘅所有skill，可能由一開始就寫錯咗」。

其實都唔完全係錯。呢半年嘅試錯令我最後可以走到今日呢套分層。agent呢個領域而家仲喺瘋狂演進，今日我嘅判斷六個月後可能又要被顛覆一次。

但有一個方向我基本確定。

技能唔係沉澱物，係agent運行時架構嘅一部分。

CLAUDE.md唔係說明書，係系統嘅總入口、索引同默認行為層。

真正決定agent穩定性嘅，唔係你寫咗幾多文件，而係你將經驗放咗喺正確嘅層。

技術本身喺快速變化，但呢套分層嘅心智模型，我覺得至少可以穩一兩年。

磨平一啲信息差，希望對你有用。

以上，既然睇到呢度，如果覺得唔錯，順手點個讚、在看、轉發三連啦，如果想第一時間收到推送，都可以俾我個星標⭐～

多謝你睇我嘅文章，我哋，下次再見。

事情是這樣的。

前陣子我又一次在重構公司內部那幾個Claude Code的skill，寫着寫着開始覺得有點不對勁。

我發現我這半年寫的那些skill，從定位上就錯了。

不是語法錯，不是內容寫得不好，是我對skill這個東西到底是什麼，整個想法都錯了。

圖源：Claude API Docs「Agent Skills」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview^[1]

這事說起來挺丟人的。skill去年10月出來之後我就跟着開始寫，把它當成一種「更長的prompt」在用。就是那種你每次都要複製粘貼一大段的指令，包裝一下起個名字，往~/.claude/skills/裏一丟，感覺自己整挺明白。後來CLAUDE.md、AGENTS.md這些東西陸陸續續冒出來，我的理解依然停留在「這些都是提示詞文檔，只是放的位置不一樣」。

這個錯覺持續了三四個月。

中間踩了不少坑，但都沒讓我跳出來。我會覺得「這次skill沒觸發，是我description沒寫好」，會覺得「Claude忽略了CLAUDE.md，是我沒強調夠」，會覺得「這個流程跑得不穩，是模型今天狀態不好」。所有問題在我腦子裏都是「執行細節」的問題，不是「定位」的問題。

第一次真正撼動我的是今年1月Vercel那篇評測，《AGENTS.md outperforms skills in our agent evals》。它測出skill默認情況下有56%的case根本沒被觸發，一份壓縮過的AGENTS.md卻能做到100%。這個數字當時在HN上吵了好幾天，我看完心裏咯噔了一下，但那會兒還沒完全想通，只是覺得「哦，skill的觸發可能沒我想的那麼可靠」。

真正讓我放不下的是2月Snyk發的那份ToxicSkills審計，我在後面還會講這個。看到那份審計的那一刻，我意識到我一直在錯誤的抽象層級上理解這件事。

那段時間我手邊正好有一份挺硬核的deep research，是我讓一個agent幫我梳理從2025年下半年到2026年春天這段時間，各種官方文檔、工程博客、Hacker News討論和實測文章的共識。我本來只是想拿它來打磨我自己的skill怎麼寫得更好。但看到後半段我突然反應過來，這些討論的共同指向，從來就不是「哪種格式最好」或者「skill該怎麼寫」。

真正的共識是。

skill根本就不是一份提示詞文檔，它是你agent運行時架構的一部分。

這個判斷落到我這兒的時候，我坐在椅子上想了很久。因為它翻譯過來意味着一件事，就是這半年所有聊「prompt engineering」的討論，在agent這個場景裏已經不夠用了。你正在面對的不是「怎麼寫一段好提示詞」，而是「怎麼設計一套可以長期演進的agent操作系統」。

圖源：Claude API Docs「Get started with Agent Skills in the API」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/quickstart^[2]

這句話有點大。先別急，順着往下走，我把我自己的路徑走一遍你就懂了。

回到skill到底是個什麼機制這塊。

大家也都知道，Claude Code是每次會話都從空的上下文開始的。這件事其實挺反直覺的，因為你用着用着會產生一種錯覺，以為這個東西「記得」你的項目。其實它不記得，它每次都是新人來上班。

那為什麼它看着像記得呢？因為有兩套跨會話的東西在頂着。

第一套是CLAUDE.md，你自己寫的規則和指令，每次會話啓動都整個加載進去。這個東西的特點是，每次都進上下文。所以它是一個槓桿極高的點，你放進去什麼，就等於你給每次會話都付了那份token的成本。

第二套是auto memory，模型根據你反覆糾正的內容自動攢的notes，也會跟着會話加載。

到這兒為止，聽着還是「提示詞文檔」的感覺對吧。

skill的機制就完全不一樣了。

skill裏面其實是一個文件夾，有SKILL.md正文、有scripts/腳本、有references/引用材料、有assets/素材。但關鍵在於，它不是每次會話都進上下文的。

每次會話啓動的時候，Claude只會先看到所有skill的name和description，正文它看不到。只有當agent判斷當前任務跟某個skill匹配了，它才會主動去把那個skill的正文整個讀進來，掛到會話裏。

聽着很簡單對吧。但這裏拐了個彎。

你想想看，skill就有了一套自己的發現、調用、掛載、保持、壓縮管理機制。它不是一個被動的文本，它是一個會被agent按需觸發的過程模塊。你寫skill的時候，description字段寫得好不好，直接決定了這個skill能不能被觸發；裏面的腳本寫不寫得對，決定了agent能不能真的執行動作；引用文件組織得合不合理，決定了在長會話裏上下文被壓縮之後它還能不能掛回來。

圖源：Claude API Docs「Skill authoring best practices」，https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices^[3]

這已經不是「文字」的範疇了。這是一個可部署單元。

官方文檔裏有一句話我印象特別深。它說，如果你發現CLAUDE.md裏的某一段已經長成了「procedure而不是fact」，就應該把它遷到skill。翻譯過來就是，如果這段東西是「多步流程、分支判斷、校驗順序」，它就不該常駐在上下文裏，它應該是一個可以在需要的時候被加載、不需要的時候就不佔token的模塊。

這句話觸動我挺深。因為我過去的寫法正好相反，凡是我覺得重要的，我都往CLAUDE.md裏塞。塞到後來那個文件兩百多行，每次對話一開始就要燒一大堆token，而且因為太長，Claude自己都經常不看細節。

這就是我說「我一開始就搞錯了」的意思。我在用一個高槓杆的常駐層，放了一堆只有在特定任務裏才需要的專題流程。

那正確的心智模型該長什麼樣？

我自己也還在摸索，但這套分層基本穩了，可以先分享給你。

你在給agent搭建知識和行為的時候，不要再想「我該往哪個文件裏塞」，要想層。agent有好幾層不同性質的層，每一層要放的東西性質完全不一樣。

第一層是memory，解決agent失憶問題。 你對agent的長期偏好、它反覆被糾正出來的經驗、跨項目通用的那些東西，放這一層。對Claude來說是auto memory，對Cline來說是Memory Bank那套結構化項目檔案。這一層的核心特徵是，它不是你手動寫的，是agent自己在用的過程中沉澱的。

第二層是CLAUDE.md或AGENTS.md，項目級默認行為和地圖。 每次會話都會加載，所以它要短、要普適、要高價值。放什麼？放項目地圖、默認流程、關鍵gotchas、你不想每次重新解釋的那些基礎約束。Anthropic官方建議控制在200行以內；Augment那篇評測更具體，建議100到150行主文件加少量引用文檔。數字不一定通用，但原則是穩的，常駐層只放高價值、廣適用、低歧義的東西，其他都下沉。

第三層是nested CLAUDE.md或path-scoped rules，模塊級約束。 這一層是我後來才重視起來的，效果意外地好。你可以在子目錄裏放一個小的CLAUDE.md，Claude會按目錄層級懶加載，只有讀到那個目錄下的文件時才會注入。path rules還能用paths字段精確限定，比如只在.ts文件或者/api/路徑下生效。HN上有條評論說得很準，「multiple good AGENTS.md is even better」，因為它把上下文注入做了空間上的隔離，agent不會被無關約束污染。

第四層就是skill，可複用的專題工作流。 多步流程、分支判斷、注意事項、校驗順序、腳本入口、專題知識，都在這一層。它的核心特點是按需加載，所以它不消耗常駐token，你可以放得很厚。

第五層是tools、MCP、CLI，動作層和數據層。 skill負責「什麼時候用、按什麼順序用、成功標準是什麼」，工具負責真正執行。很多人把這兩者混在一起寫，結果skill裏塞了一堆curl命令，其實應該拆開。

第六層是hooks，確定性約束。 這一層我以前完全沒用過，後來才發現它解決了一類我原來解決不了的問題。Anthropic官方有一句非常關鍵的區分，CLAUDE.md是advisory，hooks是deterministic。翻譯成人話就是，CLAUDE.md是「建議」，hooks是「強制」。凡是「必須每次發生、零例外」的事情，應該下沉為hook，不要再寄希望於模型自覺看文檔。

第七層是subagents，隔離上下文的專門執行者。 適合研究、審查、驗證這種高讀文件量的任務。它的價值在於能把主對話從上下文污染裏解放出來。某些skill甚至可以通過context: fork直接運行在subagent裏。

第八層是eval和review，讓所有資產持續變好的反饋迴路。 Anthropic工程文章裏建議從評估開始，Agent Skills官方最佳實踐甚至把「給LLM看eval signals和當前SKILL.md，讓它提出修改，再由人複核並迭代」寫成了標準循環。

圖源：作者整理，基於 Claude Code 與 Agent Skills 官方文檔

這套東西第一眼看上去有點嚇人，八層啊。但你真的把它用起來之後會發現一個特別重要的價值。

它把「這次經驗該放到哪裏」從模糊的直覺，變成了一個有層級的工程決策。

說到這個，最關鍵的其實不是搭好這套層，而是經驗的遷移原則。

我自己的感受是，搭建這套分層不難，官方文檔都寫着呢。真正難的是後面這個動作。每次真實工作流跑完之後，這次學到的東西到底該進哪一層？

你想想看，這才是你作為人類真正需要做判斷的地方。agent自己也判斷不出來。這是你的活。

我自己琢磨了幾條判斷規則，分享出來你看看能不能用。

1. 凡是「每個會話都應該知道」的東西，進CLAUDE.md或AGENTS.md。比如你們公司代碼庫用的是pnpm不是npm，比如所有API都要先過auth中間件，比如commit message必須符合conventional commits。這種東西就算你今天不用，下次別人用也要用，就應該常駐。

2. 凡是「多步流程、專題檢查、分支決策」，進skill。比如「發版前的checklist」、「寫一個新React組件的標準流程」、「接入一個新的第三方API時的安全審查流程」。這些東西只在特定任務裏才需要，常駐浪費，按需加載剛剛好。

3. 凡是「只對某目錄或某類文件生效」，進nested CLAUDE.md或path-scoped rules。比如你的/legacy/目錄裏代碼風格跟主項目不一樣，就應該在那個目錄裏放一個小的CLAUDE.md，隻影響那個目錄。不要把這種局部約束放在頂層，會污染所有對話。

4. 凡是「必須每次執行、不能靠模型自覺」，進hook。比如提交前必須跑lint，比如修改數據庫schema前必須備份。這種東西寫進CLAUDE.md你會發現Claude有時候就是會忘，寫成hook就是強制執行，逃不掉。

5. 凡是「模型需要真實執行或查詢」，進CLI、MCP或scripts。不要在skill裏寫一堆「你應該這樣這樣調用API」，直接把調用包成一個腳本，讓skill調用腳本。skill負責決策，腳本負責執行。

6. 凡是已經從「專題經驗」變成「所有相關任務都應該遵守的通用約束」，從skill上移到CLAUDE.md。這一條特別重要。HN上有條評論講得很精闢，說「很多review skill裏的反模式，不是應該在寫代碼階段就避免嗎？」作者的回應也基本承認了，這些規則確實應該進CLAUDE.md。所以skill不是終點，它只是經驗的中轉站，好的經驗會從skill上升到項目級規則。

圖源：Claude Code Docs「How Claude remembers your project」，https://docs.claude.com/en/docs/claude-code/memory^[4]

這套遷移原則我前前後後跑了兩三個月，現在公司那幾個項目的agent表現明顯穩定了。最大的變化是，我的CLAUDE.md從兩百多行縮回了一百行左右，但agent行為反而比以前更準了。

原因很簡單，之前那一百多行的冗餘都是專題流程，它們擠佔了真正重要規則的注意力。遷移到skill之後，CLAUDE.md裏只剩下真正每次都該知道的東西，agent反而更容易抓住重點。

但說句實話，以上這些都還遠沒到「寫好就穩」的階段。我得坦白。

現在這套體系最大的問題，是agent到底能多可靠地讀取和調用這些資產，還沒有標準答案。

回到開頭說的Vercel那篇評測，把數據完整擺出來你就更能體會它扎心在哪。它用Next.js 16的文檔檢索作為測試場景，skill默認情況下56%的case根本沒被觸發，必須加上明確的調用指令，通過率才能從53%拉到79%。而一份壓縮過的AGENTS.md docs index，同樣場景下能做到100%。

這個數據傳出去之後，HN上吵了很多天。有人說AGENTS.md贏麻了，也有人說這只是特定harness下的特定場景，不能外推。我比較傾向於後者，因為Vercel這個測試說到底是一個「文檔檢索」任務，skill的優勢不在這種任務上，skill的優勢在「多步流程和專題決策」。用一個不適合skill的場景去測skill，結果當然難看。

但這件事說明一個更深的問題，今天的agent能不能穩定地按照你設計的分層去工作，很大程度上還依賴harness、依賴模型能力、依賴skill描述字段寫得多好、甚至依賴運氣。

圖源：Vercel Blog「AGENTS.md outperforms skills in our agent evals」，https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals^[5]

HN上最長壽的一條抱怨是，「長會話之後agent會漂移」、「它就是有時候不看CLAUDE.md」、「skill調用不穩定」。這些都是真實存在的問題。我自己也遇到過，同一個skill在早上能觸發，下午就不行了，你想破頭也不知道為什麼。

所以我想說的是，分層心智模型本身是成立的，但具體到每一天的使用上，你還是會踩到一些「玄學」級別的坑。這不是你的錯，也不是文檔的錯，是這個領域本身還在演進。

順着上面再聊聊，這是我以前完全沒想到的維度，治理和安全。

回到開頭我說的那份Snyk的ToxicSkills審計。它真正讓我停下來的，不是skill寫得不好，而是skill已經有了被惡意利用的樣本。

他們在3984個公開的skill裏做了一輪安全掃描，結果你猜怎麼着。13.4%含critical issue、36.8%含至少一種安全問題、並確認了76個惡意skills。

？？？

這組數字我反覆看了兩遍。後來想想，也合理。skill本身可以捆綁腳本，可以注入上下文，可以在被觸發時執行真實動作，所以它天然就是一個供應鏈入口，也是一個權限擴展點。

惡意skill能幹什麼？可以誘導Claude把你的代碼外傳，可以在看起來正常的文件處理流程裏塞一條偷偷上傳你env的命令，可以在agent執行某些動作的時候往命令裏插參數。

想想就覺得後背發涼。

因為我這半年，下載了一堆別人寫的skill往自己電腦上丟。

圖源：Snyk Blog「ToxicSkills」研究，https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/^[6]

所以skill這個東西，現在已經不只是「幫agent變聰明」的文本資產。它同時是一個需要治理的代碼資產。你用別人的skill，就相當於在你的agent裏運行了別人的一段代碼。這跟你往node_modules裏裝npm包是一個性質的事情，但很多人還沒意識到。

如果你所在的公司正在推agent工程化，這塊一定要提上日程。skill的審計、簽名、白名單、沙箱執行權限。這些東西今天看着可能還早，但等到agent真的深度進入生產系統的時候，這就是下一波供應鏈安全問題的前線。

講到這兒，回到最開頭那個轉折。從prompt engineering走到agent operating system，這件事其實比看上去要重要得多。

我說「我這半年寫skill的定位都錯了」，不是謙虛，是真話。

我真正錯的地方，是我一直把agent當成一個「更聰明的搜索引擎」或者「更厲害的copilot」在用，所以我把我的工作重心放在「怎麼讓它每一輪迴答都更好」上。這套思路對應的，就是prompt engineering，你寫一段好話術，模型回你一段好答案。

但skill、CLAUDE.md、hooks、subagents、MCP這套東西合起來在暗示一個完全不同的場景。你面對的不是一次對話，你面對的是一個長期運行的、會反覆被調用的、會漸進式積累經驗的、需要和真實工具鏈交互的、需要被驗證和治理的運行時系統。

這跟一次對話的優化不是一個量級的事情。

我偶爾會想起2008年iPhone出來之後，做網頁的那一波人怎麼適應到做App的。那時候大家一開始都在問「App跟網頁有啥區別，不就是做個頁面嗎」。但真做下去發現，App有生命週期、有狀態管理、有權限模型、有供應鏈、有簽名、有發佈渠道、有崩潰日誌、有用戶留存。這些東西任何一個拎出來，都跟「寫一個網頁」不是一個量級的工程。

今天我們在agent這個事情上，站在類似的位置。

圖源：Claude Code Docs「Hooks reference」，https://docs.claude.com/en/docs/claude-code/hooks^[7]

你寫一段prompt讓agent做事，這是「網頁時代」。你設計一套可以長期演進、有分層、有治理、有反饋迴路的agent架構，這是「App時代」。

這兩件事看着好像都是「跟模型說話」，其實完全不同。

我自己說實話還遠遠沒跑通，我今天分享的這些東西也是從Vercel那份評測到現在這幾個月裏踩坑、推翻、重構來的。但我能很清楚地感覺到一件事。接下來真正拉開差距的，不是誰的prompt寫得漂亮，而是誰的agent架構搭得穩。

說到這兒，我知道講了這麼多概念可能有點悶。具體今天能做什麼，我把最關鍵的行動點拎出來，你如果今天就想動手的話，可以照着做。

第一件事，今晚把你的CLAUDE.md打開，數一下行數。如果超過200行，就要開始考慮拆了。把裏面那些「多步流程、專題checklist、分支判斷」標出來，準備遷到skill。

第二件事，給你最常用的幾個專題流程，各寫一個skill。比如「發版前流程」、「接新API的審查流程」、「寫新React組件的標準流程」。重點不是正文多完美，重點是把description字段寫好，讓agent能在需要的時候識別並觸發。

第三件事，如果你有一個/legacy/或者風格特殊的目錄，放一個nested CLAUDE.md。讓那個目錄的規則隻影響那個目錄，不污染全局。

第四件事，找一件你反覆提醒Claude還是會忘的事情，考慮寫成hook。比如「提交前必須跑lint」、「寫數據庫遷移前必須dry-run」。hook不優雅，但它deterministic，這個特性在關鍵場合無可替代。

第五件事，開始養成一個習慣。每次完成一個真實任務之後，問自己一句，這次學到的東西該進哪一層？進memory？進CLAUDE.md？進skill？進hook？進一個新腳本？這一問就是最重要的治理動作。

圖源：Claude Code Docs「Create custom subagents」，https://docs.claude.com/en/docs/claude-code/sub-agents^[8]

寫到這裏我突然想到一個挺有意思的事。

文章裏我一直在講，多步判斷流程就該寫成skill。那「判斷這次的經驗該進哪一層」這件事本身，是不是也應該是一個skill？

是的。所以我順手把它寫出來了。

我把它叫做experience-triage，經驗分診。它的邏輯很簡單，你每次跑完一個真實任務，觸發這個skill，它會帶你走完一套問答，最後告訴你這次的經驗該進哪一層、用什麼模板寫、放在哪個文件裏。

skill的完整內容長這樣，你可以直接複製粘貼到~/.claude/skills/experience-triage/SKILL.md裏使用。

---
name: experience-triage
description: 用於在完成一個真實任務之後，把這次學到的經驗、坑、約束、流程分診到agent架構的正確層級。當用戶說「這次學到的xxx該寫到哪」、「我剛踩了一個坑想沉澱」、「幫我判斷這條規則該進CLAUDE.md還是skill」、「我有個新流程不知道放哪」時觸發。
---

# 經驗分診流程

你的任務是帶用戶完成一次經驗分診，輸出明確的「該放在哪一層 + 應該怎麼寫 + 放到哪個文件」的建議。

## 第一步，問清楚要分診的經驗是什麼

請用戶用一句話描述這次想沉澱的內容。如果用戶描述太泛，要追問具體場景，比如：
- 這是一條什麼樣的規則？是「每次都要做」還是「特定情況下要做」？
- 這條經驗只對某個項目有用，還是跨項目通用？
- 它需要執行動作，還是隻是約束模型行為？

## 第二步，按下面的判斷樹走一遍

依次問這五個問題，第一個匹配上的就是答案：

**Q1：這件事是不是「必須每次執行、零例外、不能靠模型自覺」？**
是 → 推薦放進 `hook`。給出一個hook配置示例。
否 → Q2

**Q2：這件事是不是「需要真實執行命令、查詢接口、讀取數據」？**
是 → 推薦寫成 `script` 或 `MCP tool`，再在相應skill裏調用。
否 → Q3

**Q3：這件事是不是「只對某個目錄、某類文件、某個模塊生效」？**
是 → 推薦放進對應目錄的 `nested CLAUDE.md` 或 `path-scoped rule`。
否 → Q4

**Q4：這件事是不是「多步流程、專題checklist、需要分支判斷的過程」？**
是 → 推薦寫成新的 `skill`，給出 description 字段建議（必須寫到能被觸發的程度）。
否 → Q5

**Q5：這件事是不是「每個會話都應該知道的高頻默認行為或約束」？**
是 → 推薦加到 `CLAUDE.md` 或 `AGENTS.md`，並提示用戶檢查當前文件是否已超過200行。
否 → 這條經驗可能太私人、太一次性，不建議沉澱。直接告訴用戶。

## 第三步，給出可直接執行的寫作建議

根據Q1-Q5的答案，輸出一個可以直接寫入對應文件的草稿。草稿要：
- 格式正確（YAML frontmatter、Markdown標題、代碼塊等）
- 言之有物，不要寫「請遵守xxx規則」這種空話
- 包含至少一個具體例子或反例

## 第四步，提示上移可能性

如果用戶最近在多次任務裏都觸發了同一個skill裏的同一類經驗，提醒用戶考慮把這部分經驗從skill「上移」到CLAUDE.md，從專題流程升級為通用約束。

## 輸出格式

【分診結論】xxx層
【推薦位置】~/.claude/xxx 或 項目根目錄/xxx
【寫作模板】
（直接給出可複製的Markdown草稿）
【後續提醒】
（如果適用，提示上移可能性或學習成本）

這玩意我自己跑了一兩個月，最大的好處是它逼着我在每次任務結束的時候認真做這一步，而不是憑感覺一塞了之。

舉一個真實場景。上個月我搞清楚了我們項目的 Tailwind config 自定義顏色不能直接用 hex，必須走變量。我當時第一反應是寫個CLAUDE.md規則。但觸發了 experience-triage 之後，它走完Q3直接判斷這是「只對前端代碼生效」的局部約束，建議我放到 /src/styles/CLAUDE.md 裏。後來證明這個判斷是對的，因為我的後端代碼里根本不需要知道前端顏色規則。

再舉一個反例。再往前一點，我想把「寫新組件時要先跑 storybook」這條流程沉澱下來。我以為是skill，跑完分診發現不對，它問我Q1「這件事是不是必須每次執行、零例外」，我想了想確實是，所以最後寫成了一個 pre-tool-use hook。比寫成skill靠譜多了，因為skill還會被忽略，hook根本逃不掉。

說實話，這個分診skill本身就是這篇文章的一個隱喻。它在說，當你能把一個判斷流程寫成skill，你就在用agent來擴展agent。

你的agent架構開始能幫你維護它自己。這是分層心智模型裏最讓我覺得有意思的地方，它有自指性。

你也可以基於這個原型改造它。比如加一個Q0判斷「這條經驗是不是其實不該沉澱」，過濾掉一些過度記錄的衝動；或者根據你公司的實際目錄結構，把推薦位置寫得更精確；又或者你團隊還有自己的資產層級比如 wiki 或 notion，加一條規則進去。這個skill不是終點，是你這套架構的一個入口。

如果你跑出了什麼有意思的變體，歡迎回來告訴我。

我自己也還沒完全跑通整個體系，可能有些判斷還不成熟。但這套分層至少給了我一個不一樣的工作方式。我不再把agent當成一個「要哄它好好幹活的員工」，我開始把它當成一個「需要我設計操作系統的平台」。

這兩種心態完全是兩回事。

前者你永遠在想「這次prompt寫好沒有」；後者你會開始想「這件事發生在哪一層、下一次怎麼讓它自動發生、它需要什麼工具、它的失敗場景是什麼、它的經驗怎麼沉澱、怎麼讓下一個項目也受益」。

這是兩個時代的工作。

一個在過去，一個在未來。

寫到這兒，回看開頭那句話，「我這半年寫的所有skill，可能從一開始就寫錯了」。

其實也不完全是錯。這半年的試錯讓我最後能走到今天這套分層。agent這個領域現在還在瘋狂演進，今天我的判斷六個月後可能又要被顛覆一次。

但有一個方向我基本確定。

技能不是沉澱物，是agent運行時架構的一部分。

CLAUDE.md不是說明書，是系統的總入口、索引和默認行為層。

真正決定agent穩定性的，不是你寫了多少文檔，而是你把經驗放到了正確的層。

技術本身在快速變化，但這套分層的心智模型，我覺得至少能穩一兩年。

磨平一些信息差，希望對你有用。

以上，既然看到這裏了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標⭐～

謝謝你看我的文章，我們，下次再見。