estimate-effort

根据需求和项目源码评估开发工时（小时）。触发词：评估工时、estimate effort、预估时间、开发周期、工作量评估、sprint planning、排期、工时估算。适用于前后端需求评估，以3年经验开发者为基准。

IRON LAW: 每个工时数字必须有因素分解支撑，禁止拍脑袋估算。没有分析代码就给数字是无效评估。

工作流

• Step 1: 收集需求 ⚠️ REQUIRED

  • 1.1 读取需求描述（用户输入或指定文档路径）
  • 1.2 识别需求类型：新功能 / 重构 / Bug修复 / 系统集成
  • 1.3 确认验收标准（UAT）— 模糊需求必须先澄清

• Step 2: 分析代码库 ⚠️ REQUIRED

  • 2.1 扫描项目结构：技术栈、框架、目录组织
  • 2.2 定位与需求相关的模块和文件（用 Grep/Glob）
  • 2.3 评估现有代码状态：耦合度、可扩展性、技术债

• Step 3: 拆解任务

  • 3.1 按功能点拆分子任务（粒度：0.5-4小时/任务）
  • 3.2 标记每个子任务类型：CRUD / 业务逻辑 / UI交互 / 集成对接 / 测试 / 文档

• Step 4: 评估工时 ⚠️ REQUIRED

  • 4.1 评估每个子任务复杂度（1-5级，见 references/complexity-factors.md）
  • 4.2 查表确定基准工时（见下文"基准工时表"）
  • 4.3 应用技术栈修正系数（见 references/tech-stack-baseline.md）
  • 4.4 汇总计算：总工时 = Σ(基准工时 × 复杂度系数 × 技术栈系数) + 缓冲

• Step 5: 输出报告

  • 5.1 生成工时明细表（Markdown 表格）
  • 5.2 标注高风险项和依赖项
  • 5.3 给出优化建议（如有可复用组件/现成方案）

基准工时表（3年经验开发者）

任务类型	简单(1)	中等(2-3)	复杂(4-5)
CRUD接口	1h	2-3h	4-6h
业务逻辑	2h	3-4h	6-8h
UI组件	1.5h	3-4h	6-8h
数据模型	1h	2h	3-4h
系统集成	2h	4-6h	8-12h
单元测试	0.5h	1-2h	3-4h
文档更新	0.5h	1h	2h

缓冲规则

• 常规需求：基准工时 × 20%
• 涉及新技术/不熟悉模块：基准工时 × 30%
• 需求模糊/可能变更：基准工时 × 40%

输出格式

markdown

## 需求工时评估报告

### 基本信息
- 需求：[需求名称]
- 评估基准：3年经验 [前端/后端/全栈] 开发
- 评估日期：[YYYY-MM-DD]

### 工时明细

| # | 子任务 | 类型 | 复杂度 | 基准工时 | 系数 | 预估工时 |
|---|--------|------|--------|----------|------|----------|
| 1 | xxx | CRUD | 2 | 2h | 1.0 | 2h |
| 2 | xxx | 业务逻辑 | 3 | 4h | 1.2 | 4.8h |

### 汇总
- 基准工时合计：Xh
- 缓冲时间（20%）：Xh
- **总预估工时：Xh**（约 X 人天，按6h/天）

### 风险与依赖
- ⚠️ [风险项说明]

### 优化建议
- [建议]

反模式（禁止）

• ❌ 不看代码直接给总数
• ❌ 用"大概"、"可能"模糊数字而不给区间
• ❌ 忽略测试和文档时间
• ❌ 低估集成和联调工作量
• ❌ 需求不清楚时不追问就开始评估

确认门控

评估完成后，询问用户：

1. 评估范围是否完整？
2. 是否需要调整缓冲系数？
3. 是否需要按优先级排序任务？