Trellis 与 superpowers 源码对比信息图封面
最近在翻 AI 编程增强框架的资料，圈子里开始流传说——Trellis 比 superpowers 更强。说实话，刚听到这个结论时，心里是打了个问号的。两个项目都装过、也都读过 README，它们长得根本不像同一类东西。一个往你仓库里塞一坨目录，另一个装个插件就完事，这怎么比？
光看官方文案不算数，这种事得扒源码。把两个项目的本地仓库都拉下来通读了一遍——Trellis 的 commit 在 2026-07-07，superpowers 在 2026-07-05（v6.1.1）。结论是：那个“更强”的说法，对了一半，也错了一半。
下面把源码分析的结果摊开来。
1. 先说结论：这俩根本不在一个赛道
网上很多对比文章把 Trellis 和 superpowers 当成“同类型竞品”放一起打分，这就掉进了头号陷阱。从源码层面看，它们连抽象层都不一样。
Trellis 的 README 把自己定位成：engineering framework（工程框架）。superpowers 的自我定位是：methodology（方法学）和 skills。这俩词听着都虚，但落到代码上区别就很硬了：
| 维度 | Trellis | superpowers |
|---|---|---|
| 核心资产 | .trellis/ 目录（spec/tasks/workspace/agents/scripts） |
14 个 SKILL.md + 1 个 bootstrap hook |
| 是否进客户仓库 | 进，git tracked，团队共享 | 不进，插件目录，个人安装 |
| 运行时依赖 | Node ≥18 + Python ≥3.9，CLI + Python 脚本 | 零运行时脚本，纯 Markdown |
| License | AGPL-3.0 | MIT |
| 主要语言 | TypeScript CLI + Python 脚本 | Shell + Markdown |
一句话：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。
Trellis workflow.md 三阶段状态机与 breadcrumb 注入机制
图 2：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 个文件：antigra vity、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 HA VE A CHOICE.
这种“1% 可能就要触发”的强约束写法，本质上是把纪律塞进 prompt。AI 听不听是另一回事，但每轮对话它都被提醒一遍。
这套机制的特征很鲜明：没有运行时脚本，不往仓库里塞文件，也不维护任何持久化状态。装完插件就用，卸了就走，仓库一个字不改。
Trellis hook 物理注入与 superpowers description 行为约束对比
图 3：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%”，但这种自测数据别太当真，知道方向就行。
流程大概是：
- 读计划 → 建全局 todo
- 每个任务 dispatch 一个 fresh implementer 子袋里
- implementer 自评后写 diff 文件
- dispatch task reviewer 子袋里做两阶段评审（spec 合规 + 代码质量）
- 不通过就 dispatch fix 子袋里，循环
- 全部任务完成后，dispatch final code reviewer 做整分支评审
- 进入
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. 分维度结论：别问谁更强，问你的场景
把上面所有维度汇总，做成一张表：
| 维度 | 占优方 | 证据强度 | 适用场景 |
|---|---|---|---|
| AI 长期记忆 | Trellis | 极强（mem SDK vs 无） | 长期项目、多人协作 |
| 项目规范沉淀与团队共享 | Trellis | 极强（spec 进 git vs 插件目录） | 团队工程化 |
| 任务/PRD 全生命周期 | Trellis | 强（task.py 状态机 vs 无跟踪） | 多天多 session 任务 |
| 多平台一份配置复用 | Trellis | 强（20 configurator vs 每平台装） | 多工具混用团队 |
| 学习/部署成本 | superpowers | 强（一行命令 vs init + 团队共识） | 个人/临时项目 |
| TDD / 调试纪律 | superpowers | 中（独立 skill vs check 附带） | TDD 信仰者 |
| 子袋里评审工程化 | superpowers | 中（SDD + eval vs agents/*.md） | 量化质量追求者 |
| License 友好度 | superpowers | 极强（MIT vs AGPL-3.0） | 企业/闭源商用 |
| 生态/作者可信度 | superpowers | 中（历史长+商业支持 vs 较新） | 风险厌恶型选型 |
| 仓库侵入性 | superpowers | 强（零侵入 vs .trellis/ 目录） |
仓库洁癖 |
7. 总结与选型建议
参考文章里说“Trellis 比 superpowers 更高一层”，这句话在源码层面成立——Trellis 多了记忆、spec 沉淀、任务状态机、多平台适配，确实是“更高一层”的抽象。
但“更高一层”不等于“全面更强”。
抽象层越高，约束、侵入、License 限制、学习成本都会跟着上来。superpowers 选择留在“轻量方法学”这一层，换来的是零侵入、MIT、装完就用、TDD 纪律硬。这不是谁输给谁，而是不同思路在各自边界内的合理取舍。
具体到选型，建议如下：
- 个人开发者、临时项目、信仰 TDD：superpowers。轻、纪律硬、License 干净
- 团队工程化、长期项目、多平台混用：Trellis。记忆和 spec 沉淀的价值在这类场景才会兑现
- 企业落地、有法务审核环节：先确认能不能接受 AGPL，否则 superpowers 是更稳的选择
- 两个都用：完全可行。superpowers 装在个人 IDE 里约束工作习惯，Trellis 跑在团队项目里做工程沉淀。两者不冲突
收尾再说一句：别被“更强”这种话术带节奏，扒源码、对场景、看 License，比看 README 强一百倍。
