Preamble (run first)
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
执行流程
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 并行执行独立分析任务:
使用 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 模板,填充用户输入数据。文档结构:
- 技术概述 - 产品背景、技术目标
- 技术栈选择 - 前端、后端、开发工具
- 系统架构 - 整体架构、核心模块
- 功能可行性评估 - 功能列表与难度、高风险分析
- API接口设计 - 规范、核心接口、详细设计
- 数据库设计 - 核心表结构、索引
- 第三方服务 - 服务清单、成本预估
- 非功能性需求 - 性能、安全、可用性
- 部署方案 - 部署架构、CI/CD
- 项目风险与应对
- 开发排期建议 - 阶段划分、人力需求
兜底机制
场景: 无前置文档
如果PRD和原型都不存在,提供快速模式手动输入功能列表。
注意事项
- 技术栈推荐应考虑团队现有技术积累
- 接口设计遵循RESTful规范
- 第三方服务成本需基于实际用量预估
- 完整输出模板参见
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
⚠️ 任何一项未通过 → 补全后再标记完成。