SuperPM pm-tech

install

source · Clone the upstream repo

git clone https://github.com/konglong87/superPM

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/konglong87/superPM "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/02-solution-design/pm-tech" ~/.claude/skills/konglong87-superpm-pm-tech && rm -rf "$T"

manifest: skills/02-solution-design/pm-tech/SKILL.md

source content

Preamble (run first)

# 检查方案设计目录
mkdir -p docs/02-方案设计

# 检查前置文档
echo "📊 正在检查前置文档..."

if [ -f "docs/02-方案设计/PRD产品需求文档.md" ]; then
  echo "✅ PRD文档 - 已找到"
else
  echo "⏳ PRD文档 - 未找到"
fi

if [ -f "docs/02-方案设计/原型设计方案.md" ]; then
  echo "✅ 原型设计方案 - 已找到"
else
  echo "⏳ 原型设计方案 - 未找到"
fi

执行流程

步骤 1: 确定技术对接范围

使用 AskUserQuestion 询问：

您需要哪方面的技术对接支持？

A) 整体技术方案（技术栈、架构、第三方服务） B) 功能可行性评估（评估功能实现难度） C) 接口设计（API接口规划） D) 性能与扩展性（性能要求、扩展方案） E) 其他（请手动输入）

💡 提示：

产品规划阶段 → 推荐整体技术方案

功能设计阶段 → 推荐功能可行性评估

技术评审阶段 → 推荐接口设计

记录到变量

TECH_SCOPE

步骤 2: 读取前置数据

根据对接范围读取相应文档：

必需文档：

PRD产品需求文档（如果存在）
原型设计方案（如果存在）

可选文档：

MVP方案
需求调研报告

读取失败处理：

如果 PRD 文档不存在：

⚠️ 未找到 PRD 文档

技术对接通常需要 PRD 作为输入，明确功能需求。

您可以选择：
A) 执行 /pm-docs 生成 PRD
B) 使用 MVP 方案作为输入
C) 手动输入功能需求（快速模式）

是否继续？

步骤 3: 提取关键需求

基于前置文档提取：

从 PRD 提取：

功能列表
非功能需求（性能、安全、兼容性）
数据需求
技术要求

从原型设计提取：

交互流程
页面复杂度
特殊交互需求

步骤 4: 技术方案设计

4.1 技术栈推荐

使用 AskUserQuestion 询问：

基于产品需求，我推荐以下技术栈组合：

前端技术栈：

方案A：React + TypeScript + Ant Design

方案B：Vue3 + TypeScript + Element Plus

方案C：小程序原生开发

方案D：其他（请手动输入）

后端技术栈：

方案A：Java + Spring Boot + MySQL

方案B：Node.js + Express + MongoDB

方案C：Python + Django + PostgreSQL

方案D：Go + Gin + MySQL

方案E：其他（请手动输入）

选择依据：

团队技术栈熟练度

项目规模和复杂度

性能要求

开发周期

您倾向于哪种方案？

A) 使用推荐方案 B) 我需要调整技术栈 C) 我们已有技术栈约束（请说明）

如果选择 B 或 C，询问具体的技术栈约束。

4.2 架构设计

基于功能需求和技术栈，设计系统架构：

📐 基于您的需求，推荐以下架构方案：

{展示架构图：前端层、后端服务层、数据层、第三方服务层}

核心模块：

用户服务：认证、授权、用户信息管理

业务服务：{核心业务模块}

数据服务：数据存储、缓存、检索

是否需要调整？

A) 架构合理，继续设计接口 B) 需要调整架构 C) 我有其他想法（请手动输入）

步骤 5: 功能可行性评估

逐个评估核心功能的实现难度：

5.1 功能列表分析

对每个核心功能进行分析：

📋 功能可行性分析：{功能名称}

功能描述：{从PRD提取}

技术实现方案：

前端实现：{具体方案}

后端实现：{具体方案}

数据存储：{数据库设计}

第三方依赖：{如需要}

实现难度：

⭐ 简单：标准实现，无特殊难点

⭐⭐ 中等：需要一定开发工作量

⭐⭐⭐ 复杂：技术难度高，需要专项攻克

风险点：

{风险1}

{风险2}

建议实现周期：{预估时间}

是否继续评估下一个功能？

A) 继续评估 B) 我需要调整这个功能 C) 查看所有功能评估结果

5.2 风险识别

对高风险功能提供缓解方案：

⚠️ 高风险功能识别：

{高风险功能列表}

缓解方案：

{功能名称}：

方案1：{替代方案}

方案2：{分阶段实现}

方案3：{引入第三方服务}

是否接受这些方案？

A) 接受推荐方案 B) 需要进一步讨论 C) 调整功能需求降低风险

步骤 6: 接口设计

6.1 核心接口规划

基于功能需求，列举核心API接口：

🔌 核心API接口规划：

用户模块：

POST /api/auth/login - 用户登录

POST /api/auth/register - 用户注册

GET /api/user/profile - 获取用户信息

PUT /api/user/profile - 更新用户信息

业务模块：

GET /api/products - 获取商品列表

GET /api/products/{id} - 获取商品详情

POST /api/cart - 添加到购物车

GET /api/cart - 获取购物车列表

POST /api/orders - 创建订单

GET /api/orders/{id} - 获取订单详情

是否需要详细设计某个接口？

A) 需要详细设计接口字段 B) 接口规划足够，继续其他内容 C) 导出接口文档格式（Swagger/OpenAPI）

如果选择 A，提供接口详细设计模板。

6.2 接口详细设计

对关键接口进行详细设计：

📝 接口详细设计：POST /api/orders

接口描述：创建订单

请求方法：POST

请求路径：/api/orders

请求头：

Authorization: Bearer {token}
Content-Type: application/json

请求参数：

{
  "products": [
    {
      "product_id": "string",
      "quantity": "number",
      "sku_id": "string (可选)"
    }
  ],
  "shipping_address": {
    "receiver_name": "string",
    "phone": "string",
    "province": "string",
    "city": "string",
    "district": "string",
    "detail": "string"
  },
  "payment_method": "string (alipay|wechat|card)"
}

响应参数：

{
  "code": 200,
  "message": "订单创建成功",
  "data": {
    "order_id": "string",
    "order_no": "string",
    "total_amount": "number",
    "status": "pending_payment",
    "payment_url": "string"
  }
}

错误码：

400：参数错误
401：未授权
409：库存不足
500：服务器错误

是否继续设计其他接口？

A) 继续设计下一个接口 B) 导出所有接口文档 C) 接口设计完成

步骤 7: 第三方服务评估

7.1 需要的第三方服务

基于功能需求，推荐第三方服务：

🔧 建议引入的第三方服务：

支付服务：

支付宝支付

微信支付

短信服务：

阿里云短信

腾讯云短信

地图服务：

高德地图 API

百度地图 API

存储服务：

阿里云 OSS

腾讯云 COS

推送服务：

极光推送

个推

是否需要这些服务？

A) 需要这些服务 B) 我有其他服务提供商 C) 部分功能自行开发

7.2 成本预估

对第三方服务进行成本预估：

💰 第三方服务成本预估：

支付服务：

手续费：0.6% - 1%（每笔交易）

月成本预估：基于GMV计算

短信服务：

单价：0.03 - 0.05元/条

月用量预估：{基于用户规模}

月成本预估：{金额}

存储服务：

存储费用：{单价}/GB/月

流量费用：{单价}/GB

月成本预估：{金额}

总预估成本：{金额}/月

是否接受？

A) 成本可接受 B) 需要优化成本 C) 调整功能减少第三方依赖

步骤 8: 输出技术对接方案

使用 Write 工具创建

docs/02-方案设计/技术对接方案.md

：

# {产品名称} 技术对接方案

## 文档信息

- **产品名称**: {从PRD提取}
- **文档版本**: v1.0
- **创建时间**: {当前时间}
- **对接范围**: {整体方案/功能评估/接口设计}
- **生成工具**: super-pm v1.0.0

---

## 一、技术概述

### 1.1 产品背景

{从PRD提取：产品定位和目标}

### 1.2 技术目标

- 支持{核心功能}
- 性能要求：{具体指标}
- 扩展性：{扩展目标}
- 安全性：{安全要求}

---

## 二、技术栈选择

### 2.1 前端技术栈

**选择方案**：{技术栈名称}

**核心框架**：
- 框架：{如React/Vue}
- 语言：TypeScript
- UI组件库：{如Ant Design}
- 状态管理：{如Redux/Pinia}
- 构建工具：{如Vite/Webpack}

**选择理由**：
- {理由1}
- {理由2}

### 2.2 后端技术栈

**选择方案**：{技术栈名称}

**核心框架**：
- 语言：{如Java/Node.js/Go}
- 框架：{如Spring Boot/Express/Gin}
- 数据库：{如MySQL/MongoDB}
- 缓存：{如Redis}
- 消息队列：{如RabbitMQ}

**选择理由**：
- {理由1}
- {理由2}

### 2.3 开发工具

- 版本控制：Git
- 代码托管：{GitHub/GitLab}
- CI/CD：{Jenkins/GitHub Actions}
- 项目管理：{Jira/Notion}
- 协作文档：{语雀/飞书}

---

## 三、系统架构

### 3.1 整体架构

┌─────────────────────────────────────────┐ │ 客户端层 │ │ Web端 │ 移动端 │ 小程序 │ API │ └─────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────┐ │ 接入层（Nginx） │ └─────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────┐ │ 应用服务层 │ │ 用户服务 │ 业务服务 │ 支付服务 │ ... │ └─────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────┐ │ 数据层 │ │ MySQL │ Redis │ MongoDB │ ES │ MQ │ └─────────────────────────────────────────┘


### 3.2 核心模块

**用户服务模块**：
- 用户注册/登录
- 身份认证与授权
- 用户信息管理

**业务服务模块**：
- {核心业务模块1}
- {核心业务模块2}

**支付服务模块**：
- 支付网关对接
- 支付状态管理
- 退款处理

---

## 四、功能可行性评估

### 4.1 功能列表与实现难度

| 功能名称 | 实现难度 | 风险等级 | 预估周期 | 备注 |
|---------|---------|---------|---------|------|
| 用户注册登录 | ⭐ 简单 | 低 | 3天 | 使用标准JWT认证 |
| 商品浏览 | ⭐ 简单 | 低 | 2天 | 标准CRUD操作 |
| 购物车 | ⭐⭐ 中等 | 中 | 5天 | 需要库存同步逻辑 |
| 订单系统 | ⭐⭐⭐ 复杂 | 高 | 10天 | 状态机复杂，需事务保证 |
| 支付集成 | ⭐⭐ 中等 | 中 | 5天 | 对接第三方支付 |
| ... | ... | ... | ... | ... |

### 4.2 高风险功能分析

**功能：订单系统**

**风险点**：
- 订单状态流转复杂，容易出现状态不一致
- 库存扣减需要事务保证，避免超卖
- 支付回调处理需要幂等性设计

**缓解方案**：
- 使用状态机管理订单状态
- 采用分布式锁保证库存一致性
- 设计幂等性支付回调接口

**替代方案**：
- 简化订单状态，分阶段实现
- 使用成熟的电商框架（如mall）

---

## 五、API接口设计

### 5.1 接口规范

**基础路径**：`/api/v1`

**认证方式**：JWT Bearer Token

**响应格式**：
```json
{
  "code": 200,
  "message": "success",
  "data": {}
}

错误码规范：

200：成功
400：参数错误
401：未授权
403：无权限
404：资源不存在
500：服务器错误

5.2 核心接口列表

用户模块

1. 用户登录

接口：

POST /api/auth/login

请求参数：

{
  "email": "user@example.com",
  "password": "string"
}

响应参数：

{
  "code": 200,
  "message": "登录成功",
  "data": {
    "token": "eyJhbGciOiJIUzI1NiIs...",
    "user": {
      "id": "string",
      "name": "string",
      "email": "string"
    }
  }
}

2. 获取用户信息

接口：

GET /api/user/profile

请求头：

Authorization: Bearer {token}

响应参数：

{
  "code": 200,
  "message": "success",
  "data": {
    "id": "string",
    "name": "string",
    "email": "string",
    "phone": "string",
    "created_at": "2026-03-25T10:00:00Z"
  }
}

业务模块

3. 获取商品列表

接口：

GET /api/products

请求参数：

?page=1&size=20&category_id=xxx&sort=price_asc

响应参数：

{
  "code": 200,
  "message": "success",
  "data": {
    "list": [
      {
        "id": "string",
        "name": "string",
        "price": 99.99,
        "image": "string",
        "stock": 100
      }
    ],
    "total": 100,
    "page": 1,
    "size": 20
  }
}

{其他接口...}

5.3 接口文档导出

完整的接口文档已按照OpenAPI 3.0规范整理，可导出为Swagger格式。

六、数据库设计

6.1 核心表结构

用户表（users）：

字段名	类型	说明	约束
id	VARCHAR(36)	用户ID	PRIMARY KEY
email	VARCHAR(100)	邮箱	UNIQUE, NOT NULL
password_hash	VARCHAR(255)	密码哈希	NOT NULL
name	VARCHAR(50)	用户名
phone	VARCHAR(20)	手机号
created_at	TIMESTAMP	创建时间	NOT NULL
updated_at	TIMESTAMP	更新时间	NOT NULL

商品表（products）：

字段名	类型	说明	约束
id	VARCHAR(36)	商品ID	PRIMARY KEY
name	VARCHAR(200)	商品名称	NOT NULL
description	TEXT	商品描述
price	DECIMAL(10,2)	价格	NOT NULL
stock	INT	库存	DEFAULT 0
category_id	VARCHAR(36)	分类ID	FOREIGN KEY
created_at	TIMESTAMP	创建时间	NOT NULL

{其他表...}

6.2 索引设计

users: email (UNIQUE)
products: category_id, created_at
orders: user_id, status, created_at

七、第三方服务

7.1 服务清单

服务类型	服务商	用途	月成本预估
支付服务	支付宝/微信	支付处理	交易额的0.6%
短信服务	阿里云短信	验证码、通知	500元
对象存储	阿里云OSS	图片、文件存储	300元
CDN加速	阿里云CDN	静态资源加速	200元
短信推送	极光推送	消息推送	300元
合计			~1300元/月

7.2 服务对接要点

支付服务对接：

申请商户号
配置支付回调地址
实现签名验证逻辑
测试支付流程

短信服务对接：

申请短信签名和模板
实现短信发送接口
设置发送频率限制
监控发送成功率

八、非功能性需求

8.1 性能要求

响应时间：

页面加载：< 2秒
API响应：< 500ms（P95）
数据库查询：< 100ms

并发能力：

支持{预估并发用户数}并发用户
QPS峰值：{预估QPS}

优化方案：

Redis缓存热点数据
CDN加速静态资源
数据库读写分离
异步处理耗时操作

8.2 安全要求

认证授权：

JWT Token认证
HTTPS加密传输
密码加密存储（bcrypt）

数据安全：

敏感数据加密存储
SQL注入防护
XSS攻击防护
CSRF防护

接口安全：

接口签名验证
请求频率限制
IP黑名单

8.3 可用性要求

服务可用性：

SLA目标：99.9%
故障恢复时间：< 30分钟

监控告警：

服务健康监控
接口错误率监控
服务器资源监控

九、部署方案

9.1 部署架构

生产环境：

用户 → CDN → Nginx → 应用服务器 → 数据库
                    ↓
                 Redis缓存

服务器配置：

应用服务器：2台 4核8G
数据库服务器：1台 8核16G
Redis服务器：1台 2核4G

9.2 CI/CD流程

代码提交 → 自动测试 → 构建镜像 → 部署测试环境 → 人工验证 → 部署生产环境

工具选择：

代码托管：GitLab
CI/CD：GitLab CI
容器化：Docker + Kubernetes
监控：Prometheus + Grafana

十、项目风险与应对

10.1 技术风险

风险项	影响	概率	应对方案
技术栈不熟悉	高	中	提前技术调研，预留学习时间
第三方服务不稳定	中	低	设计降级方案，多服务商备选
性能不达标	高	中	压力测试，优化关键路径
安全漏洞	高	低	代码审查，安全扫描

10.2 项目风险

风险项	影响	概率	应对方案
需求变更频繁	高	中	敏捷开发，快速迭代
人员变动	中	低	文档完善，知识共享
周期延误	高	中	MVP优先，分阶段交付

十一、开发排期建议

11.1 阶段划分

第一阶段：基础设施（1周）

技术栈搭建
数据库设计与初始化
基础框架开发

第二阶段：核心功能（3周）

用户模块（1周）
业务核心模块（2周）

第三阶段：扩展功能（2周）

支付集成
第三方服务对接

第四阶段：测试上线（1周）

集成测试
性能优化
上线部署

总计：7周

11.2 人力需求

前端开发：1-2人
后端开发：2-3人
测试：1人
产品经理：1人
项目经理：1人

十二、下一步建议

12.1 技术对接完成后

建议执行：

技术评审 - 与技术团队评审方案可行性
/pm-feature - 功能细节拆解，为开发做准备
/pm-data - 数据埋点方案设计
/pm-risk - 风险管控方案

12.2 技术准备事项

确定技术栈并搭建开发环境
完成数据库设计评审
对接第三方服务，申请密钥
编写技术文档和开发规范
搭建CI/CD流程

附录

A. 技术选型对比

{技术栈对比表格}

B. 参考文档

PRD产品需求文档
原型设计方案
MVP方案

C. 技术资源

官方文档链接
开源项目推荐
技术博客参考

文档状态: 技术对接方案完成 生成时间: {时间戳} 生成工具: super-pm v1.0.0