最近很多人都在说卸载 Superpowers。这个曾经最火的 Claude Code 工作流框架，如今被不少人放弃：现在的模型越来越强，限制太严格的框架反而拖后腿。

我最近一直在用 Matt Pocock（Total TypeScript / AI Hero 作者）开源的一套 skills，仓库就叫 mattpocock/skills，思路很简单：小而精，需要哪个装哪个。

用了一段时间后发现，这套 skills 真正值得聊的是背后的设计哲学，功能反而是其次。从怎么对齐需求、组织工作流、对抗代码腐烂，一直延伸到怎么写好一个 skill 本身。

这篇文章从具体的 skills 讲起，最后落到这个设计哲学上。你不只是了解一套工具，也会知道怎么自己写出同等质量的 skill。

先从 /grill-me 开始。

/grill-me

你可能已经听过 /grill-me，它是整个仓库里最出圈的一个 skill。

AI Agent 最常见的问题是理解错位：没搞懂你想要什么就开始写代码，做出来的东西技术上正确，但完全不是你要的。

/grill-me 解决的就是这个。动手之前，Agent 会像一个不留情面的 tech lead，一个问题接一个问题地追问，沿着决策树的每条分支走，直到你们真正达成共识。

它不是只问不答，每次提问都会附上推荐答案，能通过读代码就回答的问题也不会来烦你。不过它也可能在小问题上问得事无巨细，不同模型表现不同。

在 /grill-me 基础上还有一个增强版 /grill-with-docs，边访谈边产出领域模型、架构决策记录（ADR）和 CONTEXT.md，把对齐成果沉淀成可复用的文档。如果项目已有代码库，可以先用 /domain-modeling 梳理领域概念和边界；/grill-me 则更适合从零开始，或对已有想法做压力测试。

这些 skill 的内容其实非常简单。/grill-me 就一句话：Run a /grilling session.，真正干活的是它背后的 /grilling，核心指令也很短，大意是"就此事的方方面面无情地采访我，直到我们达成共识"。一两句话就是一个 skill。至于为什么要拆成两个，讲到设计哲学时你就明白了。

反复用 /grill-me，你会慢慢内化"先对齐再编码"的习惯。这个习惯不用 Agent 也受益。

可组合的工作流

不少人还是喜欢类似 Superpowers 那样有完整流程的工作方式，但 Superpowers 太重也太严格了。Matt 这套 skills 提供了一个轻量的替代方案：一组可组合的节点，每个节点独立，按需跳过或重复，你随时可以介入。

/to-spec 把对话共识提炼成规格说明书，/to-tickets 再把 spec 拆成带依赖关系的工单。/implement 逐个落地，内部跑着 /tdd 的 red-green-refactor 循环。最后 /code-review 做双轴审查，一轴看代码质量，一轴看是否符合 spec。整个流程里，Agent 执行纪律，人做判断。

这套 Spec 工作流的完整实践，我之前单独写过一篇：停止让 AI 直接写代码，开始建立你的 Spec 工作流，感兴趣可以去看看。

/wayfinder

前面的流程图里你应该已经看到了这个 skill。它是这套 skills 1.1 版本新加的，我觉得也是整套工具里想象力最足的设计。

当你面对一个想法庞大、目标模糊、上下文窗口根本装不下的需求，/grill-with-docs 可能承接不住了：问题太多会没完没了，上下文太长又会丢失关键信息。

这时候就轮到 /wayfinder 出场了。Matt 本人说过："My new skill /wayfinder is letting me do stuff I've never considered trying."

它的核心隐喻是战争迷雾（fog of war）。玩过英雄联盟或王者荣耀就懂：开局整张地图都是迷雾，每走到一个地方，那一片就亮起来，直到全图可见。

/wayfinder 会在 issue tracker 上创建一份决策地图：一个父 issue 下面挂一系列子 ticket，类型有 Research、Prototype、Grilling、Task，每个都标注了阻塞关系，哪些必须先解决，哪些可以并行。

你逐个解决这些 ticket，迷雾一点点散开，路径一步步清晰。它还支持用 sub-agent 并行消化 research ticket。

我最近就在用它从零做一个语音转文字的 app。动手前我只有几个零散的想法，说不清要做成什么样，跟着 ticket 一个个聊下来，很多模糊的念头自己变清晰了，现在还在顺着这张地图继续打磨功能交互。

这和"先写一个大 spec 再执行"完全不同。传统方式假设你第一天就能做出所有正确的决策，但真正复杂的项目，这个假设本身就是错的。/wayfinder 接受不确定性，用渐进式发现代替一次性规划。

我觉得这个 skill 最厉害的地方在它背后的态度：你不需要一开始就想清楚，先走一步，走到哪里再决定下一步。

如果你的需求比较模糊、比较大，我强烈建议试试 /wayfinder。

/improve-codebase-architecture

Agent 写代码快，但也容易把项目变成一团泥。写得越快，架构腐烂得越快。

这个 skill 就是给腐烂踩刹车的：定期扫描代码库，找出重构机会，生成一份单文件的 HTML 报告，有卡片、before/after 对比图和推荐强度标注。分析优先看最近修改过的热点区域，不做全量扫描。

它背后有一套严格的共享词汇，定义在一个专门的 /codebase-design skill 里，供多个 skill 共用：module、interface、depth、seam 等等。每个词都有精确含义，不允许随意替换同义词。

最核心的概念是深模块（deep module） 。一个好的模块应该是"深"的，接口很小但能解锁大量行为。反过来，一个"浅"模块的接口几乎和实现一样复杂，用它并不能帮你简化什么。这个概念来自 John Ousterhout 的《软件设计的哲学》（A Philosophy of Software Design），Matt 把它直接编码进了 Agent 的判断标准。

怎么判断一个模块够不够深？Matt 用一个叫删除测试（Deletion Test）的方法：假设把这个模块删掉，逻辑摊回调用方，整体复杂度会不会暴涨？会，说明它真的封装了复杂度；几乎不变，说明复杂度本来就没被吸收，它是浅的。

发现候选重构点之后，它不会直接生成 PR，会先调用 /grilling 拉着你深入讨论一轮。

从代码设计到 skill 设计

Matt 在 /improve-codebase-architecture 里用深模块评判代码设计，但他没停在代码上，还把同一套思考推进到了一个新领域：给 AI 写的指令应该怎么组织？

这就是 /writing-great-skills，整个仓库里最被低估、但最值得细读的一个。它是一个写 skill 的 skill，不涉及任何具体工程任务，只告诉你一件事：如何写出可预测、可维护的 AI skill。

你仔细看就会发现，它和 /improve-codebase-architecture 在讲同一件事。

一个好 skill 就是一个深模块。你敲下的 /grill-me 是一个极小的接口，背后封装了决策树遍历、对齐检查、完成标准等大量行为。如果把每个内部步骤都暴露给用户，那它就是浅的。

Matt 在这里提出了几个概念，我挑最有价值的展开说。

上下文负担和认知负担

第一个是上下文负担和认知负担（Context Load vs Cognitive Load）。这可能是 AI 时代才有的新权衡。

将 skill 设计成模型自主调用（model-invoked），Agent 能自己判断什么时候用它，代价是 description 会常驻上下文窗口； 将 skill 设计成用户主动触发（user-invoked），上下文干净了，但你得记住它并手动调用。

常驻的上下文的代价比想象中要高。LLM 不是整个上下文窗口都一样好使，Matt 的说法是大约只有前 120k token 是 Smart Zone，模型在这个范围里才真正敏锐，超出就开始丢指令、前后矛盾。每多挂一个 skill，它的 description 就多占一块 Smart Zone。这就是 skills 装得越多、AI 越笨的底层原因。

当用户触发的 skill 多到记不住时，Matt 的解法是路由 skill（router skill）：一个同样由用户触发的 skill，列出其他 skill 的名字和各自的适用时机。你只需要记住这一个名字，认知负担就不再随 skill 数量增长。

/grill-me 也是同一种思路：它本身用户触发、零上下文占用，唯一的内容就是调用模型触发的 /grilling，行为只在一处定义。

复杂度从一个地方搬到另一个地方不算本事，好的设计是把它真正降下来。

引导词

然后是引导词（Leading Words），这个我特别喜欢。

模型在预训练中已经深刻理解某些词。与其反复写 "fast, deterministic, low-overhead loop"，不如直接用 tight 一个词搞定。与其三段话解释"渐进式探索未知领域"，不如用 fog of war。

说白了就是找到模型脑子里已经有的概念，直接激活它。前面 /wayfinder 的战争迷雾就是引导词的实践：省掉大量解释，模型的行为还更可预测。

渐进披露

还有渐进披露（Progressive Disclosure）。好的 skill 把内容按紧急程度分层：必须立刻执行的步骤放 SKILL.md 主体里，参考信息放后半部分，大块外部参考指向独立文件，需要时才加载。

这和深模块的核心思想一脉相承：模块的实现者应该主动承担复杂度，让使用者面对简单的接口。只不过在 skill 的场景下，"使用者"是模型，"复杂度"是 token 数量。

修剪

最后是修剪（Pruning）。skill 写出来不维护也会烂。Matt 分了四种烂法：沉积（Sediment，旧内容堆积没清理）、蔓延（Sprawl，越写越长失去焦点）、废话（No-Op，模型本来就会做的事你还要写一遍）、重复（Duplication，同一个意思多处出现）。

态度很简单：激进删除。如果你删了一段指令，模型的行为没变化，说明那段本来就是废话。你发现没，这就是 skill 版的删除测试。

读完 /writing-great-skills，这套 skills 为什么好用，你已经明白了。下一个好 skill，可以是你自己写的。

最后

想试试的话，一行命令装好：

 复制代码npx skills@latest add mattpocock/skills

先跑一次 /setup-matt-pocock-skills 配置你的 issue tracker 和文档位置。新项目从 /grill-me 开始，已有代码库可以先跑一次 /domain-modeling，复杂任务从 /wayfinder 开始。用你手头正在做的一个真实项目让它 grill 你一次。

你会知道它值不值得留下。