你让 AI 给项目加个权限控制它唰唰改了四十多个文件跑起来却报空指针。你让它修它又牵出三个新 bug。你回头看它写的代码变量名长得像绕口令注释和代码说的是两回事。三个月后这个功能要改需求你盯着那一团代码根本不敢动。这不是你一个人的问题。mattpocock/skills那个 5 个月冲到 17 万 star 的仓库整本 README 就在掰扯这四类破事。一、作者亲手撤下招牌 skill不是打脸是点题一个 17 万 star 的仓库作者却把自己最火的 skill 从推荐位撤了。这事儿要放在别的网红项目上早被骂成自相矛盾割韭菜了。先抛规模参数。mattpocock/skills 创建于 2026-02-03截至 2026 年 7 月中旬star 数已经冲到 17 万170,525。一个 5 个月大的仓库能拿到这个数字在 AI 编码工具里属于现象级但码哥得补一句时间锚别写成绝对第一它只是这个窗口期里最猛的那个。170,525 这个具体数字放在任何 AI 工具仓库里都是头部但它涨得最猛的那段恰恰是 Matt 开始公开劝人别把 grill-me 当默认推荐的那几个月。作者 Matt Pocock 不是蹭热度的网红。他是 Total TypeScript 的作者TypeScript 教育圈的老面孔还运营着 aihero.devnewsletter 大概 6 万开发者订阅。这种人撤自己最火的 skill不会是手滑。决策背景写在 aihero.dev/skills-grill-me 那篇博客顶部的更新声明里原话是「I stopped using /grill-me for coding. I now recommend /grill-with-docs when you want to align a plan with your codebase before implementation.」现在更进一步默认推荐domain-model作为规划起点。表面看这是打脸。你一个 17 万 star 的招牌 skill自己不用了凭什么让别人用。但码哥读完整个仓库反而觉得这一撤点破了 AI 编码的正确姿势。skill 不是供起来的框架是随时该被替换、被 hack、被组合的一次性纪律。谁把一个 skill 供着不放谁就还没真正学会用它。当纪律的意思很具体你今天用 grill-with-docs 对齐下周发现 domain-model 更顺手就换不纠结不念旧。整篇文章就绕着「把 skill 当纪律不当框架」这个立场转。这八个字是它跟 GSD、BMAD、Spec-Kit 最根本的区别。二、它到底是什么跟那些「接管流程」的框架差在哪先把仓库说清楚它到底是个啥又为什么和那些「接管流程」的框架不是一路货。mattpocock/skills 的简介就一句「Skills for Real Engineers. Straight from my .claude directory.」README 里 Matt 的定位更直白「My agent skills that I use every day to do real engineering - not vibe coding.」翻译过来这是他每天真实在用的工程纪律不是玩具。Matt 是谁前面说了他的反框架立场也写得毫不客气。原文是「Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve.」这句话是本文的核心对立轴。GSD、BMAD、Spec-Kit 这类重量级框架思路是「我帮你把整套流程接管了」。听起来省心代价是你的控制权被拿走了流程本身出了 bug 你还很难修因为你是被流程裹挟的那个人。mattpocock/skills 走的是反面。设计哲学原文「These skills are designed to be small, easy to adapt, and composable. They work with any model. Theyre based on decades of engineering experience.」小、可改、可组合、跨模型、基于工程基础。你可能会说又一个 AI 编码 skill 集合罢了star 高不代表什么社区里每月都有新套装冒出来三个月后谁还记得。这个怀疑码哥完全理解17 万 star 里水分和跟风从来不少。但是你翻完它的失败模式分类和分层设计会发现它不是在堆功能是在把几十年的工程纪律翻译成 agent 能执行的指令。光是这一点就和那些「装上去就全自动」的框架拉开了身位。mattpocock/skills 全景图Engineering/Productivity 两大类 × User-invoked/Model-invoked 两种调用层代表 skill 一一列出仓库里的 skill 分两大块Engineering代码向和 Productivity通用工作流。按调用方式又能切成两层这一刀是全文最关键的洞察后面单独开一章讲。先记住一点它不要求你全装也不要求你按某个固定顺序走。三、4 大失败模式每个都有对症的修复这部分是工程师最容易直呼「就是这样」的地方。Matt 把 AI 编码的翻车现场归成四类每一类配一个修复 skill还特意引了工程经典书。码哥一个一个拆。1. 对不齐。The Agent Didnt Do What I Want。你以为你说清楚了AI 理解的是另一回事。修复叫 grilling session盘问非代码场景用/grill-me带共享语言加 ADR 用 /grill-with-docs。引的是 The Pragmatic Programmer 那句「No-one knows exactly what they want.」没人真的清楚自己想要什么所以得盘问得对齐不能指望一句话把需求交代明白。2. 太啰嗦。The Agent Is Way Too Verbose。20 个词说 1 个词的事变量名长到读不完。修复是共享语言也就是ubiquitous language落在CONTEXT.md里。引的是 Eric Evans 的《领域驱动设计》。Matt 给了个真例子把「课程某 section 里的 lesson 被 materialize在文件系统里获得位置」压成一个领域词「materialization cascade」。好处很实在变量、函数、文件命名一致代码库更好导航agent 思考还更省 token。这事儿内建在 /grill-with-docs 里README 里 Matt 说这可能是「the single coolest technique in this repo」。3. 跑不起来。The Code Doesnt Work。看着对跑就崩。修复是反馈回路静态类型、浏览器访问、自动化测试核心是 red-green-refactor先写失败测试再修。对应 skill 是/tdd和/diagnosing-bugsreproduce → minimise → hypothesise → instrument → fix → regression-test。引的还是 The Pragmatic Programmer「The rate of feedback is your speed limit.」反馈的速度就是你的速度上限。4. 架构烂成泥。We Built A Ball Of Mud。agent 加速了编码也加速了软件熵。修复是每天投资设计。skill 是 /to-spec改代码前先问你动了哪些模块和 /improve-codebase-architecture建议每几天跑一次救架构。引 Kent Beck 的《XP》「Invest in the design of the system every day.」再引 Ousterhout 的《软件设计哲学》「The best modules are deep.」AI 编码 4 大失败模式与对应修复 skill对不齐→grill-with-docs、太啰嗦→CONTEXT.md 共享语言、跑不起来→tdddiagnosing-bugs、架构烂→to-specimprove-codebase-architectureAI 编码 4 大失败模式与对应修复 skill对不齐→grill-with-docs、太啰嗦→CONTEXT.md 共享语言、跑不起来→tdddiagnosing-bugs、架构烂→to-specimprove-codebase-architecture四个模式里码哥见过最多人栽在 ② 和 ③。把「用户在下单后 15 分钟没付款订单进待关闭释放库存」这种长句甩给 agent它每次都重新翻译一遍命名能乱到亲妈不认。。。你不在项目里先立一套共享语言就别怪 agent 写出来的代码像拼凑的。四、两种安装哲学先想清楚你要哪种实操部分来了仓库给了两条安装路子哲学完全不同选错会很别扭。第一条skills.sh30 秒装完拿到的是可编辑副本。npx skillslatest add mattpocock/skills装完在 agent 里跑一次 /setup-matt-pocock-skills它会问你三件事用哪个 issue trackerGitHub / Linear / 本地文件triage 用什么标签文档存哪里。第二条Claude Code 插件只读、永远最新、订阅式。/plugin marketplace add mattpocock/skills /plugin install mattpocock-skillsmattpocock嫌打命令麻烦shell 里也行。claude plugin marketplace add mattpocock/skills claude plugin install mattpocock-skillsmattpocock然后每仓库跑一次 /setup-matt-pocock-skills。Codex 和其他遵循 Agent-Skills 标准的 agentskills.sh 安装器已经支持原生 Codex 插件还在路线图上。官方一句话总结了两种哲学的差异。skills.sh copies the skills into your project so you can hack on them and make them your own。The plugin keeps them as a read-only, always-current bundle you dont edit。前者把 skill 拷进项目你可以改改成自己的。后者是只读、常新的打包你别动。两种安装哲学对比skills.sh 可编辑副本 vs Claude Code plugin 只读订阅维度覆盖可修改性、更新方式、适用人群和安装命令码哥的判断先放这。没有两全其美的策略。想把它改造成团队规范就选 skills.sh只想蹭一套靠谱默认、跟着作者迭代就选 plugin。别一边用 plugin 一边手痒去改也别用 skills.sh 却从不维护那两份都白费。码哥的观察团队刚上手先用 skills.sh 更稳因为你迟早要改一两个 skill 去适配自己的 issue 流程和标签体系等全组跑顺了再切成 plugin 跟着上游走反而省维护。五、User-invoked 和 Model-invoked这是全文最关键的一刀前面说仓库按调用方式切两层这一刀值得单开一章因为它解释了为什么这套东西不会变成另一个失控框架。User-invoked用户调用。只能你亲手打出 /xxx 触发职责是「编排 orchestrate」。这一类包括 ask-matt路由帮你选该用哪个 skill、grill-with-docs、triage、improve-codebase-architecture、setup-matt-pocock-skills、to-spec、to-tickets、implement、wayfinderProductivity 那边有 grill-me、handoff、teach、writing-great-skills。Model-invoked模型调用。模型可以自动调用承载「可复用的纪律 discipline」。这一类有 prototype、diagnosing-bugs、research、tdd、domain-modeling、codebase-design、code-review两轴审查Standards 加 Spec跑成并行子 agent 互不污染、resolving-merge-conflictsProductivity 那边是 grillinggrill-me / grill-with-docs 背后那个复用循环。铁律原文「A user-invoked skill may invoke model-invoked skills, but never another user-invoked one.」编排层能调纪律层但编排层之间不互调。举个具体例子你打 /implement它内部去调 /tdd、/code-review 这些纪律层但 /implement 永远不会去调另一个编排层的 /to-spec。这条单向边让整条链永远从你手里发起不会自己长出新入口让 agent 乱窜。这铁律解决了一个真问题。很多框架失控是因为上层编排互相打架你调我我调你最后没人说得清当前到底在哪个状态。码哥见过团队用重框架状态机互相跳转debug 时要先搞清自己在哪个节点纯属内耗。mattpocock/skills 把编排权留在你手里纪律沉淀在模型可复用的层里层次干净。你只管打 /xxx剩下的纪律让 agent 自己按规矩跑。这一刀才是它和「接管流程」框架的分水岭。六、把整套东西焊进你自己的工作流光知道有哪些 skill 不够得串成链才能真正用起来。官方现在推荐的规划链是 domain-model → to-prd → to-issues → tdd。这条链把「想清楚」和「做对」用 skill 焊死了而不是靠你记性。README 里还有一条更完整的落地链码哥整合一下给你用。对齐用 /grill-with-docs 或 domain-model先把需求和代码库对齐。出规格用 /to-spec把意图落成可验证的规格。拆工单用 /to-tickets每个工单声明阻塞边blocking edge谁依赖谁写清楚。实现用 /implement它在预先约定的接缝处驱动 /tdd提交前用 /code-review 收尾。定期救架构用 /improve-codebase-architecture每几天跑一次别等烂透了再救。举个具体例子你接一个「导出报表」的需求。先 /grill-with-docs 把「报表」「导出」「分页」这几个词在 CONTEXT.md 里定死agent 之后不再把导出一会儿叫 dump 一会儿叫 export。再 /to-spec 落成规格/to-tickets 拆成「数据源查询」「格式渲染」「分页接口」三个工单标注后者阻塞前者。/implement 在每个工单的接缝处驱动 /tdd红测试先写绿了再提交/code-review 两轴过一遍。两周后你感觉架构有点散跑一次 /improve-codebase-architecture它只给建议不擅自改。mattpocock/skills 推荐落地工作流对齐 → 出规格 → 拆工单 → 实现(驱动 tdd code-review) → 定期救架构grill-me 现在的定位也清楚了当你只想要一次纯粹的高压盘问、还不需要完整 domain-model 流程时用它。它没被删只是从「默认推荐」退到了「特定场景工具」这正印证了开头的立场skill 该被替换、被降级、被组合而不是供着。七、中文项目、国内团队怎么落地最后给码哥读者一份能直接抄的落地清单单独成章是因为国内团队的坑和老外不一样。从哪几个开始。别一次全装。先装 grill-with-docs对齐加共享语言加 /tdd 加 /code-review 这三件套跑顺了再加 to-spec、to-tickets、implement。为什么先这三件套而不是别的。grill-with-docs 治的是「对不齐」tdd 治的是「跑不起来」code-review 治的是「写完没人卡」。三个正好覆盖最高频的翻车点等这套节奏你了然于胸再去碰 to-spec、to-tickets、implement 这种重编排的才不会一上来就被一堆 skill 晃晕。共享语言在中文项目同样成立。把冗长业务描述压成术语表放 CONTEXT.mdagent 命名、导航、省 token 全受益。举个中文业务的类比把「用户在下单后 15 分钟内未支付则订单进入待关闭状态并释放库存」压成一个领域词「超时释单」。四个字agent 从此统一口径不用每次重新翻译那句长话。码哥提醒一句术语表不是写完就完得有人值守业务词变了 CONTEXT.md 得跟着改否则 agent 又回到各说各话。issue tracker 国内多用 GitHub 或本地文件Linear 用得少setup 时按实际选别照抄官方默认。选安装方式。想改造成团队自己的规范上 skills.sh 可编辑副本只想蹭一套靠谱默认、跟着作者更新上 plugin。一句话立场收在这。把它当「纪律工具箱」用不要当「接管一切的框架」用。这正是它跟 GSD、BMAD、Spec-Kit 的根本分野也是 Matt 撤下 grill-me 真正想告诉你的事。FAQQ1mattpocock/skills 和 Spec-Kit、GSD 到底选哪个 A 看你要控制权还是省心。GSD/Spec-Kit 帮你接管流程代价是失控难修mattpocock/skills 把纪律拆小、可组合控制权在你。码哥的判断团队流程还没稳定的先用这种不接管的等纪律内化再考虑更重的框架。Q2grill-me 被撤了我还能用吗 A 能用只是不再是默认推荐。它现在定位是「纯粹高压盘问」的场景工具不需要完整 domain-model 流程时用。Matt 没删它是把它从推荐位降级这正是 skill 该有的样子。Q3中文项目用 CONTEXT.md 共享语言agent 真能懂吗 A 能而且收益比英文项目更明显。中文业务描述往往更长更绕压成术语表后agent 命名一致、思考省 token。关键是术语得全组统一写进 CONTEXT.md 让每个 session 都读得到。Q4skills.sh 和 plugin 能混用吗 A 不建议。skills.sh 是可编辑副本plugin 是只读订阅混用会导致同一 skill 两份来源、版本对不上。选一个跟到底。Q5Codex 用户现在能用吗 A skills.sh 安装器已支持 Codex 及其他遵循 Agent-Skills 标准的 agent原生 Codex 插件还在路线图上。先用 skills.sh 装。