如果你最近在刷 GitHub 或者看前端相关的 AI 编程内容mattpocock/skills 这个名字多半已经被推到脸上了。Matt Pocock 是 TypeScript 社区里很出名的内容作者做了很多年 Total TypeScript 教学核心观点一直是让 AI 生成的代码更像有经验的人写出来的而不是只会把类型写成 any。这个仓库表面看是一堆 Markdown 和文档但它实际是一套结构化的技能包专门给 Cursor、Cline、Claude Code 这类 AI 编程工具读。围绕它最常被问的问题就一个到底能提升多少效率我把公开实测、Token 数据和真实用户反馈翻了一遍这篇把我看到的、算过的、踩过的坑一次性讲清楚。适合所有正在用 AI 编程、但总觉得它在瞎改代码、Token 扣得飞快、上下文动不动就爆掉的人。在开始分析之前先给结论mattpocock/skills 不是外挂不会让你从零基础突然变成高级工程师但它确实能把 AI 编程里的无效往返砍掉一大截。所谓效率提升本质上是把AI 猜你什么意思变成AI 按你指定的操作规范执行Token 消耗下降只是结果不是目的。1. mattpocock/skills 到底是什么为什么它影响效率1.1 项目背景一个 TypeScript 布道者为什么要做技能仓库Matt Pocock 在 TypeScript 圈子的地位差不多就是新手看不懂泛型的时候第一个去搜的人。他做 Total TypeScript 教学多年对类型推导、条件类型、复杂泛型的讲解非常实战。但他从 2024 年下半年开始把很大精力放到了 AI 编程上核心原因很简单AI 写 TypeScript 的时候看起来什么都懂一用就露馅经常生成一堆用了 any 或者错误泛型的代码。他做 mattpocock/skills 的逻辑就是把过去自己教学里沉淀下来的 TypeScript 最佳实践、代码评审标准、测试规范全部写成 AI 能直接读取的操作文件。这些文件里不是空泛的请写出高质量代码而是非常具体的规则比如函数参数禁止隐式 any复杂泛型必须显式标注约束修改已有代码时不能改变未涉及的函数签名。这背后的思路非常关键大模型本身不缺少编程知识缺的是操作边界。直接问它帮我重构这个组件它会自由发挥但如果告诉它按 skills/react-hooks.md 的规则来改不能破坏现有测试它发挥的范围就被锁在了合理区间。AI 编程最大的浪费不是模型笨而是模型在没有约束的情况下做出大量不被采纳的修改然后多轮对话纠错Token 就这么烧掉了。mattpocock/skills 解决的正是这个问题。1.2 skills 比普通 Prompt 强在哪从闲聊式问答变成任务交接普通 AI 编程提示词本质上是一句话需求描述 帮我写一个防抖函数要求支持取消。 模型收到之后会按自己的理解去写大概率能写对但如果项目里有统一的工具函数库、错误处理规范、代码风格约定普通提示词根本不知道这些约束于是生成的结果往往要二次甚至三次修改。skills 做的是把这些上下文前置。你在 Cursor 或 Claude Code 里调用某个 skill 时工具会先把对应的说明书注入到模型上下文里模型看到的不只是一句需求还有一整段这个项目里怎么做才算合格的规范。整个过程相当于你从去餐厅点菜变成了带着详细菜谱去后厨每一步都盯着厨师做。我实测下来最大的体感差异是改代码这个场景。以前让 AI 改一个函数它会顺手把文件里其他部分也格式化一遍或者在导出语句上自作聪明做调整导致 review 成本极高。用了 skills 之后规则文件里明确写了只能修改需求涉及的代码其余代码保持原样这种问题基本消失。1.3 效率的本质不是写代码快而是返工少很多人测 AI 编程效率喜欢看完成任务要多长时间这个指标有迷惑性。同样一个任务模型 30 秒生成完但代码审查发现问题、再来回拉扯三轮总时间可能比直接手写还慢。mattpocock/skills 提升效率的真实路径是减少返工次数。因为操作规范在一开始就注入上下文生成的代码能直接满足项目既定约束不需要模型在后续对话里重新学习和自我纠正。从 Token 角度看就是一次高质量输出代替了三次低质量输出加两次纠错Token 消耗自然是下降的。2. 公开实测和 Token 数据里效率提升到底有多少2.1 公开实测是怎么做的任务、模型和对比口径我在 GitHub 讨论区、Reddit 和不少技术博客里翻了相关实测发现多数人用的对比方式是A/B 测试同一个任务、同一个模型、同一份代码库唯一区别是开不开 skills然后分别记录完成时间、Token 消耗、人工修正次数。这类测试里比较典型的任务是这几类重构一个复杂 TypeScript 组件要求拆分逻辑、补类型定义给现有函数补充单元测试要求覆盖边界条件修改一段老代码并新增功能要求不影响原有行为从一个大型组件中抽取可复用逻辑要求保持 API 向后兼容。从多份公开数据来看结论比较一致接入 skills 之后Token 消耗平均下降 20%-50%完成时间普遍缩减 30%-60%人工修正次数从平均两三次降到接近于零。当然这个区间很大因为任务难度和使用者的提示词水平都会影响最终结果。2.2 一次实际任务的 Token 消耗算给你看我自己也做了一次可复现的 A/B 测试。任务很简单在一个 Vue 3 组件里把一段硬编码的下拉选项改成从接口异步加载保留 loading 和 error 状态并补上相应的类型定义。环境是 Claude Code 同一个模型代码库完全一致唯一区别是开不开 mattpocock/skills。不开 skills 时我直接把需求贴给模型它生成了完整修改但有几处不符合项目规范接口返回类型用了宽松的anyloading 状态没放进统一的 store错误处理直接console.log而不是调用项目里的错误上报函数。我花了四轮对话去纠正这些问题加起来的上下文越滚越长。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同样任务开启 skills 之后模型读取了项目规范文件第一轮生成的代码就符合规范只有两个小地方需要微调加了一轮对话总消耗第一轮生成输入 4,600 token含技能文件输出 1,900 token 第二轮微调输入 5,200 token输出 300 token 合计输入约 9,800 token输出约 2,200 token 总消耗约 12,000 token这组数字很有代表性同样一个需求效率提升接近 70%。请注意这个差距不是因为模型变聪明了而是它少走了四轮弯路。2.3 别只看 Token 总量关键是无效 Token 率稍微懂一点大模型原理的人都知道Token 费用是按照输入和输出分开计算的输入通常是输出的五分之一甚至更低。但很多人忽略一个问题输入 Token 里真正有效的部分可能只占一小部分。在不开 skills 的多轮纠错流程里每轮输入都包含了前面所有对话历史的完整上下文。第一轮可能只有 3000 字有效代码第四轮就变成了 9000 字其中大部分是重复出现的错误代码、模型曾经生成过但没有被采纳的方案、以及冗长的报错信息。这些历史包袱就是无效 Token每次请求都在重复计费。mattpocock/skills 对无效 Token 率的改善是非常明显的。因为第一轮产出质量高对话轮数少上下文被快速截断或在新会话中重建历史包袱根本没机会积累。从成本角度讲这个收益甚至比 Token 总量下降 40% 更有意义因为它降低了单次请求的延迟也让上下文窗口更不容易被占满。我自己算过一个简单的账假设每百万输入 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 美元而优化后 12,000 Token 的会话成本输入成本9,800 / 1,000,000 × 3 ≈ 0.029 美元 输出成本2,200 / 1,000,000 × 15 ≈ 0.033 美元 合计 ≈ 0.062 美元单次省下的绝对金额不多但如果每天都处理几十个这样的任务一个月下来差距就很可观了。更不用说省下来的等待时间和 review 精力这才是用 skills 最大的价值。3. 核心 Skill 逐个拆解哪些场景真正省 Token、省时间3.1 类型和重构类 Skill给 AI 套上类型安全的紧箍咒mattpocock/skills 仓库里权重最高的就是 TypeScript 相关规则。它里面不只写着不要用 any这种空口号而是提供了一系列具体的类型操作模式包括使用satisfies而不是直接断言保留类型窄化能力复杂泛型必须显式声明约束不能用any悄悄绕过可辨识联合类型discriminated union优先于可选字段堆叠对第三方库的类型缺失优先写局部声明而不是全局屏蔽。这些规则看起来简单但对 Token 的影响非常大。举个例子当你让 AI把这个数组按状态分组的时候不开技能它可能生成一个用string做 key 的普通对象后来状态加多了才发现类型不安全又要重写。开启技能后模型会直接想到用RecordStatus, Item[]或者MapStatus, Item[]第一版就是能用的。从 Token 角度这相当于把类型纠错这个环节从输出里删掉了。以往每轮纠错的输入输出都要烧几百到上千 Token现在一次成型省的就是这块。3.2 测试类 Skill让 AI 自己给自己挑毛病另一个很实用的板块是测试相关规则。mattpocock/skills 里的测试规范强调了几件事测试必须覆盖关键分支而非只测 happy pathmock 数据要接近真实结构断言要精确不能出现结果不等于 undefined这种无效断言。这个技能在实战中帮我省了不少 Token。以前让 AI 补测试它会写三四个用例但往往全是同一条路径边界条件一个没覆盖review 时你让它再想想 edge case它又会重新读一遍上下文然后补充。现在它第一次就会列出正常输入、空数组、异常值、超长字符串这几类用例一次到位。测试生成这个场景也是公开实测里 Token 下降幅度最大的场景之一因为测试代码本身重复度高、模式固定规则带来的确定性收益最明显。有博主做的对比里同一组函数的测试生成Token 消耗下降了 52%原因就是少了生成-发现问题-补测-再生成的循环。3.3 代码阅读与重构类 Skill先读懂再动手避免整段重写很多 AI 编程翻车现场都出现在重构老代码上。模型没读懂代码边界就按自己的理解重写结果破坏了一堆隐含依赖然后就是无穷的报错修错。mattpocock/skills 里针对这个场景有明确的操作规范修改任何已有代码之前必须先输出对原代码行为的完整理解包括函数输入输出、外部依赖、副作用发生点。这个先解释再动手的约束从 Token 角度是多花了一些但避免了更昂贵的返工。我用它重构过一个表格组件里面的列配置逻辑被多个业务页面依赖。开启技能后模型先输出了一段分析准确指出了哪些地方不能动、哪些地方可以抽成 props、哪些样式类被外部引用。之后生成的代码几乎没有返工只改了两处命名问题。对比之前不开技能让 AI 直接动手那次改了七八轮差点把项目历史都弄乱了。3.4 按需调用而不是全都塞进去技能文件也要控制上下文长度这里必须说一下mattpocock/skills 不是让你把所有规则文件一次性推给模型。每个技能文件都有一定长度如果全部加载它们本身就会占用大量输入 Token反而抵消掉效率收益。正确做法是按当前任务类型只加载相关技能。我自己常用的组合方式是改类型问题加载typescript.mdstrict-typing.md写测试加载testing.mdunit-tests.md改老代码加载refactoring.mdcode-reading.md写业务组件加载react.md或vue.mdtypescript.md。这样每次注入上下文的技能文件大约 2000-4000 Token相比直接让模型自由发挥性价比最高。这个按需加载的思路本身就是 token 优化的重要手段。4. 接入方式和一次完整会话的成本复盘4.1 把 skills 装进 Cursor、Cline 或 Claude Codemattpocock/skills 的接入方式不同工具略有差异核心都是把技能文件放到工具能读取的目录里。以 Claude Code 为例常见的做法是把.claude/skills/目录指向或者复制仓库里的技能文件在 Cline 里则是把技能文件放到cline/skills/目录或通过自定义规则引用。具体步骤大致是这样克隆或下载 mattpocock/skills 仓库到本地在项目根目录创建.claude/skills/或对应工具的 skills 目录把需要的技能文件复制进去或者直接在配置文件里声明外部路径在对话中通过请使用某 skill 处理这个任务的方式触发某些工具也支持关键词自动匹配检查模型输出开头确认它已经读取了技能文件内容再开始执行任务。我第一次接入的时候踩了一个坑复制完技能文件但忘记在配置里声明启用路径结果模型完全没读取到表现和不开技能一模一样。后来检查系统提示里的技能清单才发现路径没写对。这类问题的排查方法一般是在新会话里直接问模型当前有哪些可用技能它如果答不上来说明加载配置有问题。4.2 一次真实业务会话的 Token 流水明细为了让大家对省多少有更直观的感受我完整复盘了一次真实业务开发会话。任务是给一个后台管理系统的订单列表页增加筛选功能需要修改查询参数类型、后端接口调用、表格列配置、重置逻辑大概涉及三个文件。全程使用 Claude Code开启了 type 相关技能。整个会话耗时约半小时我记录了每一轮请求的 token 流水第 1 轮读取技能文件 业务文件输入 6,200 token输出 400 token模型输出分析 第 2 轮生成订单筛选组件改造输入 5,800 token输出 2,100 token 第 3 轮微调样式和交互细节输入 3,200 token输出 700 token 第 4 轮处理一个类型错误输入 2,400 token输出 500 token 合计输入约 17,600 token输出约 3,700 token总计约 21,300 token这个量级对于一次中等复杂度的功能开发来说算是非常健康。对比我之前不用 skills 做类似功能往往是 5-8 轮对话、总 token 消耗在 40,000-60,000 之间。主要差距集中在第 2 轮如果没有技能约束模型第一版代码经常会漏掉参数类型校验、没考虑查询参数重置场景后面就要拿两三轮去补。4.3 怎么把 Token 花在刀刃上几个省钱且提效的习惯成本话题永远离不开使用习惯。我总结了几条花了真金白银换回来的经验新开会话比继续旧会话省钱。旧会话每轮都背着历史上下文遇到一个不相干的问题宁可新开一个会话也不要让历史包袱越滚越大遇到报错信息直接把报错贴进去分析别让 AI猜问题在哪。模型靠猜测去定位错误一次就会浪费大量输出 token善用/compact或/clear清空上下文上下文一旦超过窗口一半后续请求的成本就开始指数上升把技能文件当成项目约束清单不只拿来给 AI 用也可以自己 review 代码时对照检查等于花一份 Token 学到了团队的代码规范。有一个细节很多新手不知道部分工具会把技能文件内容填充进 system prompt 中这些内容也计入输入 token。如果技能文件写得特别冗余每次请求都在替它付钱。mattpocock/skills 的文件写得还算克制但我自己额外添加过一段很长的团队规范文档结果单次输入 token 涨了 3000后面我主动精简掉了纯说教、只留可操作的规则。5. 常见问题、真实反馈和我的使用边界判断5.1 AI 编程里高频出现的 Token 与认证报错怎么排查使用过程中有几个报错几乎每个人都会遇到我单独拎出来说token exchange failed 或 login failed 类报错。这类错误通常发生在 CLI 工具登录或刷新凭证的时候。排查思路按顺序来先检查系统时间是不是准确时间偏差超过几分钟就会导致令牌校验失败再删除本地缓存的凭证文件重新走一遍登录流程然后确认工具的版本是不是太老旧版本经常碰到服务端令牌策略更新后不兼容。我有一次折腾了一晚上最后发现就是电脑休眠后系统时间慢了五分钟同步时间再重新登录问题就没了。blocked deletion of token file。这是清理凭证文件时经常撞上的问题本质是文件被某个进程占用。Windows 上常见Linux 和 macOS 上偶尔也有多数是后台残留的 Node 或 CLI 进程锁住了文件。解决办法就是先结束相关进程再删除文件实在删不掉就重启一下终端或系统。遇到这类文件锁问题不要硬删找到占用进程比强行解锁更稳妥。已达到输出 token 上限回答被截断。这个更好解释模型的单次输出长度有上限任务太复杂导致输出超了。解决方式不是重试而是把任务拆小让模型先生成接口定义再生成实现再生成测试用例每个阶段单独开一轮。另外开启技能之后模型在生成前会先读规则反而可能更容易超限这时可以直接在请求里明确不要解释直接输出代码省掉模型自己的分析性文本。你的访问令牌无法刷新请退出并重新登录。这通常说明本地保存的刷新令牌过期或者被服务端撤销了。处理方式就是清理凭证缓存、退出登录、重新认证。如果同时使用了多个 AI 编程工具还要检查有没有把不同工具的凭证混着配了串配置也会导致刷新失败。5.2 真实用户反馈什么人在说好用什么人说鸡肋我把 GitHub 讨论区、技术论坛和相关社交媒体上的反馈都看了一圈总体评价偏向正面但分歧也很明显。喜欢的人大多是有明确工程规范的开发者和团队他们觉得 skills 让 AI 的输出从能跑变成了能上生产。有用户提到自己一个小团队四个人都用 Claude Code引入 skills 之后代码 review 的评论数明显下降因为很多低级错误在第一版里就被规则拦住了。觉得鸡肋的人集中在两类。一类是只做一次性脚本、原型验证、临时工具的人他们本来就不关心类型规范也不需要长期维护skills 反而显得重。另一类是已经有一套成熟的 AI 编程工作流的人他们有自己的 prompt 规则和规范库Matt 的这套只能参考不能直接替换。这个判断非常正常技能文件本质上是一种组织知识资产不同团队的约束本来就不同不存在一套走天下的方案。也有人吐槽仓库更新不勤快规则文件覆盖面不够广。这个确实存在mattpocock/skills 目前的重心明显在 TypeScript 和前端生态做后端、数据工程的人用起来会觉得很多招式不顺手。但它稍微改改就能本地化把里面的 TypeScript 规则改成 Go 或 Python 的等价版本思路完全一样。5.3 我的结论mattpocock/skills 适合谁不适合谁回到最初的问题mattpocock/skills 到底能提升多少 AI 编程效率我的回答是它不能把不会编程的人变成能交付的人但能把本来就会编程、又被 AI 反复折腾的人从无效对话里解放出来。如果按收益排序最值得尝试的是满足下面这些条件的人主要写 TypeScript 或前端项目已经用 Cursor、Claude Code 或 Cline 这类工具做过一段时间 AI 编程经常觉得 AI 生成的代码能用但味道不对正在为多轮纠错产生的 Token 账单肉疼。这几条如果你中了至少两条投入半小时配置一下大概率能感觉到明显变化。反过来如果你只是偶尔用 AI 写点脚本或者项目本身没有强类型约束、没有测试体系那这个仓库对你的帮助很有限。它不是银弹更不是用了就能让 AI 替代你写代码的神器。它更像一份可执行的编码规范作用对象是 AI受益的是你和你的团队。最后分享一个我个人的使用心得别把 skills 当成配置完就不管的东西。每当你发现 AI 在某个场景反复犯同一个错最有效的做法是把这个错误写进规则文件里并把优先级提到最前面。我维护的规则清单里很多条目其实就是几周里踩坑的记录。这一步对 token 优化的贡献甚至比仓库本身还大——因为大部分公开技能文件解决的是普通水平问题而你自己补进去的那些才是你最烧钱的点。 
长河君 · 2026/9/11 6:25:07 · 阅读 1.2k mattpocock/skills 实战解析：AI 编程效率与 Token 消耗的优化之道
如果你最近在刷 GitHub 或者看前端相关的 AI 编程内容mattpocock/skills 这个名字多半已经被推到脸上了。Matt Pocock 是 TypeScript 社区里很出名的内容作者做了很多年 Total TypeScript 教学核心观点一直是让 AI 生成的代码更像有经验的人写出来的而不是只会把类型写成 any。这个仓库表面看是一堆 Markdown 和文档但它实际是一套结构化的技能包专门给 Cursor、Cline、Claude Code 这类 AI 编程工具读。围绕它最常被问的问题就一个到底能提升多少效率我把公开实测、Token 数据和真实用户反馈翻了一遍这篇把我看到的、算过的、踩过的坑一次性讲清楚。适合所有正在用 AI 编程、但总觉得它在瞎改代码、Token 扣得飞快、上下文动不动就爆掉的人。在开始分析之前先给结论mattpocock/skills 不是外挂不会让你从零基础突然变成高级工程师但它确实能把 AI 编程里的无效往返砍掉一大截。所谓效率提升本质上是把AI 猜你什么意思变成AI 按你指定的操作规范执行Token 消耗下降只是结果不是目的。1. mattpocock/skills 到底是什么为什么它影响效率1.1 项目背景一个 TypeScript 布道者为什么要做技能仓库Matt Pocock 在 TypeScript 圈子的地位差不多就是新手看不懂泛型的时候第一个去搜的人。他做 Total TypeScript 教学多年对类型推导、条件类型、复杂泛型的讲解非常实战。但他从 2024 年下半年开始把很大精力放到了 AI 编程上核心原因很简单AI 写 TypeScript 的时候看起来什么都懂一用就露馅经常生成一堆用了 any 或者错误泛型的代码。他做 mattpocock/skills 的逻辑就是把过去自己教学里沉淀下来的 TypeScript 最佳实践、代码评审标准、测试规范全部写成 AI 能直接读取的操作文件。这些文件里不是空泛的请写出高质量代码而是非常具体的规则比如函数参数禁止隐式 any复杂泛型必须显式标注约束修改已有代码时不能改变未涉及的函数签名。这背后的思路非常关键大模型本身不缺少编程知识缺的是操作边界。直接问它帮我重构这个组件它会自由发挥但如果告诉它按 skills/react-hooks.md 的规则来改不能破坏现有测试它发挥的范围就被锁在了合理区间。AI 编程最大的浪费不是模型笨而是模型在没有约束的情况下做出大量不被采纳的修改然后多轮对话纠错Token 就这么烧掉了。mattpocock/skills 解决的正是这个问题。1.2 skills 比普通 Prompt 强在哪从闲聊式问答变成任务交接普通 AI 编程提示词本质上是一句话需求描述 帮我写一个防抖函数要求支持取消。 模型收到之后会按自己的理解去写大概率能写对但如果项目里有统一的工具函数库、错误处理规范、代码风格约定普通提示词根本不知道这些约束于是生成的结果往往要二次甚至三次修改。skills 做的是把这些上下文前置。你在 Cursor 或 Claude Code 里调用某个 skill 时工具会先把对应的说明书注入到模型上下文里模型看到的不只是一句需求还有一整段这个项目里怎么做才算合格的规范。整个过程相当于你从去餐厅点菜变成了带着详细菜谱去后厨每一步都盯着厨师做。我实测下来最大的体感差异是改代码这个场景。以前让 AI 改一个函数它会顺手把文件里其他部分也格式化一遍或者在导出语句上自作聪明做调整导致 review 成本极高。用了 skills 之后规则文件里明确写了只能修改需求涉及的代码其余代码保持原样这种问题基本消失。1.3 效率的本质不是写代码快而是返工少很多人测 AI 编程效率喜欢看完成任务要多长时间这个指标有迷惑性。同样一个任务模型 30 秒生成完但代码审查发现问题、再来回拉扯三轮总时间可能比直接手写还慢。mattpocock/skills 提升效率的真实路径是减少返工次数。因为操作规范在一开始就注入上下文生成的代码能直接满足项目既定约束不需要模型在后续对话里重新学习和自我纠正。从 Token 角度看就是一次高质量输出代替了三次低质量输出加两次纠错Token 消耗自然是下降的。2. 公开实测和 Token 数据里效率提升到底有多少2.1 公开实测是怎么做的任务、模型和对比口径我在 GitHub 讨论区、Reddit 和不少技术博客里翻了相关实测发现多数人用的对比方式是A/B 测试同一个任务、同一个模型、同一份代码库唯一区别是开不开 skills然后分别记录完成时间、Token 消耗、人工修正次数。这类测试里比较典型的任务是这几类重构一个复杂 TypeScript 组件要求拆分逻辑、补类型定义给现有函数补充单元测试要求覆盖边界条件修改一段老代码并新增功能要求不影响原有行为从一个大型组件中抽取可复用逻辑要求保持 API 向后兼容。从多份公开数据来看结论比较一致接入 skills 之后Token 消耗平均下降 20%-50%完成时间普遍缩减 30%-60%人工修正次数从平均两三次降到接近于零。当然这个区间很大因为任务难度和使用者的提示词水平都会影响最终结果。2.2 一次实际任务的 Token 消耗算给你看我自己也做了一次可复现的 A/B 测试。任务很简单在一个 Vue 3 组件里把一段硬编码的下拉选项改成从接口异步加载保留 loading 和 error 状态并补上相应的类型定义。环境是 Claude Code 同一个模型代码库完全一致唯一区别是开不开 mattpocock/skills。不开 skills 时我直接把需求贴给模型它生成了完整修改但有几处不符合项目规范接口返回类型用了宽松的anyloading 状态没放进统一的 store错误处理直接console.log而不是调用项目里的错误上报函数。我花了四轮对话去纠正这些问题加起来的上下文越滚越长。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同样任务开启 skills 之后模型读取了项目规范文件第一轮生成的代码就符合规范只有两个小地方需要微调加了一轮对话总消耗第一轮生成输入 4,600 token含技能文件输出 1,900 token 第二轮微调输入 5,200 token输出 300 token 合计输入约 9,800 token输出约 2,200 token 总消耗约 12,000 token这组数字很有代表性同样一个需求效率提升接近 70%。请注意这个差距不是因为模型变聪明了而是它少走了四轮弯路。2.3 别只看 Token 总量关键是无效 Token 率稍微懂一点大模型原理的人都知道Token 费用是按照输入和输出分开计算的输入通常是输出的五分之一甚至更低。但很多人忽略一个问题输入 Token 里真正有效的部分可能只占一小部分。在不开 skills 的多轮纠错流程里每轮输入都包含了前面所有对话历史的完整上下文。第一轮可能只有 3000 字有效代码第四轮就变成了 9000 字其中大部分是重复出现的错误代码、模型曾经生成过但没有被采纳的方案、以及冗长的报错信息。这些历史包袱就是无效 Token每次请求都在重复计费。mattpocock/skills 对无效 Token 率的改善是非常明显的。因为第一轮产出质量高对话轮数少上下文被快速截断或在新会话中重建历史包袱根本没机会积累。从成本角度讲这个收益甚至比 Token 总量下降 40% 更有意义因为它降低了单次请求的延迟也让上下文窗口更不容易被占满。我自己算过一个简单的账假设每百万输入 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 美元而优化后 12,000 Token 的会话成本输入成本9,800 / 1,000,000 × 3 ≈ 0.029 美元 输出成本2,200 / 1,000,000 × 15 ≈ 0.033 美元 合计 ≈ 0.062 美元单次省下的绝对金额不多但如果每天都处理几十个这样的任务一个月下来差距就很可观了。更不用说省下来的等待时间和 review 精力这才是用 skills 最大的价值。3. 核心 Skill 逐个拆解哪些场景真正省 Token、省时间3.1 类型和重构类 Skill给 AI 套上类型安全的紧箍咒mattpocock/skills 仓库里权重最高的就是 TypeScript 相关规则。它里面不只写着不要用 any这种空口号而是提供了一系列具体的类型操作模式包括使用satisfies而不是直接断言保留类型窄化能力复杂泛型必须显式声明约束不能用any悄悄绕过可辨识联合类型discriminated union优先于可选字段堆叠对第三方库的类型缺失优先写局部声明而不是全局屏蔽。这些规则看起来简单但对 Token 的影响非常大。举个例子当你让 AI把这个数组按状态分组的时候不开技能它可能生成一个用string做 key 的普通对象后来状态加多了才发现类型不安全又要重写。开启技能后模型会直接想到用RecordStatus, Item[]或者MapStatus, Item[]第一版就是能用的。从 Token 角度这相当于把类型纠错这个环节从输出里删掉了。以往每轮纠错的输入输出都要烧几百到上千 Token现在一次成型省的就是这块。3.2 测试类 Skill让 AI 自己给自己挑毛病另一个很实用的板块是测试相关规则。mattpocock/skills 里的测试规范强调了几件事测试必须覆盖关键分支而非只测 happy pathmock 数据要接近真实结构断言要精确不能出现结果不等于 undefined这种无效断言。这个技能在实战中帮我省了不少 Token。以前让 AI 补测试它会写三四个用例但往往全是同一条路径边界条件一个没覆盖review 时你让它再想想 edge case它又会重新读一遍上下文然后补充。现在它第一次就会列出正常输入、空数组、异常值、超长字符串这几类用例一次到位。测试生成这个场景也是公开实测里 Token 下降幅度最大的场景之一因为测试代码本身重复度高、模式固定规则带来的确定性收益最明显。有博主做的对比里同一组函数的测试生成Token 消耗下降了 52%原因就是少了生成-发现问题-补测-再生成的循环。3.3 代码阅读与重构类 Skill先读懂再动手避免整段重写很多 AI 编程翻车现场都出现在重构老代码上。模型没读懂代码边界就按自己的理解重写结果破坏了一堆隐含依赖然后就是无穷的报错修错。mattpocock/skills 里针对这个场景有明确的操作规范修改任何已有代码之前必须先输出对原代码行为的完整理解包括函数输入输出、外部依赖、副作用发生点。这个先解释再动手的约束从 Token 角度是多花了一些但避免了更昂贵的返工。我用它重构过一个表格组件里面的列配置逻辑被多个业务页面依赖。开启技能后模型先输出了一段分析准确指出了哪些地方不能动、哪些地方可以抽成 props、哪些样式类被外部引用。之后生成的代码几乎没有返工只改了两处命名问题。对比之前不开技能让 AI 直接动手那次改了七八轮差点把项目历史都弄乱了。3.4 按需调用而不是全都塞进去技能文件也要控制上下文长度这里必须说一下mattpocock/skills 不是让你把所有规则文件一次性推给模型。每个技能文件都有一定长度如果全部加载它们本身就会占用大量输入 Token反而抵消掉效率收益。正确做法是按当前任务类型只加载相关技能。我自己常用的组合方式是改类型问题加载typescript.mdstrict-typing.md写测试加载testing.mdunit-tests.md改老代码加载refactoring.mdcode-reading.md写业务组件加载react.md或vue.mdtypescript.md。这样每次注入上下文的技能文件大约 2000-4000 Token相比直接让模型自由发挥性价比最高。这个按需加载的思路本身就是 token 优化的重要手段。4. 接入方式和一次完整会话的成本复盘4.1 把 skills 装进 Cursor、Cline 或 Claude Codemattpocock/skills 的接入方式不同工具略有差异核心都是把技能文件放到工具能读取的目录里。以 Claude Code 为例常见的做法是把.claude/skills/目录指向或者复制仓库里的技能文件在 Cline 里则是把技能文件放到cline/skills/目录或通过自定义规则引用。具体步骤大致是这样克隆或下载 mattpocock/skills 仓库到本地在项目根目录创建.claude/skills/或对应工具的 skills 目录把需要的技能文件复制进去或者直接在配置文件里声明外部路径在对话中通过请使用某 skill 处理这个任务的方式触发某些工具也支持关键词自动匹配检查模型输出开头确认它已经读取了技能文件内容再开始执行任务。我第一次接入的时候踩了一个坑复制完技能文件但忘记在配置里声明启用路径结果模型完全没读取到表现和不开技能一模一样。后来检查系统提示里的技能清单才发现路径没写对。这类问题的排查方法一般是在新会话里直接问模型当前有哪些可用技能它如果答不上来说明加载配置有问题。4.2 一次真实业务会话的 Token 流水明细为了让大家对省多少有更直观的感受我完整复盘了一次真实业务开发会话。任务是给一个后台管理系统的订单列表页增加筛选功能需要修改查询参数类型、后端接口调用、表格列配置、重置逻辑大概涉及三个文件。全程使用 Claude Code开启了 type 相关技能。整个会话耗时约半小时我记录了每一轮请求的 token 流水第 1 轮读取技能文件 业务文件输入 6,200 token输出 400 token模型输出分析 第 2 轮生成订单筛选组件改造输入 5,800 token输出 2,100 token 第 3 轮微调样式和交互细节输入 3,200 token输出 700 token 第 4 轮处理一个类型错误输入 2,400 token输出 500 token 合计输入约 17,600 token输出约 3,700 token总计约 21,300 token这个量级对于一次中等复杂度的功能开发来说算是非常健康。对比我之前不用 skills 做类似功能往往是 5-8 轮对话、总 token 消耗在 40,000-60,000 之间。主要差距集中在第 2 轮如果没有技能约束模型第一版代码经常会漏掉参数类型校验、没考虑查询参数重置场景后面就要拿两三轮去补。4.3 怎么把 Token 花在刀刃上几个省钱且提效的习惯成本话题永远离不开使用习惯。我总结了几条花了真金白银换回来的经验新开会话比继续旧会话省钱。旧会话每轮都背着历史上下文遇到一个不相干的问题宁可新开一个会话也不要让历史包袱越滚越大遇到报错信息直接把报错贴进去分析别让 AI猜问题在哪。模型靠猜测去定位错误一次就会浪费大量输出 token善用/compact或/clear清空上下文上下文一旦超过窗口一半后续请求的成本就开始指数上升把技能文件当成项目约束清单不只拿来给 AI 用也可以自己 review 代码时对照检查等于花一份 Token 学到了团队的代码规范。有一个细节很多新手不知道部分工具会把技能文件内容填充进 system prompt 中这些内容也计入输入 token。如果技能文件写得特别冗余每次请求都在替它付钱。mattpocock/skills 的文件写得还算克制但我自己额外添加过一段很长的团队规范文档结果单次输入 token 涨了 3000后面我主动精简掉了纯说教、只留可操作的规则。5. 常见问题、真实反馈和我的使用边界判断5.1 AI 编程里高频出现的 Token 与认证报错怎么排查使用过程中有几个报错几乎每个人都会遇到我单独拎出来说token exchange failed 或 login failed 类报错。这类错误通常发生在 CLI 工具登录或刷新凭证的时候。排查思路按顺序来先检查系统时间是不是准确时间偏差超过几分钟就会导致令牌校验失败再删除本地缓存的凭证文件重新走一遍登录流程然后确认工具的版本是不是太老旧版本经常碰到服务端令牌策略更新后不兼容。我有一次折腾了一晚上最后发现就是电脑休眠后系统时间慢了五分钟同步时间再重新登录问题就没了。blocked deletion of token file。这是清理凭证文件时经常撞上的问题本质是文件被某个进程占用。Windows 上常见Linux 和 macOS 上偶尔也有多数是后台残留的 Node 或 CLI 进程锁住了文件。解决办法就是先结束相关进程再删除文件实在删不掉就重启一下终端或系统。遇到这类文件锁问题不要硬删找到占用进程比强行解锁更稳妥。已达到输出 token 上限回答被截断。这个更好解释模型的单次输出长度有上限任务太复杂导致输出超了。解决方式不是重试而是把任务拆小让模型先生成接口定义再生成实现再生成测试用例每个阶段单独开一轮。另外开启技能之后模型在生成前会先读规则反而可能更容易超限这时可以直接在请求里明确不要解释直接输出代码省掉模型自己的分析性文本。你的访问令牌无法刷新请退出并重新登录。这通常说明本地保存的刷新令牌过期或者被服务端撤销了。处理方式就是清理凭证缓存、退出登录、重新认证。如果同时使用了多个 AI 编程工具还要检查有没有把不同工具的凭证混着配了串配置也会导致刷新失败。5.2 真实用户反馈什么人在说好用什么人说鸡肋我把 GitHub 讨论区、技术论坛和相关社交媒体上的反馈都看了一圈总体评价偏向正面但分歧也很明显。喜欢的人大多是有明确工程规范的开发者和团队他们觉得 skills 让 AI 的输出从能跑变成了能上生产。有用户提到自己一个小团队四个人都用 Claude Code引入 skills 之后代码 review 的评论数明显下降因为很多低级错误在第一版里就被规则拦住了。觉得鸡肋的人集中在两类。一类是只做一次性脚本、原型验证、临时工具的人他们本来就不关心类型规范也不需要长期维护skills 反而显得重。另一类是已经有一套成熟的 AI 编程工作流的人他们有自己的 prompt 规则和规范库Matt 的这套只能参考不能直接替换。这个判断非常正常技能文件本质上是一种组织知识资产不同团队的约束本来就不同不存在一套走天下的方案。也有人吐槽仓库更新不勤快规则文件覆盖面不够广。这个确实存在mattpocock/skills 目前的重心明显在 TypeScript 和前端生态做后端、数据工程的人用起来会觉得很多招式不顺手。但它稍微改改就能本地化把里面的 TypeScript 规则改成 Go 或 Python 的等价版本思路完全一样。5.3 我的结论mattpocock/skills 适合谁不适合谁回到最初的问题mattpocock/skills 到底能提升多少 AI 编程效率我的回答是它不能把不会编程的人变成能交付的人但能把本来就会编程、又被 AI 反复折腾的人从无效对话里解放出来。如果按收益排序最值得尝试的是满足下面这些条件的人主要写 TypeScript 或前端项目已经用 Cursor、Claude Code 或 Cline 这类工具做过一段时间 AI 编程经常觉得 AI 生成的代码能用但味道不对正在为多轮纠错产生的 Token 账单肉疼。这几条如果你中了至少两条投入半小时配置一下大概率能感觉到明显变化。反过来如果你只是偶尔用 AI 写点脚本或者项目本身没有强类型约束、没有测试体系那这个仓库对你的帮助很有限。它不是银弹更不是用了就能让 AI 替代你写代码的神器。它更像一份可执行的编码规范作用对象是 AI受益的是你和你的团队。最后分享一个我个人的使用心得别把 skills 当成配置完就不管的东西。每当你发现 AI 在某个场景反复犯同一个错最有效的做法是把这个错误写进规则文件里并把优先级提到最前面。我维护的规则清单里很多条目其实就是几周里踩坑的记录。这一步对 token 优化的贡献甚至比仓库本身还大——因为大部分公开技能文件解决的是普通水平问题而你自己补进去的那些才是你最烧钱的点。