前言

之前曾撰写过一篇关于利用 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+ 测试全部通过。当然这并不意味着每次都能如此，但至少说明前置澄清确实很有帮助。因为 grill-me 极其精简，所以能够把尽可能多的上下文空间留给后续逻辑，这一点本身就是巨大的优势。

怎么安装

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