Pm Tech

---
name: pm-tech
version: 2.0.0
description: |
  Use when: 需要与技术团队对接技术方案、评估技术可行性、制定技术架构、评估第三方服务
  Do NOT use when: 技术方案已由技术团队确定、仅需功能描述无需技术评估
allowed-tools:
  - Agent
  - Read
  - Write
  - AskUserQuestion
  - Bash
---

## Preamble (run first)

```bash
bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
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
```

---

## 执行流程

```dot
digraph pm_tech {
    rankdir=TB;
    node [shape=box, style=filled, fillcolor="#e3f2fd"];
    
    "确定技术范围" [shape=box, fillcolor="#bbdefb"];
    "读取前置数据" [shape=box, fillcolor="#bbdefb"];
    "提取关键需求" [shape=box, fillcolor="#bbdefb"];
    "技术方案设计" [shape=box, fillcolor="#c8e6c9"];
    "功能可行性评估" [shape=box, fillcolor="#ffe0b2"];
    "接口设计" [shape=box, fillcolor="#ffe0b2"];
    "第三方服务评估" [shape=box, fillcolor="#fff9c4"];
    "输出技术方案" [shape=box, fillcolor="#fff9c4"];
    
    subgraph cluster_subagent {
        label="Subagent 并行评估";
        style=filled;
        fillcolor="#f3e5f5";
        "技术栈调研" [shape=box, fillcolor="#e1bee7"];
        "成本预估" [shape=box, fillcolor="#e1bee7"];
        "风险分析" [shape=box, fillcolor="#e1bee7"];
        "技术栈调研" -> "功能可行性评估" [style=dashed];
        "成本预估" -> "第三方服务评估" [style=dashed];
        "风险分析" -> "功能可行性评估" [style=dashed];
    }
    
    "确定技术范围" -> "读取前置数据";
    "读取前置数据" -> "提取关键需求";
    "提取关键需求" -> "技术方案设计";
    "技术方案设计" -> "功能可行性评估";
    "功能可行性评估" -> "接口设计";
    "接口设计" -> "第三方服务评估";
    "第三方服务评估" -> "输出技术方案";
}
```

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

使用 AskUserQuestion 询问：

> 您需要哪方面的技术对接支持？
>
> A) 整体技术方案（技术栈、架构、第三方服务）
> B) 功能可行性评估（评估功能实现难度）
> C) 接口设计（API接口规划）
> D) 性能与扩展性（性能要求、扩展方案）
> E) 其他（请手动输入）
>
> 💡 提示：产品规划→整体方案，功能设计→可行性评估，技术评审→接口设计

记录到变量 `TECH_SCOPE`

---

### 步骤 2: 读取前置数据

**必需文档**：PRD产品需求文档、原型设计方案（需其一）
**可选文档**：MVP方案、需求调研报告

如果 PRD 不存在：

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

---

### 步骤 3: 提取关键需求

从 PRD 提取：功能列表、非功能需求（性能/安全/兼容性）、数据需求
从原型设计提取：交互流程、页面复杂度

---

### 步骤 4: 技术方案设计

#### 4.1 技术栈推荐

> 基于产品需求，推荐以下技术栈：
>
> **前端**：方案A React+TS+Ant Design / 方案B Vue3+TS+Element Plus / 方案C 小程序原生
> **后端**：方案A Java+Spring Boot+MySQL / 方案B Node.js+Express+MongoDB / 方案C Python+Django+PG / 方案D Go+Gin+MySQL
>
> 选择依据：团队熟练度、项目规模、性能要求、开发周期
>
> A) 使用推荐方案
> B) 需要调整
> C) 已有技术栈约束

#### 4.2 架构设计

> 📐 推荐架构方案：
> - 前端层 → 接入层(Nginx) → 应用服务层 → 数据层
> - 核心模块：用户服务、业务服务、数据服务
>
> A) 架构合理，继续
> B) 需要调整
> C) 我有其他想法

---

### 步骤 5: 功能可行性评估

#### 5.1 逐个功能分析

对每个核心功能提交以下评估：

> 📋 **{功能名称}**
> - **技术实现**：前端方案、后端方案、数据存储、第三方依赖
> - **难度**：⭐简单 / ⭐⭐中等 / ⭐⭐⭐复杂
> - **风险**：{风险点}
> - **建议周期**：{预估时间}
>
> A) 继续评估下一个
> B) 需要调整这个功能
> C) 查看所有评估结果

#### 5.2 高风险功能识别

> ⚠️ 高风险功能汇总：列出风险项及缓解方案（替代方案/分阶段/引入第三方）
>
> A) 接受推荐方案
> B) 需要进一步讨论
> C) 调整功能需求降低风险

---

### 步骤 6: 接口设计

#### 6.1 核心API规划

> 🔌 核心API接口：
>
> **用户模块**：POST /api/auth/login, POST /api/auth/register, GET/PUT /api/user/profile
> **业务模块**：GET /api/products, GET /api/products/{id}, POST /api/cart, POST /api/orders
>
> 是否需要详细设计某个接口？
>
> A) 需要详细设计
> B) 已经足够
> C) 导出Swagger格式

#### 6.2 接口详细设计（可选）

对关键接口提供详细设计：请求方法、路径、请求头、请求参数（JSON Schema）、响应参数、错误码

---

### 步骤 7: 第三方服务评估

#### 7.1 服务推荐

> 🔧 第三方服务：支付(支付宝/微信)、短信(阿里云/腾讯云)、地图(高德/百度)、存储(OSS/COS)、推送(极光/个推)

#### 7.2 成本预估

> 💰 成本参考：支付手续费0.6-1%，短信0.03-0.05元/条，存储{单价}/GB/月

---

### Subagent 并行分析（v2.0 新增）

在步骤 4（技术方案设计）前，主 agent 可派发 subagent 并行执行独立分析任务：

```markdown
使用 Agent 工具并行派发：

Agent 1: 技术栈调研
  - 调研各技术栈的社区活跃度、生态成熟度、人才市场
  - 输出：技术栈对比报告（JSON）

Agent 2: 成本预估
  - 估算开发成本、第三方服务费用、运维成本
  - 输出：成本预估明细（JSON）

Agent 3: 风险分析
  - 识别技术风险、替代方案、降级策略
  - 输出：风险评估矩阵（JSON）

主 agent 等待所有 subagent 完成，整合结果用于技术方案设计。
```

### 版本对比（v1 vs v2）

| 维度 | v1（串行） | v2（Subagent 并行） |
|------|-----------|-------------------|
| 技术栈调研 | 主 agent 手动分析 | Subagent 并行调研 |
| 成本预估 | 手动计算 | Subagent 自动计算 |
| 风险分析 | 逐个评估 | Subagent 并行评估 |
| Token 占用 | 分析细节占用主上下文 | Subagent 独立上下文 |
| 执行效率 | 线性顺序 | 并行 3x 加速 |

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

使用 Write 工具创建 `docs/02-方案设计/技术对接方案.md`。

参考 `references/output-template.md` 模板，填充用户输入数据。文档结构：

1. **技术概述** - 产品背景、技术目标
2. **技术栈选择** - 前端、后端、开发工具
3. **系统架构** - 整体架构、核心模块
4. **功能可行性评估** - 功能列表与难度、高风险分析
5. **API接口设计** - 规范、核心接口、详细设计
6. **数据库设计** - 核心表结构、索引
7. **第三方服务** - 服务清单、成本预估
8. **非功能性需求** - 性能、安全、可用性
9. **部署方案** - 部署架构、CI/CD
10. **项目风险与应对**
11. **开发排期建议** - 阶段划分、人力需求

---

## 兜底机制

### 场景: 无前置文档

如果PRD和原型都不存在，提供快速模式手动输入功能列表。

---

## 注意事项

1. 技术栈推荐应考虑团队现有技术积累
2. 接口设计遵循RESTful规范
3. 第三方服务成本需基于实际用量预估
4. 完整输出模板参见 `references/output-template.md`

---

## 输出质量对比

**✅ Good 示例**：
```
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
```

**❌ Bad 示例**：
```
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
```

---

## 常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯：

| 误区 | 正确做法 |
|------|---------|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |

---

## 产出质量检查 / Verification Checklist

- [ ] 前置依赖已满足（输入文档/数据已收集）
- [ ] 核心步骤已全部执行
- [ ] 输出文档已生成到 `docs/` 目录
- [ ] 每个判断都有数据/证据支撑
- [ ] 已推荐 2-3 个后续 skill

> ⚠️ 任何一项未通过 → 补全后再标记完成。

---