本文分享如何通过Claude Superpowers 技能体系提升产品开发全流程效率，从原型梳理到代码评审实现完整闭环。

1. 基于 superpowers brainstorm 梳理产品原型

1.1 工作流程

Brainstorm 技能帮助你在产品前期快速发散思维，梳理清晰的产品结构：

1.2 示例：用户管理系统原型梳理

Prompt 示例：

使用 superpowers brainstorm 帮我梳理一个用户管理系统的产品原型，要求包含：
- 用户注册登录模块
- 权限管理模块
- 用户信息管理模块
- 操作日志模块

输出示例：

用户管理系统产品原型梳理
1. 用户故事
作为用户，我可以通过邮箱/手机号注册账号
作为用户，我可以通过密码/验证码登录
作为管理员，我可以查看所有用户列表
作为管理员，我可以分配不同角色权限
作为系统，我需要记录所有用户操作日志
2. 功能模块拆分
模块	功能点
认证授权	注册、登录、Token刷新、登出
用户管理	查询、创建、编辑、删除用户
权限管理	角色定义、权限分配
操作日志	日志记录、日志查询

1.3 最佳实践

先发散后收敛：Brainstorm 阶段先尽可能多列出需求点，再进行优先级排序
可视化输出：要求输出 Mermaid 流程图或架构图，更直观理解整体结构
模块分层：按照业务领域拆分模块，避免模块之间过度耦合

2. 基于 superpowers using-git-worktrees 创建 Git Worktree 加速并行开发

2.1 为什么使用 Git Worktree

传统多分支开发需要频繁切换分支，影响开发效率：
传统开发方式 Git Worktree 方式
频繁 git stash / git checkout 多个工作目录并行开发
单个分支只能改一个功能 多功能同时开发互不干扰
依赖重新安装 共享 node_modules，节省空间

2.2 使用示例

创建多个 Git Worktree：

# 查看现有 worktree
git worktree list

# 从 main 分支创建新的 worktree 用于开发用户认证功能
git worktree add -b feature/auth-service ./worktrees/auth-service main

# 创建权限管理功能 worktree
git worktree add -b feature/permission-service ./worktrees/permission-service main

# 创建日志模块 worktree
git worktree add -b feature/log-service ./worktrees/log-service main

项目目录结构：

project-root/
├── .git/
├── main/                      # 主分支
├── worktrees/
│   ├── auth-service/          # 认证功能分支
│   ├── permission-service/    # 权限功能分支
│   └── log-service/           # 日志功能分支
└── node_modules/              # 共享依赖 (通过软链)

配置共享依赖：

# 在每个 worktree 中创建软链接到主目录的 node_modules
ln -s ../../node_modules ./node_modules

2.3 清理用完的 Worktree

# 删除不再使用的 worktree
git worktree remove worktrees/old-feature

# 或者
git worktree prune

2.4 优势

✅ 并行开发多个功能互不影响
✅ 无需频繁切换分支，保持开发上下文
✅ 共享依赖，节省磁盘空间
✅ 方便在不同功能分支之间对比代码

3. 基于 superpowers:write-plan 生成规范的接口文档定义

按照执行计划生成产品原型对应的接口文档定义。

3.1 文档组织结构

docs/
├── API.md             # 总目录索引
├── COMMON.md          # 公共定义
│   ├── 错误码定义
│   ├── 枚举定义
│   ├── 公共分页参数
│   └── 公共返回封装
├── AUTH.md            # 认证模块接口
├── USER.md            # 用户模块接口
├── PERMISSION.md      # 权限模块接口
└── LOG.md             # 日志模块接口

3.2 COMMON.md 示例

# 公共定义 COMMON

## 1. 公共返回封装
### 响应格式
所有 API 统一返回如下格式：
```typescript
interface ApiResponse<T> {
  code: number;          // 业务状态码
  message: string;       // 响应消息
  data: T;               // 响应数据
  requestId: string;     // 请求ID，用于问题追踪
  timestamp: number;     // 服务器时间戳
}

2. 公共分页参数
   请求参数

interface PaginationQuery {
  page: number;          // 页码，从1开始
  pageSize: number;      // 每页条数，默认20
}

分页返回

interface PaginationResult<T> {
  list: T[];
  total: number;         // 总条数
  page: number;
  pageSize: number;
  totalPages: number;
}

3. 错误码定义

错误码	含义
0	成功
1001	参数错误
1002	未授权
1003	权限不足
1004	资源不存在

1005	系统内部错误
2001	用户已存在
2002	用户不存在
2003	密码错误

3.3 业务接口文档示例 AUTH.md

# 认证模块接口 AUTH

## 1. 用户注册
### 接口地址
`POST /api/v1/auth/register`

### 请求参数
interface RegisterRequest {
  email: string;         // 邮箱
  password: string;      // 密码
  nickname: string;      // 昵称
}
### 返回数据
interface RegisterResponse {
  userId: string;
  accessToken: string;
  refreshToken: string;
}

### 响应示例
{
  "code": 0,
  "message": "success",
  "data": {
    "userId": "abc123",
    "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "refreshToken": "def456..."
  },
  "requestId": "req-123456",
  "timestamp": 1712678400000
}
## 2. 用户登录
### 接口地址
`POST /api/v1/auth/login`
// ... 其他接口定义

3.4 最佳实践

i. 统一规范：所有接口遵循相同的请求和响应格式
ii. 类型定义完整：每个接口都要有清晰的 TypeScript 类型定义
iii. i示例完整：提供完整的请求和响应示例，方便开发对接
iv. 分组清晰：每个 API group 对应单独文档，公共定义放到 COMMON

---

4. 基于 superpowers:execute-plan 执行接口功能代码实现

按照 write-plan 生成的接口文档，执行代码实现。

4.1 分层架构实现示例

src/
├── controllers/     # 控制层
├── services/        # 业务逻辑层
├── repositories/    # 数据访问层
├── models/          # 数据模型/类型定义
├── middlewares/     # 中间件
├── utils/           # 工具函数
└── index.ts         # 入口文件
```Plain Text


### 4.2 示例代码：用户注册接口实现
**controller `src/controllers/AuthController.ts`:**
```typescript
import { Request, Response } from 'express';
import { AuthService } from '../services/AuthService';
import { ApiResponse, RegisterRequest } from '../models/Auth';

export class AuthController {
  constructor(private authService: AuthService) {}

  async register(req: Request, res: Response): Promise<void> {
    const { email, password, nickname } = req.body as RegisterRequest;
    
    try {
      const result = await this.authService.register(email, password, nickname);
      res.json({
        code: 0,
        message: 'success',
        data: result,
        requestId: req.id,
        timestamp: Date.now()
      } as ApiResponse<typeof result>);
    } catch (error) {
      res.json({
        code: error.code,
        message: error.message,
        data: null,
        requestId: req.id,
        timestamp: Date.now()
      });
    }
  }
}

**service ** src/services/AuthService.ts :

import { UserRepository } from '../repositories/UserRepository';
import { HashUtil } from '../utils/HashUtil';
import { TokenUtil } from '../utils/TokenUtil';
import { RegisterRequest, RegisterResponse } from '../models/Auth';

export class AuthService {
  constructor(
    private userRepository: UserRepository,
    private hashUtil: HashUtil,
    private tokenUtil: TokenUtil
  ) {}

  async register(data: RegisterRequest): Promise<RegisterResponse> {
    // 检查用户是否已存在
    const existingUser = await this.userRepository.findByEmail(data.email);
    if (existingUser) {
      throw new Error('2001: 用户已存在');
    }

    // 加密密码
    const passwordHash = await this.hashUtil.hash(data.password);
    
    // 创建用户
    const user = await this.userRepository.create({
      email: data.email,
      passwordHash,
      nickname: data.nickname,
    });

    // 生成 token
    const accessToken = this.tokenUtil.generateAccessToken(user.id);
    const refreshToken = this.tokenUtil.generateRefreshToken(user.id);

    return {
      userId: user.id,
      accessToken,
      refreshToken,
    };
  }
}

4.3 执行计划要点

按模块实现：按照接口文档分组依次实现，一个模块测试完成再进行下一个
遵循接口定义：严格按照接口文档定义的参数和返回格式实现
分层清晰：保持各层职责单一，便于后续维护和测试
添加注释：关键业务逻辑添加清晰注释

---

5. 基于 superpowers test-driven-development 测试驱动开发

5.1 TDD 工作流

5.2 测试用例示例 AuthService.test.ts

import { AuthService } from './AuthService';
import { UserRepository } from '../repositories/UserRepository';
import { HashUtil } from '../utils/HashUtil';
import { TokenUtil } from '../utils/TokenUtil';

describe('AuthService', () => {
  let userRepository: jest.Mocked<UserRepository>;
  let hashUtil: jest.Mocked<HashUtil>;
  let tokenUtil: jest.Mocked<TokenUtil>;
  let authService: AuthService;

  beforeEach(() => {
    userRepository = {
      findByEmail: jest.fn(),
      create: jest.fn(),
    } as any;
    hashUtil = {
      hash: jest.fn(),
    } as any;
    tokenUtil = {
      generateAccessToken: jest.fn(),
      generateRefreshToken: jest.fn(),
    } as any;
    authService = new AuthService(userRepository, hashUtil, tokenUtil);
  });

  it('应该成功注册新用户', async () => {
    // 准备
    userRepository.findByEmail.mockResolvedValue(null);
    hashUtil.hash.mockResolvedValue('hashed_password');
    userRepository.create.mockResolvedValue({ id: 'user_123', email: 'test@example.com' });
    tokenUtil.generateAccessToken.mockReturnValue('access_token');
    tokenUtil.generateRefreshToken.mockReturnValue('refresh_token');

    // 执行
    const result = await authService.register({
      email: 'test@example.com',
      password: 'password123',
      nickname: 'Test User',
    });

    // 断言
    expect(result.userId).toBe('user_123');
    expect(result.accessToken).toBe('access_token');
    expect(result.refreshToken).toBe('refresh_token');
    expect(userRepository.findByEmail).toHaveBeenCalledWith('test@example.com');
  });

  it('用户已存在时应该抛出错误', async () => {
    // 准备
    userRepository.findByEmail.mockResolvedValue({ id: 'existing' });

    // 执行 & 断言
    await expect(authService.register({
      email: 'existing@example.com',
      password: 'password123',
      nickname: 'Existing',
    })).rejects.toThrow('2001: 用户已存在');
  });
});

5.3 运行测试

# 运行所有测试
npm test

# 运行指定测试文件
npm test -- AuthService.test.ts

# 生成覆盖率报告
npm test -- --coverage

5.4 测试覆盖率示例

File	% Stmts	% Branch	% Funcs	% Lines
AuthService.ts	100%	100%	100%	100%
UserRepository.ts	95%	90%	100%	95%

---

6. 基于 superpowers requesting-code-review 进行代码评审

6.1 代码评审请求模板

## 代码评审请求: 用户认证模块实现

### 📝 变更概述
实现了用户注册和登录功能，包含：
- 用户注册接口
- 用户登录接口
- Token 刷新接口
- 密码加密

### 📁 修改文件
- `src/controllers/AuthController.ts` - 新增
- `src/services/AuthService.ts` - 新增
- `src/models/Auth.ts` - 新增
- `src/repositories/UserRepository.ts` - 新增
- `tests/services/AuthService.test.ts` - 新增

### 🔍 重点需要评审的部分
1. 密码加密逻辑是否安全
2. Token 生成方式是否合理
3. 错误处理是否完善
4. 测试用例是否覆盖完整

### ✅ 已完成
- [x] 代码符合项目编码规范
- [x] 所有测试用例通过
- [x] 接口文档已更新

### 📸 测试结果截图
![测试结果](../../screenshots/auth-test-results.png)

### ❓ 疑问
- 密码加盐策略是否需要调整？请评审同学帮忙看看。

6.2 代码评审检查清单

检查项 状态
✅ 功能是否符合需求 通过
✅ 接口定义是否与文档一致 通过
✅ 错误处理是否完善 通过
✅ 代码是否有注释 通过
✅ 是否包含测试用例 通过
⚠️ 性能是否需要优化 需要评审
✅ 安全问题 通过

6.3 最佳实践

小批量评审：每次评审不要超过 400 行代码，拆分多个 PR
明确重点：指明哪些部分需要重点关注，节省评审者时间
提供测试结果：附上测试通过截图和覆盖率报告
及时回应：评审反馈及时修改和回复

---

总结：完整开发流程图

效率提升统计

阶段	传统开发	Superpowers 工作流	提升
原型梳理	2-3天	2-4小时	80%↓
接口文档	1-2天	1-2小时	90%↓
并行开发效率	受切换分支影响	多分支同时开发	50%↑
代码评审	沟通成本高	标准化模板	60%↓沟通成本

Bug率 高 测试驱动开发 70%↓线上Bug

---

结语

通过 Claude Superpowers 这套技能体系，可以实现从产品原型到代码评审全流程的 AI 辅助开发，保持清晰的开发节奏，提高代码质量，减少沟通成本。关键要点：
i. 先规划后实现：先梳理原型和接口文档，再写代码
ii. 并行开发：使用 Git Worktree 同时开发多个功能
iii. 测试驱动：先写测试再写实现，保证代码质量
iv. 规范评审：标准化代码评审请求，提高评审效率
完整示例项目结构

your-project/
├── docs/
│   ├── API.md
│   ├── COMMON.md
│   ├── AUTH.md
│   ├── USER.md
│   ├── PERMISSION.md
│   └── LOG.md
├── src/
│   ├── controllers/
│   ├── services/
│   ├── repositories/
│   ├── models/
│   ├── middlewares/
│   ├── utils/
│   └── index.ts
├── tests/
│   ├── services/
│   └── controllers/
├── worktrees/
│   ├── auth-service/
│   ├── permission-service/
│   └── log-service/
└── package.json

如果你正在使用 Claude 进行开发，可以试试这套工作流，相信会给你带来不错的效率提升！