上线后的调用次数不能单独证明项目有效。用户可能反复尝试同一个失败任务，也可能因为入口不方便而很少使用。复盘应回到最初的业务任务，同时检查质量、采用情况和完成任务所需的总投入。
先保留原流程的基线
在试用前，记录同类任务的人工处理时长、返工情况和工作量。使用 AI 后，采用相近难度的任务进行比较，并记录参与者经验与资料范围。工作量或任务难度变化很大时，应分组说明，避免把差异全部归功于工具。
建议记录“开始准备到结果被接受”的时间，其中包括查找资料、模型等待、人工核对、修改和失败后重做。只测生成速度，会遗漏使用者承担的工作。
用三个问题组织复盘
| 问题 | 建议记录 | 需要解释的异常 |
|---|---|---|
| 结果是否可用 | 通过量、失败类型、复核耗时 | 生成快但修改多 |
| 用户是否采用 | 合格任务中实际使用的数量、放弃原因 | 入口不顺手或资料更新慢 |
| 投入是否可接受 | 调用、运行、维护及人工复核投入 | 单次失败引发多次重试 |
“有效完成率”的分母应包含本统计范围内的失败任务。未开放的任务另列，不应混入结果。对外展示数据前，保留样本范围和计算方法。
一个计算示例
假设某类报告人工整理平均需要 30 分钟，使用工具后准备与生成需要 8 分钟、复核修改需要 12 分钟，则每份被接受的报告节省约 10 分钟。这只是演算示例，不是小火堆的客户效果或收益承诺。
如果部分报告失败并返回人工流程，还需要把失败处理时间计入整体结果。节省的时间也不自动等于现金成本减少；企业可以将其用于提升响应速度、减少积压或承担更多工作，再观察实际变化。
按成功任务分摊运行开销
记录模型调用、必要资源、产品授权和维护投入，再结合被接受的任务数量进行比较。开发等一次性投入可按内部管理口径另列或分摊，不应和每月运行费用混在一起而无法解释。
具体价格随供应商、版本和采购方式变化，评估时使用当期账单或正式报价。本文不提供固定单价，也不把任何示例作为市场价格。
下一步怎样决定
如果结果可靠但使用少，先检查入口、培训和任务选择；如果使用多但错误集中，优先修复对应资料或接口；如果质量稳定且单位任务投入可接受，再讨论扩大用户与场景。
每次复盘保留决定、依据、负责人和下次检查日期。这样企业能够解释为什么追加投入、缩小范围或停止某项功能。相关方法见首个场景选择和项目范围与预算。