estimate-calibrator

估算校准器

将单点猜测替换为结构化的三点估算：将工作拆分为原子单元，为每个单元估算最佳、最可能和最坏情况，识别未知项和假设，使用 PERT 计算汇总范围，并给出有明确依据的置信度等级。

参考文件

文件	内容	加载时机
references/estimation-methods.md	PERT 公式、三点估算、蒙特卡洛基础知识	始终
references/unknown-categories.md	技术、范围、外部和组织层面的不确定性类型	识别未知项
references/calibration-tips.md	估算中的认知偏差、历史校准、缓冲策略	始终
references/sizing-heuristics.md	常见任务规模模式、复杂度指标、参考类别数据	需要快速估算规模时

前置条件

• 工作项说明（功能、任务、项目）
• 已拆分的任务（或先使用 task-decomposer skill）
• 上下文：团队熟悉程度、技术栈、现有代码库

工作流

阶段 1：拆分工作

如果工作项尚未拆分为原子单元：

1. 拆分为任务 — 每项任务都应能独立估算。
2. 合理的粒度 — 任务应为 1 小时至 3 天。更大的任务不确定性更高；应进一步拆分。
3. 识别依赖关系 — 关键路径上的任务决定最短工期。

阶段 2：三点估算

为每项任务估算三种情景：

情景	定义	思路
最佳情况	一切顺利，没有意外。	“如果我以前做过完全相同的事情”
最可能情况	正常阻力，有一些小障碍。	“考虑到常见挫折后的现实预期”
最坏情况	出现重大问题，但并非灾难性。	“墨菲定律，但不至于酿成灾难”

关键规则： 最坏情况不等于“一切都出错”。它是现实中较差的情景（第 90 百分位），而不是末日般的情景（第 99 百分位）。

阶段 3：识别未知项

对影响估算的未知项进行分类：

类别	示例	影响
技术	“以前从未用过这个库”	最可能情况会更长，最坏情况则会长得多
范围	“需求可能会变更”	所有估算都可能发生变化
外部	“依赖合作伙伴提供 API 访问权限”	阻塞风险——可能导致完全延期
集成	“尚未使用生产数据测试”	集成时会出现隐藏的复杂性
组织	“需要设计审批”	占用日历时间，而非投入时间

阶段 4：计算范围

对于单项任务，使用 PERT 公式：

Expected = (Best + 4 × Likely + Worst) / 6
Std Dev = (Worst - Best) / 6

对于汇总（项目）估算：

• 预期值之和表示总预期工期
• 标准差平方和的平方根表示汇总不确定性

Phase 5：评估置信度

置信度	含义	适用情况
高	可能情况在 ±20% 以内	任务已充分了解，团队以前做过
中	可能情况在 ±50% 以内	存在一些未知因素，团队有一定熟悉度
低	可能情况在 ±100% 以内或更高	存在重大未知因素，涉及新技术

输出格式

## Estimate: {Work Item}

### Summary
| Scenario | Duration |
|----------|----------|
| Best case | {time} |
| Likely case | {time} |
| Worst case | {time} |
| **PERT expected** | **{time}** |
| **Confidence** | **{High/Medium/Low}** |

### Task-Level Estimates

| # | Task | Best | Likely | Worst | PERT | Unknowns |
|---|------|------|--------|-------|------|----------|
| 1 | {task} | {time} | {time} | {time} | {time} | {key unknown or "None"} |
| 2 | {task} | {time} | {time} | {time} | {time} | {key unknown} |
| | **Total** | **{sum}** | **{sum}** | **{sum}** | **{pert}** | |

### Key Unknowns

| # | Unknown | Category | Impact on Estimate | Mitigation |
|---|---------|----------|-------------------|------------|
| 1 | {unknown} | {Technical/Scope/External} | +{time} if realized | {spike, prototype, early test} |

### Assumptions
- {Assumption 1 — what must be true for this estimate to hold}
- {Assumption 2}

### Risk Factors
- {Risk}: If realized, adds {time}. Likelihood: {High/Medium/Low}.

### Confidence Rationale
**{High/Medium/Low}** because:
- {Specific reason — e.g., "Team has built 3 similar features"}
- {Specific reason — e.g., "External API is a new integration"}

### Recommendation
{Commit to PERT expected with {X}% buffer, or spike the top unknown first.}

校准规则

1. 给出三个点，而非一个。 单点估算总是错误的。三个点能表达不确定性——这是任何估算中最重要的部分。
2. 最坏情况是第 90 百分位，而非第 99 百分位。 “小行星撞上办公室”不是有用的最坏情况。“API 文档有误，我们需要逆向工程协议”才是现实的最坏情况。
3. 未知因素比已知难点更会推高估算。 一个难但充分了解的任务，比一个简单但新颖的任务更容易预测。
4. 估算不是承诺。 应传达范围，而非截止日期。如果利益相关方需要一个单一数字，就给出 PERT 期望值，并根据置信度加上缓冲。
5. 尽早探查未知因素。 如果某个未知因素主导了估算范围，应先投入 1-2 天进行探查，再估算其余部分。

错误处理

问题	解决方法
工作项尚未分解	先将其分解为 3-8 个任务（或建议使用 task-decomposer 技能）。
没有历史参考	相对于已知任务进行估算：“这大约是 auth 功能的 2 倍。”
利益相关方希望得到单一数字	提供带有相应置信度缓冲的 PERT 期望值（高：+20%，中：+50%，低：+100%）。
估算看起来过大	检查任务列表是否范围蔓延。移除非必要任务，并确定可以延期的内容。
团队从未做过这类工作	将置信度标为低。建议在承诺估算之前先进行探查。

不应进行估算的情况

以下情况应提出异议：

• 工作属于探索性质（研究、探查）——应设定时间上限，而非进行估算
• 需求完全未定义——应先明确范围
• 用户要求为大型项目精确到小时的估算——应提供范围，而非虚假的精确度
• 估算会被当作承诺使用，却不承认其中的不确定性