WACX 任务时间预估

它解决什么问题

给任务列过清单的人大概都有这种体验：一开始雄心勃勃估「两天搞定」，两周后还在改第三轮。问题在于，「还要多久」这句话很少有靠谱答案——要么拍脑袋报个数字，要么报完就忘了，下次预估还是凭感觉。

这个技能针对两类高频场景：

• 完成时间预估（ETA）：给单个任务、整个项目或里程碑算一个带置信区间的完成窗口，而不是一个孤立的数字。
• 超期即停与归因：当实际用时超过预估（默认超支 50%），立刻停止该任务，而不是继续硬撑，并给出延迟原因和改进建议。

它只服务于一种输入：由任务列表（TaskList）跟踪的工作，写代码、写文档、设计、调研、运维、家务、学习都适用。工作单元可以是任务数、章节、PR、工单、页面、字数等任何可计数的量。

它怎么工作

技能把预估拆成几个确定步骤，每一步都有脚本兜底，不允许凭空编数：

1. 界定范围：先确认总量和已完成量。estimate.py 强制要求显式传入 --unit 和有效的 --total/--done，拿不到数据就直接报错退出，从脚本层面杜绝「看似精确实则无依据」的假数字。
2. 采集进度：优先从任务列表读取 completed / in_progress / pending 与 blockedBy 依赖，其次用任务时间戳推算节奏，实在不够就问用户。不读取任何私人文件。
3. 推导速度：内置 22 类任务的速度预设（覆盖写作、代码、数据、调研等），按 agent / human 两种模式取不同量级。代理自己跑任务用 agent 模式，报壁钟时长而非日历工作日，避免把 AI 速度当成人类工时。
4. 计算与汇报：输出乐观 / 基准 / 悲观三档完成日期，汇报前先列出所有换算假设（速度来源、执行模式、校准状态、阻塞项、超期阈值）请用户纠偏。
5. 自动回写：任务前后各调用一次 track-start / track-stop，自动记录壁钟耗时并写入本地校准文件，按 (mode, task_type) 分桶。

核心是一个棘轮校准机制：首次加载只有经验值（校准因子 1.0、不确定带 50%）；每记录一对预估/实际数据，该桶的校准因子和不确定带就更新一次，且只进不退。样本少时区间宽、样本多且稳定时区间收窄；样本数 ≥3 后，不确定带按实际残差的 80 分位分布计算，避免「围绕错误中心把区间收得过窄」的虚假精度。

超期监测走 overrun_check.py：必须显式声明预估来源（calibration / user-stated / prior-eta / preset），选 manual 会被硬拦截——没有可信预估就没有可信的停手判定。命中阈值后停止推进，按 8 类原因（范围蔓延、阻塞依赖、估算偏低、打断切换、返工、工具环境、信息缺失、精力状态）逐项排查，命中的必须给出具体证据，再附改进建议。

适用边界与注意点

• 只认任务列表数据：进度只能来自 TaskList、时间戳或用户口述，不读私人记忆、文档、配置。速度来源枯竭时会显式声明无法预估并请求输入，而不是编一个数。
• 阻塞单列：被 blockedBy 卡住的任务不计入当前速度，单独列出，别把它混进「正常推进中」。
• 预估与实测必须同桶：track-start 的 --estimated-hours 必须来自相同 --mode / --task-type 的 eta_calc 输出，否则校准因子会被错误乘算，把正确的量级又压偏。
• 区间如实呈现：不得为显得积极而收窄悲观档，区间宽度本身就是风险信号。
• 未喂养要显式说明：纯预估查询、没有实际用时可回写时，必须说明「本次未记录实际，棘轮未喂养」，不能默默跳过。
• 校准数据是运行时产物：棘轮数据写在 .workbuddy/skills-data/wacx-time-estimation/calibration.json，随项目走、可随时删除，不在技能分发包内。

适合长期反复出现的同类任务——预设只是起点，校准因子才是关键。偶尔做一次的任务，经验初值加 disclaimer 足够用。