Trellis 比 superpowers 更强？扒完两个仓库，发现它们根本不在一个抽象层

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 159 篇，AI 编程最佳实战「2026」系列第 49 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

Trellis 与 superpowers 源码对比信息图封面

最近在翻 AI 编程增强框架的资料，看到一种说法开始在小圈子里流传：Trellis 比 superpowers 更强。

说实话刚看到这个结论我是有点警惕的。两个项目我都装过、读过 README，它们长得根本不像同一类东西。一个往你仓库里塞一坨目录，另一个装个插件就完事，怎么比？

光看官方文案不算数，这种事得扒源码。我把两个项目的本地仓库都拉下来通读了一遍——Trellis 的 commit 在 2026-07-07，superpowers 在 2026-07-05（v6.1.1）。结论是：那个"更强"的说法，对了一半，也错了一半。

下面把扒到的东西摊开来。

说明：本文基于 Trellis（mindfold-ai/Trellis，commit at 2026-07-07）和 superpowers（obra/superpowers，v6.1.1，commit at 2026-07-05）两个项目的本地源码分析整理而成，所有目录结构、文件数量、机制描述均以源码为准。文章只做了源码层面的静态分析，没有在真实项目中跑完整开发流程做对比验证，文中对"哪个更适合什么场景"的判断属于基于源码证据的推理，实际选型请以你自己的项目环境和试用结果为准。 如果你有 Trellis 或 superpowers 的实际使用经验，欢迎在评论区分享交流。

1. 先说结论：这俩根本不在一个赛道

网上很多对比文章把 Trellis 和 superpowers 当成"同类型竞品"放一起打分，这就掉进了头号陷阱。源码层面看，它们连抽象层都不一样。

Trellis 的 README 把自己定位成：

An out-of-box engineering framework for AI coding

关键词是 engineering framework（工程框架）。superpowers 的自我定位是：

A complete software development methodology for your coding agents, built on top of a set of composable skills

关键词是 methodology（方法学）+ skills。

这俩词听着都虚，落到代码上区别就很硬了：

一句话：Trellis 是"重资产工程框架"，superpowers 是"轻提示方法学"。说"Trellis 更强"前，得先问一句——强在哪条赛道上。

Trellis 目录树与 superpowers 扁平 skill 结构对比

图 1：左侧 Trellis 的 .trellis/ 目录（7 类持久化资产），右侧 superpowers 的 14 skill + 1 hook 扁平结构——两种完全不同的工程哲学

2. Trellis 到底是什么：拆开 .trellis/ 看

光看 README 容易被营销话术带跑。真要理解 Trellis，得看 trellis init 之后仓库里多了什么。

2.1 一个目录，六类资产

.trellis/
├── workflow.md          # 708 行的工作流"宪法"
├── config.yaml          # 项目级配置
├── spec/                # 按 package/layer 组织的项目规范（人 + AI 共写）
├── tasks/               # 每个任务一个目录：prd.md / design.md / implement.md / *.jsonl
├── workspace/           # 按开发者分的 session 日志（journal-N.md）
├── agents/              # 子代理定义：architect / check / implement / plan / research
└── scripts/             # Python 脚本：task.py / get_context.py / add_session.py

这 7 类资产是 Trellis 跟 superpowers 最本质的区别。它把"规范、任务、记忆"作为持久化资产写进仓库。superpowers 用完即走，啥都不留。

2.2 那 708 行的 workflow.md

这不是普通文档。它定义了三个 Phase 的状态机：

Phase 1: Plan    → 分类请求、获取建任务许可、产出规划产物
Phase 2: Execute → 仅在 task.py start 之后才开始改码
Phase 3: Finish  → 验证、回写 spec、提交、归档

注意这跟 README 对外宣传的"四阶段循环 Plan → Implement → Verify → Finish"不是一回事。README 那套是对外话术，把 implement/check/update-spec 这三个子代理调用包装成"阶段"。workflow.md 内部才是运行时状态机本体，三个 Phase 之间靠 task.py start 和 task.py archive 做状态迁移。读源码的时候要把这两层分清楚，不然会被命名绕晕。

真正贯穿这套状态机的是 [workflow-state:STATUS] breadcrumb 契约。每轮对话开始，hook 都会注入一段提示，告诉 AI 当前处于哪个阶段、下一步该干嘛。这是逐轮对话里仅有的信号源，没有别的 fallback，hook 脚本只解析这些 tag。

⚠️ 这里有个坑：breadcrumb 协议完全依赖 hook 注入。如果你用的平台不支持 hooks（比如 Antigravity 很保守），整个工作流就瘸了。源码里 Antigravity configurator 是有的，但 README 自己也隐晦提到了这一点。

Trellis workflow.md 三阶段状态机与 breadcrumb 注入机制

图 1：Trellis 的 workflow.md 内部状态机——三个 Phase 靠 task.py start / archive 做状态迁移，workflow-state:STATUS breadcrumb 是每轮对话里仅有的信号源

2.3 两个被低估的子系统：mem 和 channel

Trellis 真正的杀手锏藏在 packages/core/src/ 下面，README 里几乎没宣传。

mem 子系统——跨会话记忆检索。不是简单的 grep，里面有：

• phase.ts：按工作流阶段过滤
• filter.ts：按来源/角色过滤
• dialogue.ts：把原始 session 转成干净对话
• CLI 入口：trellis mem list / search / context / extract / projects

channel 子系统——多 worker 协作。trellis channel spawn 能起独立 worker，config.yaml 里有 worker_guard（idle_timeout: 5m、max_live_workers: 6）做 OOM 防护。这块在多代理并发场景下是真有用的。

superpowers 这两块完全没有对应物。不是夸大，源码摆在那儿。

2.4 20 个 configurator：一份配置，多平台复用

packages/cli/src/configurators/ 下数了数，正好 20 个文件：antigravity、claude、codebuddy、codex、copilot、cursor、devin、droid、gemini、kilo、kiro、opencode、pi、qoder、reasonix、trae、zcode……

每个 configurator 干一件事：把同一份 .trellis/ 结构翻译成对应平台能识别的 hooks/commands/agents 配置。这是 Trellis 宣传的"支持 16 platforms"的真实落点（README 写 16，实际 20 个文件）。

3. superpowers 到底是什么：14 个 skill + 1 个 hook

把镜头切到 superpowers 这边，画风完全变了。

3.1 skill 清单（截至 v6.1.1）

brainstorming                   # 苏格拉底式设计细化，HARD-GATE：不画完图不准写码
writing-plans                   # 把设计拆成 2-5 分钟一个的可执行任务
executing-plans                 # 批量执行计划，带人类 checkpoint
subagent-driven-development     # 当前 session 内每任务一个 fresh 子代理 + 两阶段评审
dispatching-parallel-agents     # 并发子代理工作流
using-git-worktrees             # 隔离工作树开发
test-driven-development         # RED-GREEN-REFACTOR
systematic-debugging            # 4 阶段根因分析
verification-before-completion  # 声称完成前必须跑验证
requesting-code-review          # 评审前置清单
receiving-code-review           # 收到评审后的回应纪律
finishing-a-development-branch  # merge / PR / 丢弃决策
writing-skills                  # 写新 skill 的规范
using-superpowers               # 启动时注入的 bootstrap 元 skill

14 个，没多没少。

3.2 触发机制：靠 description 里的强约束措辞

superpowers 只有一个 hook：hooks/hooks.json 注册了 SessionStart，触发后把 using-superpowers skill 注入对话开头。之后所有 skill 触发完全靠 AI 自主判断。

打开任意一个 SKILL.md 看 description，你会看到大量这种措辞：

YOU ABSOLUTELY MUST invoke the skill.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE.

这种"1% 可能就要触发"的强约束写法，本质上是把纪律塞进 prompt。AI 听不听是另一回事，但每轮对话它都被提醒一遍。

这套机制的特征很鲜明：没有运行时脚本，不往仓库里塞文件，也不维护任何持久化状态。装完插件就用，卸了就走，仓库一个字不改。

Trellis hook 物理注入与 superpowers description 行为约束对比

图 2：Trellis 的 hook 物理注入 spec 文件 vs superpowers 的 description 行为约束——前者 AI 不用记得，照着上下文执行；后者靠 AI 自觉读规则

3.3 SDD：v6.0 重写的核心

v6.0（2026-06-16）的核心改动是重写了 SDD（subagent-driven-development）。RELEASE-NOTES 里的原话大致是：在他们的 eval 场景下，Claude Code 和 Codex 能在相近质量下跑得更快、token 也省不少。具体数字官方写的是"速度快约 2 倍、token 省约 50%"，但这种自测数据别太当真，知道方向就行。

流程大概是：

1. 读计划 → 建全局 todo
2. 每个任务 dispatch 一个 fresh implementer 子代理
3. implementer 自评后写 diff 文件
4. dispatch task reviewer 子代理做两阶段评审（spec 合规 + 代码质量）
5. 不通过就 dispatch fix 子代理，循环
6. 全部任务完成后，dispatch final code reviewer 做整分支评审
7. 进入 finishing-a-development-branch 决策合并/PR/丢弃

关键设计是continuous execution——任务之间不暂停问人，除非 BLOCKED 或全完成。这对"无人值守跑长任务"很关键。

v6.1.0（2026-06-30）的轻量化改进也值得提一句。压缩了 using-superpowers bootstrap：删掉 graphviz 图、折叠 Instruction-Priority 段、删冗余的 tool-mapping 表，主要省的是每 session 的 token 开销。同时移除了 Gemini CLI 支持（Google 把它 EOL 了），Codex 也不再装 SessionStart hook——Codex 自己会触发 skill，hook 反而让 UX 更差。紧接着 v6.1.1（2026-07-02）修了 v6.1.0 引入的 Codex hook 回退 bug。

4. 现在回到正题："更强"到底强在哪

把参考文章里的论据和源码对照一下，"Trellis 更强"的说法主要集中在四个点。

4.1 项目记忆（最硬的论据）

superpowers 在 README 哲学部分只字未提"记忆"或"跨 session"。Trellis 的 workspace/journal-N.md + mem SDK 是结构化的、可检索的、跨开发者的记忆层。

这一点证据非常硬。Trellis 有完整的 packages/core/src/mem/ 子系统，superpowers 没有任何对应物——每个 session 从零开始，靠 skill description 提醒。

适用场景：长期维护一个项目、多人协作、需要"上次做到哪了"的连续性。这种场景 Trellis 明显更强。

4.2 规范注入 vs 行为约束

这是个有意思的对比：

• superpowers 的 skill 是行为约束："你必须先 brainstorm"、"你必须先写测试"——靠 AI 自觉读 description
• Trellis 的 spec 是上下文注入：hook 把 .trellis/spec/ 里相关的规范文件物理注入到子代理 prompt 里——AI 不用记得，照着上下文执行就行

后者更工程化，前者更轻。哪个更强，取决于你信不信 AI 会自觉读规则。

说实话，从可控性角度看，物理注入比行为约束靠谱。但代价是 Trellis 要维护那堆 spec 文件、要写 hook、要配 .trellis/，复杂度上去了。

4.3 任务/PRD 持久化

Trellis 的 task.py 是一个真正的状态机：

planning → in_progress → completed → archived

配合 implement.jsonl / check.jsonl 这两个上下文清单，任务可以跨 session、跨平台 resume。

这套机制的关键细节：清单在任务创建时播种，brainstorm 阶段由 AI curate 真正需要的 spec/research 文件进去。子代理被 dispatch 时，hook 自动把清单里引用的文件注入到子代理 prompt 里。这就是 Trellis"AI 不靠记忆、靠注入"的落地方式。

superpowers 的 writing-plans 产出文档后就不管了，没有运行时跟踪。

什么场景下占优：那种要跑好几天、跨 session 还得 handoff 的复杂任务。Trellis 在这块明显更有抓手。

4.4 多平台一份配置复用

Trellis 的 20 个 configurator，让同一份 .trellis/ 能翻译成各平台配置。superpowers 是每个 harness 单独装一次插件。

如果你团队里 Claude Code、Cursor、Codex 混用，Trellis 这种"一份配置复用"的价值就出来了。但如果你只用一个平台，这个优势约等于零。

5. 但"更强"在五个地方站不住

把视角反过来。源码同样能证伪"Trellis 全面碾压"。

5.1 学习和部署成本

Trellis 要 Node ≥18 + Python ≥3.9，要全局装 npm 包，要在每个项目里 trellis init，要团队共识把 .trellis/ 进 git。

superpowers 一行 /plugin install 完事，仓库零侵入。

对个人开发者、临时项目、不想给仓库加文件的人，superpowers 完胜。差距不是一点半点，是能不能用起来的差距。

5.2 TDD 和调试纪律

superpowers 有两个专门的 skill：

• test-driven-development：RED-GREEN-REFACTOR，措辞极强，删掉先写的代码
• systematic-debugging：4 阶段根因分析

Trellis 的 trellis-check 子代理虽然跑 lint/test，但 workflow.md 里对测试的描述是"能跑就跑"，不是"先写测试再写码"。没有强制 TDD 流程。

对信仰 TDD 的人，superpowers 的纪律性更强。这一点不是立场问题，是源码里白纸黑字的事实。

5.3 SDD 的工程化成熟度

superpowers v6.0 重写的 SDD 有完整的 implementer-prompt.md / task-reviewer-prompt.md / code-reviewer.md 三件套，还有独立的 eval 体系（superpowers-evals 仓库），公开跑评测。

Trellis 的子代理定义在 .trellis/agents/*.md 里（architect / check / implement / plan / research 共 5 个），分工更细，但每个 agent 的 prompt 比 superpowers 简单，也没有公开的 eval 数据。

对追求"每个子任务都有量化质量基准"的人，superpowers 更扎实。

5.4 License

Trellis 是 AGPL-3.0——网络使用即触发源码公开义务。企业落地时法务一定会问，这是个绕不开的硬门槛。

superpowers 是 MIT，企业可以直接拿去改、闭源商用。

这一点对个人开发者无所谓，但对企业采用是决定性的。AGPL 这个 License 选型，注定了 Trellis 在企业市场会比较难推。

5.5 生态和作者可信度

superpowers 作者 Jesse Vincent 是 Request Tracker（RT）的作者、Perl 社区老人、Anthropic 外部合作者。仓库有完整的 RELEASE-NOTES（84KB）、贡献者指南、eval 体系、commercial support。

Trellis 背后是 Mindfold 公司，文档站 docs.trytrellis.app，商业模型更"产品化"，但社区历史短。

这点见仁见智，但生态成熟度上 superpowers 占优。

Trellis 与 superpowers 六维能力对比雷达图

图 4：六个维度对比——Trellis 在记忆/规范/任务/多平台占优，superpowers 在成本/TDD/SDD/License/生态占优，谁也没压倒谁

6. 分维度结论：别问谁更强，问你的场景

把上面所有维度汇总，做成一张表：

7. 我的判断

参考文章里说"Trellis 比 superpowers 更高一层"，这句话在源码层面成立——Trellis 多了记忆、spec 沉淀、任务状态机、多平台适配，确实是"更高一层"的抽象。

但"更高一层"不等于"全面更强"。

抽象层越高，约束、侵入、License 限制、学习成本都会跟着上来。superpowers 选择留在"轻量方法学"这一层，换来的是零侵入、MIT、装完就用、TDD 纪律硬。这不是输给 Trellis，是另一种设计权衡。

具体到选型，我的建议是：

• 个人开发者、临时项目、信仰 TDD：superpowers。轻、纪律硬、License 干净
• 团队工程化、长期项目、多平台混用：Trellis。记忆和 spec 沉淀的价值在这类场景才会兑现
• 企业落地、有法务审核环节：先确认能不能接受 AGPL，否则 superpowers 是更稳的选择
• 两个都用：完全可行。superpowers 装在个人 IDE 里约束自己的工作习惯，Trellis 跑在团队项目里做工程沉淀。两者不冲突

收尾再说一句：别被"更强"这种话术带节奏，扒源码、对场景、看 License，比看 README 强一百倍。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！