工作量评估技能
用途
接收产品需求描述，为使用以下技术栈的小型研发团队输出模块级工作量评估表：
- 后端：Spring Boot（Java）
- PC前端：Vue 2 / Vue 3
- 移动端：UniApp（H5 / 微信小程序 / App）
- 小程序：微信小程序原生
- 数据库：MySQL
评估流程
第一步：识别技术边界
读取需求，识别是否涉及团队未掌握的技术。
参考 references/tech-baselines.md 第九节"遇到团队不熟悉的技术时"。
如发现超出技能栈的技术，必须先询问用户，明确：
1. 该需求是否一定要用该技术实现？
2. 是否计划引入外部资源或接受学习成本？
等用户确认后再继续评估。
第二步：识别第三方采购工具
在拆解模块之前，先扫描需求中是否涉及需要采购的第三方工具/服务。
判断标准——满足以下任一条即为采购工具：
- 需要向第三方付费订阅或按量计费（如短信服务、地图API、云存储、AI接口）
- 是成熟的 SaaS/PaaS 产品，团队只负责接入而不开发其核心功能（如腾讯IM、声网、极光推送）
- 属于外部平台强制依赖（如微信支付、支付宝、百度OCR）
处理规则：
- 采购类工具单独列入"第三方采购清单"，不计入开发工时
- 仅评估与该工具的集成工时（SDK接入、接口对接、回调处理等），计入开发模块
- 参考 references/tech-baselines.md 第八节"第三方采购工具集成工时参考"
第三步：拆解功能模块
将需求拆分为若干独立功能模块，每个模块对应一个可交付的功能单元。
模块拆解原则：
- 按业务功能边界拆（而非技术层拆）
- 前后端同一功能归入同一模块，但工时分别列出
- 数据库设计单独列为一个模块（如有）
- 通用基础设施（登录/权限/项目初始化）单独列出
- 采购工具的集成工时单独为一行，备注中注明对应的采购工具名称
第四步：查基准工时
参考 references/tech-baselines.md 查询各技术方向的基准工时区间。
对每个模块，分别给出：
- 最小工时（乐观估算）
- 最大工时（保守估算）
- 建议工时（取中间值，通常偏保守）
第五步：叠加联调与测试工时
在总开发工时基础上叠加：
- 自测工时 = 总开发量 × 20%
第六步：应用风险系数
默认使用中风险系数 ×1.35，除非需求方明确说明以下情况：
- 需求已完全确定、无变更风险 → 低风险 ×1.2
- 需求不稳定、含未知技术、强依赖第三方 → 高风险 ×1.5
输出格式
以 Markdown 表格输出，格式如下：
## 工作量评估报告
**项目/需求名称**：[需求标题]
**评估日期**：[日期]
**评估人**：AI辅助评估
**风险等级**：中风险（×1.35）
### 第三方采购清单（不计入开发工时）
> 以下工具/服务需单独采购，费用由需求方与供应商协商，不在本次工时评估范围内。
| 序号 | 工具/服务名称 | 用途 | 计费方式（参考） | 备注 |
|------|-------------|------|--------------|------|
| 1 | 腾讯云短信 SMS | 验证码发送 | 按条计费，约0.045元/条 | 需备案主体 |
| 2 | 声网 Agora | 音视频通话 | 按分钟计费 | 含SDK接入费 |
### 各模块工时明细
| 序号 | 功能模块 | 涉及技术 | 基准工时（人天） | 备注 |
|------|---------|---------|--------------|------|
| 1 | 用户登录与权限 | Spring Boot + Vue | 3 | 含JWT、RBAC基础版 |
| 2 | 短信验证码集成 | Spring Boot + 腾讯云SMS | 1 | 仅集成工时，SMS服务见采购清单 |
| 3 | 商品管理（后台） | Spring Boot + Vue | 4 | 含图片上传、批量导入 |
| ... | ... | ... | ... | ... |
| N | 联调测试（自测）| - | X | 总开发量×20% |
### 汇总
| 项目 | 工时（人天） |
|------|------------|
| 基准工时合计 | XX |
| 含自测工时 | XX |
| 应用风险系数后（×1.35） | **XX** |
> ⚠️ 以上工时不含第三方采购工具的费用，采购成本请参考"第三方采购清单"。
### 评估说明
[逐条说明各模块评估依据，以及特别需要注意的风险点]
### ⚠️ 风险提示
[列出评估中发现的不确定因素和建议]
注意事项
- 遇到需求模糊的模块，主动在评估说明中注明假设条件，并建议需求方进一步澄清。
- 遇到超出技能栈的技术需求，必须暂停评估，先向用户确认（见第一步）。
- 不要凭空猜测工时，所有工时都应对照
references/tech-baselines.md中的基准区间得出。 - 工时单位统一为人天（1人天=8小时）。
- 如用户明确告知需求已高度确定，可降为低风险系数（×1.2）；如涉及大量第三方集成或需求频繁变更，建议提升为高风险（×1.5）并向用户说明原因。
