CC端到端开发skill：fully-coding 和 OpenSpec、Spec Kit、BMAD、SuperClaude 的对比

前言：这篇文章基于 fully-coding 的竞品对比报告，整理它与 OpenSpec、GitHub Spec Kit、BMAD-METHOD、SuperClaude Framework 的核心差异。本文不是严格 benchmark，而是面向工具演进的定性分析。

本博文对应的代码仓库见：(Github)[https://github.com/seedily/claude-coding-skills]

背景

fully-coding 不是唯一一种 Claude Code 开发工作流。围绕 spec、plan、tasks、agents、code review、testing，已经有很多工具和方法论。

常见对比对象包括：

• OpenSpec。
• GitHub Spec Kit。
• BMAD-METHOD。
• SuperClaude Framework。
• Claude Code 官方 /plan、/code-review。
• Anthropic webapp-testing、skill-creator。

但这些工具并不是完全同型。直接问“谁更强”意义不大，更好的问题是：

在什么场景下，哪种工具更合适？

核心定位差异

可以先用一句话区分它们。

工具	定位
OpenSpec	轻量 spec-driven 开发推进工具
GitHub Spec Kit	结构化、治理更强的 spec-driven toolkit
BMAD-METHOD	AI Agile 多角色开发方法论
SuperClaude Framework	Claude Code 增强型命令 / Agent 工具箱
fully-coding	项目级 9 步串行交付 Orchestrator

fully-coding 的定位不是“最快生成 plan”，而是“在企业项目里完成可审计、可恢复、可同步文档的交付闭环”。

更准确地说，它是在 Claude Code 上落地 SDD（Specification-Driven Development，规范驱动开发）：把规范视为第一性产物，把代码实现看作规范流转后的结果之一。

这决定了它的优势和短板。

9 步流程覆盖对比

fully-coding 的 9 步如下：

需求检索 → 需求生成 → 开发范围 → 开发方案 → 开发实现 → 代码评审 → 测试用例 → 文档更新 → 自主进化

不同工具覆盖重点不同：

fully-coding 步骤	OpenSpec	Spec Kit	BMAD-METHOD	SuperClaude	fully-coding
Step 1 需求检索	中	中	中	中	高
Step 2 需求生成	高	高	高	中高	高
Step 3 开发范围	高	高	高	高	高
Step 4 开发方案	高	高	高	高	高
Step 5 开发实现	中高	高	高	高	高
Step 6 代码评审	中	中	中	中高	高
Step 7 测试用例	中	中高	中高	高	高
Step 8 文档更新	中	中	中	中高	高
Step 9 自主进化	低	中	中	中	高

结论很清楚：

• OpenSpec / Spec Kit 强在 Step 2-5。
• BMAD-METHOD 强在 Step 1-5，尤其产品、PRD、架构。
• SuperClaude 强在 Step 3-7，尤其开发体验和工具命令覆盖。
• fully-coding 强在 Step 1-9，尤其后半程闭环。

fully-coding 的优势

1. 完整交付闭环

很多工具可以生成 spec、plan 或 tasks，但不一定强制走完评审、测试、文档同步和自检。

fully-coding 把这些后半程动作纳入流程：

• Step 6 DBA + Reviewer 合并评审。
• Step 7 测试用例与失败修复。
• Step 8 知识库同步。
• Step 9 文档一致性自检。

这让它更适合企业项目交付。

2. 项目规则遵循

fully-coding 通过规则文件约束实现：

• DDD 分层。
• 编码规范。
• 持久层规范。
• 安全规则。
• 异常规则。
• 错误码规则。
• Git 规则。
• 幂等性设计。

相比通用命令工具，它更强调“按当前项目规则开发”。

3. 规范化文档交接

fully-coding 不把文档当成事后说明，而是把 userStory、codingLog、blockLog、知识库文档都设计成步骤之间的交接件。

这种做法带来两个差异：一是后续步骤可以基于明确文档继续推进，二是中断后的恢复进程可以判断哪些规范已经完成、哪些字段还缺失。对于超长周期编程来说，这比单纯依赖上下文窗口更稳。

4. 审计和续跑

fully-coding 使用：

• status
• current-step
• current-role
• last-heartbeat
• blockLog
• codingLog
• auto-resume

这套机制让长任务可审计、可恢复、可控失败。

5. 知识库同步

fully-coding 会同步：

• 服务设计文档。
• 功能实现文档。
• 功能实现概览。
• 菜单功能迭代文档。
• 错误码文档。

这是它和很多 spec-driven 工具的明显差异。

fully-coding 的短板

fully-coding 也有明显代价。

短板	原因	应对方向
流程偏重	标准模式覆盖 9 步	增加 --plan-only、--quick-dev
token 成本较高	评审、测试、文档同步都会消耗上下文	runtime-load-map 懒加载
简单任务体验不如轻量工具	小 bug 不一定需要完整闭环	使用 --quick-dev
任务拆解显式度不如 Spec Kit	Step 4 原本缺少显式 task list	增加 Implementation Tasks
产品 / PRD 角色不如 BMAD	当前更偏工程交付	增强 PRD / 产品分析模板
命令灵活性不如 SuperClaude	流程刚性高	保留标准流程，同时提供轻量模式

关键点是：不要因为流程重就删除 9 步。9 步是 fully-coding 的差异化优势。更合理的做法是分层执行。

三个执行模式如何补足短板

fully-coding 已经通过三种模式降低使用成本。

模式	对标对象	价值
标准模式	企业级完整交付	保留完整审计、评审、测试、文档闭环
--plan-only	OpenSpec / Spec Kit	只生成需求、范围、方案，不修改代码
--quick-dev	SuperClaude / /plan / /code-review	小任务保留范围、实现、评审、测试，跳过完整文档闭环

这让 fully-coding 不再只有一种“重流程”形态。

与官方局部能力的关系

Claude Code 官方能力也值得对标，但要注意它们不是完整竞品。

工具	对标步骤	优势	局限
/plan	Step 3 / Step 4	官方内置、轻量、适合改动前规划	不负责测试、文档同步、知识库管理
/code-review	Step 6	使用简单、成本低、常规 review 能力强	不一定理解 userStory / codingLog，不一定有 DBA 视角
webapp-testing	Step 7	Playwright、截图、DOM、浏览器日志能力强	主要覆盖 Web UI，不覆盖后端集成测试
skill-creator	benchmark / eval	可做 with-skill / baseline 对比、tokens、timing、review viewer	不是业务开发工具

更合理的做法不是替代它们，而是吸收它们的长处。

例如：

• 吸收 /plan 的轻量规划体验。
• 吸收 /code-review 的低成本评审入口。
• 吸收 webapp-testing 的 UI 验证流程。
• 吸收 skill-creator 的 benchmark 方法。

后续优化路线

基于对比，fully-coding 后续可以优先做这些事情：

优先级	优化项	对标对象	价值
P0	Step 4 增加 Implementation Tasks	OpenSpec / Spec Kit	让方案更可执行，方便 Step 5 按任务推进
P0	建立 benchmark	skill-creator	从主观判断变成可度量
P1	强化 Web 测试流程	webapp-testing / SuperClaude	降低“代码通过但 UI 不可用”的风险
P1	优化 --quick-dev 日志粒度	SuperClaude / /code-review	小任务更轻，但保留审计信息
P2	增强 PRD / 产品分析模板	BMAD-METHOD	补足产品和用户视角

建议的 benchmark 场景

如果要验证这些判断，建议用固定任务集：

场景	输入示例	评估重点
简单查询接口	新增资讯分类列表查询接口，支持启用状态过滤，返回树形结构	plan 速度、影响范围准确率、代码一次通过率
复杂写操作	新增用户收藏资讯功能，要求并发下幂等	幂等性、唯一约束、事务、错误码、并发测试
后台管理页面	新增资讯标签管理页面，支持分页、搜索、新增、编辑、禁用	前后端联动、菜单 / 路由 / 权限、UI 测试
明确 Bug 修复	修复资讯列表按发布时间倒序排序不生效的问题	定位速度、是否过度设计、token 消耗
中断恢复测试	执行到开发实现后模拟中断，再恢复任务	恢复成功率、状态一致性、是否重复修改

指标包括：

• tokens。
• duration。
• plan completeness。
• compile success。
• test success。
• review findings。
• doc sync completeness。
• human score。

总结

fully-coding 不应该把自己定位成“最快的 plan 工具”。

它真正的竞争力是：

完整交付闭环
项目规则遵循
评审测试自动修复
知识库同步
中断恢复
审计追踪
batch 串行调度

如果只看轻量规划，OpenSpec 和 Spec Kit 很强。如果看命令灵活性，SuperClaude 很强。如果看产品和角色方法论，BMAD-METHOD 很强。

但如果目标是企业项目里的规范化交付，fully-coding 的 9 步流水线、SDD 思想、文档驱动、状态机和知识库同步机制会更有优势。