2026 年 Claude Code 工作流框架全景对比：ECC、Superpowers、GSD、gstack、BMAD、Taskmaster、ZCF

数据基准：2026 年 4 月 10 日。Star 数来自 GitHub issues/discussions/releases 页实时确认，非估算。本文新增 Everything Claude Code（ECC）并同步更新全部数据。

这半年 Claude Code 生态爆炸了。

从 2025 年底到 2026 年初，围绕 Claude Code 出现了一批质量远超「一堆 prompt」的工程化工作流框架。它们有一个共同出发点：AI 写代码的问题从来不是智能不够，而是纪律不够。 给一个足够强的模型施加足够严格的流程约束，产出质量会远超让同等模型随意发挥。

本文对目前最主流的七个框架做深度横向对比，给出的不是罗列，而是判断。

背景：为什么需要这些框架？

当你把一个复杂任务交给裸 Claude Code，大概率会看到这样的过程：

模型跳过设计直接开始写代码
写了几百行后偏离原始需求
会话上下文越来越长，质量开始下降（Context Rot）
模型开始「自信地错误」：声称完成但实际有大量遗漏
换一个会话就忘了所有上下文，每次都要从头交代

这些问题催生了工作流框架。它们的本质是用结构化流程替代随意 prompt，强制 AI 在动手之前先思考、先规划、先验证，并在会话之间保持记忆。

七大框架速览

框架	仓库	Stars（2026-04-10）	核心作者	定位
ECC	affaan-m/everything-claude-code	142,000	Affaan Mustafa（Anthropic Hackathon 冠军）	agent harness 性能优化系统
Superpowers	obra/superpowers	130,617	Jesse Vincent（Prime Radiant）	方法论骨架
gstack	garrytan/gstack	62,000	Garry Tan（YC CEO）	虚拟工程团队
GSD	gsd-build/get-shit-done	46,900	TÂCHES	上下文工程 + Spec-Driven
BMAD-METHOD	bmad-code-org/BMAD-METHOD	43,200	BMad Code 团队	敏捷全生命周期
Taskmaster	eyaltoledano/claude-task-master	25,900	Eyal Toledano	AI 任务管理器
ZCF	UfoMiao/zcf	5,700	UfoMiao	零配置安装器（国产）

一、ECC（Everything Claude Code）：agent harness 性能优化系统

仓库：affaan-m/everything-claude-code | 版本：v1.10.0 | 安装：

# 官方插件市场（推荐）
/plugin marketplace add affaan-m/everything-claude-code
/plugin install everything-claude-code@everything-claude-code

# 或 npm 安装（跨平台）
npx ecc-install

ECC 是目前 GitHub star 数第一的 Claude Code 框架（142,000 stars，超越 Superpowers），由 Affaan Mustafa 于 2025 年 9 月赢得 Anthropic × Cerebral Valley Hackathon 后，将其 10 个月的生产级配置于 2026 年 1 月开源。

ECC 的定位与其他框架有本质区别：它不是工作流脚本，而是 agent harness 性能优化系统——解决的是 Claude Code 「遗忘、不一致、不安全」三个系统性问题，通过结构化规则、钩子、记忆持久化和安全扫描，让 agent 的行为可预期、可重复、可审计。

重要：全部 hook 脚本已用 Node.js 重写，完整支持 Windows、macOS（含 Intel）、Linux，无平台限制。

核心数字（v1.10.0，2026-04-05）

组件	数量	说明
Agents	47	专业子 agent
Skills	181	工作流知识文件
Commands	79	slash 命令
Rules	34	常驻规则（含 12 语言生态）
Hooks	20+	触发式自动化
MCP Configs	14	预配置 MCP 服务器

四层架构

ECC 的四层设计解决了不同层次的问题：

Layer 1 Rules（规则层）
  └─ 常驻加载，始终生效
  └─ 通用规则（git 工作流、TDD 80%覆盖率、安全规范）
  └─ 语言规则（Java/TypeScript/Python/Go/Rust/Kotlin/C++等 12 个生态）

Layer 2 Hooks（钩子层）
  └─ 触发式自动化，无需手动干预
  └─ PostToolUse：代码保存后自动格式化（Black/Prettier）
  └─ Stop：会话结束自动保存上下文摘要
  └─ PreToolUse：拦截危险操作（禁止 git commit --no-verify）
  └─ SessionStart：加载上次会话记忆

Layer 3 Skills（技能层）
  └─ 按需加载，渐进式披露
  └─ 先加载名称和描述（~100 tokens），匹配任务后才加载完整内容
  └─ 覆盖：后端模式、前端模式、TDD、安全审查、持续学习等

Layer 4 Agents（Agent 层）
  └─ 专业子 agent 委托执行
  └─ 每个 agent 独立上下文，互不污染
  └─ NanoClaw v2 负责模型路由和技能热加载

完整 Agent 清单

规划与设计类

Agent	文件	职责
planner	`planner.md`	功能实现规划，拆解任务结构
architect	`architect.md`	系统设计决策，架构方案制定

代码质量类

Agent	文件	职责
tdd-guide	`tdd-guide.md`	测试驱动开发全流程引导
code-reviewer	`code-reviewer.md`	代码质量与安全综合审查
security-reviewer	`security-reviewer.md`	漏洞分析与安全专项审查
refactor-cleaner	`refactor-cleaner.md`	死代码清理，重构引导

语言专项类（按语言分 reviewer + build-resolver）

Agent	覆盖语言
typescript-reviewer	TypeScript
python-reviewer	Python
java-reviewer / java-build-resolver	Java / Spring Boot
kotlin-reviewer / kotlin-build-resolver	Kotlin / Android
go-reviewer / go-build-resolver	Go
pytorch-build-resolver	PyTorch / 深度学习

测试与运维类

Agent	文件	职责
build-error-resolver	`build-error-resolver.md`	构建错误自动诊断修复
e2e-runner	`e2e-runner.md`	Playwright E2E 测试执行
doc-updater	`doc-updater.md`	代码变更后自动同步文档
database-reviewer	`database-reviewer.md`	数据库/Supabase Schema 审查

关键 Slash Commands

命令	功能
`/tdd`	启动完整 TDD 循环（RED→GREEN→REFACTOR）
`/plan`	生成结构化实现计划
`/review`	调用 code-reviewer agent
`/security-scan`	运行 AgentShield 安全扫描
`/e2e`	创建 E2E 测试
`/learn`	触发持续学习循环，提取当前会话模式
`/harness-audit`	评估你的 harness 配置，输出健康分数
`/loop-start`	启动自动化循环任务
`/quality-gate`	运行质量门控检查
`/model-route`	手动调整模型路由策略
`/sessions`	查看历史会话记录
`/instinct-import`	导入外部 instinct 模式
`/skill-create`	从当前仓库 git 历史生成专属 skill
`/configure-ecc`	交互式配置向导
`/pm2`	PM2 多服务管理
`/multi-plan`	多 agent 并行规划

两大杀手级特性

AgentShield：生产级安全扫描器

这是 ECC 最独特的功能，其他框架没有类似工具：

# 无需安装，直接扫描
npx ecc-agentshield scan

# 自动修复安全问题
npx ecc-agentshield scan --fix

# 三 agent 红蓝对抗深度分析（攻击者 + 防御者 + 审计者）
npx ecc-agentshield scan --opus --stream

扫描范围：CLAUDE.md、settings.json、MCP configs、hooks、agent definitions、skills——涵盖密钥泄露（14 种模式）、权限审计、hook 注入分析、MCP 服务器风险、agent 配置审查，共 5 个类别、102 条静态分析规则、1282 个测试用例。

持续学习系统（Continuous Learning v2）

ECC 会从你的会话中自动提取模式，生成「instinct」——带置信度评分的可复用知识单元：

/learn       # 触发当前会话学习循环
/skill-create   # 从 git 历史生成专属 skill

每次成功解决一个问题，ECC 会把解法提炼成 instinct，下次遇到类似场景会自动加载。随着使用时间增长，Claude 会越来越「懂」你的代码库。

选择性安装（Selective Install）

v1.9.0 引入 manifest 驱动的安装管线，不需要安装全部组件：

# 只安装 Java 相关 + 安全审查
ecc install --profile developer \
  --with lang:java \
  --with agent:security-reviewer \
  --without skill:continuous-learning

亮点

完整跨平台：Node.js 重写的 hook 脚本，Windows/macOS Intel/Linux 全支持
渐进式披露：skill 按需加载，不会撑爆上下文窗口
ECC 2.0 alpha：Rust 控制面板，已可用（dashboard、sessions、daemon 命令）
社区成熟：113+ 贡献者，7 种语言翻译，768 次提交

局限

功能庞大，配置学习成本高——建议从 --profile developer 基础包开始
MCP 配置过多会严重压缩上下文窗口（官方警告：全开可能从 200k 缩到 70k）
ECC Tools（GitHub App）Pro 功能需付费（$19/seat/month）
偏「配置层」而非「工作流引擎」，不直接解决 spec 规划和需求澄清

最佳实践

1. 先跑 /harness-audit，了解现状再优化

安装完成后第一件事不是开始写代码，而是评估当前 harness 配置质量：

/harness-audit
# 输出：各模块健康分数，指出缺失的规则/hook/agent

2. MCP 服务器不要全开——严守上下文预算

ECC 提供 14 个 MCP 配置，全开会让 200k 上下文窗口缩水到 70k。按项目需要选择：

// .claude/settings.json
{
  "disabledMcpServers": [
    "postgres",      // 不用数据库 MCP
    "slack",         // 不用 Slack 集成
    "stripe"         // 不用支付 MCP
  ]
}

3. 语言规则按项目精确安装，不要安装全量

Java 项目不需要 Python 规则，TypeScript 项目不需要 Kotlin agent：

# Spring Boot 项目的推荐安装
ecc install --profile developer \
  --with lang:java \
  --with agent:java-reviewer \
  --with agent:java-build-resolver \
  --with agent:security-reviewer \
  --with agent:tdd-guide

4. 让 /learn 变成每日习惯

每天工作结束时运行一次 /learn，让 ECC 从当天的会话中提取可复用模式。随着时间积累，Claude 会越来越熟悉你的代码库约定：

# 每日收工前：
/learn
# ECC 分析当日会话，提炼出 instinct，置信度 > 0.7 的自动保存

5. AgentShield 在上线前必跑

每次重大功能上线前，运行 AgentShield 扫描一遍 agent 配置：

# 快速扫描（日常）
npx ecc-agentshield scan

# 上线前深度扫描（三 agent 对抗分析）
npx ecc-agentshield scan --opus --stream

6. 用 /skill-create 把团队知识沉淀成 skill

ECC 最强大的功能之一：分析你的 git 历史，把团队的隐性操作流程变成显式 skill：

/skill-create         # 分析当前仓库
/skill-create --instincts  # 同时生成 instincts

比如：你们项目每次加新数据库表都要做「改 schema → 写 migration → 更新索引」，这个模式会被自动提炼成一个 /new-table skill。

7. 与 Superpowers 组合使用效果最好

ECC 解决的是「规则执行层」问题（记忆、一致性、安全），Superpowers 解决的是「工作流方法论」问题（设计、规划、TDD纪律）。两者互补：

ECC：提供持久记忆 + 安全规则 + 自动格式化 + 语言规范
Superpowers：提供 brainstorming + writing-plans + executing-plans + 验证纪律

安装顺序：先装 ECC（建立底层规则），再装 Superpowers（建立工作流纪律）。

ECC 标准开发流程

ECC 的流程以 hook 驱动 为核心——大多数环节是自动触发的，而不是手动调用命令。你的主要操作点集中在会话开始、任务启动和会话结束三个节点。

① 会话开始
   └─ SessionStart hook 自动触发
   └─ 加载上次会话摘要（context 恢复）
   └─ 加载项目语言规则（Java/TS/Python 等）
         ↓
② 任务规划
   └─ /plan  → planner agent 拆解任务结构
   └─ /harness-audit（可选，新项目首次必跑）
         ↓
③ TDD 实现循环
   └─ /tdd → tdd-guide agent 强制 RED→GREEN→REFACTOR
   └─ PostToolUse hook 自动触发：
         保存文件 → 自动格式化（Black/Prettier/gofmt）
         检测到 git commit --no-verify → 自动拦截
         检测到修改 linter 配置 → 重定向修复真正的代码
         ↓
④ 代码审查
   └─ /review → code-reviewer agent（质量 + 安全综合审查）
   └─ /security-scan → AgentShield（安全漏洞扫描）
         ↓
⑤ E2E 测试（如有前端）
   └─ /e2e → e2e-runner agent（Playwright 测试生成与执行）
         ↓
⑥ 文档同步
   └─ /review 内嵌触发 doc-updater agent（检测到代码变更自动更新文档）
         ↓
⑦ 提交与收尾
   └─ git commit（符合规范格式，ECC rules 强制执行）
   └─ Stop hook 自动触发：
         保存当前会话摘要到 ~/.claude/sessions/
         提取本次会话模式
         ↓
⑧ 持续学习（每日/每周）
   └─ /learn → 提炼 instinct，置信度评分
   └─ /skill-create → 从 git 历史生成专属 skill（新项目建立后运行一次）

关键理解：ECC 的流程中，③ 和 ⑦ 的大部分动作是自动发生的，你无需手动触发。Hook 系统在后台默默执行规范检查、格式化和上下文保存，你感知不到它的存在，但它在持续保障代码质量一致性。

ECC + Superpowers 叠加流程

适用场景：跨平台 solo 开发，既需要 ECC 的规则执行底座，又需要 Superpowers 的结构化工作流方法论。

两者的分工：ECC 管「规则自动执行」，Superpowers 管「流程纪律」。Superpowers 的技能在 ECC 的规则环境中运行，相当于流程纪律 × 规则强制执行的乘积效果。

【项目初始化（一次性）】
├─ ECC：ecc install --profile developer --with lang:java
├─ ECC：/harness-audit（验证配置健康）
└─ ECC：/skill-create（从 git 历史生成项目专属 skill）

【每次对话开始】
├─ ECC SessionStart hook（自动）：恢复上次会话摘要
└─ Superpowers /using-superpowers：建立技能查找模式

【需求阶段（有新功能/需求时）】
└─ Superpowers /superpowers:brainstorming
      苏格拉底式追问 → 澄清意图、约束条件、设计选择
      ↓（brainstorming 输出作为 planning 输入）

【规划阶段】
├─ ECC /plan → planner agent 初步拆解
└─ Superpowers /superpowers:writing-plans
      细化到 2~5 分钟/任务，含精确文件路径和验证命令

【开发分支隔离】
└─ Superpowers using-git-worktrees（自动触发）
      创建独立 worktree，不污染主分支

【实现阶段】
├─ Superpowers test-driven-development（自动触发）
│     RED（写失败测试）→ GREEN（最少代码）→ REFACTOR
├─ ECC PostToolUse hook（自动）：格式化 + 拦截危险操作
└─ Superpowers executing-plans 或 subagent-driven-development
      按计划执行，每步两阶段 review

【验证阶段】
├─ Superpowers verification-before-completion（自动触发）
│     必须展示真实命令输出才能声称完成
└─ ECC /security-scan（AgentShield）

【代码审查阶段】
├─ Superpowers requesting-code-review（自动触发）
├─ ECC /review → code-reviewer agent
└─ Superpowers receiving-code-review（收到反馈后触发）
      防止表演性同意，技术上验证反馈正确性

【遇到 Bug 时】
├─ Superpowers systematic-debugging（自动触发）
│     4 阶段根因分析
└─ ECC build-error-resolver agent（构建错误专项）

【收尾阶段】
├─ Superpowers finishing-a-development-branch（合并/PR/清理）
├─ ECC Stop hook（自动）：保存会话摘要
└─ ECC /learn：提炼本次会话 instinct

ECC + GSD 叠加流程

适用场景：长周期项目（跨多个月、多个 milestone），需要跨会话不丢失上下文，同时又需要 ECC 的规则执行底座。

两者的分工：ECC 管「单次会话内的规则执行」，GSD 管「跨会话的项目状态」。ECC 的 hook 保证每次会话代码质量一致，GSD 的 spec 和 milestone 保证整个项目方向不偏移。

【项目初始化（一次性）】
├─ ECC：安装语言规则 + /harness-audit + /skill-create
└─ GSD：/gsd:new-project
         ├─ Researcher agent：技术调研
         ├─ 交互式需求澄清（20+ 问题）
         └─ 生成 PROJECT.md + ROADMAP.md + .planning/ 状态目录

【每个 Milestone 开始】
└─ GSD：/gsd:new-milestone 或 /gsd:discuss-phase N
         定义本 milestone 范围、交付标准

【每个 Phase 规划】
├─ GSD：/gsd:plan-phase N（含 Plan-Checker agent 验证完整性）
└─ ECC：SessionStart hook 自动加载上次摘要（ECC 补充 GSD 的跨会话能力）

【执行阶段（每个任务）】
├─ GSD：/gsd:execute-phase N
│     ├─ 为每个任务开新的 200k 上下文窗口（解决 Context Rot）
│     ├─ 精确注入任务相关文件（不带历史包袱）
│     └─ 波次并行执行独立任务
├─ ECC PostToolUse hook（自动）：格式化 + 拦截危险操作
└─ ECC tdd-guide agent（在 GSD 执行任务时提供 TDD 保障）

【验证阶段】
├─ GSD：/gsd:verify-work N（Verifier agent 验收）
└─ ECC：/security-scan（上线前 AgentShield 安全扫描）

【代码审查】
├─ ECC：/review → code-reviewer agent
└─ GSD debug 知识库（.planning/debug/knowledge-base.md）同步更新

【发布阶段】
└─ GSD：/gsd:ship N（创建 PR，含验收证据）

【会话结束（每次）】
├─ ECC Stop hook（自动）：保存会话摘要
└─ GSD STATE.md 自动更新：记录当前 milestone 进度

【Milestone 收尾】
├─ GSD：/gsd:complete-milestone
├─ ECC：/learn（提炼本 milestone instinct）
└─ ECC：/skill-create --instincts（更新项目专属 skill）

三流程对比总结：

	ECC 单独	ECC + Superpowers	ECC + GSD
适合项目规模	任意	中小型，单 milestone	大型，多 milestone
需求澄清	无	✅ brainstorming	✅ discuss-phase
跨会话记忆	hook 摘要（轻量）	hook 摘要（轻量）	✅ 完整 spec 持久化
TDD 执行	hook 强制	✅ 技能严格执行	hook 强制
Context Rot 防御	无	无	✅ 每任务新窗口
安全扫描	✅ AgentShield	✅ AgentShield	✅ AgentShield
学习积累	✅ instinct 系统	✅ instinct 系统	✅ instinct + debug 知识库

适用场景

首选入口级框架。ECC 是目前覆盖最广的 Claude Code 增强系统，适合任何平台（Windows/Linux/Mac 全支持）。建议作为底层配置层，再按需叠加 Superpowers（方法论）或 GSD（上下文工程）。

二、Superpowers：纪律的化身

仓库：obra/superpowers | 版本：v5.0.7 | 安装：Claude Code 官方插件市场

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Superpowers 的核心洞察可以用一句话概括：AI 写代码的问题不是智能，是纪律。

它由 Jesse Vincent（Prime Radiant）在 2025 年 10 月发布，通过在 Claude Code 的 agent 循环中注入结构化「技能」（SKILL.md），强制 Claude 按照真实软件工程流程行事。每个技能本质上是一份精确的行为规范，告诉 Claude「遇到这类任务，必须按这个流程走」。

注意：/superpowers:brainstorm、/superpowers:write-plan、/superpowers:execute-plan 这三个旧命令已标记为 Deprecated（废弃），请使用下方表格中的新命令名。

完整技能命令清单

设计与规划类

技能	触发命令	说明
brainstorming	`/superpowers:brainstorming`	苏格拉底式需求澄清。在任何创作性工作之前必须使用——创建功能、构建组件、添加功能或修改行为。通过追问探索用户意图、需求与设计，把模糊想法变成清晰规范，再进入实现阶段。
writing-plans	`/superpowers:writing-plans`	详细实现计划生成。当你已有规格说明或多步骤任务需求时使用，在动任何代码之前。输出每步骤含精确文件路径、完整代码和验证步骤的执行计划，粒度控制在 2~5 分钟/任务。
using-superpowers	`/using-superpowers`	技能系统入门引导。每次对话开始时使用——建立技能查找和使用的工作方式，要求在任何回应（包括澄清问题）之前先调用 Skill tool 查询可用技能。

执行与并发类

技能	触发命令	说明
executing-plans	`/superpowers:executing-plans`	批量执行含检查点。当你已有书面实现计划，在独立会话中执行时使用。每个任务完成后有 review 检查点，防止错误累积传递。
subagent-driven-development	自动触发	当前会话快速迭代。在当前会话中执行实现计划时使用，带两阶段 review（规范合规性检查 → 代码质量检查）。与 executing-plans 的区别：不开新会话，适合较小任务。
dispatching-parallel-agents	自动触发	并行 agent 分发。当面对 2 个以上相互独立的任务时使用——这些任务之间没有共享状态或顺序依赖。Superpowers 会自动判断是否满足并行条件。
using-git-worktrees	自动触发	并行开发分支隔离。开始需要与当前工作区隔离的功能开发时，或执行实现计划之前使用。自动创建隔离的 git worktree，含智能目录选择和安全验证，防止不同任务互相污染。

质量保障类

技能	触发命令	说明
test-driven-development	自动触发	红绿重构循环。实现任何功能或 bug 修复时，在写实现代码之前使用。严格执行 RED（写失败测试）→ GREEN（写最少代码让测试通过）→ REFACTOR（重构）循环，含测试反模式参考清单。
requesting-code-review	自动触发	提交前 review 清单。完成任务、实现重要功能、或准备合并之前使用，验证工作是否满足需求。包含预检查清单，减少 reviewer 的来回沟通成本。
receiving-code-review	自动触发	响应 review 反馈。收到代码审查反馈时，在实施建议之前使用——尤其当反馈不清晰或技术上存疑时。要求技术严谨和验证，不接受表演性同意或盲目实施。
verification-before-completion	自动触发	完成前强制验证。准备声明工作完成、已修复、测试通过，或准备 commit/PR 之前使用。必须运行验证命令并确认输出，才能做出任何成功声明。核心原则：证据先于断言（evidence before assertions）。
systematic-debugging	自动触发	4 阶段根因分析。遇到任何 bug、测试失败或意外行为时，在提出修复方案之前使用。包含根因追踪（root-cause-tracing）、纵深防御（defense-in-depth）、条件等待（condition-based-waiting）等技术。

工作流收尾类

技能	触发命令	说明
finishing-a-development-branch	自动触发	分支合并决策工作流。实现完成、所有测试通过，需要决定如何整合工作时使用。提供结构化选项：直接合并、创建 PR 或清理，引导完成开发工作的收尾。

元技能类

技能	触发命令	说明
writing-skills	自动触发	创建新技能的最佳实践。创建新技能、编辑已有技能，或在部署前验证技能是否有效时使用。包含技能测试方法论，是扩展 Superpowers 能力的入口。

标准开发流程

这是 Superpowers 设计的黄金路径，每个步骤对应一个技能：

① using-superpowers（每次对话开始）
         ↓
② brainstorming（有新想法/功能时）
         ↓
③ using-git-worktrees（创建独立分支）
         ↓
④ writing-plans（生成实现计划）
         ↓
⑤ test-driven-development（写测试 → 写实现）
         ↓
⑥ executing-plans 或 subagent-driven-development
         ↓
⑦ verification-before-completion（强制验证）
         ↓
⑧ requesting-code-review（提交 review）
         ↓
⑨ receiving-code-review（处理反馈）
         ↓
⑩ finishing-a-development-branch（合并/PR/清理）

遇到 bug 随时插入 systematic-debugging；遇到可并行任务随时插入 dispatching-parallel-agents。

亮点

零依赖原则：整个框架没有任何 npm 依赖，纯 Markdown 技能文件，无供应链风险
技能自动触发：大多数技能不需要手动调用，Claude 判断场景后自动激活
超严的 PR 审核：仓库 PR 拒绝率 94%，每行技能文本都经过大量真实场景测试

局限

没有内置的跨会话任务持久化（需配合 Taskmaster 或 GSD）
本身不解决 Context Rot 问题
技能自动触发依赖模型判断，偶尔需要手动提示

最佳实践

1. 每次对话第一句话触发 using-superpowers

这是建立整个会话工作模式的基础。Claude 会知道自己有哪些技能可用，并在每次响应前先查询相关技能，而不是直接开始生成。

# 每次开启新 Claude Code 会话时：
"我们开始一个新任务，先使用 using-superpowers 建立工作模式"

# 或者直接描述任务，Claude 会自动触发
"我想在梯帮帮里加一个商品收藏功能"
→ Claude 自动触发 using-superpowers → brainstorming

2. brainstorming 不可跳过，即使需求看起来很清楚

这是新手最常跳过的步骤。brainstorming 的苏格拉底追问模式会挖出你没想到的约束条件，哪怕多花 10 分钟，也比三小时后推倒重来划算。

触发 brainstorming 后，Claude 会追问：
- 这个功能服务哪类用户，他们的核心诉求是什么？
- 与现有功能（购物车？历史记录？）有什么区别和关联？
- 最大收藏数量？收藏满了怎么处理？
- 商品下架后，收藏记录保留还是删除？
- 是否需要跨设备同步？

每个问题都可能改变技术选型决策。

3. writing-plans 要细到「让不熟悉项目的人也能执行」

每个任务必须包含：精确文件路径、完整代码片段或修改说明、可运行的验证命令。粒度目标：2~5 分钟/任务。

## 任务 3：创建收藏 Service 层

文件：src/main/java/com/tibb/service/FavoriteService.java

实现：
- addFavorite(Long userId, Long productId): void
- removeFavorite(Long userId, Long productId): void
- getFavoriteList(Long userId, PageParam page): IPage<FavoriteVO>
- isFavorited(Long userId, Long productId): boolean

验证：运行 FavoriteServiceTest，所有用例绿色通过

4. verification-before-completion 是不可绕过的门槛

Claude 有时会在没有真正验证的情况下声称「已完成」。这个技能强制要求在任何成功断言之前运行验证命令并附上输出：

# Claude 必须展示这样的证据，才能说「完成了」：
$ mvn test -pl module-favorite
...
Tests run: 23, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

5. systematic-debugging 的 4 阶段不能跳步

遇到 bug 时，不要让 Claude 直接「试试这个修法」。强制走完 4 阶段：

Phase 1 根因追踪：复现问题 → 隔离变量 → 找到根本原因（不是表象）
Phase 2 纵深防御：这个根因还有哪些其他表现形式？是否已存在其他地方？
Phase 3 条件验证：修复条件是否真正满足？不是「应该会好」，是「验证了会好」
Phase 4 回归保护：写测试防止同类问题复现

6. receiving-code-review 防止盲目妥协

这个技能最容易被忽视，但非常关键。它防止 Claude 在收到 review 反馈时「表演性同意」——即嘴上说「你说得对」，然后直接实施，而不验证反馈是否在技术上成立：

# 反例（不好）：
Reviewer: "这里应该用单例模式"
Claude: "明白，我立刻改成单例模式" → 直接改

# 正例（receiving-code-review 要求）：
Claude: "在实施之前先验证：当前实现是否真的存在多实例问题？
        查看 Bean 作用域配置... Spring 默认是单例，这里已经是 @Service
        → 反馈可能基于误解，需要和 reviewer 确认"

7. 用 superpowers-chrome 补全浏览器 QA 能力

新增的 obra/superpowers-chrome 插件跨平台（含 Linux 和 Intel Mac），弥补 Superpowers 原生没有 QA 能力的短板：

/plugin install superpowers-chrome@superpowers-marketplace

适用场景

入门首选，也是最佳底层方法论。不管最终选哪个框架，Superpowers 定义的这套流程（先设计后实现、TDD、强制验证、系统性调试）都值得内化为开发习惯。它和 GSD、Taskmaster 不冲突，可以叠加使用。

三、gstack：一个 YC CEO 的工程哲学

仓库：garrytan/gstack | 安装：git clone + ./setup

git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

2026 年 3 月 12 日，Garry Tan 在发布 gstack 的同一天，在 SXSW 对 Bill Gurley 说：「我睡眠只有四小时，我有 cyber psychosis。」这个框架是他把二十年产品经验打包进 AI agent 的产物。

gstack 的独特性在于角色驱动：它不是给 Claude 一堆规则，而是给它一组角色，每个角色有明确的职责边界和决策原则。

核心角色体系（28 个 slash commands）

角色	命令	职责
YC 合伙人	`/office-hours`	挑战你的产品假设，找出「10星产品」
CEO	`/plan-ceo-review`	四种模式：扩展/选择性扩展/保持/收缩
工程经理	`/plan-eng-review`	锁定架构、数据流、边界条件
设计师	`/design-review`	AI slop 检测，80 项视觉审计
安全官	`/cso`	OWASP Top 10 + STRIDE 威胁建模
QA Lead	`/qa`	打开真实 Chrome，用户视角测试
发布经理	`/ship`	测试覆盖率审计 + 一键发布

杀手级特性：持久化 Chromium

gstack 运行一个长寿命 Chromium daemon，通过 localhost HTTP 通信，每条命令延迟约 100ms。这意味着登录状态、Cookies、标签页在命令之间全部保留。这是目前 Claude Code 生态中最完整的浏览器 QA 能力。

重要限制

browse 二进制仅支持 macOS ARM64（Apple Silicon）。 Linux、Windows、Intel Mac 均不可用。这是架构决策，不是 bug，短期内不会改变。

最佳实践

1. 把 /office-hours 当成每个新功能的强制入口

gstack 的核心价值不是 QA，而是产品判断力。/office-hours 会挑战你的假设，找出需求背后真正的问题。Garry Tan 的用法是：任何新功能的第一步都是 /office-hours，而不是写代码。

/office-hours
> 我想给梯帮帮加一个「收藏商品」功能

Claude（CEO 角色）会追问：
- 用户为什么要收藏？是为了比价还是稍后购买？
- 已有购物车，收藏和购物车的区别是什么？
- 如果删掉这个功能，用户会流失吗？

2. 审查链的正确顺序：CEO → Eng → Design，不可颠倒

产品逻辑有问题时，技术实现再好也是浪费。顺序应该是：

/plan-ceo-review    # 确认产品方向正确
    ↓
/plan-eng-review    # 锁定技术架构，发现边界条件
    ↓
/plan-design-review # UI/UX 审查
    ↓
实现代码
    ↓
/review             # 代码审查（自动 fix + 标记风险）
    ↓
/qa                 # 真实浏览器测试
    ↓
/ship               # 发布

3. /freeze 是你在生产环境调试时的救命稻草

当你在 debug 一个生产 bug 时，最怕 Claude 改错文件。用 /freeze 把作用域锁定在出问题的模块：

/freeze src/payment    # Claude 只能修改 src/payment/ 下的文件
# ... 调试完毕后
/unfreeze

4. /careful 用于一切不可逆操作前

数据库迁移、权限变更、删除逻辑——任何改完不好回头的操作前都应该先跑 /careful。它会让 Claude 显式列出「爆炸半径」（blast radius）并请求确认。

5. /retro 作为周期性健康检查

每周跑一次 /retro，它会生成结构化复盘：commit 数、代码行数、测试覆盖率趋势、重复模式。比任何项目管理工具都直接：

/retro          # 当前项目
/retro global   # 跨所有项目汇总

6. Intel Mac / Linux 用户的降级方案

无法使用 browse 二进制的用户，可以搭配 obra/superpowers-chrome 或 Playwright MCP 补全 QA 能力，其余所有 Markdown 技能（CEO/Eng/Design review、/ship、/cso 等）均可正常使用。

适用场景

有 Apple Silicon Mac 的产品型开发者，尤其是重视 UI/UX 质量和安全的项目。如果你在用 Intel Mac 或 Linux，只能用 gstack 的规划和审查类命令，无法使用浏览器相关功能。

四、GSD：上下文工程的集大成者

仓库：gsd-build/get-shit-done | 安装：Claude Code 官方插件市场

npx get-shit-done-cc@latest
# 或指定平台
npx get-shit-done-cc --claude --global

GSD 由 TÂCHES 的 Lex Christopherson 构建，名字直白到不需要解释。它针对的核心问题是 Context Rot——随着会话时间增长，AI 的输出质量系统性下降。

解决思路

GSD 的答案是：不要试图在一个会话里完成所有事情。 每个任务都在新的 200k token 上下文窗口中执行，dispatch 时精确注入所需文件，不带历史包袱。

核心架构

29 个 Skills
12 个 Custom Agents（Researcher/Plan-Checker/Verifier）
2 个 Hooks（状态栏 + 更新检查器）

完整工作流：

/gsd:new-project
    ↓ Researcher agent（技术调研）
/gsd:discuss-phase N（澄清需求）
    ↓ Plan-Checker agent（验证完整性）
/gsd:plan-phase N（制定实现计划）
    ↓ 波次并行执行
/gsd:execute-phase N（每个任务独立提交 git）
    ↓ Verifier agent（验收）
/gsd:ship N（创建 PR）
    ↓
/gsd:new-milestone（循环）

波次并行执行

这是 GSD 最精妙的设计之一。依赖有向图自动计算可并行的任务组：

WAVE 1（并行）：User Model + Product Model
WAVE 2（并行）：Order API（依赖 Wave1）+ Cart API（依赖 Wave1）
WAVE 3：Checkout（依赖 Wave2 的全部）

每个任务完成后自动 git commit，可精确回滚到任意节点。

GSD-2：从 Prompt 框架到真正的 Agent

GSD 团队在 v1 爆火后推出了独立 CLI 版本 GSD-2（gsd-build/gsd-2），基于 Pi SDK 直接操控 agent harness，做到了 v1 只能「请求 LLM 做」的事情：

任务间真正清空上下文窗口
SQLite 状态机驱动，不依赖 LLM 判断
卡死检测和崩溃恢复
/gsd auto：完全自主模式，走开，回来看成果

最佳实践

1. /gsd:new-project 的问题不要「快速跳过」

GSD 启动流程会问你一系列问题：需要 Researcher agent 吗？是否激活 Plan-Checker？选哪个模型 profile？很多人图省事一路回车，结果丧失了 GSD 最核心的质量门控能力。

推荐配置：

Researcher：开启（技术选型前总是值得调研）
Plan-Checker：开启（防止计划遗漏需求）
Verifier：开启（验收阶段不省）
模型 profile：balanced（Opus 做规划，Sonnet 做执行）

2. 每个 Milestone 都应该是独立可交付的

GSD 的 milestone 设计原则：每个 milestone 结束时，产品应该处于可 demo 状态。不要把「后端接口」和「前端界面」拆成两个 milestone——它们合在一起才是完整功能。

# 好的 milestone 拆分：
# Milestone 1：用户注册登录（含前后端 + 测试）
# Milestone 2：商品列表展示（含搜索 + 筛选）
# Milestone 3：购物车 + 结算流程

# 不好的拆分：
# Milestone 1：所有后端 API
# Milestone 2：所有前端页面

3. 用 --chain 标志加速日常工作

对于已经熟悉的技术栈，discuss 阶段可以简短，直接链式执行：

/gsd:discuss-phase 1 --chain    # 讨论完自动进入 plan + execute
/gsd:quick "修复订单状态同步 bug" --research --full
#           ↑ 快速任务模式，--research 先调研，--full 开启所有质量门

4. 利用 debug 知识库避免重蹈覆辙

GSD 会把每次解决的 debug 会话追加到 .planning/debug/knowledge-base.md。养成习惯：遇到奇怪 bug 先搜这个文件：

grep -r "Redis connection" .planning/debug/knowledge-base.md

5. 多会话并行的隔离策略

GSD 支持并发多个 Claude 实例，用环境变量隔离：

# 终端 1：开发新功能
GSD_PROJECT=feature-payment claude

# 终端 2：同时修复另一个 bug
GSD_PROJECT=fix-auth-edge claude

两个会话状态完全隔离，互不干扰。

6. GSD-2 的自主模式使用时机

GSD-2 的 /gsd auto 适合明确、封闭的任务，不适合探索性工作：

# 适合 auto 模式：
# "实现商品搜索接口，支持关键词 + 分类 + 价格区间过滤，写单元测试"

# 不适合 auto 模式：
# "优化用户体验"（目标不明确）
# "调研竞品功能"（开放式探索）

自主模式运行时，在另一个终端保持监控，随时可以中断。

适用场景

Solo 开发者构建复杂长期项目的最佳选择。如果你的项目跨越多个月、多个 milestone，GSD 的跨会话持久化和波次执行能力无可替代。

五、BMAD-METHOD：被低估的敏捷框架

仓库：bmad-code-org/BMAD-METHOD | 安装：

npx bmad-method@latest install

BMAD（Breakthrough Method for Agile AI-Driven Development）是这六个框架里最完整的团队协作框架，但社区讨论热度明显低于前三。

差异化优势

Scale-Adaptive 智能：BMAD 根据项目复杂度自动调整规划深度：

项目级别	描述	PRD 要求	架构要求
Level 0	单个原子性改动	可选	可选
Level 1	1~10 个 story	推荐	推荐
Level 2	5~15 个 story	必须	必须
Level 3	12~40 个 story	必须	必须
Level 4	40+ story 企业级	必须	必须

12+ 专业 Agent 角色：Business Analyst → Product Manager → UX Designer → System Architect → Scrum Master → Developer → QA Engineer → Tech Writer，还有「Party Mode」可以让多个 agent 同时在一个会话中讨论。

官方中文文档：这是六个框架中唯一提供完整官方中文翻译的。v6 版本的 zh-CN 文档已覆盖所有核心工作流。

扩展包生态：DevOps、网络安全（bmad-cyber-sec）、游戏开发、AI/ML 工程、市场营销... 模块化扩展机制成熟。

已知问题

社区里有一份详细的「v6 稳定版结构性分析」直言：对于单人小项目，BMAD 的流程复杂度超过了它带来的收益。对于熟练用户，一个良好维护的 CLAUDE.md + 结构化计划可能更高效。

最佳实践

1. 用 bmad-help 作为你的工作流导航员

BMAD 的最大学习成本是搞不清楚「现在该用哪个 agent / 哪个 workflow」。随时召唤 bmad-help：

/bmad-help
> 我已经有了 PRD，现在想开始架构设计，下一步是什么？

bmad-help 会告诉你：
→ 当前应该进入 Phase 3（Solutioning）
→ 使用 /architecture workflow
→ 前置条件：PRD 已通过 /validate-prd 检查

2. PRD 质量决定一切——用 /validate-prd 强制检查

BMAD 最核心的文档是 PRD（产品需求文档）。PRD 写得模糊，后续所有 agent 的输出都会跟着模糊。在进入实现阶段前，必须跑：

/validate-prd    # BMAD 会逐条审查 PRD 的完整性和一致性

常见 PRD 问题：缺少边界条件、非功能需求（性能、安全）未定义、用户故事与验收标准脱节。

3. 按复杂度选择正确的 Level，不要高估项目规模

新手倾向于把所有项目设为 Level 3/4，结果陷入文档地狱。诚实评估：

Level 0：改一个按钮颜色 → 直接改，不需要 BMAD
Level 1：加一个简单 API 接口 → /bmad-quick-flow
Level 2：实现用户权限体系 → 完整 BMAD 流程
Level 3：重构核心模块 → 完整 BMAD + 所有 agent
Level 4：从零到一新产品 → 完整 BMAD + 多轮迭代

4. Party Mode 的正确使用场景

Party Mode 允许多个 agent 在同一会话中协作讨论，适合架构决策争议或技术方案 trade-off 分析：

启动 Party Mode：
"请让 Architect 和 Developer 同时参与讨论：
我们应该用微服务还是单体架构？项目规模是 3 人团队，
预期用户量 10 万，需要在 3 个月内上线。"

→ Architect 会强调可维护性和扩展性
→ Developer 会强调开发速度和复杂度
→ 你从两个视角获得更完整的判断

5. 善用 BMAD 扩展包，不要重复造轮子

遇到专业领域需求时，先看是否有官方扩展包：

需要测试策略？→ bmad-method-test-architecture-enterprise（TEA 模块）
需要安全审计？→ bmad-cyber-sec
做 AI/ML 项目？→ BMAD AI/ML Expansion Pack
需要市场营销文案？→ Marketing & Growth Module

npx bmad-method install --module tea    # 安装测试架构模块

6. 中文用户直接使用官方中文文档

BMAD 是唯一有完整官方中文文档的框架，建议中文用户直接查阅：

# 安装时选择中文
npx bmad-method@latest install --lang zh-CN

BMAD 的甜蜜点是：有明确产品规划需求的 solo 开发者或小团队，特别是项目处于 Level 2~3（中型功能集）时。

六、Taskmaster：任务持久化的标杆

仓库：eyaltoledano/claude-task-master | 安装：

npm install -g task-master-ai
# 或通过 Claude Code MCP
claude mcp add task-master-ai --scope user -- npx -y task-master-ai@latest

Taskmaster 和前四个框架有本质区别：它是任务管理层，而不是工作流引擎。它不告诉 Claude 怎么写代码，而是给 AI agent 提供一个可读写的永久任务状态。

核心工作流

1. 写 PRD → .taskmaster/docs/prd.txt
2. 解析 PRD → tasks.json（含依赖有向图 + 复杂度评分）
3. 问 AI "What's next?" → 返回满足依赖的最高优先级任务
4. 实现 → 标记完成 → 循环

技术亮点

36 个 MCP 工具，支持 13 种 IDE（Cursor、Claude Code、Windsurf、VS Code 等）
每次执行后自动 git commit，可精确追溯
波次并行：独立任务同时执行
配套 Hamster 协作平台，多人共享 task state

注意事项

Taskmaster 使用 MIT + Commons Clause 协议，这意味着你可以自由使用，但不能将其作为商业服务对外销售。对个人和企业内部使用没有限制。

最佳实践

1. PRD 是一切的起点——写得越详细，任务拆得越准

Taskmaster 的 AI 解析质量与 PRD 质量强正相关。好的 PRD 模板：

# 功能名称：用户收藏商品

## 背景
用户在浏览商品时希望收藏感兴趣的商品，方便稍后查看。

## 用户故事
- 作为买家，我可以点击商品页的心形图标收藏商品
- 作为买家，我可以在「我的收藏」页面查看所有收藏
- 作为买家，我可以取消收藏

## 验收标准
- 收藏状态实时同步（多设备）
- 商品下架后，收藏列表中保留记录但标注「已下架」
- 最大收藏数量：500 件

## 非功能需求
- 收藏/取消操作响应时间 < 200ms
- 数据持久化，不因登录设备变化丢失

2. 用 core 模式降低 token 消耗

Taskmaster 默认加载 36 个 MCP 工具，对长项目来说上下文占用过多。日常开发只用 7 个核心工具就够：

claude mcp add task-master-ai --scope user \
  --env TASK_MASTER_TOOLS="core" \
  -- npx -y task-master-ai@latest

core 模式包含：get_tasks、next_task、get_task、set_task_status、update_subtask、parse_prd、expand_task。70% 的日常操作这 7 个工具完全覆盖。

3. 复杂任务的「先分析后拆解」流程

不要直接让 AI 解析 PRD 就开始干。先做复杂度分析，再决定哪些任务需要拆成子任务：

# Step 1：解析 PRD，生成初始任务列表
task-master parse-prd .taskmaster/docs/prd.txt

# Step 2：分析复杂度，找出需要拆解的任务
task-master analyze-complexity
task-master complexity-report    # 查看可读报告

# Step 3：对复杂度高的任务拆子任务
task-master expand --id=5        # 拆解 task 5
task-master expand --all         # 批量拆解所有高复杂度任务

4. 利用依赖图保证执行顺序

Taskmaster 的核心能力是依赖有向图。要充分利用它，在 PRD 里就要写清楚依赖关系，或者在任务生成后手动补充：

# 查看当前可执行（所有依赖已满足）的任务
task-master next

# 手动添加依赖（task 8 依赖 task 5 完成后才能开始）
task-master add-dependency --id=8 --depends-on=5

5. 用 watch 模式监控多 agent 并行进度

同时开多个 Claude Code 会话处理不同任务时，用 watch 模式实时监控整体进度：

task-master list --watch    # 实时刷新任务状态
task-master list --compact  # 紧凑模式，减少输出干扰

6. 和 GSD 配合使用的最优姿势

Taskmaster 和 GSD 不是竞争关系，而是互补的两层：

GSD：定义「做什么」（Spec、规划、工作流引擎）
    ↓
Taskmaster：管理「做到哪了」（任务状态、依赖追踪、进度同步）

实际操作：用 /gsd:new-project 生成完整规划后，把执行计划导出为 Taskmaster 的 PRD 格式，让 Taskmaster 接管任务追踪。

适用场景

与 GSD 或 BMAD 配合效果最佳。用后者做项目规划和工作流引擎，用 Taskmaster 做任务追踪和跨会话状态管理。单独使用时，适合偏爱 Cursor/Windsurf 等 IDE 的开发者。

七、ZCF：国内开发者的配置神器

仓库：UfoMiao/zcf | 安装：

npx zcf

ZCF（Zero-Config Code Flow）是本文唯一一个国产工具，定位非常清晰：降低中国开发者使用 Claude Code 的上手门槛。

核心功能

交互式菜单，一键选择需要安装/配置的内容
整合国内主流 API 中转服务（Crazyrouter、PackyCode、AICodeMirror 等）
内置 BMad + spec 工作流安装
MCP 服务器一键配置
--lang zh-CN 中文界面

最佳实践

1. 团队初始化：一次跑，人人用

ZCF 最适合「给刚加入的团队成员配置环境」这个场景。把配置流程整理成 SOP：

# 团队 Claude Code 环境标准初始化流程：
npx zcf i

# 交互式菜单中依次选择：
# 1. API 配置（选择你们团队使用的中转服务）
# 2. 安装工作流（选 GSD 或 BMad，与团队保持一致）
# 3. MCP 服务器配置（按需选择 GitHub、Notion 等）
# 4. 语言设置（zh-CN）

把上述配置选项记录在内部文档里，团队成员 10 分钟内就能完成环境配置。

2. 使用 --lang zh-CN 降低团队沟通成本

对于以中文为工作语言的团队，统一用中文界面减少理解歧义：

npx zcf --lang zh-CN    # 中文菜单
npx zcf u               # 仅更新工作流，保留现有配置

3. 利用 ZCF 快速切换 API 中转服务

当某个中转服务不稳定时，用 ZCF 快速切换，而不是手动修改配置文件：

npx zcf
# 选择「CCR 快速配置菜单」→ 切换中转服务提供商

4. ZCF 不是终点，是起点

安装 ZCF 后，不要停在默认配置上。根据项目性质追加专项工具：

# ZCF 初始化完成后：

# 如果做长期产品开发
npx get-shit-done-cc --claude --global

# 如果需要 TDD 和 code review 纪律
/plugin install superpowers@superpowers-marketplace

# 如果团队用敏捷流程
npx bmad-method@latest install

使用建议

ZCF 不是独立的工作流框架，而是其他框架的安装向导。对于需要给团队多人配置 Claude Code 环境的场景（尤其是国内网络环境），ZCF 能节省大量重复配置时间。

通用最佳实践：不管用哪个框架

这些原则适用于所有框架，是让 Claude Code 持续高质量输出的基础。

CLAUDE.md 是你最重要的配置文件

每个项目根目录都应该有精心维护的 CLAUDE.md。它是 Claude 每次启动时读取的上下文，相当于给新员工的入职手册：

# 项目：梯帮帮

## 技术栈
- 后端：Java 17 + Spring Boot 3.x + MyBatis-Plus
- 前端：Vue 3 + UniApp（H5 + 小程序）
- 数据库：MySQL 8 + Redis 7
- 部署：阿里云 + Jenkins CI/CD

## 开发规范
- 所有 API 返回格式统一使用 R<T> 包装
- 数据库字段命名使用 snake_case
- 禁止在 Service 层直接调用 Mapper，必须通过接口
- 新功能必须先写单元测试

## 禁止事项
- 禁止直接修改 main 分支
- 禁止在代码里硬编码配置（使用 application.yml）
- 禁止跳过 code review 直接合并

## 当前 Milestone
Milestone 3：师傅接单系统（预计 2026-04-30 完成）

CLAUDE.md 要像代码一样迭代——发现 Claude 的行为不符合预期，就更新 CLAUDE.md，而不是每次重复提醒。

Context 管理是长期项目的关键

Claude Code 有上下文限制，超过阈值后质量下降。实践参考：

0% ~ 50%：正常工作，不用管
50% ~ 70%：开始注意，避免加载不必要的大文件
70% ~ 90%：主动运行 /compact 压缩上下文
90% +：立即 /clear 开新会话，或切换到有上下文管理的框架（GSD）

无论用哪个框架，都要养成「任务完成就开新会话」的习惯，不要在同一个会话里连续处理多个不相关任务。

每个任务都要有验收标准

在 prompt 里明确告诉 Claude「完成的标准是什么」：

# 不好的任务描述：
"帮我优化一下数据库查询"

# 好的任务描述：
"优化商品列表页的数据库查询。
完成标准：
1. 查询时间从当前 800ms 降到 200ms 以内（可用 EXPLAIN 验证）
2. 不改变返回数据结构
3. 保持分页逻辑不变
4. 写一个单元测试验证结果正确性"

让 git 成为你的安全网

配合任何框架使用时，都应该开启细粒度提交：

# 在 CLAUDE.md 或 settings.json 里配置：
# 每个独立改动（新增功能、bug 修复、重构）都应单独提交
# 提交信息格式：feat/fix/refactor(scope): 描述

# GSD 和 Taskmaster 会自动做到这一点
# 使用 Superpowers 时，execute-plan 阶段也会自动提交

细粒度的 git 历史让你可以精确回滚到任意节点，是 AI 大量生成代码时最重要的安全保障。

横向对比总表

维度	ECC	Superpowers	gstack	GSD	BMAD	Taskmaster	ZCF
Stars	142,000	130,617	62,000	46,900	43,200	25,900	5,700
核心定位	harness 优化系统	方法论骨架	虚拟工程团队	上下文工程	敏捷全周期	任务管理	配置安装器
安装方式	官方插件市场/npx	官方插件市场	git clone	官方插件市场	npx 安装	npm/MCP	npx
macOS Intel	✅	✅	⚠️ 浏览器不可用	✅	✅	✅	✅
Linux	✅	✅	⚠️ 浏览器不可用	✅	✅	✅	✅
Windows	✅	✅	⚠️ 浏览器不可用	✅	✅	✅	✅
上下文持久化	hook 自动保存	worktree 隔离	会话内学习	最强，跨会话	文件持久化	tasks.json	基础
浏览器/QA	E2E agent（Playwright）	chrome 插件	最强（ARM64）	gsd-browser	TEA 模块	无	无
安全扫描	AgentShield（最强）	无	OWASP+STRIDE	CI 扫描	模块支持	无	无
持续学习	instinct 系统	无	/learn 基础	debug 知识库	无	无	无
语言专项支持	12 语言生态	无	无	无	扩展包	无	无
设计审查	无	无	最强	无	UX Agent	无	无
多模型支持	NanoClaw v2 路由	有限	基础	按阶段分配	全面	36+ 提供商	含中国中转
中文支持	有（社区翻译）	无	无	无	官方中文	无	原生中文
TDD	hook 强制执行	核心特性	覆盖率审计	有限	QA Agent	需自配	无
Spec/需求澄清	无	brainstorming	office-hours	最完整	PRD 驱动	PRD 解析	无
Solo 适合度	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
开源协议	MIT	MIT	MIT	MIT	MIT	MIT+CC	MIT

选择策略

如果你是 Solo Founder，构建长周期产品（跨平台，含 Linux/Intel Mac/Windows）

底层：ECC + 方法论：Superpowers + 上下文：GSD

三者分工明确、互不冲突：

ECC：持久记忆 + 语言规则 + 安全防护（底层，始终运行）
Superpowers：brainstorming + TDD + 代码审查纪律（工作流方法论）
GSD：跨会话 spec 管理 + Context Rot 防御（长期项目核心）

# 安装顺序
/plugin marketplace add affaan-m/everything-claude-code
/plugin install everything-claude-code@everything-claude-code

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

npx get-shit-done-cc --claude --global

如果你是产品型创业者，重视 UI/UX 和上线质量（需要 Apple Silicon Mac）

ECC + gstack。

ECC 负责代码质量和安全底线，gstack 的 /plan-ceo-review + /qa（真实 Chrome）+ /ship 流水线负责产品质量和发布。

如果你在带小团队（3~10 人），有明确产品规划

ECC + BMAD-METHOD + Taskmaster。

ECC 统一团队代码规范（语言规则 + 安全扫描），BMAD 负责从 PRD 到架构设计，Taskmaster 负责任务分发和跨成员状态追踪。

如果你是 Cursor/Windsurf 用户，不用 Claude Code CLI

ECC（Cursor 支持完整 hook）+ Taskmaster 作为 MCP 服务。ECC 对 Cursor 提供 15 种 hook 事件类型的完整适配。

如果你是国内用户，刚开始接触 Claude Code

先跑 ZCF 配置 API 中转，再安装 ECC 作为基础层：

# 第一步：ZCF 配置 API 中转 + Claude Code 环境
npx zcf

# 第二步：安装 ECC（全平台底层基础）
/plugin marketplace add affaan-m/everything-claude-code
/plugin install everything-claude-code@everything-claude-code

# 第三步：视需要叠加 Superpowers 或 GSD
/plugin install superpowers@superpowers-marketplace

一些不那么显然的观察

ECC 成为事实上的配置标准。它不是最有个性的框架，但它解决了最基础的问题：让 AI agent 的行为可重复、可审计。其他框架解决「做什么、怎么做」，ECC 解决「确保按规则做」。两者不是替代关系。

框架不能替代思考。这七个框架都在设法用结构弥补 AI 的纪律缺失，但它们的前提是你知道自己要建什么。如果需求本身是模糊的，任何框架都救不了你。

Context Rot 是真实问题。超过一定长度后，Claude 的输出质量会系统性下降，而且你很难察觉——模型会保持自信的语气，同时输出越来越差的结果。GSD 的跨会话机制和 ECC 的 hook 持久化是目前两个最成熟的解法，方向不同，可以叠加。

安全不是可选项。随着 AI agent 获得越来越多的权限（读写文件、执行命令、访问 MCP 服务器），配置层的安全漏洞变得真实可利用。ECC 的 AgentShield 是目前唯一专门针对 agent 配置的安全扫描器，值得列入任何生产级部署的标准流程。

这个生态还在爆炸期。从 2025 年 9 月到 2026 年 4 月，ECC 从 0 到 14 万星，Superpowers 从 0 到 13 万星，整个框架生态的迭代速度远超传统工具。今天写的对比，三个月后可能已经需要更新。

本文数据基于 2026 年 4 月 10 日 GitHub 公开信息。相关框架均处于高速迭代阶段，建议直接参阅各仓库最新 README。

相关链接

2026 年 Claude Code 工作流框架全景对比：ECC、Superpowers、GSD、gstack、BMAD、Taskmaster、ZCF ​

背景：为什么需要这些框架？ ​

七大框架速览 ​

一、ECC（Everything Claude Code）：agent harness 性能优化系统 ​

核心数字（v1.10.0，2026-04-05） ​

四层架构 ​

完整 Agent 清单 ​

规划与设计类 ​

代码质量类 ​

语言专项类（按语言分 reviewer + build-resolver） ​

测试与运维类 ​

关键 Slash Commands ​

两大杀手级特性 ​

亮点 ​

局限 ​

最佳实践 ​

ECC 标准开发流程 ​

ECC + Superpowers 叠加流程 ​

ECC + GSD 叠加流程 ​

适用场景 ​

二、Superpowers：纪律的化身 ​

完整技能命令清单 ​

设计与规划类 ​

执行与并发类 ​

质量保障类 ​

工作流收尾类 ​

元技能类 ​

标准开发流程 ​

亮点 ​

局限 ​

最佳实践 ​

适用场景 ​

三、gstack：一个 YC CEO 的工程哲学 ​

核心角色体系（28 个 slash commands） ​

杀手级特性：持久化 Chromium ​

重要限制 ​

最佳实践 ​

适用场景 ​

四、GSD：上下文工程的集大成者 ​

解决思路 ​

核心架构 ​

波次并行执行 ​

GSD-2：从 Prompt 框架到真正的 Agent ​

最佳实践 ​

适用场景 ​

五、BMAD-METHOD：被低估的敏捷框架 ​

差异化优势 ​

已知问题 ​

最佳实践 ​

六、Taskmaster：任务持久化的标杆 ​

核心工作流 ​

技术亮点 ​

注意事项 ​

最佳实践 ​

适用场景 ​

七、ZCF：国内开发者的配置神器 ​

核心功能 ​

最佳实践 ​

使用建议 ​

通用最佳实践：不管用哪个框架 ​

CLAUDE.md 是你最重要的配置文件 ​

Context 管理是长期项目的关键 ​

每个任务都要有验收标准 ​

让 git 成为你的安全网 ​

横向对比总表 ​

选择策略 ​

如果你是 Solo Founder，构建长周期产品（跨平台，含 Linux/Intel Mac/Windows） ​

如果你是产品型创业者，重视 UI/UX 和上线质量（需要 Apple Silicon Mac） ​

如果你在带小团队（3~10 人），有明确产品规划 ​

如果你是 Cursor/Windsurf 用户，不用 Claude Code CLI ​

如果你是国内用户，刚开始接触 Claude Code ​

一些不那么显然的观察 ​

📚 相关文章

💬 评论

2026 年 Claude Code 工作流框架全景对比：ECC、Superpowers、GSD、gstack、BMAD、Taskmaster、ZCF

背景：为什么需要这些框架？

七大框架速览

一、ECC（Everything Claude Code）：agent harness 性能优化系统

核心数字（v1.10.0，2026-04-05）

四层架构

完整 Agent 清单

规划与设计类

代码质量类

语言专项类（按语言分 reviewer + build-resolver）

测试与运维类

关键 Slash Commands

两大杀手级特性

亮点

局限

最佳实践

ECC 标准开发流程

ECC + Superpowers 叠加流程

ECC + GSD 叠加流程

适用场景

二、Superpowers：纪律的化身

完整技能命令清单

设计与规划类

执行与并发类

质量保障类

工作流收尾类

元技能类

标准开发流程

亮点

局限

最佳实践

适用场景

三、gstack：一个 YC CEO 的工程哲学

核心角色体系（28 个 slash commands）

杀手级特性：持久化 Chromium

重要限制

最佳实践

适用场景

四、GSD：上下文工程的集大成者

解决思路

核心架构

波次并行执行

GSD-2：从 Prompt 框架到真正的 Agent

最佳实践

适用场景

五、BMAD-METHOD：被低估的敏捷框架

差异化优势

已知问题

最佳实践

六、Taskmaster：任务持久化的标杆

核心工作流

技术亮点

注意事项

最佳实践

适用场景

七、ZCF：国内开发者的配置神器

核心功能

最佳实践

使用建议

通用最佳实践：不管用哪个框架

CLAUDE.md 是你最重要的配置文件

Context 管理是长期项目的关键

每个任务都要有验收标准

让 git 成为你的安全网

横向对比总表

选择策略

如果你是 Solo Founder，构建长周期产品（跨平台，含 Linux/Intel Mac/Windows）

如果你是产品型创业者，重视 UI/UX 和上线质量（需要 Apple Silicon Mac）

如果你在带小团队（3~10 人），有明确产品规划

如果你是 Cursor/Windsurf 用户，不用 Claude Code CLI

如果你是国内用户，刚开始接触 Claude Code

一些不那么显然的观察