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

数据基准：2026 年 4 月 3 日。Star 数来自 GitHub issues/discussions 页实时确认，非估算。

这半年 Claude Code 生态爆炸了。

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

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

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

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

1. 模型跳过设计直接开始写代码

2. 写了几百行后偏离原始需求

3. 会话上下文越来越长，质量开始下降（Context Rot）

4. 模型开始「自信地错误」：声称完成但实际有大量遗漏

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

六大框架速览

一、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（废弃），请使用下方表格中的新命令名。

完整技能命令清单

设计与规划类

执行与并发类

质量保障类

工作流收尾类

元技能类

标准开发流程

这是 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 问题

• 技能自动触发依赖模型判断，偶尔需要手动提示

更新

• 技能在你更新插件时会自动更新

/plugin update superpowers

最佳实践

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）

杀手级特性：持久化 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 根据项目复杂度自动调整规划深度：

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 大量生成代码时最重要的安全保障。

横向对比总表

选择策略

如果你是 Solo Founder，构建长周期产品

主力 GSD + 底座 Superpowers。

GSD 解决跨会话记忆问题，Superpowers 提供 TDD 和 code review 纪律。两者互补，不冲突。用 ZCF 给团队成员初始化环境。

如果你是产品型创业者，重视 UI/UX 和上线质量

gstack（需要 Apple Silicon Mac）。

/plan-ceo-review 帮你想清楚产品方向，/qa 用真实浏览器测试，/cso 扫安全漏洞。整个发布流水线在 /ship 里一条命令完成。

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

BMAD-METHOD + Taskmaster。

BMAD 负责从 PRD 到架构设计，Taskmaster 负责任务分发和状态追踪，支持多人并行工作。

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

Taskmaster 作为 MCP 服务。支持最多 IDE，几乎可以接入任何工作流。

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

先跑 ZCF 做基础配置，再安装 GSD 或 Superpowers。

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

# 第二步：安装 GSD
# 在 Claude Code 内：
# npx get-shit-done-cc --claude --global

# 第三步（可选）：加 Superpowers
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

一些不那么显然的观察

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

Context Rot 是真实问题。上面提到 GSD 解决 Context Rot，这不是营销噪音。超过一定长度后，Claude 的输出质量会系统性下降，而且你很难察觉——模型会保持自信的语气，同时输出越来越差的结果。任何严肃的长期项目都需要考虑这个问题。

这个生态还在爆炸期。Superpowers 在五个月内从 0 到 13 万星，gstack 在一周内从 0 到 2.3 万星，整个框架生态的迭代速度远超传统工具。今天写的对比，半年后可能已经不够准确。

Anthropic 在推进官方化。官方插件市场的出现意味着 Anthropic 在有意识地让第三方框架成为 Claude Code 生态的一部分。可以预期未来会有更多框架通过官方渠道分发和更新。

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

相关链接

• obra/superpowers

• garrytan/gstack

• gsd-build/get-shit-done

• gsd-build/gsd-2

• bmad-code-org/BMAD-METHOD

• eyaltoledano/claude-task-master

• UfoMiao/zcf