工作量评估技能

用途

接收产品需求描述，为使用以下技术栈的小型研发团队输出模块级工作量评估表：

• 后端：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** |

> ⚠️ 以上工时不含第三方采购工具的费用，采购成本请参考"第三方采购清单"。

### 评估说明

[逐条说明各模块评估依据，以及特别需要注意的风险点]

### ⚠️ 风险提示

[列出评估中发现的不确定因素和建议]

注意事项

1. 遇到需求模糊的模块，主动在评估说明中注明假设条件，并建议需求方进一步澄清。
2. 遇到超出技能栈的技术需求，必须暂停评估，先向用户确认（见第一步）。
3. 不要凭空猜测工时，所有工时都应对照 references/tech-baselines.md 中的基准区间得出。
4. 工时单位统一为人天（1人天=8小时）。
5. 如用户明确告知需求已高度确定，可降为低风险系数（×1.2）；如涉及大量第三方集成或需求频繁变更，建议提升为高风险（×1.5）并向用户说明原因。