20万星里程碑达成！GitHub封神技能包，专治AI瞎写、失忆、造屎山
20多个技能，包含需求规划、代码开发、工具安全、知识管理全流程。
作者丨 高允毅
编辑丨 岑 峰
昨天，TypeScript圈大佬、AI 工程化先锋 Matt Pocock 喜滋滋宣布，他的开源项目 “mattpocock/skills” 在全球最大开源平台GitHub喜提 20万颗星 。
20万颗星什么概念？绝对的开源界顶流。
近四个月的时间里，该项目一路爆火，下载量更是高达 1300万次 ，网友清一色评价：实至名归。
它之所以爆红，全靠两个字：实用。简单来说，这是一套 基于 Markdown 的、可自由组合的“AI 工作流技能包（Skill s） ”。
几乎每一位长期使用 Claude Code 的工程师，都深陷同一个困境。AI工具确实有潜力，但它不了解你的团队工作方式。不知道你写功能前要先写测试，不知道哪些Git操作需要人工审批，更不清楚你的代码库采用什么架构模式。
项目里包含 20 多个Skill文件，从 需求规划、代码开发、工具安全、知识管理 等全流程的疑难杂症，它都一一拆解了，而且全部沉淀自 Matt 多年一线实战经验。
不同于市面上笨重、全权接管开发环境的巨型 AI 框架，这套技能包极致轻巧、零冗余、无需额外安装工具，原生适配 Claude Code，简单适配后即可用于 Cursor，同时极度省 Token、上手成本极低。
01
项目的起源
mattpocock/skills的诞生非常有戏剧性。它最早根本不是一个精心策划的"开源大作"，而是Matt Pocock在2026年初遭遇一系列 AI编程翻车 后，出于极度愤怒和沮丧，在自己电脑本地写下的"防AI作弊与防失控补丁"。
2026年初，Matt刚创办教育平台AI Hero。因为团队人少，他开始全职重度依赖Claude Code、Cursor等AI代理来写业务代码。但很快，他就撞上了全球资深工程师都头疼的四大问题。
先是AI的 "长文本失忆症" 。 随着对话变长，AI转头就忘了半小时前定下的关键架构决策，开始胡乱给变量命名。
接着 AI开始自作主张 。 每当Matt抛出一个模糊想法，AI也不确定需求，立刻上手写500行代码，结果根本不是他想要的业务逻辑。
然后 AI还会作弊 。 如果让AI先写业务代码最后补测试，它为了交差会伪造配合其错误代码的"假测试断言"。
最可怕的是 AI造屎山 的速度比人还快。在缺乏重构流程的情况下，几天时间就会把代码模块搞得错综复杂、难以维护。
经历了几次全盘崩溃后，Matt愤怒地总结了一句话："你指尖随时拥有一支水准中上的工程师舰队。但诡异的是，这帮人完全没有记忆。AI时代最大的瓶颈，根本不是产能，而是人类对它的控制。"
为了规范 AI 开发行为，Matt开始在本地~/.claude/skills目录里写下一条条Markdown指令，把工程决策权牢牢抓在手里。
2026年4月29日，Matt把这些本地技能开源了。当天单日暴涨7300颗星，一周后突破59000，到8月稳定在20万颗星以上，成为 2026 年现象级开源项目。
02
走红的原因
在整个项目的20多个技能里，最初让它火爆出圈的是只有十几行Markdown描述的 /grill-me（拷问我） 。 Matt 称这是整个仓库里 “最酷的技能，没有之一”。
传统AI辅助编程往往是单向投喂。你丢给它一篇长文档，随口交代一句"照着这个写个功能"，AI通常走马观花扫一眼，漏掉最致命的API限制，然后给你一坨根本跑不通的代码。
但 /grill-me 彻底颠覆了这种模式。它会强制AI先吞噬文档，再质询人类，最后对齐共识。其核心指令是： "请围绕这个需求严厉地、毫不留情地拷问我，一次只问一个问题，直到我们对设计树的所有分支、依赖和边界达成共识。"
这个技能的灵感来源于 Matt 读的一本书《The Design of Design》，其作者正是已故图灵奖得主、软件工程领域“圣经”《人月神话》的创作者布鲁克斯。书中提到：“所谓的软件设计，就是走完一棵树的所有分支，把选择一个个定下来。”
更有意思的是，Matt在这个拷问机制里埋了精妙的"防失控开关"。为了防止人类被问得精疲力尽，AI提问时必须附带一个它推导出的"最优推荐答案"，人类很多时候只需敲一个"Yes"就能快速定夺。
同时设了一条红线：如果在文档里找不到配置，且无法从本地代码库推导，AI必须立刻停止提问并向人类报告缺失。这直接解决了AI习惯性"瞎编API"的毛病。
这一过程中，为了解决AI表达冗余，污染上下文的问题，Matt 后来将该机制进一步升级为了 /grill-with-docs 技能，可通过多轮对话梳理生成专属 CONTEXT.md 领域字典，沉淀项目专属术语体系。既大幅节省 Token，又让 AI 精准理解业务语义，统一团队沟通语言。
当这种高强度拷问进行三四十分钟后，通常会产生海量上下文对话。
为了防止AI犯"长文本失忆症"，下一个技能 /to-spec （规格说明书） 登场。它能在瞬间将冗长的对话精简压缩，固化成一份不可篡改的技术规格书或 PRD 文件，作为后续代码生成的绝对“依据”。
当进入开发环节后， /to-issues 技能出场，给AI重新拆解任务。
以往 AI 拆解任务总喜欢水平拆分，先建数据库，再写接口，最后画前端。一旦中间出岔子，很容易全部崩盘。
而 /to-issues的神奇之处是强制 AI 采用垂直切片拆解模式：每一个任务都是可独立运行、可测试、可交付的完整业务单元，按需适配前后端、测试链路。它还会给任务打标签，哪些任务需要人盯着，哪些AI可以挂机自动写完，分得清清楚楚。
在写代码的过程中，为了防止AI作弊，先写实现再补测试，甚至伪造结果，保障代码质量的 /tdd （测试驱动开发） 技能就出场了。
它会强制AI 必须严格遵守“红-绿-重构”的铁律：必须先写测试，报错就亮红灯，直到让测试变绿为止，优化只能排在后面。一旦测试亮红灯，整个工作流当场熔断，没有商量余地。
在面对 AI 产出代码的速度实在太快、导致技术债变成屎山的问题时，Matt 设计了 /improve-architecture （垃圾清理器） 技能。
AI 会主动去找代码里隐藏的问题，每隔几天运行一次，检查命名有没有变形，顺手给臃肿的模块做个瘦身和解耦。
此外，还有像 setup-pre-commit 这样统一代码风格与提交规范的技能，和 Obsidian-Vault 这样整理知识库的技能，都在实战过程中十分好用。