Estimate Effort
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%
输出格式
## 需求工时评估报告
### 基本信息
- 需求：[需求名称]
- 评估基准：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/天）
### 风险与依赖
- ⚠️ [风险项说明]
### 优化建议
- [建议]
反模式（禁止）
- ❌ 不看代码直接给总数
- ❌ 用"大概"、"可能"模糊数字而不给区间
- ❌ 忽略测试和文档时间
- ❌ 低估集成和联调工作量
- ❌ 需求不清楚时不追问就开始评估
确认门控
评估完成后，询问用户：
- 评估范围是否完整？
- 是否需要调整缓冲系数？
- 是否需要按优先级排序任务？