AI应用投入产出评估的核心，是把投入侧（工具与模型费用、人力与时间、集成与治理成本）和产出侧（可归因的效率、质量、交付变化）放在同一时间窗、同一分母下核算，并保留可核验的证据链。本文围绕研发场景，给出评估目标、指标清单、数据口径、计算步骤、完整算例与结果解读方法，帮助读者形成一套可复算的评估方案。
要点总览（TL;DR）
- 评估AI应用投入产出，先明确结论服务于续费扩容、场景取舍还是流程推广，再据此确定评估对象、时间窗和结论形式。
- 投入侧核算工具与模型费用、人力工时、集成维护和培训成本；产出侧看任务完成时间、返工率、评审通过率和交付周期等结果指标，调用次数只作过程参考。
- 每项指标写清分子分母、统计单位、时间窗、数据来源和缺失值规则，基线期与观察期同口径对比，产出变化同时给出绝对变化和相对变化。
- 算例演示：一个团队一个季度总投入48,000元，平均任务完成时间从10小时降至8.5小时，按人力单价折算节省约66,000元，但该结果仅作方向性参考。
- 结果解读要区分相关与因果，至少同时覆盖一项效率指标和一项质量指标，样本过少时报告绝对数和样本量，结论表述留出后续验证空间。
评估目标：先回答投入产出要支持哪个决策
投入产出评估先要明确结论服务于哪个决策，再决定取哪些数、看多长周期。目标不同，评估对象和结论形式差别很大：为续费扩容做评估，需要证明投入带来的产出变化能持续；为场景取舍做评估，需要横向比较不同AI应用场景的单位投入产出；为流程推广做评估，需要说明在某个团队验证过的做法能否复制到其他团队。
建议在评估启动前写一页评估目标说明，包含四项内容：
- 评估对象：明确纳入哪些团队、哪些AI应用场景。例如“两个后端团队在需求拆解与代码评审辅助两个场景中的使用”，对象边界要写到团队和场景粒度，避免用“全公司AI应用”这类无法取数的表述。
- 决策用途：写清结论将用于继续投入、收缩某个场景，还是扩大试点范围。用途决定结论需要多强的证据：扩大试点通常需要更稳定的观察期数据，收缩则可以先看方向性信号。
- 结论形式：约定输出是对比结论（观察期相对基线期的变化）、区间判断（给出变化范围而非单点值），还是待补数据项清单（说明哪些指标暂不可得）。提前约定可以避免算完才发现数据不足以支撑结论。
- 评估周期与复盘节奏：确定基线期长度、观察期长度和复盘频率。研发工作周期较长，观察期通常需要覆盖至少一个完整的迭代周期或季度，短于一个迭代的观察容易把正常波动当成效果。
这一页说明同时是后续口径争议的裁决依据：当某个指标是否纳入、某段时间是否计入产生分歧时，回到评估目标判断它是否影响目标决策，不影响的一律简化处理。
指标与范围：投入项和产出项各算哪些
投入产出评估常见的失真，是把调用次数、使用人数这类过程指标当成产出。过程指标说明使用强度，结果指标才反映业务变化。两类指标都要采集，但结论要落在结果指标上。下表给出研发场景常用的投入项与产出项清单。
| 指标名 | 类型 | 衡量对象 | 单位 |
|---|---|---|---|
| 工具与模型费用 | 投入 | AI工具订阅、模型调用、算力等直接支出 | 元/期 |
| 人力工时 | 投入 | 使用、配置、维护AI应用所投入的人时 | 人时/期 |
| 集成与维护成本 | 投入 | 与现有系统对接、日常运维、问题处理 | 人时或元/期 |
| 培训成本 | 投入 | 推广培训、文档编写、答疑支持 | 人时/期 |
| 任务完成时间 | 产出 | 同类任务从开始到完成的耗时 | 小时/任务 |
| 返工与缺陷 | 产出 | 交付后被退回修改或发现缺陷的比例 | 次/百任务或百分比 |
| 评审通过率 | 产出 | 首次提交即通过评审的比例 | 百分比 |
| 交付周期 | 产出 | 需求从进入到交付的端到端时长 | 天/需求 |
| 使用频次、调用次数 | 过程 | 使用强度，用于解释产出变化的来源 | 次/期 |
范围上，本文聚焦AI应用在研发团队中的投入产出核算。技术模型基准测试与模型能力评测属于另一类工作，衡量的是模型本身的能力上限，与团队投入产出不是同一口径；一般研发效能指标体系建设涉及更广的度量体系设计，本文只在需要时引用其中与AI应用直接相关的指标，不展开体系设计。明确不纳入的范围，可以防止评估无限扩张、迟迟出不了结论。
数据口径：分子分母、时间窗与缺失值怎么定
口径定义的目标是让另一个人拿着同样的规则能算出同样的数。每项指标至少写清五项：分子、分母、统计单位、时间窗、数据来源。下表给出常用指标的参考口径，实际使用时按团队情况调整并固定下来。
| 指标 | 公式（分子/分母） | 统计单位 | 数据来源 | 缺失值规则 |
|---|---|---|---|---|
| 平均任务完成时间 | 任务实际耗时合计 / 完成任务数 | 小时/任务 | 工时系统、工作项状态流转记录 | 无耗时记录的任务剔除，并记录剔除数量 |
| 返工率 | 返工任务数 / 交付任务总数 | 百分比 | 缺陷记录、评审退回记录 | 缺陷记录缺失的批次整体标注为不可用 |
| 评审通过率 | 首次通过评审数 / 提交评审总数 | 百分比 | 代码评审或文档评审记录 | 评审记录不完整的提交不计入分母 |
| 交付周期 | 交付时间减进入时间之和 / 交付需求数 | 天/需求 | 需求工作项状态变更时间 | 中途取消的需求剔除 |
| 单位任务投入 | 期间总投入成本 / 完成任务数 | 元/任务 | 账单、工时记录 | 费用未结算的月份按已出账部分折算并标注 |
时间窗设置上，基线期与观察期应长度相近、业务节奏可比。例如基线期取AI应用上线前的一个季度，观察期取上线后的一个季度；如果观察期内包含长假或重大需求波动，需要在结论中标注。数据来源要固定到具体系统：工时来自工时系统，任务状态来自工作项管理工具，评审结论来自评审记录，费用来自账单。采集方式优先用导出或报表，减少人工填报带来的口径漂移。
缺失值与异常值需要事先约定规则：单条记录缺失时剔除并记录数量；整批数据缺失时该指标标注为不可用，不用估算值填充后当作实测值。分母为零或样本过少时，不计算比率，直接报告绝对数和样本量。例如某场景观察期内完成任务只有个位数，返工率即使算出百分比也不具备解释力，应写成“样本不足，暂不计算比率”。
计算与评估步骤：从基线到观察期的对比
计算流程可以固定为五步，每一步都留下取数记录，保证结果可复算。
- 建立基线期数据：按S3的口径，从各系统导出基线期数据，逐项计算指标值，记录取数日期、数据范围和剔除记录数。基线期数据一经确认即冻结，后续不因观察期发现新情况而回头修改。
- 观察期同口径取数：观察期使用与基线期完全相同的公式、统计单位和数据来源。如果观察期内工具或流程发生变化导致口径必须调整，单独标注并说明影响，不与原口径数据直接混算。
- 投入成本折算：费用类投入按账单金额计入；人力类投入按工时乘以约定的人力单价折算为金额，人力单价在评估启动时确定并全程使用同一数值。两类成本相加得到期间总投入，再除以期间完成任务数，得到单位任务投入。
- 计算产出变化：每项产出指标同时给出绝对变化和相对变化。绝对变化是观察期值减基线期值，相对变化是绝对变化除以基线期值。基线期值为零时只报绝对变化，不计算相对变化。
- 分层计算：按场景或团队分别计算，再汇总。分层可以发现某个场景产出明显改善而另一个场景没有变化的情况，避免汇总平均值掩盖差异。
评估所需的数据分散在工时、工作项状态、评审记录和账单中。以ONES承载研发管理流程的团队为例，工作项的状态流转、评审记录和迭代数据保存在ONES Project中，团队知识沉淀在ONES Wiki中，评估取数时可以从这些记录中导出任务耗时、返工和评审通过情况；ONES Assistant智能助手连接ONES Project、ONES Wiki与ONES TestCase，能基于项目、工作项、迭代和Wiki页面等上下文回答问题并执行操作，把结果保存为工作项或Wiki页面，评估过程中的口径说明和取数记录也可以沉淀为Wiki页面，供复盘时核对。
算例：一个团队一个季度的投入产出核算
以下数值均为假设数据，仅用于演示计算过程，不代表任何真实团队水平或达标线。
假设投入数据：某后端团队一个季度内，AI工具订阅与模型调用费用合计12,000元；使用、配置与维护投入合计160人时，按约定人力单价200元/人时折算为32,000元；培训投入20人时，折算4,000元。期间总投入为12,000+32,000+4,000=48,000元。
假设产出数据：基线期一个季度完成任务200个，平均任务完成时间10小时，返工率8%，评审通过率70%；观察期完成任务220个，平均任务完成时间8.5小时，返工率6%，评审通过率78%。
| 指标 | 基线期 | 观察期 | 绝对变化 | 相对变化 |
|---|---|---|---|---|
| 平均任务完成时间 | 10小时/任务 | 8.5小时/任务 | -1.5小时/任务 | -15% |
| 返工率 | 8% | 6% | -2个百分点 | -25% |
| 评审通过率 | 70% | 78% | +8个百分点 | +11.4% |
| 单位任务投入 | — | 48,000/220≈218元/任务 | — | — |
按平均任务完成时间折算，每任务节省1.5小时，220个任务合计节省330小时，按200元/人时折算约66,000元，与48,000元投入相比，时间节省折算值高于投入。这个结果只能作为方向性参考：节省的工时是否真正转化为其他产出，取决于团队是否把释放的时间用于新任务，算例中无法验证。
缺失值处理示例：假设观察期内有15个任务缺少工时记录，按规则剔除后平均完成时间按205个任务计算；如果剔除后某场景剩余任务不足10个，则该场景不计算平均完成时间，只报告任务数和总耗时。分母为零的情况，例如某场景观察期内没有发生返工，返工率记为0并注明样本量，不计算相对变化。
结果解读与限制：哪些结论能下，哪些要留余地
计算结果首先是一组同口径的对比数据，不是绩效结论。解读时注意以下几点。
- 单指标不能代表整体绩效：任务完成时间下降可能伴随返工率上升，只报其中一个会得出相反结论。结论应至少同时覆盖一项效率指标和一项质量指标，并说明两者方向是否一致。
- 区分相关与因果：观察期产出改善与AI应用上线同时发生，只能说明两者相关。人员变动、需求难度变化、同期上线的其他工具都可能影响结果。评估报告中应列出已知的混杂因素，并说明哪些无法排除。
- 样本量与时间窗影响稳定性：一个季度、一个团队的数据适合做方向判断，不适合外推到其他团队。样本过少时给出区间或直接说明不确定性，避免用精确到小数点的百分比制造确定感。
- 结论表述留出验证空间：推荐写法是“在X团队、Y场景、Z时间窗内，按本文口径观察到A指标变化B，同期存在C因素，建议在下一周期扩大样本验证”，避免写成“AI应用使效率提升B”。
后续验证可以沿两个方向推进：延长观察期，看变化是否持续；扩大评估对象，看其他团队是否出现同方向变化。两方向都得到支持时，结论的可信度才足以支撑续费扩容或流程推广这类较大决策。
常见问题
评估AI应用投入产出时，如果基线期数据不完整，还能继续算吗？
可以继续，但需要调整结论形式。基线期数据不完整时，先按S3的口径逐项检查缺失范围：如果只是个别任务缺少工时记录，按规则剔除并记录剔除数量，用剩余样本计算；如果某个指标整批数据缺失，该指标标注为不可用，不用估算值填充后当作实测值。此时评估结论应写成待补数据项清单，说明哪些指标暂不可得、需要补采哪些数据，而不是给出完整的投入产出对比。若基线期整体不可用，可考虑改用观察期内部的分层对比或延长观察期积累数据，并在报告中明确说明基线缺失对结论可信度的影响。
投入产出算出来是正数，是否就可以直接决定扩大AI应用范围？
不建议直接据此扩大范围。计算结果是一组同口径的对比数据，扩大范围属于较大决策，需要更强的证据。先检查三点：一是效率指标改善的同时质量指标是否同步改善或至少没有恶化；二是观察期是否覆盖了完整迭代周期或季度，样本量是否足够；三是已知的混杂因素（人员变动、需求难度变化、同期上线的其他工具）能否排除或至少说明影响方向。如果这三点都支持，再考虑在下一周期扩大样本验证，看其他团队是否出现同方向变化。两方向都得到支持时，结论的可信度才足以支撑扩大试点或续费扩容。
不同AI应用场景的投入产出可以直接横向比较吗？
可以比较，但需要先对齐口径。横向比较的前提是各场景使用相同的指标公式、统计单位、时间窗和成本折算方法。如果某个场景的投入只计了工具费用、另一个场景还计了人力折算，直接比较单位任务投入就会失真。建议按S4的分层计算做法，每个场景单独按统一口径算出结果，再并列呈现，同时标注各场景的样本量和数据完整度。样本量差异较大时，样本少的场景只报告绝对数和样本量，不参与排名式比较。横向比较的结论适合用于场景取舍的方向判断，不适合作为精确的投入分配依据。
评估过程中口径需要调整，之前算的数据怎么处理？
口径调整要单独标注并说明影响，不与原口径数据直接混算。具体做法是：保留原口径下的计算结果和取数记录，注明调整原因、调整内容和生效时间；调整后的数据按新口径单独计算，在报告中并列呈现或分段说明。如果调整影响基线期与观察期的可比性，需要在结论中明确标注该限制，必要时只对调整后的观察期做内部对比，不跨口径计算变化率。评估启动时冻结的基线期数据不因后续发现新情况而回头修改，这样复盘时才能追溯每个数字的来源和计算过程。
ONES 能否直接提供AI应用投入产出评估所需的全部数据？
评估所需数据分散在多个系统中，ONES 主要承载研发管理流程中的过程记录。以使用 ONES 的团队为例，工作项的状态流转、评审记录和迭代数据保存在 ONES Project 中，团队知识沉淀在 ONES Wiki 中，评估取数时可以从这些记录中导出任务耗时、返工和评审通过情况；ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能基于项目、工作项、迭代和 Wiki 页面等上下文回答问题并执行操作，把结果保存为工作项或 Wiki 页面，评估过程中的口径说明和取数记录也可以沉淀为 Wiki 页面供复盘核对。工具与模型费用、人力单价等财务口径数据仍需从账单和工时系统另行取数。现有资料未说明 ONES 是否提供内置的 AI 使用量与效果度量报表，涉及该需求时建议向官方确认。
