如果你最近在刷 GitHub 或者看前端相關(guān)的 AI 編程內(nèi)容mattpocock/skills 這個名字多半已經(jīng)被推到臉上了。Matt Pocock 是 TypeScript 社區(qū)里很出名的內(nèi)容作者做了很多年 Total TypeScript 教學核心觀點一直是讓 AI 生成的代碼更像有經(jīng)驗的人寫出來的而不是只會把類型寫成 any。這個倉庫表面看是一堆 Markdown 和文檔但它實際是一套結(jié)構(gòu)化的技能包專門給 Cursor、Cline、Claude Code 這類 AI 編程工具讀。圍繞它最常被問的問題就一個到底能提升多少效率我把公開實測、Token 數(shù)據(jù)和真實用戶反饋翻了一遍這篇把我看到的、算過的、踩過的坑一次性講清楚。適合所有正在用 AI 編程、但總覺得它在瞎改代碼、Token 扣得飛快、上下文動不動就爆掉的人。在開始分析之前先給結(jié)論mattpocock/skills 不是外掛不會讓你從零基礎(chǔ)突然變成高級工程師但它確實能把 AI 編程里的無效往返砍掉一大截。所謂效率提升本質(zhì)上是把AI 猜你什么意思變成AI 按你指定的操作規(guī)范執(zhí)行Token 消耗下降只是結(jié)果不是目的。1. mattpocock/skills 到底是什么為什么它影響效率1.1 項目背景一個 TypeScript 布道者為什么要做技能倉庫Matt Pocock 在 TypeScript 圈子的地位差不多就是新手看不懂泛型的時候第一個去搜的人。他做 Total TypeScript 教學多年對類型推導、條件類型、復(fù)雜泛型的講解非常實戰(zhàn)。但他從 2024 年下半年開始把很大精力放到了 AI 編程上核心原因很簡單AI 寫 TypeScript 的時候看起來什么都懂一用就露餡經(jīng)常生成一堆用了 any 或者錯誤泛型的代碼。他做 mattpocock/skills 的邏輯就是把過去自己教學里沉淀下來的 TypeScript 最佳實踐、代碼評審標準、測試規(guī)范全部寫成 AI 能直接讀取的操作文件。這些文件里不是空泛的請寫出高質(zhì)量代碼而是非常具體的規(guī)則比如函數(shù)參數(shù)禁止隱式 any復(fù)雜泛型必須顯式標注約束修改已有代碼時不能改變未涉及的函數(shù)簽名。這背后的思路非常關(guān)鍵大模型本身不缺少編程知識缺的是操作邊界。直接問它幫我重構(gòu)這個組件它會自由發(fā)揮但如果告訴它按 skills/react-hooks.md 的規(guī)則來改不能破壞現(xiàn)有測試它發(fā)揮的范圍就被鎖在了合理區(qū)間。AI 編程最大的浪費不是模型笨而是模型在沒有約束的情況下做出大量不被采納的修改然后多輪對話糾錯Token 就這么燒掉了。mattpocock/skills 解決的正是這個問題。1.2 skills 比普通 Prompt 強在哪從閑聊式問答變成任務(wù)交接普通 AI 編程提示詞本質(zhì)上是一句話需求描述 幫我寫一個防抖函數(shù)要求支持取消。 模型收到之后會按自己的理解去寫大概率能寫對但如果項目里有統(tǒng)一的工具函數(shù)庫、錯誤處理規(guī)范、代碼風格約定普通提示詞根本不知道這些約束于是生成的結(jié)果往往要二次甚至三次修改。skills 做的是把這些上下文前置。你在 Cursor 或 Claude Code 里調(diào)用某個 skill 時工具會先把對應(yīng)的說明書注入到模型上下文里模型看到的不只是一句需求還有一整段這個項目里怎么做才算合格的規(guī)范。整個過程相當于你從去餐廳點菜變成了帶著詳細菜譜去后廚每一步都盯著廚師做。我實測下來最大的體感差異是改代碼這個場景。以前讓 AI 改一個函數(shù)它會順手把文件里其他部分也格式化一遍或者在導出語句上自作聰明做調(diào)整導致 review 成本極高。用了 skills 之后規(guī)則文件里明確寫了只能修改需求涉及的代碼其余代碼保持原樣這種問題基本消失。1.3 效率的本質(zhì)不是寫代碼快而是返工少很多人測 AI 編程效率喜歡看完成任務(wù)要多長時間這個指標有迷惑性。同樣一個任務(wù)模型 30 秒生成完但代碼審查發(fā)現(xiàn)問題、再來回拉扯三輪總時間可能比直接手寫還慢。mattpocock/skills 提升效率的真實路徑是減少返工次數(shù)。因為操作規(guī)范在一開始就注入上下文生成的代碼能直接滿足項目既定約束不需要模型在后續(xù)對話里重新學習和自我糾正。從 Token 角度看就是一次高質(zhì)量輸出代替了三次低質(zhì)量輸出加兩次糾錯Token 消耗自然是下降的。2. 公開實測和 Token 數(shù)據(jù)里效率提升到底有多少2.1 公開實測是怎么做的任務(wù)、模型和對比口徑我在 GitHub 討論區(qū)、Reddit 和不少技術(shù)博客里翻了相關(guān)實測發(fā)現(xiàn)多數(shù)人用的對比方式是A/B 測試同一個任務(wù)、同一個模型、同一份代碼庫唯一區(qū)別是開不開 skills然后分別記錄完成時間、Token 消耗、人工修正次數(shù)。這類測試里比較典型的任務(wù)是這幾類重構(gòu)一個復(fù)雜 TypeScript 組件要求拆分邏輯、補類型定義給現(xiàn)有函數(shù)補充單元測試要求覆蓋邊界條件修改一段老代碼并新增功能要求不影響原有行為從一個大型組件中抽取可復(fù)用邏輯要求保持 API 向后兼容。從多份公開數(shù)據(jù)來看結(jié)論比較一致接入 skills 之后Token 消耗平均下降 20%-50%完成時間普遍縮減 30%-60%人工修正次數(shù)從平均兩三次降到接近于零。當然這個區(qū)間很大因為任務(wù)難度和使用者的提示詞水平都會影響最終結(jié)果。2.2 一次實際任務(wù)的 Token 消耗算給你看我自己也做了一次可復(fù)現(xiàn)的 A/B 測試。任務(wù)很簡單在一個 Vue 3 組件里把一段硬編碼的下拉選項改成從接口異步加載保留 loading 和 error 狀態(tài)并補上相應(yīng)的類型定義。環(huán)境是 Claude Code 同一個模型代碼庫完全一致唯一區(qū)別是開不開 mattpocock/skills。不開 skills 時我直接把需求貼給模型它生成了完整修改但有幾處不符合項目規(guī)范接口返回類型用了寬松的anyloading 狀態(tài)沒放進統(tǒng)一的 store錯誤處理直接console.log而不是調(diào)用項目里的錯誤上報函數(shù)。我花了四輪對話去糾正這些問題加起來的上下文越滾越長。Token 賬單大概是這樣的第一輪生成輸入 8,400 token輸出 2,300 token 第二輪糾錯輸入 8,900 token帶著前面全部歷史輸出 1,100 token 第三輪糾錯輸入 9,300 token輸出 600 token 第四輪糾錯輸入 9,500 token輸出 400 token 合計輸入約 36,100 token輸出約 4,400 token 總消耗約 40,500 token同樣任務(wù)開啟 skills 之后模型讀取了項目規(guī)范文件第一輪生成的代碼就符合規(guī)范只有兩個小地方需要微調(diào)加了一輪對話總消耗第一輪生成輸入 4,600 token含技能文件輸出 1,900 token 第二輪微調(diào)輸入 5,200 token輸出 300 token 合計輸入約 9,800 token輸出約 2,200 token 總消耗約 12,000 token這組數(shù)字很有代表性同樣一個需求效率提升接近 70%。請注意這個差距不是因為模型變聰明了而是它少走了四輪彎路。2.3 別只看 Token 總量關(guān)鍵是無效 Token 率稍微懂一點大模型原理的人都知道Token 費用是按照輸入和輸出分開計算的輸入通常是輸出的五分之一甚至更低。但很多人忽略一個問題輸入 Token 里真正有效的部分可能只占一小部分。在不開 skills 的多輪糾錯流程里每輪輸入都包含了前面所有對話歷史的完整上下文。第一輪可能只有 3000 字有效代碼第四輪就變成了 9000 字其中大部分是重復(fù)出現(xiàn)的錯誤代碼、模型曾經(jīng)生成過但沒有被采納的方案、以及冗長的報錯信息。這些歷史包袱就是無效 Token每次請求都在重復(fù)計費。mattpocock/skills 對無效 Token 率的改善是非常明顯的。因為第一輪產(chǎn)出質(zhì)量高對話輪數(shù)少上下文被快速截斷或在新會話中重建歷史包袱根本沒機會積累。從成本角度講這個收益甚至比 Token 總量下降 40% 更有意義因為它降低了單次請求的延遲也讓上下文窗口更不容易被占滿。我自己算過一個簡單的賬假設(shè)每百萬輸入 Token 費用 3 美元、每百萬輸出 Token 費用 15 美元常見模型定價的近似值不同廠商有差異上面那個 40,500 Token 的會話成本大約是輸入成本36,100 / 1,000,000 × 3 ≈ 0.108 美元 輸出成本4,400 / 1,000,000 × 15 ≈ 0.066 美元 合計 ≈ 0.174 美元而優(yōu)化后 12,000 Token 的會話成本輸入成本9,800 / 1,000,000 × 3 ≈ 0.029 美元 輸出成本2,200 / 1,000,000 × 15 ≈ 0.033 美元 合計 ≈ 0.062 美元單次省下的絕對金額不多但如果每天都處理幾十個這樣的任務(wù)一個月下來差距就很可觀了。更不用說省下來的等待時間和 review 精力這才是用 skills 最大的價值。3. 核心 Skill 逐個拆解哪些場景真正省 Token、省時間3.1 類型和重構(gòu)類 Skill給 AI 套上類型安全的緊箍咒mattpocock/skills 倉庫里權(quán)重最高的就是 TypeScript 相關(guān)規(guī)則。它里面不只寫著不要用 any這種空口號而是提供了一系列具體的類型操作模式包括使用satisfies而不是直接斷言保留類型窄化能力復(fù)雜泛型必須顯式聲明約束不能用any悄悄繞過可辨識聯(lián)合類型discriminated union優(yōu)先于可選字段堆疊對第三方庫的類型缺失優(yōu)先寫局部聲明而不是全局屏蔽。這些規(guī)則看起來簡單但對 Token 的影響非常大。舉個例子當你讓 AI把這個數(shù)組按狀態(tài)分組的時候不開技能它可能生成一個用string做 key 的普通對象后來狀態(tài)加多了才發(fā)現(xiàn)類型不安全又要重寫。開啟技能后模型會直接想到用RecordStatus, Item[]或者MapStatus, Item[]第一版就是能用的。從 Token 角度這相當于把類型糾錯這個環(huán)節(jié)從輸出里刪掉了。以往每輪糾錯的輸入輸出都要燒幾百到上千 Token現(xiàn)在一次成型省的就是這塊。3.2 測試類 Skill讓 AI 自己給自己挑毛病另一個很實用的板塊是測試相關(guān)規(guī)則。mattpocock/skills 里的測試規(guī)范強調(diào)了幾件事測試必須覆蓋關(guān)鍵分支而非只測 happy pathmock 數(shù)據(jù)要接近真實結(jié)構(gòu)斷言要精確不能出現(xiàn)結(jié)果不等于 undefined這種無效斷言。這個技能在實戰(zhàn)中幫我省了不少 Token。以前讓 AI 補測試它會寫三四個用例但往往全是同一條路徑邊界條件一個沒覆蓋review 時你讓它再想想 edge case它又會重新讀一遍上下文然后補充?，F(xiàn)在它第一次就會列出正常輸入、空數(shù)組、異常值、超長字符串這幾類用例一次到位。測試生成這個場景也是公開實測里 Token 下降幅度最大的場景之一因為測試代碼本身重復(fù)度高、模式固定規(guī)則帶來的確定性收益最明顯。有博主做的對比里同一組函數(shù)的測試生成Token 消耗下降了 52%原因就是少了生成-發(fā)現(xiàn)問題-補測-再生成的循環(huán)。3.3 代碼閱讀與重構(gòu)類 Skill先讀懂再動手避免整段重寫很多 AI 編程翻車現(xiàn)場都出現(xiàn)在重構(gòu)老代碼上。模型沒讀懂代碼邊界就按自己的理解重寫結(jié)果破壞了一堆隱含依賴然后就是無窮的報錯修錯。mattpocock/skills 里針對這個場景有明確的操作規(guī)范修改任何已有代碼之前必須先輸出對原代碼行為的完整理解包括函數(shù)輸入輸出、外部依賴、副作用發(fā)生點。這個先解釋再動手的約束從 Token 角度是多花了一些但避免了更昂貴的返工。我用它重構(gòu)過一個表格組件里面的列配置邏輯被多個業(yè)務(wù)頁面依賴。開啟技能后模型先輸出了一段分析準確指出了哪些地方不能動、哪些地方可以抽成 props、哪些樣式類被外部引用。之后生成的代碼幾乎沒有返工只改了兩處命名問題。對比之前不開技能讓 AI 直接動手那次改了七八輪差點把項目歷史都弄亂了。3.4 按需調(diào)用而不是全都塞進去技能文件也要控制上下文長度這里必須說一下mattpocock/skills 不是讓你把所有規(guī)則文件一次性推給模型。每個技能文件都有一定長度如果全部加載它們本身就會占用大量輸入 Token反而抵消掉效率收益。正確做法是按當前任務(wù)類型只加載相關(guān)技能。我自己常用的組合方式是改類型問題加載typescript.mdstrict-typing.md寫測試加載testing.mdunit-tests.md改老代碼加載refactoring.mdcode-reading.md寫業(yè)務(wù)組件加載react.md或vue.mdtypescript.md。這樣每次注入上下文的技能文件大約 2000-4000 Token相比直接讓模型自由發(fā)揮性價比最高。這個按需加載的思路本身就是 token 優(yōu)化的重要手段。4. 接入方式和一次完整會話的成本復(fù)盤4.1 把 skills 裝進 Cursor、Cline 或 Claude Codemattpocock/skills 的接入方式不同工具略有差異核心都是把技能文件放到工具能讀取的目錄里。以 Claude Code 為例常見的做法是把.claude/skills/目錄指向或者復(fù)制倉庫里的技能文件在 Cline 里則是把技能文件放到cline/skills/目錄或通過自定義規(guī)則引用。具體步驟大致是這樣克隆或下載 mattpocock/skills 倉庫到本地在項目根目錄創(chuàng)建.claude/skills/或?qū)?yīng)工具的 skills 目錄把需要的技能文件復(fù)制進去或者直接在配置文件里聲明外部路徑在對話中通過請使用某 skill 處理這個任務(wù)的方式觸發(fā)某些工具也支持關(guān)鍵詞自動匹配檢查模型輸出開頭確認它已經(jīng)讀取了技能文件內(nèi)容再開始執(zhí)行任務(wù)。我第一次接入的時候踩了一個坑復(fù)制完技能文件但忘記在配置里聲明啟用路徑結(jié)果模型完全沒讀取到表現(xiàn)和不開技能一模一樣。后來檢查系統(tǒng)提示里的技能清單才發(fā)現(xiàn)路徑?jīng)]寫對。這類問題的排查方法一般是在新會話里直接問模型當前有哪些可用技能它如果答不上來說明加載配置有問題。4.2 一次真實業(yè)務(wù)會話的 Token 流水明細為了讓大家對省多少有更直觀的感受我完整復(fù)盤了一次真實業(yè)務(wù)開發(fā)會話。任務(wù)是給一個后臺管理系統(tǒng)的訂單列表頁增加篩選功能需要修改查詢參數(shù)類型、后端接口調(diào)用、表格列配置、重置邏輯大概涉及三個文件。全程使用 Claude Code開啟了 type 相關(guān)技能。整個會話耗時約半小時我記錄了每一輪請求的 token 流水第 1 輪讀取技能文件 業(yè)務(wù)文件輸入 6,200 token輸出 400 token模型輸出分析 第 2 輪生成訂單篩選組件改造輸入 5,800 token輸出 2,100 token 第 3 輪微調(diào)樣式和交互細節(jié)輸入 3,200 token輸出 700 token 第 4 輪處理一個類型錯誤輸入 2,400 token輸出 500 token 合計輸入約 17,600 token輸出約 3,700 token總計約 21,300 token這個量級對于一次中等復(fù)雜度的功能開發(fā)來說算是非常健康。對比我之前不用 skills 做類似功能往往是 5-8 輪對話、總 token 消耗在 40,000-60,000 之間。主要差距集中在第 2 輪如果沒有技能約束模型第一版代碼經(jīng)常會漏掉參數(shù)類型校驗、沒考慮查詢參數(shù)重置場景后面就要拿兩三輪去補。4.3 怎么把 Token 花在刀刃上幾個省錢且提效的習慣成本話題永遠離不開使用習慣。我總結(jié)了幾條花了真金白銀換回來的經(jīng)驗新開會話比繼續(xù)舊會話省錢。舊會話每輪都背著歷史上下文遇到一個不相干的問題寧可新開一個會話也不要讓歷史包袱越滾越大遇到報錯信息直接把報錯貼進去分析別讓 AI猜問題在哪。模型靠猜測去定位錯誤一次就會浪費大量輸出 token善用/compact或/clear清空上下文上下文一旦超過窗口一半后續(xù)請求的成本就開始指數(shù)上升把技能文件當成項目約束清單不只拿來給 AI 用也可以自己 review 代碼時對照檢查等于花一份 Token 學到了團隊的代碼規(guī)范。有一個細節(jié)很多新手不知道部分工具會把技能文件內(nèi)容填充進 system prompt 中這些內(nèi)容也計入輸入 token。如果技能文件寫得特別冗余每次請求都在替它付錢。mattpocock/skills 的文件寫得還算克制但我自己額外添加過一段很長的團隊規(guī)范文檔結(jié)果單次輸入 token 漲了 3000后面我主動精簡掉了純說教、只留可操作的規(guī)則。5. 常見問題、真實反饋和我的使用邊界判斷5.1 AI 編程里高頻出現(xiàn)的 Token 與認證報錯怎么排查使用過程中有幾個報錯幾乎每個人都會遇到我單獨拎出來說token exchange failed 或 login failed 類報錯。這類錯誤通常發(fā)生在 CLI 工具登錄或刷新憑證的時候。排查思路按順序來先檢查系統(tǒng)時間是不是準確時間偏差超過幾分鐘就會導致令牌校驗失敗再刪除本地緩存的憑證文件重新走一遍登錄流程然后確認工具的版本是不是太老舊版本經(jīng)常碰到服務(wù)端令牌策略更新后不兼容。我有一次折騰了一晚上最后發(fā)現(xiàn)就是電腦休眠后系統(tǒng)時間慢了五分鐘同步時間再重新登錄問題就沒了。blocked deletion of token file。這是清理憑證文件時經(jīng)常撞上的問題本質(zhì)是文件被某個進程占用。Windows 上常見Linux 和 macOS 上偶爾也有多數(shù)是后臺殘留的 Node 或 CLI 進程鎖住了文件。解決辦法就是先結(jié)束相關(guān)進程再刪除文件實在刪不掉就重啟一下終端或系統(tǒng)。遇到這類文件鎖問題不要硬刪找到占用進程比強行解鎖更穩(wěn)妥。已達到輸出 token 上限回答被截斷。這個更好解釋模型的單次輸出長度有上限任務(wù)太復(fù)雜導致輸出超了。解決方式不是重試而是把任務(wù)拆小讓模型先生成接口定義再生成實現(xiàn)再生成測試用例每個階段單獨開一輪。另外開啟技能之后模型在生成前會先讀規(guī)則反而可能更容易超限這時可以直接在請求里明確不要解釋直接輸出代碼省掉模型自己的分析性文本。你的訪問令牌無法刷新請退出并重新登錄。這通常說明本地保存的刷新令牌過期或者被服務(wù)端撤銷了。處理方式就是清理憑證緩存、退出登錄、重新認證。如果同時使用了多個 AI 編程工具還要檢查有沒有把不同工具的憑證混著配了串配置也會導致刷新失敗。5.2 真實用戶反饋什么人在說好用什么人說雞肋我把 GitHub 討論區(qū)、技術(shù)論壇和相關(guān)社交媒體上的反饋都看了一圈總體評價偏向正面但分歧也很明顯。喜歡的人大多是有明確工程規(guī)范的開發(fā)者和團隊他們覺得 skills 讓 AI 的輸出從能跑變成了能上生產(chǎn)。有用戶提到自己一個小團隊四個人都用 Claude Code引入 skills 之后代碼 review 的評論數(shù)明顯下降因為很多低級錯誤在第一版里就被規(guī)則攔住了。覺得雞肋的人集中在兩類。一類是只做一次性腳本、原型驗證、臨時工具的人他們本來就不關(guān)心類型規(guī)范也不需要長期維護skills 反而顯得重。另一類是已經(jīng)有一套成熟的 AI 編程工作流的人他們有自己的 prompt 規(guī)則和規(guī)范庫Matt 的這套只能參考不能直接替換。這個判斷非常正常技能文件本質(zhì)上是一種組織知識資產(chǎn)不同團隊的約束本來就不同不存在一套走天下的方案。也有人吐槽倉庫更新不勤快規(guī)則文件覆蓋面不夠廣。這個確實存在mattpocock/skills 目前的重心明顯在 TypeScript 和前端生態(tài)做后端、數(shù)據(jù)工程的人用起來會覺得很多招式不順手。但它稍微改改就能本地化把里面的 TypeScript 規(guī)則改成 Go 或 Python 的等價版本思路完全一樣。5.3 我的結(jié)論mattpocock/skills 適合誰不適合誰回到最初的問題mattpocock/skills 到底能提升多少 AI 編程效率我的回答是它不能把不會編程的人變成能交付的人但能把本來就會編程、又被 AI 反復(fù)折騰的人從無效對話里解放出來。如果按收益排序最值得嘗試的是滿足下面這些條件的人主要寫 TypeScript 或前端項目已經(jīng)用 Cursor、Claude Code 或 Cline 這類工具做過一段時間 AI 編程經(jīng)常覺得 AI 生成的代碼能用但味道不對正在為多輪糾錯產(chǎn)生的 Token 賬單肉疼。這幾條如果你中了至少兩條投入半小時配置一下大概率能感覺到明顯變化。反過來如果你只是偶爾用 AI 寫點腳本或者項目本身沒有強類型約束、沒有測試體系那這個倉庫對你的幫助很有限。它不是銀彈更不是用了就能讓 AI 替代你寫代碼的神器。它更像一份可執(zhí)行的編碼規(guī)范作用對象是 AI受益的是你和你的團隊。最后分享一個我個人的使用心得別把 skills 當成配置完就不管的東西。每當你發(fā)現(xiàn) AI 在某個場景反復(fù)犯同一個錯最有效的做法是把這個錯誤寫進規(guī)則文件里并把優(yōu)先級提到最前面。我維護的規(guī)則清單里很多條目其實就是幾周里踩坑的記錄。這一步對 token 優(yōu)化的貢獻甚至比倉庫本身還大——因為大部分公開技能文件解決的是普通水平問題而你自己補進去的那些才是你最燒錢的點。