Claude Code 安装与 Superpowers 实战：从想法到发布的工程化工作流

Tue, 28 Apr 2026 00:00:00 +0000

为什么需要 Superpowers

Claude Code 原生已经很强——读代码、写文件、跑命令，日常够用。但面对复杂任务时，它容易"一步到位直接写"，然后反复修 bug。你不是在写代码，是在和 AI 打乒乓球。

Superpowers 解决的问题就是这个。它是一套工程化工作流，把软件开发的标准流程——澄清需求、写设计文档、拆分任务、TDD、调试、审查、验证——固化为 18 个 Skill。Claude 拿到的不再是一句"帮我做 X"，而是一整套经过验证的做事方法。

下面用一个完整的 Go 项目——从零写一个并发安全的缓存库——把 18 个 Skill 串一遍。

安装

Claude Code

Windows 下需要 Node.js 20+，推荐 npm 全局安装：

`1`	`npm install -g @anthropic-ai/claude-code`

macOS/Linux 同理。装完后终端输入 claude 启动，首次会引导登录 Anthropic 账号并绑定 API Key。

Superpowers 插件

`1`	`npx skills add anthropics/skills@superpowers -g -y`

安装后重启 Claude Code，npx skills list 确认看到 18 个 superpowers: 前缀的 Skill。无需额外配置，对话中自动触发。

实战：Go 并发安全缓存库

我们的目标是写一个带 TTL 过期、LRU 淘汰、并发安全的 Go 缓存库。下面按 Superpowers 的完整流程走一遍。

1. 想法 → brainstorming

在项目目录下打开 Claude Code，输入：

我想写一个 Go 的并发安全缓存库，支持 TTL 过期和 LRU 淘汰策略

这时 Superpowers 的 brainstorming Skill 自动介入——Claude 不会直接写代码，而是开始追问：

几个问题帮我理清需求：

缓存容量是固定的还是可配置的？有默认值吗？

TTL 是在 Set 时指定每个 key 独立的过期时间，还是全局统一？

API 风格偏好——Get(key) (value, bool) 这种标准模式，还是需要额外返回 error？

淘汰策略是纯 LRU，还是需要支持 LFU / ARC 等扩展接口？

追问结束后，Claude 提出两种方案：

方案 A — sync.Map + 惰性删除：利用 sync.Map 的无锁读，过期 key 在 Get 时惰性清理，简单但 LRU 维护麻烦
方案 B — 分片 + mutex + 双向链表（推荐）：标准做法，每个分片独立锁，链表维护访问顺序，TTL 用 time.AfterFunc 或惰性检查

确认方案 B 后，Claude 把设计文档写入 docs/superpowers/specs/。

2. 设计 → writing-plans

brainstorming 结束后，Claude 自动调用 writing-plans，将设计文档转化为可执行的任务列表：

1. 定义 Cache 接口（Set/Get/Del/Len）
2. 实现 item 结构体（value + expiration + list.Element）
3. 实现 LRU 双向链表（promote + evict）
4. 实现分片锁管理器（hash key → shard）
5. 实现 TTL 过期检查（惰性删除 + 可选后台清理）
6. 编写并发安全测试（-race 检测）
7. 编写基准测试（benchmark）

每个任务有明确的输入、输出和验收标准，不再是一个模糊的"帮我写个缓存库"。

3. 隔离 → using-git-worktrees

正式编码前，Claude 建议创建隔离的工作树：

这个改动不小，建议先在 worktree 里做，不会弄乱 main 分支。

接受后，Claude 调用 EnterWorktree，在 .claude/worktrees/ 下创建独立分支和目录。所有的文件变更都隔离在这个环境里，随时可以丢弃重来，不影响主分支。

4. 编码 → TDD + 并行 Agent

test-driven-development Skill 介入——Claude 先写测试：

func TestCache_SetAndGet(t *testing.T) {
    c := cache.New(cache.WithMaxItems(100))
    c.Set("key1", "value1", 5*time.Second)
    val, ok := c.Get("key1")
    assert.True(t, ok)
    assert.Equal(t, "value1", val)
}

func TestCache_Expiry(t *testing.T) {
    c := cache.New(cache.WithMaxItems(100))
    c.Set("key1", "value1", 50*time.Millisecond)
    time.Sleep(100 * time.Millisecond)
    _, ok := c.Get("key1")
    assert.False(t, ok)
}

测试写完后才进入实现。此时 dispatching-parallel-agents 发挥作用——LRU 链表实现和 TTL 过期逻辑是两个独立任务，Claude 同时启动两个 subagent 并行处理：

1
2

[subagent-1] 实现 LRU 双向链表 + promote + evict
[subagent-2] 实现 TTL 惰性过期检查 + 后台清理 goroutine

两个 agent 完成后，主 Agent 把它们的结果合并到分片锁管理器中。并行的好处是等待时间减半——LRU 链表和 TTL 互不依赖，完全可以同时写。

5. 排查 → systematic-debugging

编码完成后运行测试：

`1`	`go test -race ./...`

咦，race detector 报了一个 data race。Claude 没有猜原因，而是触发 systematic-debugging：

观察到的现象：TestCache_ConcurrentSet 在 -race 下报 data race，指向 item.lastAccess 字段的并发写入。

假设一：promote 操作没有在锁内修改链表节点假设二：TTL 检查的 goroutine 和 Set 之间没有同步

先验证假设一：在 promote 调用处加 trace 日志，确认是否在 shard.mu.Lock() 之外执行。

逐步排除后定位到根因：Get 中的 promote 操作读取了 item.lastAccess 但未加写锁。修复后 -race 干净通过。

整个过程不是 Claude 盲目改代码，而是形成假设 → 逐个验证 → 定位根因，和人类 debug 的思维方式一致。

6. 审查 → requesting-code-review + receiving-code-review

测试通过后，Claude 调用 requesting-code-review，由独立的 code-reviewer agent 审查代码。审查结果返回：

缺少 Keys() 方法，调用方无法遍历所有有效 key

TTL 后台清理 goroutine 没有优雅退出机制，调用 New() 多次会泄漏 goroutine

WithMaxItems(0) 应该视为无限制，当前实现会 panic

receiving-code-review Skill 此时介入——它提醒 Claude 不要"全盘接受所有建议"：

评估每条审查意见：第一条确实需要，第二条必须修，第三条是防御性编程可以加。不要为了"让 reviewer 满意"而过度工程。

修复这三条后重新运行测试，确认没有引入回归。

7. 验证 → verification-before-completion

代码改完了，Claude 没有直接说"搞定了"，而是执行 verification-before-completion：

1
2
3

go test -race -count=3 ./...      # 重复三次确认无 flaky
go test -bench=. -benchmem ./...   # 基准测试通过
go vet ./...                       # 静态分析无警告

三项全部通过后，Claude 才报告完成。先验证再宣称——这是 Superpowers 的核心纪律。

8. 收尾 → finishing-a-development-branch

功能验证通过，finishing-a-development-branch 给出三个选项：

合并到 main（本地直接 merge）

创建 PR（推到远程并 gh pr create）

保留当前分支，稍后处理

选择 2 后，Claude 分析 diff，生成 PR 标题和描述，推送到远程并创建 Pull Request。Worktree 清理后回到原工作目录，main 分支干干净净。

Superpowers Skill 速查表

阶段	Skill	用途
构思	`brainstorming`	需求澄清、方案探索、设计文档
设计	`writing-plans`	设计文档 → 可执行任务清单
设计	`executing-plans`	在独立会话中按计划逐步执行
编码	`using-git-worktrees`	创建隔离工作树，避免污染主分支
编码	`test-driven-development`	先写测试再写实现
编码	`dispatching-parallel-agents`	并行调度 subagent 处理独立任务
编码	`subagent-driven-development`	在独立 subagent 中执行任务
调试	`systematic-debugging`	假设驱动、逐步验证的调试方法
审查	`requesting-code-review`	请求独立 code-reviewer 审查代码
审查	`receiving-code-review`	评估审查反馈，有选择地采纳
验证	`verification-before-completion`	运行验证命令后才宣称完成
发布	`finishing-a-development-branch`	合并/PR/保留的结构化收尾
发布	`gh-cli`	GitHub CLI 操作辅助
发布	`git-commit`	自动生成规范 commit 信息
工具	`using-superpowers`	Superpowers 总入口，引导正确使用
工具	`find-skills`	搜索和发现第三方 Skill
工具	`writing-skills`	创建和编辑自定义 Skill
工具	`update-config`	配置 settings.json（权限、环境变量等）

小结

Superpowers 的价值不是"让 Claude 更强"，而是让 Claude 做事更有章法。从想到做、从做到上线，每个阶段有对应的 Skill 把流程框住——需求先澄清、方案先设计、代码先测试、完成先验证。这恰好是优秀工程师的工作习惯，现在通过 Skill 机制固化到了 AI 编程流程里。

Superpowers on 你怂你mua