我扒了 Matt 的 skill 原始碼:他寫好 skill 守著四條鐵律(還抓到他刪了 caveman)

30 秒速覽

寫靠譜的 skill,只有一個目標:可預測——同一情形,AI 每次走同一個流程。四條鐵律全為它服務,各打一個反例:

怎麼觸發:模型自動判斷該不該用它,還得為此長期佔著上下文;還是只在你明確喊時才觸發。選錯=白佔上下文。

放多少:SKILL.md 只留每條路都用得上的,其餘下沉外連。反例:臃腫、沉積。

用什麼詞:借 AI 腦子裡已經有的現成概念當「主導詞」,一詞錨定一片行為。反例:廢話詞、重複。

怎麼收尾:每步給一個可驗證的完成標準。反例:沒幹完就溜號。

四條全來自 Matt Pocock 的 writing-great-skills;四個反例,全是從他自己的改版記錄裡挖的真例。

我把 Matt 的 skill 原始碼扒了一遍

同樣是 / 一下,有的 skill 每次都把活幹完,有的時靈時不靈。差別不在運氣,在寫法。

沒人有空啃 skill 原始碼——我替你啃了。我盯的是 Matt Pocock,做了一整套 AI 協作 skill 的人。他寫過一個很妙的東西:一個專門講怎麼寫好 skill 的 skill(writing-great-skills)。我把這篇,加上他幾十個 skill 的原始碼和提交歷史一起翻了一遍,扒出四條鐵律。

四條而已,但每條我都配了一個反例——而且反例一個沒編,全是從 Matt 自己的提交記錄裡挖的,他親手犯過、又親手改掉。連他都要回頭改,就說明這些坑是真的。

學會這四條:自己寫 skill 少踩坑;不寫,也能偷到他「把隨機 AI 逼出確定性」的那套心法。

好 skill 只有一個標準:可預測

模型是隨機的——同一句話問兩遍,答得未必一樣。skill 的全部意義,是從這台隨機機器裡榨出確定性:讓它每次走同一個流程。

「A skill exists to wrangle determinism out of a stochastic system.」 —— Matt,writing-great-skills

注意是流程,不是輸出。腦力激盪該每次蹦不同點子,但展開的方式得穩。

判一個 skill 好壞,就這一個標準:可預測。下面四條,全為它服務。

第一條 · 怎麼觸發:你明確喊,還是模型自動判斷?

寫 skill 第一個要拍的板:這個 skill,該由模型自己判斷什麼時候用它,還是只在你明確喊它的時候才啟動? 技術上就一個開關——要不要寫 description:

模型自動觸發(model-invoked,帶 description):AI 自己讀得到它、自己決定何時用。代價是這段 description 每一輪對話都掛在上下文裡,佔 token、佔注意力——這叫上下文負載。
使用者明確觸發(user-invoked,設 disable-model-invocation):description 被摘掉,模型看不見它,只有你手敲名字才啟動。不花 AI 一分上下文,代價轉到你頭上:你得自己記得它存在——這叫認知負載。

原則:只有當模型(或別的 skill)非得自己搆到它不可,才讓它自動觸發;否則設成手動,白賺零上下文負載。

反例:一個你其實只會手敲的 skill,卻留著 description,讓它每輪空佔你的上下文。

真例:這取捨 Matt 自己都來回秤過。grill-with-docs 的 disable-model-invocation 開關,他先刪掉了——放手讓模型自動觸發;到最新版又把它加了回來,改回純手動。同一個開關,刪了又加。這說明「自動還是手動」是個真得權衡的決定,不是隨手一設。

自己用:預設手動,先把上下文省下來;只有當你確實需要模型自己判斷「現在該用它了」,才給它 description。一句話自檢:「這 skill,誰需要搆到它?」答案是「只有我」,就手動。

手動 skill 攢多了你自己記不過來,那是認知負載爆了。解法是再寫一個路由 skill:一個手動 skill,專門列出其它 skill、告訴你什麼時候用哪個。Matt 那個 ask-matt 就是幹這個的。

第二條 · 放多少:SKILL.md 只留「每條路都用得上」的

資訊階梯:每條使用路徑都用得上的,放進 SKILL.md 正文;只有某些情況才用的,下沉到單獨的外連檔案,正文裡只留一句「需要時去看那個」的指標。目的是讓頂層始終清爽——東西堆太多,AI 真正該做的動作就被淹了。

反例兩種,都有名字:

臃腫(sprawl):啥都往一個檔案裡塞,越寫越長。哪怕每行都對、都不重複,光是「長」本身就是病——AI 得先趟過一堆字才搆到該幹的活。
沉積(sediment):舊內容只加不刪,一層層積下來,後來人得像考古一樣往下刨,才找得到還有效的那部分。

真例:grill-with-docs 早期是個胖單體——盤問邏輯、文件格式、ADR 範本,全塞在一個檔案裡。Matt 把它一拆為三:盤問那半獨立成 grilling,寫文件那半獨立成 domain-modeling,連 ADR、術語表的格式檔案也下沉進 domain-modeling;grill-with-docs 只剩一句話的薄殼,把兩者串起來。這就是拿資訊階梯給臃腫 skill 減重。

自己用:寫完回頭刪。每一行問一句「這是每條路都要的嗎?」不是的,要麼下沉外連,要麼直接砍。一個糙但好使的直覺——SKILL.md 越短、越只剩主幹,通常越靠譜。

第三條 · 用什麼詞:借 AI 腦子裡已經有的概念

這條最反直覺,我自己也是琢磨了好一會兒才轉過彎。

主導詞(leading word):一個 AI 在訓練時早就學過、自帶一身聯想的現成概念。不限於專業術語——遊戲、軍事、醫學、日常成語都算,只要 AI 一看就懂。寫進 skill,你不用解釋,它就把那一整串行為調出來。

例(全是借的,沒一個是 Matt 發明的):

fog of war(戰爭迷霧,來自遊戲/軍事)→ AI 立刻懂「前方看不清,憑手頭局部資訊行動」。
tracer bullets(曳光彈,來自《程式設計師修練之道》)→「先打通一條最薄的端到端,看準方向再加料」。
triage(檢傷分類,來自醫院急診)、caveman(原始人=省話)、grilling(拷問)——拎現成概念就用。

去哪找:先把你要的行為說清楚,再倒著問「哪個現成的詞、典故,本身已經就是這個意思?」往成語、名著、方法論、遊戲軍事、醫學體育裡撈。AI 讀過的東西,就是你的詞庫。

怎麼驗——no-op 測試:把這個詞單獨寫進去、不加解釋,AI 就照你要的做了嗎?做到了=真主導詞,在白賺 AI 的先驗;還得你解釋半天它才懂=它沒在出力,落進了反例:

廢話(no-op):寫了、但 AI 本來就會照做的話。比如「be thorough(要仔細)」——AI 預設就有點仔細,這行約等於沒寫。修法不是加解釋,是換個更狠的詞:「be thorough」→「relentless(窮追不捨)」。
重複(duplication):同一個意思寫了好幾遍。既費維護(改一處得改全部),又把這個意思的分量在 AI 眼裡抬過了頭。

真例:Matt 對這倆是真動刀的。他收緊 review skill,提交說明白紙黑字寫著「single-sourced rules, no-op cuts」——歸併重複規則、砍掉廢話行。他甚至回頭對 writing-great-skills 這篇本身下手,專門「把 no-op 獵殺到句子級」。

自己用:別用一整句話去描述你要的行為,找一個現成的詞去鉤它;然後把每個形容詞、副詞拎出來做 no-op 測試——刪了它,AI 行為會變嗎?不變的,就是水,刪。

第四條 · 怎麼收尾:每步要有可驗證的完成標準

skill 常是一串步驟。每一步到底幹完沒有,靠**完成標準(completion criterion)**判定。

好的完成標準有兩條講究:一是可驗證——AI 能客觀判定「做完了」還是「沒做完」,而不是憑感覺拍板;二是該窮盡就窮盡——比如「每一個改動過的模型都要交代到」,而不是含糊的「列個變更清單」。

反例 · 提前收工(premature completion):完成標準定得糊(「達成共識」「理解到位」),AI 搆不著一條明確的邊界,注意力就從「把活幹完」滑向「趕緊算完」,沒真幹完就溜到下一步。

還有個連帶機制:AI 要是看得見後面還排著哪些步驟,那股「快點做完往下走」的拉力會更強。對治之一,是把後續步驟藏到另一個 skill 裡,別讓當前這步惦記著趕路。

真例:grilling(從 grill-with-docs 拆出來的盤問那半)的招牌動作,就是一題一題問、你答完一題才問下一題——它的主導詞正是「relentless(窮追不捨)」。當初把盤問和寫文件拆成兩個 skill,也是這道理:別讓 AI 盤你的時候惦記著「問完趕緊去寫文件」,那樣它會草草收尾。拆開,盤問這一步就只剩盤問。

自己用:把每步的收尾條件寫成可驗證、最好可窮盡的(「每個 X 都……」,而不是「差不多了」);要是發現 AI 老在某步搶跑,就把後面的步驟挪到別的 skill 裡去。

用這四條,看一件怪事:他為什麼刪了 caveman?

拿這四條去看個真實的案發現場。

我們第一篇講的 caveman(讓 AI 閉嘴、只說重點),現在去 Matt 的原始儲存庫找不到了——被刪了。刪除記錄很樸素:

5 月底,他刪掉了整個 caveman SKILL.md,提交說明就一句「精簡產力類 skill」。
半個月後,又清掉 README、外掛清單裡殘留的引用。
沒有任何新 skill 來接班。 直接刪。

為什麼?用四條一量就懂:caveman 是個手動 skill,佔的是你的認知負載——你得記得它在。可它幹的那點事(省話、去客套),一句指令、或者一個全域輸出風格就能要到,不值得單獨佔一個「你得記住的格子」。刪它,正是在整個 skill 集合層面剪枝,砍掉不划算的負載。

聲明一句:Matt 的提交說明只寫了「精簡」,沒展開,這是我用這套框架做的解讀。但框架能給出一個自圓其說的解釋——這恰恰是它的用處。

四條不只是寫 skill 的清單,它還能解釋真實世界裡一個 skill 為什麼活、為什麼死。

速查卡

鐵律	該做	反例	一句話自檢
怎麼觸發	只有要被模型自動搆到才帶 description,否則手動	白佔上下文負載	「這個 skill,誰需要搆到它?」
放多少	SKILL.md 只留每條路都要的,其餘下沉外連	臃腫 / 沉積	「這行是每條路都要的嗎?」
用什麼詞	借 AI 已有的現成概念當主導詞,一詞錨定一片行為	廢話詞 / 重複	「刪了這行,AI 行為會變嗎?」
怎麼收尾	每步給一個可驗證、能窮盡的完成標準	提前收工	「這步做完沒,AI 能客觀判定嗎?」

唯一標準:可預測——同一情形,AI 每次走同一個流程。四條全為它服務。

最後

四條,寫 skill 直接照著用。就算你這輩子不打算寫 skill,它背後那套「怎麼把隨機的 AI 逼出確定性」的思路,照樣能讓你平時調 AI 調得更穩——說到底,這才是偷師高手真正的好處:你拿到的不是幾條規則,是他腦子裡那套判斷。

出處:本文拆解 Matt Pocock 的 writing-great-skills(及其 GLOSSARY.md),儲存庫 mattpocock/skills,MIT 授權,版本 6eeb81b。文中「真實案例」都能在該儲存庫的提交歷史裡查到(已附 commit 連結)。

同系列:第一篇 · caveman · 第二篇 · grill-with-docs