前言
之前写过一篇关于用 Superpowers 打造靠谱 AI 开发工作流的文章，在公司项目开发里我用得更多的也是 Superpowers。
最近逛 L 站的时候，看到不少人在讨论 grill-me 和 Trellis 这套组合。刚开始我也觉得，这套方案看起来更节省 token，也更轻量。
但实际想了一圈之后，我反而觉得这事没那么绝对。
这篇就想把这三个东西放在一起说清楚：它们到底是什么、项目里怎么用、怎么安装和组合、以及什么场景下该选谁。
我更想把它写成一篇使用判断，而不是纯教程。因为对大多数人来说，真正难的不是知道名字，而是搞清楚什么时候该用、怎么搭配、哪些时候根本不用上。
而且我一直觉得，我们使用 AI 开发的重点不是为了用 skill 而用 skill。真正重要的是，它能不能帮我们把需求校准得更准，把执行偏差压得更小。
这里先说一个前提：实际干活的还是 Codex / Claude Code / Cursor 里的模型，grill-me、Trellis、Superpowers 只是让模型按不同 workflow 做事。区别不在谁执行，而在它按什么流程执行。
先说结论
我自己的理解是：
grill-me负责把需求问清楚Trellis负责长任务执行和流程接力Superpowers负责更重的正式交付流程
它们不是替代关系，更像是三种不同重量的工作方式。
更准确一点说：
- 小问题很多时候根本不用上 skill，直接裸对话就行
- 需求不清楚时，再用
grill-me - 需求清楚但任务长时，再接
Trellis - 任务大、协作重、要文档和审计时，再上
Superpowers
这里我想先把一个前提说清楚：
不是所有任务都值得上 workflow。
有些任务本来就很小，硬套一套流程反而更麻烦。而且还浪费 token，所以裸对话不是偷懒，而是某些场景下最省事的方式。
先把这三个东西讲明白
可能有同学已经比较了解 Superpowers 了，但对 grill-me 和 Trellis 还不太熟。这里我先大概讲一下它们都是什么。
grill-me 是什么
grill-me 本质上是一个需求澄清型 skill，来自 Matt Pocock 的 skills 仓库。
它最大的特点是极其轻量。整个 skill 就几句话，但效果出奇的好。
它最强的地方不是直接帮我们写代码，而是会一层一层把我们没想清楚的点逼出来。
我实际用下来，它经常会问得很细，细到我一开始没想到的边界条件、依赖关系、验收标准，都会被它提前拎出来。
我自己的一个案例里，用 grill-me 问一个复杂的项目级功能，它问了 20 多个问题，而 brainstorming 大概只问了 7-8 个。对比之下，grill-me 的提问都比较细致，属于抬杠式提问，比较喜欢扣细节，而 brainstorming 的问题就更注重核心工程问题。
grill-me询问过程:
brainstorming 询问过程：
我自己的一个测试项目里，最后 100+ 测试全过。当然这不是说每次都能这样，只是说明前置澄清确实有帮助。
因为它极其精简，所以能把尽可能多的上下文空间留给后面的逻辑，这一点本身就是巨大的优势。
怎么安装
最省事的方式是把仓库地址丢给 Claude Code 或 Codex，让它按 skill 的安装方式帮我们装。
怎么用
装好之后，在需要澄清需求的时候启动这个 skill 就行。在支持 skill 的工具里，可以通过 skill 选择器或自然语言触发；不同工具的触发方式不完全一样，核心都是一样的：它会开始连续追问，把我们的需求一点点问清楚。
问完之后记得让它把结果写入计划文档，然后清空上下文再执行，这样能保持最干净的执行环境。
Trellis 是什么
Trellis 更像一套项目级 workflow，来自 Trellis 仓库。
它不是单纯一个 skill，而是一个 npm CLI 加一套项目级文件，更像一个框架。它会把需求、任务、执行、上下文这些东西串起来，让长任务可以顺着一条比较稳定的路往下走。
它的核心优势是 progressive loading（渐进式加载），设计目标就是减少不必要的 context 占用。只在需要时加载相关 spec，不会一次性把所有内容塞进 context。
Trellis 的用法可以理解成：它不是替我们问需求的工具，而是把一个项目变成适合 AI 长期接力开发的项目。
它会在项目里维护这些东西：
.trellis/spec/- 项目规范、技术约定、编码标准.trellis/tasks/- 每个任务的 PRD、验收标准、状态、review 记录.trellis/workspace/- 个人工作日志、决策记录、handoff.trellis/workflow.md- 开发流程- 根据平台生成对应目录，比如
.codex/skills/（Codex）、.claude/skills/（Claude Code）、.cursor/（Cursor）等 AGENTS.md或CLAUDE.md等 - 给对应平台的项目入口说明
所以它和 grill-me 的关系是：
- grill-me：把这次要做什么问清楚
- Trellis：把问清楚的内容沉淀成任务，然后按流程执行、检查、收尾
比较顺的组合方式就是这样。
怎么安装
Trellis 是通过 npm 安装的：
bash
npm install -g @mindfoldhq/trellis如果官方文档要求 beta 版本，就按文档版本安装。
然后在项目目录里初始化：
bash
trellis init --codex -u kaka初始化时会问我们用的平台（Codex、Claude Code、Cursor 等），然后生成对应的文件结构。具体生成哪些文件取决于我们选择的平台。
怎么用
按 Trellis 文档的说法，0.5 之后更偏 skill-first。在支持的平台里，可以用类似 /start 或 /trellis:start 的方式加载项目上下文，不同平台触发方式不完全一样。
加载后，它会根据当前任务自动加载相关的 spec 和上下文，而不是一次性把所有东西都塞进来。
Superpowers 是什么
这里我就不再重复说明了，还不了解的可以参考我之前写的这篇文章：Claude Code进阶：用Superpowers打造靠谱的AI开发工作流。
简单来说，Superpowers 更重。它不是只盯着问清楚或者跑起来，而是把 brainstorming、plan、execute、test、review 这些步骤都纳进来，形成一套更完整的交付流程。
这也是为什么它在公司正式交付里反而很合适。因为很多时候我们需要的本来就不是最快写完，而是让别人能看懂、能对齐、能 review、能追踪。
我会把它理解成一种更完整的工作法。它的优点是稳，尤其适合新手、复杂协作、需要可追踪计划的任务。它的问题也很明显：上下文占用多、流程感重、启动慢，有时候会让模型花太多精力在遵守方法论上，而不是直接理解任务。
所以我不会把它简单归类成太重不好用。更准确地说，它是偏治理复杂度的，而不是偏单点提效的。
为什么需要让 skill 介入
我觉得这里是很多人容易忽略的地方。
在写Superpowers文章的时候我也说过，我们用了这么久 AI 开发，其实都能感觉到，不同模型写出来的代码质量是不一样的。
有些模型我们需要反复复盘好几次，才能让它逐渐接近我们想要的结果；有些更强的模型基本一次就能过。
但不管模型强不强，只要我们前面把需求说得太粗，AI 还是很容易理解偏。
尤其是我们在开发功能的时候，如果只是简单说一个目的就让它去干，它很可能会把想做什么理解成怎么做，最后出来的东西和我们真正想要的还是会差一截。
所以这时候，grill-me 这类 skill 的价值就出来了。
它不是替我们开发，而是帮 AI 把需求校准得更准一点。
这也是我前面那句话想表达的意思：
不是为了用 skill 而用 skill，而是因为它能帮我们把需求校准得更准、把执行偏差压得更小。
在项目里怎么用
比如我现在大多是在 Codex 里面进行开发的，所以我更愿意这么理解它们：
用 grill-me 的时候
我会先让它把需求盘清楚，先别急着写代码。它适合拿来做前置澄清，尤其是我自己也还没完全想透的时候。
如果问我 grill-me 最适合什么时候用，我会说：
- 我还没完全想透需求
- 我担心漏掉边界
- 我希望先把问题问完整
- 我不想一上来就开始写
它的优势不是能做更多，而是先把问题问准。
用 Trellis 的时候
当需求已经比较清楚了，但后面还有一段比较长的执行过程，我就会考虑让 Trellis 接上。它更像把前面问清楚的东西，变成一个能持续推进的任务。
我会把它理解成长程执行器。前面如果已经把目标、边界、约束弄清楚了，那 Trellis 就适合接着跑。
所以它不是拿来替代思考的，而是拿来承接思考后的执行的。
用 Superpowers 的时候
如果是公司里的正式交付，我反而更倾向直接走 Superpowers。因为这种场景本来就要求文档、对齐、review、提交说明，流程重一点不是缺点，反而是必要的。
这也是我后面越来越认可它的地方。在公司场景里，很多时候不是写出来就完了，而是还要让领导大概能看懂，让同事能对齐，让 review 能过，让交付能说清楚。
所以它的重，不只是重在步骤多，而是重在把很多隐性的东西显式化了。
小任务的时候
如果只是改一个 bug、补一个函数、调一下小逻辑，我通常连 skill 都不想开。直接裸对话、直接做，反而最省事。
这点我想单独拎出来，因为它很容易被忽略。
很多人一上来就想找一个最强工作流，但实际开发里有相当一部分任务根本没必要上 workflow。小任务最怕的不是能力不够，而是流程太厚。
grill-me + Trellis 实际怎么配合
比如我接到一个需求，通常不会直接让 AI 开干，而是先用 grill-me 盘问一轮。
grill-me 会先把目标、边界、非目标、验收标准这些东西问清楚。问完之后，我会让它把结果整理成一个简短的需求摘要或者 plan。
确认完之后，再把这份确认结果交给 Trellis，让它接着按项目流程往下跑：
- 读取项目上下文
- 加载相关 spec
- 开始实现
- 跑测试
- 做 review
- 最后输出提交说明
这样做的好处是，前面把需求问准了，后面就不容易跑偏。
我自己的感觉是，grill-me 问得越细，后面的计划越清楚，执行时返工就越少。这点很实在。
而且因为 grill-me 极其精简，它不会占用太多 context，所以后面 Trellis 接手的时候，还有足够的空间去加载项目 spec 和执行逻辑。
安装不等于冲突
我看到有同学说，那我安装了 grill-me 和 Trellis 是不是就要卸载 Superpowers？反之也是？不能共存会冲突？
这几个东西可以同时装，通常不会冲突。真正容易出问题的，不是安装，而是同一轮任务里同时启用多个流程。
我觉得这一点特别值得写清楚，因为很多人会把同时安装和同时使用混在一起。
- 安装是静态的，互不影响
- 使用是动态的，容易互相抢节奏
真正混乱的不是我们装了谁，而是这一轮到底按谁的流程走。
比如我们又让 Superpowers 进 brainstorming，又让 grill-me 连续追问，又让 Trellis 接管执行，就会出现流程重叠：
- 问题重复
- 计划过度冗长
- 执行前迟迟不动手
- review / plan / execute 边界混乱
- 上下文被流程说明占掉太多
所以更好的方式是都装，但按场景只主动点名一个主流程。
我会这样分：
- 小任务：不用 skill，直接做
- 需求不清楚：用 grill-me
- 需求问清楚后要长时间执行：用 Trellis
- 高风险 / 复杂协作 / 需要规范计划：用 Superpowers
如果想组合，最好是分两轮：
- 先用 grill-me 问清楚需求
- 再明确说基于刚才的澄清结果，用 Trellis 执行
而不是一上来就把三个一起丢进去。
我会比较推荐这种思路：
- 先定主流程
- 再让其它工具做辅助
- 不要让多个 workflow 在同一阶段争夺主导权
为什么 grill-me + Trellis 会显得更轻
我觉得这套组合轻，主要是因为它把工作拆成了两段：
- 先把需求问准
- 再让执行器长跑
它不要求每个任务都走一套很厚的流程，所以更适合高频日常开发。
从 token 消耗的角度来看，这个差异会更明显：
grill-me 的 token 消耗
grill-me 极其精简，就几句话，几乎不占 context。它能把尽可能多的上下文空间留给后面的逻辑，这一点本身就是巨大的优势。
我自己的感觉是，grill-me 问得越细，后面的计划越清楚，执行时返工就越少。这点很实在。
Trellis 的 token 消耗
Trellis 虽然是个完整框架，但它的 progressive loading（渐进式加载）设计让它实际用起来并不会特别占 token。
它只在需要时加载相关 spec，不会一次性把所有内容塞进 context。小任务只加载小 context，大任务才加载大 context。
Superpowers 的 token 消耗
Superpowers 的每个步骤都有独立的 prompt：
/brainstorming有自己的 prompt/writing-plans有自己的 prompt/verification-before-completion有自己的 prompt
这意味着：
- 优点：每个环节都有专业指导，质量有保障
- 缺点：如果每次都按完整流程走，小任务也会显得 token 成本偏高
所以从 token 效率来看：
- grill-me + Trellis：按需加载，轻量高效
- Superpowers：全流程覆盖，token 消耗大
这也是为什么 L 站上很多人会觉得 grill-me + Trellis 这套组合更适合日常开发。
但这不是绝对的
我觉得 grill-me + Trellis 更轻、Superpowers 更重这个说法，大体是对的，但不是绝对的。
更准确地说：
- grill-me + Trellis 更轻，因为它把工作拆成两段：先把需求问清楚，再让执行器长跑
- Superpowers 更重，因为它把计划、执行、测试、review 这些都纳进一个更完整的流程里，前置成本更高，token 也更容易花掉
所以 L 站上那种 Superpowers 太重了，轻量开发用 grill-me + Trellis 这个判断，对大多数个人开发场景是成立的。
但我还是觉得：
- 轻量 ≠ 更好
- 重流程 ≠ 更差
它们只是适合不同任务。
为什么 Superpowers 会显得重
因为它默认把很多步骤显式化了。
比如 brainstorming、plan、execute、test、review 这一套，放在复杂任务里很好用，但放在一个小 bug、一个小功能上，就会显得有点重。
所以我不太觉得它重是坏事。它只是更适合需要治理复杂度的场景。
现在模型本身已经很强了，很多时候我们缺的不是让它能做事，而是让它别带着错误假设就开工。
这也是为什么 grill-me 会有价值。它只做最关键的前置动作：把需求问清楚。不会像 Superpowers 那样把整个流程都压上去。
换句话说，Superpowers 的价值不只是让 AI 能做事，而是让 AI 按一个更稳定、更可审计的方式做事。
怎么分场景
我自己的分法很简单：
- 需求模糊，但任务不大：grill-me
- 需求问清楚后，要长时间改代码：grill-me + Trellis
- 任务大、风险高、需要审计和对齐：Superpowers
- 只是改个小 bug，补个函数：都不用，直接做
比如在我们公司，每个功能都需要写文档、三方对齐、需求评审、code review、提交说明。领导需要了解每个功能的变动、新增、逻辑交互这些。
这种情况下，我会更倾向用 Superpowers。因为它能把这些流程要求都兜住：
- brainstorming 阶段可以产出需求文档
- plan 阶段可以产出技术方案
- review 阶段可以产出 code review 记录
- 提交说明可以从整个流程里自动生成
所以在公司正式交付里，Superpowers 不一定重得多余，反而是刚好。
这也是我最后会倾向的结论：
轻量开发，grill-me + Trellis 更顺。
正式交付，Superpowers 更稳。
最后想说的
我觉得 L 站上那种 Superpowers 太重了，轻量开发用 grill-me + Trellis 这个说法，大体是对的。但它隐含了一个前提：我们追求的是效率和手感，而不是全流程治理。
而在公司正式交付里，很多时候我们本来就需要流程。这种情况下，Superpowers 不一定重得多余，反而是刚好。
所以我现在更倾向于把这三者看成不同场景下的工具：
- grill-me 负责问清楚
- Trellis 负责接着跑
- Superpowers 负责把正式流程兜住
真正重要的不是把工具都装全，而是知道什么时候该让哪个工具当主角。