2025 年下半年以来,围绕 Claude Code 等 coding agent 的"工作流框架"井喷式涌现——它们不改模型,而是在 agent 之上叠一层技能(skills)、命令(commands)、子代理(subagents)、钩子(hooks)和规格(specs),试图把"随手 vibe coding"约束成可复现的工程流程。

本文挑了 12 个有代表性的项目做横向评测。方法:把仓库全部 clone 到本地做源码级审查,配合 GitHub API 核验成熟度指标,并对每个项目派独立 agent 做对抗式交叉验证。评测维度包括:分类定位、成熟度与治理风险、硬技术程度(是空泛口号还是真材实料)、扩展点注册机制,以及对各家 coding agent 的支持面。

关于 star 数:下文 star/fork 数据经 GitHub REST + GraphQL 双接口核验一致,且用 react/linux/vscode 作控制组验证了接口准确(返回真实值)。但需警惕:几个仓库的 star 增速在物理上不合理——superpowers 建仓仅 9 个月却有 25.5 万 star(高于诞生十余年的 React),ECC 半年 23 万 star + 3.5 万 fork,mattpocock/skills 5 个月 17 万——几乎肯定含刷星或运营放大成分。因此 star 只能当"热度信号",不代表质量或成熟度,评测仍以版本节奏、治理结构、许可证、工程规范等更硬的指标为准。

参评项目:spec-kit、OpenSpec、BMAD-METHOD、superpowers、agent-skills、compound-engineering、gstack、gsd-core、trellis、oh-my-openagent、everything-claude-code(ECC)、mattpocock-skills。

速查(TL;DR)

一句话选型:新项目规格驱动 → spec-kit(官方最稳);存量代码改造 → OpenSpec(delta 规格更轻);团队敏捷全流程 → BMAD-METHOD;纪律/评审派 → superpowers / agent-skills / compound-engineering;抗上下文腐烂、跨会话记忆 → gsd-core / trellis 的设计思路。想让工作流被最多框架/工具支持,优先押 Codex CLI / OpenCode / Claude Code / Cursor 这四个通用底座。

三句话看透:① 硬技术上没有空泛口号——11 家源码级评分全部 ≥4/5;② 真正的差异在三个取舍:重工程真软件 vs 纯 Markdown 剧本、钦定技术栈 vs 技术无关、机器门禁强制 vs 靠 AI 自觉;③ 它们注册扩展点的方式分 4 种范式:原生插件 / CLI 生成器 / symlink / 编程式。

项目定位硬技术许可 / 主要风险一等适配 agent 数注册范式
spec-kit官方规格驱动(SDD)4.0MIT / 方法论重、宪法模板留空需自填33CLI 生成器
OpenSpec🥉delta 规格,棕地友好4.0MIT / 单人主导、PR 积压27CLI 生成器
BMAD-METHOD敏捷角色全流程4.0MIT+商标 / 学习曲线陡44插件+生成器
superpowers🥇TDD 硬门禁纪律4.0MIT / 自身无 CI、PR 积压7原生插件
agent-skills🥈SDLC 六阶段(Addy Osmani)4.5MIT / 巴士因子高、偏 Web 栈4原生插件
compound-eng🥉复利工程,对抗评审4.5MIT / token 消耗高、需认同哲学10原生插件
gstack虚拟工程团队(Garry Tan)5.0MIT / 营销制度化、无 release、单人9symlink
gsd-core上下文工程抗 rot4.5MIT / 源于 rug-pull 项目的社区 fork18原生插件
trellisspec+task+记忆持久化4.7AGPL-3.0 / 早期 v0.6、单人15CLI 生成器
oh-my-openagent多模型编排 harness5.0SUL 非开源禁商用 / 绑 OpenCode、单人3编程式
ECC超大工具箱/素材库4.0MIT / “889"实为 278、AgentShield 不可验证9原生插件
mattpocock/skills工程流程 skill(Matt Pocock)3.5MIT / 一人主导、star 增速反常2原生插件

规模与热度(GitHub 数据,2026-07-15)

star/fork 经 REST + GraphQL 双接口核验一致。“热度可信度"一栏依据"建仓时长 vs star 量级"判断增速是否合理:

项目StarsForks建仓热度可信度
superpowers255,03622,8012025-10❗ 反常(9 个月 > React,极可能刷星)
everything-claude-code229,88535,1892026-01❗ 反常(半年 23 万 + 3.5 万 fork)
mattpocock/skills171,42514,7272026-02❗ 反常(5 个月 17 万)
gstack121,98118,2362026-03❗ 反常(4 个月 12 万)
spec-kit121,43910,8032025-08✅ 可信(GitHub 官方大热)
agent-skills78,4248,4232026-02⚠️ 偏高(作者影响力大,或含放大)
oh-my-openagent65,8435,3712025-12⚠️ 偏高
OpenSpec60,9654,2282025-08⚠️ 偏高
BMAD-METHOD50,6165,8242025-04✅ 相对可信(社区成熟)
compound-engineering23,1941,8662025-10✅ 可信
trellis12,6357042026-01✅ 可信
gsd-core6,6304262026-05✅ 可信(fork 自 get-shit-done)

判读:star 榜与工程质量几乎无关——热度最高的 superpowers/ECC/gstack 反而是增速最反常的;而工程硬度天花板 gsd-core 的 star 最低。别把 star 当选型依据。

先分类:三个不同物种

把 12 个放在一起容易误比,因为它们解决的问题层次不同:

家族解决的核心问题成员
① 规格驱动(Spec-Driven)写代码前先把"要造什么"固化成可复核的规格spec-kit、OpenSpec
② 方法论 / 角色化工作流把软件工程流程(计划→评审→交付)固化成 AI 可执行的纪律BMAD-METHOD、superpowers、agent-skills、compound-engineering、gstack、mattpocock-skills
③ Agent Harness / 上下文与编排增强对抗上下文腐烂、跨会话记忆、多模型编排gsd-core、trellis、oh-my-openagent、ECC

边界有重叠——superpowers 既是方法论也是 skills 框架,gstack/trellis 既是工作流也是 harness,BMAD 也带浓重的规格驱动色彩。上表按"最主要卖点"归类。

逐项目画像

每个项目一段,融合定位、成熟度/治理、硬技术分与优劣。

规格驱动

spec-kit(GitHub 官方,MIT)——规格驱动开发(SDD)的官方旗舰,把 Constitution → Specify → Plan → Tasks → Implement 落成"宪法 + 模板 + 合规门"的可执行流水线,通过独立 CLI specify 适配 33 个 agent。成熟度:官方团队 + 社区维护,巴士因子健康,发版极密(接口仍在漂移)。硬技术 4.0:门禁引擎(合规门、只读一致性审查、覆盖率指标)是真机制,但宪法模板全是空占位符——用户不认真填,它的"硬"就落空;自身仓库工程质量一流(测试 > 源码、多 OS CI、Actions 按 SHA 钉版本)。最稳的官方选择,适合追求一致性的中大型项目。

OpenSpec(Fission AI,MIT)——最轻量的规格驱动。核心创新是 delta 规格:变更只描述"变了什么”(ADDED/MODIFIED/REMOVED),归档时自动并入主规格,天然适配存量代码和并行变更。纯 npm + Markdown,不依赖 Python。硬技术 4.0:delta 格式有 Zod schema + 编译器级冲突检测(跨 section 冲突、重名、RENAMED 碰撞全报 ERROR),但刻意技术无关、未编码 TDD/评审。风险:单核作者、PR 积压,跨仓库协作(Stores)仍是 Beta。存量项目里 spec-kit 的更轻替代。

方法论 / 角色化工作流

BMAD-METHOD(BMad Code,MIT+商标)——最"重"也最完整的方法论,把 PM/架构/开发/QA 做成角色 agent,规划-实现两阶段分离,Analyst→PM→Architect→SM→Dev→QA 跑完整 SDLC,还有游戏/创意等扩展包出圈到非软件领域。成熟度:社区、文档、发版都成熟(v6 主线),支持 44 个平台居首。硬技术 4.0:workflow 用受控 XML DSL,dev-story 强制 red-green-refactor + DoD 门禁 + HALT 条件,校验器还带确定性正则和元工具自测。劣:学习曲线陡、V4→V6 反复重构、小项目过度工程。适合团队级、复杂、需追溯的项目。

superpowers(Jesse Vincent / obra,MIT)——理念最"硬核"的纪律框架。用 SessionStart hook 注入 + 硬性关卡强制工程纪律:TDD 的 “Iron Law”(没有失败测试就不许写实现,“写在测试前的代码必须删除”),外加 git worktree 隔离、子 agent 双阶段评审。大量精力花在**“防止 AI 给自己找借口绕过规则”**(反规避对照表)。硬技术 4.0:最佳实践编码颗粒度到命令级,但真正的机器门禁少、自身仓库甚至没有 CI,靠 hook 注入 + AI 自觉。作者是开源老兵(K-9 Mail)。劣:极年轻却已 v6、PR 积压、流程对小改动偏重。

agent-skills(Addy Osmani,MIT)——把资深工程师"不在 diff 里"的价值(写规格、测试、评审、控 scope)编码成 SDLC 六阶段(DEFINE→PLAN→BUILD→VERIFY→REVIEW→SHIP),约 24 个 skill + 8 个 slash 命令 + 4 个角色人格,每个技能内置"agent 偷懒借口对照表”,理念源自 Google 工程文化(Hyrum’s Law、Beyoncé Rule 等)。硬技术 4.5:有量化阈值(LCP≤2.5s、JS<200KB gzip 等)、钦定 TS/React/Web 栈、并有可运行的三层校验(结构/触发路由/行为)。劣:巴士因子高(作者一人贡献占绝对多数)、偏 Web/前端栈、仍 v0.6 早期。与 superpowers 理念高度相似,但 SDLC 覆盖更系统、作者影响力更大。

compound-engineering(Every Inc,MIT)——理念最独特的"复利工程":每次工作让下次更容易,80% 精力在规划与评审。/ce-compound 把每次教训回写成结构化知识库(强 enum schema:18 值 problem_type 等),/ce-code-review 做多 agent 对抗式评审,甚至有跨模型对抗脚本(把同一份 brief 交给不同厂商 CLI 独立评审)。硬技术 4.5:规则被编译成 enum/schema/脚本/CI 门禁,可机器校验;运营专业(语义化自动发版)。劣:token 消耗高、见效慢、价值依赖你认同其哲学。方法论派的标杆。

gstack(Garry Tan / YC CEO,MIT)——把 Claude Code 包装成"你雇了一个工程团队",23+ 角色技能覆盖研发全生命周期(CEO→设计→工程三重评审、安全审计、真实浏览器 QA、跨模型复核)。硬技术 5.0(反直觉):有真实的 LLM-judge eval 体系、多 runner CI 矩阵、grep 级安全审计、静态 tripwire 测试——工程内核相当硬。但:本质是一个人的配置固化(无正式 release、单人主导),且把创始人营销(“810× 生产力”、YC 叙事)制度化写进 PR 治理规则(禁止社区 PR 软化宣传)。当灵感库/范本可以,但它是"高热度个人方法论"而非中立生产级框架。

mattpocock/skills(Matt Pocock / Total TypeScript,MIT)——“给真正做工程的人用"的 skill 集(README 直言 “real engineering, not vibe coding”),40 个 skill(22 个成熟),显式把自己摆在 GSD/BMAD/spec-kit 的对立面:小、可组合、model-agnostic、不夺走你的控制权。核心是工程流程(grilling 对齐需求、用 CONTEXT.md 共享领域语言、TDD、to-spec→to-tickets→implement→code-review),刻意技术无关——尽管作者是 TS 顶流,promoted skill 基本不绑 TypeScript。硬技术 3.5:方法论编码到教科书级(TDD 的"seam 接缝"规则、内联 Fowler 12 条 code smell),但自身仓库无测试、无 lint,CI 只发版不校验,不变量全靠 CLAUDE.md+ADR 约束 agent;无 commands/hooks/MCP。劣:一人主导、star 增速反常。理念克制、内容硬核的个人工程哲学 skill 集,适合认同"控制权在你"取向的开发者。

Agent Harness / 上下文与编排增强

gsd-core(open-gsd 社区,MIT)——直击 “context rot”:用 fresh-context 子 agent 并行执行 + 落盘状态(STATE.md/CONTEXT.md)对抗长会话上下文腐烂,五阶段循环 Discuss→Plan→Execute→Verify→Ship,“先验证再宣布完成"是 fail-closed 硬门禁。硬技术 4.5,自身工程硬度是这批天花板:变异测试棘轮、15 条 AST 级反假测试 lint、12 类强制对抗性 QA 矩阵、66 个 ADR。⚠️ 最大隐忧是治理背景:它是原项目 gsd-build/get-shit-done 因作者失联 + $GSD 代币被指 rug-pull 后的社区 fork(非官方交接)。技术很好,但历史包袱与品牌信任是硬伤。

trellis(Mindfold AI,AGPL-3.0)——用 .trellis/ 目录做 spec/task/journal 三层持久化解决"AI 失忆”,Plan→Implement→Verify→Finish 闭环,与 Claude Code 原生 hook/subagent 集成深。硬技术 4.7:工作流被编译成可解析状态机 + 测试不变量 + 发布连续性门禁,营销与实质约 5:95。劣:仅 v0.6 早期、单人主导、AGPL 强 copyleft(商用闭源需法务评估)。概念完整,但采用风险偏高。

oh-my-openagent(code-yeongyu,SUL-1.0 非开源)——oh-my-zsh 式的多模型编排 harness,主打模型无关 + 低成本,给不同模型各写一套 prompt。硬技术 5.0,是这批里最像"真软件"的:21 万行生产 TS + 更多测试,哈希锚定编辑、LSP、AST-Grep 三样硬技术全有可运行实现,用 TS 编译器 API 做源码级元审计当门禁。❗硬伤:SUL 许可禁商用分发(非开源)、深度绑定 OpenCode/Codex、与上游模型厂商关系紧张、实质是单人 + 自家 bot 高速 dogfooding。能力强,但许可与平台风险大。

everything-claude-code (ECC)(affaan-m,MIT)——最"大而全"的工具箱:278 个 skill + 67 subagents + 94 commands + 语言专用 rules,纯官方扩展点集成,供应链安全 CI 齐全。硬技术 4.0:门控 TDD 流水线、供应链 IOC 扫描、多语言 rules 都是真的。但两个招牌数字有水分:README 宣称的 “889 skills” 实为 278(其余是 i18n 翻译 + 多编辑器镜像凑数),“AgentShield 1282 测试/102 规则” 在本仓库内零实现(是外部 npm 包的自述,不可验证)。当素材库/最佳实践参考最合适,别无脑全量安装。

硬技术程度:是口号还是真材实料?

把 12 个仓库全部 clone 到本地,每个派独立 agent 只读源码,按 5 个维度打分(1-5,5=最硬核具体):① 工程规范强制度 ② 最佳实践编码 ③ 技术选择意见强度 ④ 内容丰富度 ⑤ 自身仓库工程硬度。

项目综合①规范强制②实践编码③技术意见④丰富度⑤自身工程强制方式
gstack5.055555CI 门禁 + 静态 tripwire 测试
oh-my-openagent5.055555源码级元审计测试 + hook
trellis4.7455*/无关55测试不变量 + 发布门禁
compound-eng4.555355enum schema + CI + 跨模型对抗评审
gsd-core4.545255变异测试棘轮 + AST 级反假测试 lint
agent-skills4.545455三层校验(结构/路由/行为)
BMAD-METHOD4.045254确定性校验器 + 元工具自测
spec-kit4.034155门禁引擎(内容留空给用户填)
OpenSpec4.053.514.54Zod schema + 编译器级冲突检测
superpowers4.045243.5hook 注入 + AI 自觉(自身无 CI)
ECC4.0453.544CI 校验 + 供应链扫描
mattpocock/skills3.545243CLAUDE.md+ADR 约束(无测试/lint)

* trellis/gstack/oh-my-openagent/agent-skills 对用户项目技术无关,但对自身 + 内置脚本强钦定;③ 列反映后者。

几个关键结论:

  1. 没有一个是"空泛口号”——全部 4 分以上。 即便看起来最"轻"的 superpowers、agent-skills,进入 SKILL.md 内部都是可执行到命令级的硬内容;营销话术普遍只存在于 README 门面。
  2. 分成两个物种:“真软件” vs “纯 Markdown 剧本”。 真软件(大型 TS/Node 应用 + 测试 + CI):oh-my-openagent、trellis、gsd-core、compound、OpenSpec、gstack、BMAD、ECC;纯 Markdown 剧本(靠 AI 遵循、机器强制少):superpowers、agent-skills。
  3. “技术选择意见强度”(③列)决定适配面。 刻意技术无关的(spec-kit/OpenSpec/gsd-core/BMAD/superpowers)一套方法论适配任意语言,但开箱约束偏软;强钦定栈的(agent-skills=TS/React、gstack=Bun/Chromium、oh-my-openagent=Bun/tsgo)开箱即用但适配面窄。
  4. “强制方式"拉开工程档次。 机器 fail-closed 门禁最硬(gsd-core 的变异测试棘轮、oh-my-openagent 的编译器级元审计、compound 的 enum schema、OpenSpec 的 delta 冲突检测);靠 AI 自觉 + 说服话术较软(superpowers 的 Iron Law + 反规避对照表——这套"反偷懒借口"其实 agent-skills/gstack 也都有)。

一句话: 差异不在"有没有真货”,而在(a)重工程真软件还是纯提示剧本、(b)钦定技术栈还是技术无关、(c)机器门禁还是 AI 自觉。工程硬度天花板是 gsd-core / oh-my-openagent。

扩展点是怎么注册的?

12 个框架都建立在 Claude Code 的原生扩展点词汇之上,差异在用不用、怎么下发。

原生注册"契约"

扩展点注册文件关键字段 / 触发方式
plugin.claude-plugin/plugin.jsonname/version + 可选指针 commands/skills/agents/hooks
marketplace.claude-plugin/marketplace.jsonplugins[](含 source),/plugin marketplace add <repo> 发现
skillskills/<name>/SKILL.mdfrontmatter 仅 name+description;模型按 description 自动触发
commandcommands/<name>.md(或 .toml)frontmatter name/description/argument-hint/allowed-tools;用户 / 显式调用
subagentagents/<name>.mdfrontmatter name/description/tools(白名单)/model/color
hookhooks/hooks.json事件 SessionStart/PreToolUse/PostToolUse/Stop → matcher → command,路径用 ${CLAUDE_PLUGIN_ROOT}
tool(MCP).mcp.jsonmcpServers map,type: stdio|http

关键区分:skill = 模型自动触发的能力包;command = 用户 / 手动触发;subagent = 可委派的独立上下文。三者 frontmatter 与目录都不同。

四种注册范式

范式成员机制安装方式
A 原生 plugin 清单式superpowers、agent-skills、gsd-core、compound、ECC、BMAD、mattpocock自己就是 Claude 插件,plugin.json+marketplace.json/plugin marketplace add → /plugin install
B CLI 生成器 / 多适配器式spec-kit、OpenSpec、trellis一套源,init 时按目标 agent 编译成不同格式specify init / openspec init / trellis init
C 安装脚本 symlink 式gstacksetup 把 repo symlink 进各家 skills/ 目录./setup
D 编程式 / 宿主 API 式oh-my-openagentagent/hook 写在 TS 代码里,经宿主 plugin interface 注册bunx omo install

范式 A 的 plugin.json 指向资产分三种风格:裸清单(superpowers,靠约定目录被扫描)、目录指针(gsd-core,"skills":"./skills/")、显式文件数组(agent-skills,逐个列 agents);BMAD 更进一步在 marketplace.json 里拆成多个子插件。

范式 B 是"技术无关"三家的实现根基:spec-kit 用 agents.py 注册表把一条命令渲染成 markdown/toml/yaml/SKILL.md 四种格式;OpenSpec 用 29 个 TS 适配器(各实现 getFilePath()+formatFile());trellis 为每个平台备一个模板目录、init 时按平台拷贝。

范式 D 的 oh-my-openagent 本质是 OpenCode 的 TS 插件,agent/hook 在代码里注册,同时另做一套 Codex 静态插件——是编程式 + 静态混合。

几点横切观察:

  • .agents/ 正成为跨工具事实标准——多数项目都在原生 .claude/ 之外建了这个中立目录。
  • 多平台镜像两种做法:提交期静态镜像(ECC 把 skill 复制成多语言/多编辑器多份,正是"889"虚胖来源)vs 安装期动态生成(范式 B)。
  • hook 复杂度天差地别:superpowers 仅 1 个 SessionStart hook;gsd-core 全事件覆盖(prompt-guard/read-guard/context-monitor…);ECC 的 hook 里内联一大段 JS 引导器兼容多种安装路径,最重。

一句话: 范式 A 是"我就是个 Claude 插件"(绑定深、开箱即用);范式 B 是"我是编译器,把一套源翻译成 N 家格式"(平台无关,代价是多一层生成器);范式 C 是"symlink 进去就行";范式 D 是"写进宿主代码 API"(能力最强,但与宿主强耦合)。

对各家 Coding Agent 的支持矩阵

排版:coding agent 作行,12 项目作列(短代号)。取证方法:范式 B(生成器)按其适配器/集成/模板目录清单计(有代码实证的"一等公民"支持);范式 A/C/D 按已提交的平台目录计。这是"一等适配"的下限,不是"能不能用"的上限——通用 SKILL.md/plugin 格式任何兼容工具都能读,只是没提交专属目录。

列代号:BMAD=BMAD-METHOD、SK=spec-kit、OS=OpenSpec、GSD=gsd-core、TR=trellis、CE=compound-engineering、ECC=everything-claude-code、SP=superpowers、AS=agent-skills、GST=gstack、OMO=oh-my-openagent、MP=mattpocock/skills。

Coding AgentBMADSKOSGSDTRCEECCSPASGSTOMOMP计
Codex CLI✅✅✅✅✅✅✅✅✅✅✅✅12
Claude Code✅✅✅✅✅✅✅✅✅✅✅11
OpenCode✅✅✅✅✅✅✅✅✅✅✅11
Cursor✅✅✅✅✅✅✅✅✅✅10
Gemini CLI✅✅✅✅✅✅✅7
Pi✅✅✅✅✅✅✅7
Kiro✅✅✅✅✅✅6
Trae✅✅✅✅✅✅6
Cline✅✅✅✅✅5
CodeBuddy✅✅✅✅✅5
GitHub Copilot✅✅✅✅✅5
Kimi✅✅✅✅✅5
Qwen Code✅✅✅✅✅5
Factory Droid✅✅✅✅4
Hermes✅✅✅✅4
Kilo Code✅✅✅✅4
Qoder✅✅✅✅4
Antigravity✅✅✅3
Auggie✅✅✅3
Bob✅✅✅3
Junie✅✅✅3
Windsurf✅✅✅3
Zcode✅✅✅3
Agy✅✅2
Amp✅✅2
Crush✅✅2
Devin✅✅2
Firebender✅✅2
Goose✅✅2
Lingma✅✅2
Mistral Vibe✅✅2
OMP✅✅2
OpenClaw✅✅2
Roo Code✅✅2
Rovo Dev✅✅2
Zed✅✅2
iFlow✅✅2
Adal✅1
Amazon Q✅1
Augment✅1
CodeWhale✅1
Command Code✅1
Continue✅1
Cortex✅1
Costrict✅1
Forge✅1
Grok✅1
Kode✅1
Mux✅1
Neovate✅1
Ona✅1
OpenHands✅1
Pochi✅1
Reasonix✅1
Replit✅1
Shai✅1
Slate✅1
Tabnine✅1
VS Code✅1
Warp✅1
Zencoder✅1
每项目一等适配合计44332718151097493261

去重后共覆盖 61 个 coding agent。计数 1-2 的长尾几乎全被 BMAD、spec-kit、OpenSpec 三家瓜分。

读表要点:

  1. 四个"通用底座":Codex CLI、OpenCode、Claude Code、Cursor 被 10-12 家全覆盖,是当前 agent 生态的最大公约数。想让工作流被最多框架支持,优先押这四个。
  2. 覆盖广度 = 范式决定:范式 B 的生成器天生广(BMAD 44、spec-kit 33、OpenSpec 27,多加一个 agent 只是多写一个适配器);最窄的是 oh-my-openagent(3,编程式深绑 OpenCode/Codex)和 mattpocock/skills(2,只 Claude Code + Codex)。广度与深度此消彼长。
  3. 长尾即"跑马圈地":只被一家支持的 20+ 个冷门 agent(Warp/Replit/OpenHands/Amazon Q…)几乎全被 BMAD 和 spec-kit/OpenSpec 瓜分,在比拼"支持最多工具"的营销位。

五分制评分与排名

本表只评价本文所审计的工程能力，不代表项目的通用功能、社区活跃度或整体产品质量。 License 不参与评分。七个维度等权，每项 1–5 分，总分为 35 分，平均分为总分除以 7。

  • 1 分：未发现该能力，或现有机制没有解决本维度的问题。
  • 2 分：存在基础约定或局部机制，但作用域较窄，缺少系统性验证。
  • 3 分：已有可用的结构化机制，覆盖不完整或不同 artifact 间仍不统一。
  • 4 分：能力较强，有明确合同与自动检查，仅在范围或闭环上有少量缺口。
  • 5 分：形成系统性闭环，有明确合同、自动验证和稳定性证据。

“ID 唯一性范围”使用更严格的范围解释：单文件/单轮 workflow 通常为 2 分，稳定的 artifact lineage 或项目子域为 3 分，跨受管文件的项目级正式索引为 4 分；只有跨项目中央注册和冲突 检查才为 5 分。因此 tao-dev 在这一项为 4 分，而不是 5 分。

排名项目自动化测试成熟度结构化确认性测试ID 顺序稳定性ID 跨文件稳定性ID 唯一性范围书籍化与交叉引用文档 Schema 与检查总分 / 35平均 / 5
1tao-dev5555455344.86
2compound-engineering-plugin4454323253.57
3gsd-core5433323233.29
4OpenSpec5342225233.29
5spec-kit4343224223.14
6gstack5432223213.00
7everything-claude-code4342223202.86
8trellis3233233192.71
9=BMAD-METHOD2332233182.57
9=oh-my-openagent5321223182.57
11agent-skills3521123172.43
12superpowers3511122152.14
13skills111112181.14

排序先比较总分；同分时依次比较结构化确认性测试、文档 Schema、ID 唯一性范围。 BMAD-METHOD 与 oh-my-openagent 在这些比较项上仍相同，因此并列第 9。测试项评价的是测试 体系成熟度，不按测试声明数量线性换算；例如真实 agent eval、mutation、golden parity 和 语义判定会影响得分。

总体对比

项目License测试数量结构化确认性测试文档书籍化与交叉引用文档 Schema 与检查
BMAD-METHODMIT约 12 文件 / 194 声明部分：有 artifact 验证、质量 rubric 和测试场景，但未发现统一的 skill 行为规则/场景/事件证据体系部分：有 Astro 文档站与导航校验；未把每轮生成的 spec/design/plan 统一纳入一部可校验的书部分：模板、必需段落、链接和导航检查较多；没有覆盖全部受管文档类型的统一 schema 注册表
OpenSpecMIT约 100 / 1,840部分：CLI、parser、archive、validation 的行为测试充分；重点是 artifact 引擎，不是独立的真实 agent 确认性评测较弱：spec/change 互相引用，但未发现“项目全部文档从统一书籍根可达”的发布约束强：base/spec/change schema、可定制 artifact graph、严格校验；约束对象主要是 OpenSpec artifacts
agent-skillsMIT0 / 0；另有 24 组 eval强：结构检查、触发/路由 eval、可选 graded behavioral eval 分层明确较弱：README 和 references 形成导航，但没有统一成带全局交叉引用检查的书部分：skill frontmatter、命名、必需章节和 command parity 有检查；不是通用项目文档 schema
compound-engineering-pluginMIT约 115 / 2,374较强：大量 workflow/skill 合同测试、review personas 和文档 claim/frontmatter 校验；未发现像 tao-dev 一样统一的 live-client 行为规则矩阵较弱：文档目录和 skill references 完整，但没有全库书籍根、可达性和稳定发布 URL 合同部分：若干 artifact 有固定 contract，部分正文明确允许开放结构；不是所有文档共用的统一 schema
everything-claude-codeMIT约 189 / 3,450部分：有 eval harness、agent 安全与 skill surface 测试；未发现统一规则 ID + 场景 ID + 真实客户端证据链较弱：多语言 README/docs 导航丰富，但没有项目文档书籍化的全局可达性检查部分：配置、安装、provenance、plugin 等 JSON Schema 很强；主要约束机器配置，不是需求/设计/任务文档
gsd-coreMIT约 615 / 17,775较强：golden parity、adversarial fixtures、property 与 mutation 门槛很强；主要验证工具链和 artifact 处理，不等同于独立 skill 行为确认较弱：有大量指南和模板引用，但未发现统一书籍根与全量文档可达性合同部分：roadmap/state/frontmatter/config 等有解析和对抗性校验；没有统一的正式文档 profile 注册表
gstackMIT约 443 / 5,972较强：大量 skill、registry、fixture、headless/PTY 与 schema-pack 测试；确认性证据分散在不同 skill 和工具中较弱：有生成的 skill 文档与设计文档，但不是统一项目书籍及稳定实体引用系统部分：task emission、settings、skill frontmatter 等有 schema；需求/设计/计划没有共同的全局文档 schema
oh-my-openagentSustainable Use License 1.0；第三方组件沿用原许可约 1,720 / 12,757部分：运行时、插件、schema 和集成测试规模很大；未发现覆盖需求/设计/任务 artifact 的统一确认性规则矩阵较弱：参考文档很多，但未发现把全部项目文档作为一部书校验可达性和交叉引用部分：配置及 help/status/doctor 等 JSON Schema 很强；不覆盖全部 Markdown 工程文档
skillsMIT0 / 0未发现：有方法论说明，但本地没有成体系的自动 eval/test harness较弱：README 到 skill/docs 有人工链接，不是可构建、可校验的统一书较弱：主要依赖 Markdown 约定，未发现统一文档 schema 与项目级关系检查
spec-kitMIT约 102 / 3,069部分：CLI、模板、bundle/manifest contract 测试充分，也有跨 artifact analyze；没有统一的真实 agent 行为评测证据链较弱：官方文档与 walkthrough 完整，但 feature 产物没有被统一汇编成项目书籍较强：spec/plan/tasks 模板与 bundle/manifest 校验明确；约束集中在 feature workflow，非全部 Markdown
superpowersMIT约 13 / 178；行为 eval 位于外部仓库强：要求真实 Claude Code/Codex 会话和 LLM verifier 的 before/after eval；本地仓库只包含基础设施测试与接入说明较弱：skill/references 可导航，但没有统一书籍根、全量可达性或实体交叉引用检查较弱：SKILL frontmatter 和编写约定明确，未发现需求/设计/任务文档的机器可读统一 schema
trellisAGPL-3.0约 77 / 1,572部分：core/CLI/task/channel 测试和场景文档存在；未发现独立的 skill 行为确认性评测矩阵部分：有外部文档站和多语言场景文档；项目 artifact 未统一纳入可验证的书籍关系图部分：task/channel store 有 schema；需求、设计、实现 Markdown 仍主要靠目录/模板约定
tao-devApache-2.060 个测试文件 / 437 个 pytest 收集项强：12 条规则、9 个场景、真实 Claude/Codex 隔离运行、tool event 与 workspace diff、确定性/语义 oracle、mutation 检查；live 调用需显式授权，不由普通 pytest 自动发起强：docs/index.md 是书籍根；所有纳管页必须可达、无循环/重复目标；toctree 只决定阅读顺序，稳定实体 URL 不依赖文件路径强（限受管文档）：机器可读 profile 注册表、严格 frontmatter/section/entity/relation/task graph/retirement/navigation 校验；覆盖 docs/**/*.md，不声称覆盖仓库每个 Markdown

ID 稳定性与唯一性范围

项目主要 ID 形态调整顺序后是否稳定内容跨文件移动后是否稳定实际唯一性范围判断
BMAD-METHODFR-1..N、旅程/成功指标 ID、story ID条件稳定：PRD 内 FR 可保留；story 在 spec 固定前允许重排/重编号未规定：未发现跨文件移动仍由全局索引确认同一对象一份 PRD、spec 或 story 生命周期；不是项目全局这是 artifact 内的连续编号与追踪键，不应称为真正全局 ID
OpenSpec规范化 Requirement 标题作为 identity基本稳定：排序不影响标题 identity；改名必须走 RENAMED 语义不稳定/未保证：移到另一 spec 后进入另一命名域，且标题冲突按该 spec 判断单个 spec/capability；稳定 UUID 仍是未来计划标题键不是跨文件、跨项目的永久实体 ID
agent-skillseval 文件中的数字 id未保证：可人工保留，但没有独立身份合同否：不同 eval 文件会从相同数字重新开始单个 eval 文件文件内唯一
compound-engineering-pluginR-*、U-*、KTD-*、A-*、F-*、AE-*稳定：明确要求 plan 修订时不重编号，允许留下缺号部分稳定：brainstorm 到 unified plan 等受控流转可保留；任意跨文档移动没有项目级去重索引单个 unified-plan/artifact lineage是强 lineage ID，但不是项目全局 ID
everything-claude-codespec miner 以 FileName.methodName 派生 requirement ID稳定：仅调整说明文字顺序或显示名称不变否/条件性很强：移动或重命名代码文件、方法会改变派生 ID单次 mined spec 或 enforcement point 集合稳定性绑定代码位置，不是文档对象的永久全局身份
gsd-coreREQ-*、分类需求号、plan 引用；SUMMARY 内 D1...条件稳定：复制到 roadmap/plan 后可持续追踪，但未发现统一的 never-renumber 合同部分：引用可以跨 requirements/roadmap/plan；权威定义跨文件搬迁的身份保持未明确REQ 多为项目/里程碑；D* 明确只在单份 SUMMARY 内；task ID 也更局部存在跨 artifact traceability，但不是单一全局命名域
gstack稳定 registry/question ID；每次 run 的 T1/T2...混合：registry ID 稳定；run 内顺序型 task ID 可能随重排变化未形成统一合同：不同 registry/run/report 各有自己的作用域registry、fixture 或单个 run_id多种局部 ID 共存，不能合并称为全局 ID
oh-my-openagent运行时 task T-{uuid} 等通常稳定：随机 task ID 不依赖列表顺序不适用/未规定：这是运行时任务身份，不是 Markdown 需求/设计对象task store、session/team 等运行时域UUID 风格运行时 ID 不等于工程文档的全局稳定 ID
skills未发现正式 artifact ID否否无标题、目录和列表序号不能当稳定 ID
spec-kitfeature 内 FR-001、T001、CHK001条件稳定：converge 流程要求 append-only、不重编号旧任务；任务号仍带执行顺序含义部分：spec/plan/tasks 通过 source refs 串联，但定义移到另一个 feature 不受全局索引保护单个 feature/spec/plan/checklist一轮 feature 工作流内唯一，不是项目全局
superpowersTask 1、Task 2 等位置编号否：重排会改变编号与语义对应否单份 plan位置编号，不是实体 ID
trellis任务目录 MM-DD-slug；task.json.id = slug部分：任务目录身份不依赖内部文档顺序部分：整个任务目录移入 archive 受支持；内部需求/设计条目没有独立稳定 ID单个 task 目录；slug 本身可在不同日期目录重复支持任务容器迁移，不支持内容实体的项目级全局身份
tao-devDOC/REQ/UC/ADR/TASK/CHG/EVD_YYYYMMDD_<80-bit-random>稳定：ID 与排列、toctree 顺序及任务执行顺序解耦；任务顺序由关系表达稳定：同一对象的定义和 ID 一起移动；标题、文件名和路径变化不重编号。拆出新对象或改变类型时必须新建 ID单个项目版本的正式索引，跨受管文件并包含 retirement records；跨项目引用需显式导入对方索引，没有中央注册服务本组最接近严格的“项目级全局稳定 ID”，但不能表述为跨所有仓库的全球唯一 ID

横向规律

  1. 都是"提示词/工作流编排层",没有新增底层能力——上限全部受宿主模型与 agent 平台能力约束。没有一个是"银弹"。
  2. 趋同的四/五阶段循环:几乎所有项目都收敛到 Plan → Implement → Verify → Ship/Compound + 子 agent 隔离 + 落盘状态持久化。这已是 2026 年的事实标准范式。
  3. “平台无关"是新标配:几乎每家都在 .claude/.cursor/.codex/.gemini/... 各建目录,Claude Code 通常是主 harness。
  4. 成熟度普遍虚高:绝大多数仓库年龄 < 1 年却已到 v2~v6,破坏性变更频繁;高 star ≠ 生产验证。
  5. 巴士因子被严重低估:spec-kit / BMAD / compound-engineering 有真正的团队/社区;gstack / trellis / oh-my-openagent / OpenSpec / agent-skills 高度依赖单一作者。
  6. 许可证要认真看:多数 MIT,但 oh-my-openagent(SUL 非开源禁商用) 和 trellis(AGPL 传染性) 对企业集成是实打实的坑。

选型建议

按 个人 vs 团队 × 轻量 vs 重流程

轻量 / 快速迭代重流程 / 强纪律
个人开发者OpenSpec(棕地小改)、gsd-core(多 runtime)superpowers / agent-skills(单人也要高质量 TDD)
团队compound-engineering(规划前置 + 经验复用)BMAD-METHOD(完整可追溯 SDLC)

按具体场景

  • 已有代码库、只想加点规格约束、讨厌仪式 → OpenSpec(delta 规格)
  • 想要官方背书、跨多种 AI 工具通用、绿地棕地都做 → spec-kit
  • 团队级、要角色分工和完整敏捷流程、甚至扩到非软件领域 → BMAD-METHOD
  • 单人但坚持严格 TDD 和代码质量 → superpowers 或 agent-skills(后者 SDLC 覆盖更系统、偏 Web 栈)
  • 认同"重计划评审、沉淀复利"哲学、追求评审质量 → compound-engineering
  • 想借鉴抗上下文腐烂 / 跨会话记忆的设计 → 参考 gsd-core / trellis(注意 gsd-core 的治理背景与 trellis 的 AGPL)
  • 想抄一套现成 skills/subagents 做二次开发 → ECC 当素材库
  • 需谨慎评估:gstack(无 release、单人、营销制度化)、oh-my-openagent(SUL 非开源 + 平台绑定)、gsd-core(rug-pull 历史包袱)

结语

一年之内,coding agent 工作流框架已经从"几段提示词"进化成"带变异测试、AST 级 lint、跨模型对抗评审的真软件”。它们在硬技术上普遍超出预期——真正需要甄别的不是"有没有货",而是:它是重工程还是提示剧本、绑不绑你的技术栈、靠机器门禁还是 AI 自觉、许可证和巴士因子能不能进你的生产环境。 想稳,选官方 spec-kit;想轻,选 OpenSpec;想要完整团队流程,选 BMAD;想要工程纪律,看 superpowers/agent-skills——但无论选谁,先看清许可证和维护结构,再决定是否押注。

附:参评项目

数据为 2026-07 快照,会随时间变化;各项目自述指标带 marketing 性质,本文以源码级核实为准。