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