grill-me、Trellis、Superpowers：不同场景下怎么用？

前言

之前写过一篇关于用 Superpowers 打造靠谱 AI 开发工作流的文章，公司在正式交付场景里，Superpowers 确实稳。不过最近逛 L 站，发现不少人在讨论 grill-me 和 Trellis 这套组合。乍一看，这套方案更节省 token，也更轻量，但实际想了一圈之后，反而觉得这事没那么绝对。

这篇就想把这三个东西放在一起说清楚：它们到底是什么、项目里怎么用、怎么安装和组合、以及什么场景下该选谁。更想把它写成一篇使用判断，而不是纯教程。因为对大多数人来说，真正难的不是知道名字，而是搞清楚什么时候该用、怎么搭配、哪些时候根本不用上。

而且重点从来不是为了用 skill 而用 skill。真正重要的是，它能不能帮我们把需求校准得更准，把执行偏差压得更小。

先交代一个前提：实际干活的还是 Codex / Claude Code / Cursor 里的模型，grill-me、Trellis、Superpowers 只是让模型按不同 workflow 做事。区别不在于谁执行，而在于它按什么流程来执行。

先说结论

可以这么理解：

• grill-me 负责把需求问清楚
• Trellis 负责长任务执行和流程接力
• Superpowers 负责更重的正式交付流程

它们不是替代关系，更像是三种不同重量的工作方式。

更准确一点说：

• 小问题很多时候根本不用上 skill，直接裸对话就行
• 需求不清楚时，再用 grill-me
• 需求清楚但任务长时，再接 Trellis
• 任务大、协作重、要文档和审计时，再上 Superpowers

有一个前提需要先说清楚：有些任务本来就很小，硬套一套流程反而更麻烦，还浪费 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 安装的：

npm install -g @mindfoldhq/trellis

如果官方文档要求 beta 版本，就按文档版本安装。然后在项目目录里初始化：

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 介入

这里其实是很多人容易忽略的地方。写了这么久的 AI 开发，其实都能感觉到，不同模型写出来的代码质量是不一样的。有些模型需要反复复盘好几次，才能让它逐渐接近我们想要的结果；有些更强的模型基本一次就能过。但不管模型强不强，只要我们前面把需求说得太粗，AI 还是很容易理解偏。

尤其是开发功能的时候，如果只是简单说个目的就让它去干，它很可能会把“想做什么”理解成“怎么做”，最后出来的东西和我们真正想要的还是会差一截。所以这时候，grill-me 这类 skill 的价值就出来了——它不是替我们开发，而是帮 AI 把需求校准得更准一点。

在项目里怎么用

比如现在大多是在 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 极其精简，就几句话，几乎不占 context。它能把尽可能多的上下文空间留给后面的逻辑，这一点本身就是巨大的优势。grill-me 问得越细，后面的计划越清楚，执行时返工就越少——这点很实在。

Trellis 虽然是个完整框架，但它的 progressive loading（渐进式加载）设计让它实际用起来并不会特别占 token。它只在需要时加载相关 spec，不会一次性把所有内容塞进 context。小任务只加载小 context，大任务才加载大 context。

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 负责把正式流程兜住。真正重要的不是把工具都装全，而是知道什么时候该让哪个工具当主角。