Grill-me、Trellis、Superpowers三大场景实测对比

场景概述

此前我撰写过一篇关于利用 Superpowers 构建高效 AI 开发工作流的实践分享，在公司的正式交付场景中，Superpowers 的稳定性得到了充分验证。但近期在 L 站上注意到，不少开发者开始频繁讨论 grill-me 与 Trellis 的组合方案。表面看来，这套搭配更为节省 token，也更轻盈灵活。然而深入思考后发现，结论未必如此简单。

本文旨在将这三个工具放在同一坐标系下讲透：各自的定位、适合的项目阶段、安装与组合方式，以及不同场景下的选择依据。与其写成一篇纯教程，我更希望把它写成一则使用判断指南。对于多数开发者来说，真正的难点不在于记住名称，而在于判断何时启用、如何搭配、以及哪些场景根本无需依赖。

核心原则始终是：使用 skill 不是为了炫技，而是为了将需求校准得更精确，将执行偏差压到更低。

先厘清一个前提：真正负责代码编写的仍然是 Codex / Claude Code / Cursor 背后的模型，grill-me、Trellis、Superpowers 只是指导模型按特定工作流程去执行。差异不在于谁来执行，而在于按什么样的流程来执行。

结论先行

用一句话概括各自的职责：

• 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 会先将目标、边界、非目标、验收标准等要素问清楚。问完之后，让它将结果整理成一个简洁的需求摘要或计划。确认无误后，再将这份确认结果交给 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 负责将正式流程兜住。真正重要的不是把所有工具都装全，而是知道在哪个场景下该让哪个工具当主角。