AI任务成功率用“被判定为成功完成的AI任务数”除以“纳入统计的AI任务总数”计算，结果以百分比表示。要让这个数字可复算、可比较，需要先固定三件事：什么算一个AI任务、什么算成功、统计时间窗与分母范围。本文面向研发场景中的AI辅助任务，给出定义表、取数口径、计算步骤和一个完整算例，并说明结果解读的边界；模型基准测试不在讨论范围内。
要点总览（TL;DR）
- AI任务成功率 = 成功任务数 ÷ 纳入统计任务总数 × 100%，分子分母必须来自同一任务单元定义和同一统计时间窗，否则数字不可复算。
- 统计前先固定任务单元（一次请求、一个工作项或一次完整交付，三者不混用）和成功分级（直接采纳、小改后采纳、重做、放弃），并约定前两级是否计入分子。
- 重试任务按最终结果计一次，拆分任务按子任务或父任务择一计数；未判定任务单列披露，分母为零时写“本期无纳入统计的任务”，不写0%或100%。
- 成功率受任务难度构成和判定尺度影响，需与返工率、平均尝试次数、人工介入时长组合解读，不设通用达标线，结论要带上团队、任务类型和口径条件。
评估目标：AI任务成功率要回答什么问题
这个指标服务于一个具体判断：在某一类研发任务上，AI辅助是否已经稳定可用，能否继续扩大使用范围。它统计的是任务层面的完成情况，回答“这类任务交给AI辅助，多大比例能顺利做完”，适合用来观察试点进展、比较不同任务类型的成熟度、决定下一阶段推广哪些场景。
评估开始前，建议把要支撑的决策问题写清楚，一般控制在两到三个，例如：
- 本期试点中，哪些任务类型的AI辅助完成情况已经稳定，可以扩大使用范围？
- 与上期基线相比，同一任务类型的成功率是否发生变化，变化来自任务构成还是判定标准？
- 未成功任务集中在哪个环节，需要补充上下文、调整流程还是收紧适用范围？
需要区分两类问题。“任务完成”问的是这次AI辅助产出是否被使用人接受并进入后续流程；“业务价值提升”问的是交付周期、缺陷密度、人力投入等结果是否改善。成功率只能为前者提供证据，后者需要另行设计对照与观察周期。把完成率直接写成“AI带来了效率提升”，属于超出指标能力的结论。
评估对象也应事先说明：统计的是研发流程中由AI参与的需求拆解、代码辅助、测试用例生成、文档撰写等任务，评价的是这些任务在真实工作流中的完成情况。模型在公开数据集上的准确率、推理能力等基准结果属于另一类评估，不能与本文口径混用。
指标与范围：任务单元、成功判定与统计边界
可执行的定义框架由四部分组成：任务单元、成功分级、纳入排除范围、重试与拆分规则。四者需要在统计开始前以书面形式固定，报告期内保持不变。
任务单元怎么定
常见口径有三种：一次请求、一个工作项、一次完整交付。一次请求以使用人发起的一次AI交互为单位，颗粒度细、记录多，适合观察交互层面的可用性；一个工作项以研发管理系统中的需求、任务、缺陷为单位，与团队日常管理对齐；一次完整交付以端到端产出为单位，例如一个需求从拆解到测试用例完成，颗粒度粗但更接近业务结果。
三种口径不能混用。同一份报告只采用一种，并在报告首页注明。若团队既想看交互质量又想看交付结果，应分别建立两套统计，各自独立计算，不把两套数字相加或平均。
成功判定分级
建议采用四级判定，前两级是否计入分子需事先约定并披露。下表给出可直接套用的定义：
| 等级 | 判定标准 | 是否计入分子 |
|---|---|---|
| 直接采纳 | 产出无需修改或仅做格式调整即进入后续流程 | 计入 |
| 小改后采纳 | 使用人做局部修改后采纳，核心结构与结论保留 | 计入（需在报告中说明） |
| 重做 | 产出方向可用但需大幅改写，或使用人重新发起同类任务 | 不计入 |
| 放弃 | 产出未被使用，任务转由人工完成或取消 | 不计入 |
“小改”与“重做”的边界最容易产生分歧。可操作的做法是约定修改幅度阈值，例如修改内容不超过产出的三分之一且不改变主要结论，判为小改；超过阈值或需要重新组织结构的，判为重做。阈值一旦确定，整个报告期沿用。
纳入与排除范围
纳入范围应写明试点团队、任务类型和时间窗。例如“2025年3月1日至3月31日，A团队在需求拆解与测试用例生成两类任务上的全部AI辅助记录”。排除项同样要列明，常见的有：试用性质的探索任务、因系统故障中断且未产生有效产出的任务、重复提交的同一任务。排除项必须有记录，不能只凭印象剔除。
重试与拆分的计数规则
重试任务按最终一次结果计数，不按尝试次数累加。同一任务重试三次后成功，记为一个成功任务，而不是三个任务中一个成功。若需要观察重试成本，可另设“平均尝试次数”作为辅助指标。
拆分任务有两种处理方式：按拆分后的子任务分别计数，或按父任务整体判定。二者择一，全报告期保持一致。按子任务计数适合颗粒度均匀的场景，按父任务判定适合子任务之间存在依赖、单独评价意义不大的场景。拆分规则变化时，应在报告中标注口径变更，不与历史数据直接比较。
数据口径与证据：成功率靠什么数据支撑
成功率由两类数据共同支撑：系统记录提供任务是否存在、何时发生、状态如何变化；人工判定提供这次产出属于哪个成功等级。缺少任何一类，分子都无法可靠得出。
定量字段清单
| 字段 | 用途 | 来源示例 |
|---|---|---|
| 任务标识 | 去重、关联子任务与父任务 | 工作项编号或请求ID |
| 任务类型 | 分组计算 | 需求拆解、测试用例、文档撰写等 |
| 所属团队与项目 | 分组计算、范围核对 | 项目空间、团队字段 |
| 创建与完成时间 | 确定统计时间窗 | 状态流转时间戳 |
| 状态流转记录 | 判断是否完成、是否回退 | 工作项状态历史 |
| 采纳与回退记录 | 辅助判定成功等级 | 评审结论、状态变更 |
| 重试次数 | 辅助指标，不进入分子分母 | 同一任务的重复请求记录 |
定性证据形式
成功等级最终由人判定，证据应可追溯。可用的形式包括：评审记录中的结论与意见、修改前后的版本对比、使用人对修改幅度的简短说明。判定人应相对固定，或至少在同一任务类型上由同一人判定，避免不同人尺度不一导致数字波动。
在研发管理工具中沉淀这些记录，可以减少事后补录。例如 ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能把自然语言指令转化为可追踪的工作项或 Wiki 页面，产出结果保存在系统中，任务标识、状态与评审意见随工作项一并留存，为后续统计提供原始记录。需要说明的是，成功率报表本身仍需按本文口径另行汇总，工具承担的是记录沉淀与追溯环节。
缺失值与未判定任务
未判定任务指已发生但尚未给出成功等级的任务。处理方式有三种：计入分母并按未成功处理、从分母中剔除、单列为“待判定”。推荐单列并在报告中披露数量，因为它既不影响已判定任务的比率，也提醒读者样本尚未闭合。缺失关键字段（如任务类型、完成时间）的记录应单独列出，查明原因后再决定是否纳入，不能默认按成功或失败填充。
数据可比性的前提是同一任务分类体系、同一判定标准、同一统计时间窗。三者任一变化，都应在报告中标注，跨期比较时说明差异来源。
计算步骤：从原始记录到成功率
基本公式为：
AI任务成功率 = 成功任务数 ÷ 纳入统计任务总数 × 100%
其中成功任务数按事先约定的等级口径取数，纳入统计任务总数为分母，两者必须来自同一任务单元定义和同一时间窗。
取数与去重步骤
- 按时间窗筛选任务记录，时间以完成时间为准，避免跨期任务重复计入。
- 按任务单元定义去重。以工作项为单位时，同一工作项的多条AI交互记录合并为一条；以请求为单位时，保留每次独立请求。
- 应用纳入排除清单，剔除探索性任务、系统故障中断任务和重复提交记录，剔除数量单独记录。
- 按成功分级逐条判定，未判定任务单列，不进入分子。
- 确定分母：已判定任务数加未判定任务数，或仅取已判定任务数，按事先约定执行并在报告中注明。
- 计算总体成功率，再按任务类型、团队、时间窗分组计算。
分组计算与呈现
总体值容易掩盖结构差异，建议至少按任务类型分组呈现。分组后每组样本量不同，样本过少的分组应标注数量，不单独下结论。跨团队比较时，需确认两边的任务难度构成和判定标准一致，否则只作参考。
分母为零与样本过少
分母为零时成功率无定义，报告中写“本期无纳入统计的任务”，不写0%或100%。样本量低于事先约定的下限（例如30条）时，可给出数值但标注“样本不足，仅供参考”，并同时披露样本量。任何情况下都不为了让数字好看而合并不同任务类型或拉长时间窗。
算例：一个月的AI任务成功率如何得出
以下为演示情景，数据为虚构，用于说明计算过程。
某团队统计2025年3月需求拆解类AI辅助任务。任务单元为工作项，成功判定采用四级标准，直接采纳与小改后采纳计入分子，未判定任务计入分母并单列。当月共产生任务记录132条，去重后128条，剔除系统故障中断2条，纳入统计126条。
| 项目 | 数量 |
|---|---|
| 纳入统计任务总数（分母） | 126 |
| 直接采纳 | 61 |
| 小改后采纳 | 34 |
| 重做 | 18 |
| 放弃 | 7 |
| 未判定 | 6 |
成功任务数为61加34，等于95。成功率为95除以126，约等于75.4%。若仅以已判定任务为分母，则为95除以120，约等于79.2%。两种口径差异来自6条未判定任务，报告中选择前者并注明“含未判定6条，按未成功计入”。
按子类型分组后，需求条目拆解成功率约81%，验收标准生成约68%，后者样本量为42条，可单独呈现。重试任务中有一条重试两次后小改采纳，按最终结果计为一个成功任务，不重复计数。拆分任务按子任务分别计数，父任务不另行统计，避免同一产出被计算两次。
结果呈现建议采用“总体值加分组值”的表格，每行标注样本量，未判定数量单列一行。这样读者既能看整体水平，也能判断各分组结论的可信度。
解读与限制：成功率高低说明什么、不说明什么
成功率反映的是纳入统计任务中完成情况的比例，它受任务难度构成、判定标准和样本范围共同影响。解读时应把这三个因素与数字一起说明。
- 任务构成影响可比性。一个团队本期多做了简单任务，成功率自然上升，这不代表能力提升。跨团队或跨期比较前，先核对任务类型分布是否接近。
- 高成功率可能来自宽松判定。若“小改后采纳”的阈值放宽，或判定人倾向从宽，数字会偏高。定期抽查判定记录、保持判定人稳定，是控制这一风险的基本做法。
- 单看成功率会遗漏成本。成功任务可能伴随大量重试和人工修改。建议与返工率、平均尝试次数、人工介入时长、任务周期变化组合解读，形成一组相互印证的指标。
- 不设通用达标线。不同任务类型、不同团队基础差异大，宜以试点期基线或团队自定目标作为参照，说明目标设定的依据。
- 结论保留条件。表述为“在A团队3月需求拆解任务、现行判定标准下，成功率为75.4%”，比“AI任务成功率75%”更准确，也避免把单指标直接写成绩效结论。
常见误读包括：把成功率等同于业务收益、用总体值掩盖分组差异、忽略未判定任务、在口径变更后仍与历史数据直接比较。规避方式是在每份报告中固定披露任务单元、成功分级、分母构成、样本量和口径变更记录，让读者能够自行复算并判断结论的适用范围。
常见问题
任务单元选“一次请求”还是“一个工作项”，对成功率影响大吗？
影响明显，因为两种口径的分子分母完全不同。以一次请求为单位，同一工作项下的多次交互会被分别计数，成功率更接近交互层面的可用性；以一个工作项为单位，多次交互合并为一条，成功率反映的是任务层面的完成情况。
选择依据是评估目的：观察交互质量和提示词效果，用请求口径；判断某类研发任务能否扩大使用范围，用工作项口径。两种口径可以并行统计，但各自独立计算，不把两套数字相加或平均。报告首页注明本期采用哪一种，报告期内保持不变。
“小改后采纳”和“重做”的边界怎么定，判定人之间不一致怎么办？
边界靠事先约定的修改幅度阈值来定，例如修改内容不超过产出的三分之一且不改变主要结论判为小改，超过阈值或需要重新组织结构判为重做。阈值写进统计口径文档，整个报告期沿用。
判定人不一致时，可采取三项措施：同一任务类型固定由同一人判定；定期抽查已判定记录，比对不同判定人的尺度差异；对争议样本保留修改前后版本对比作为证据。若中途更换判定人，应在报告中标注，跨期比较时说明可能的影响。
未判定任务应该计入分母吗？
两种做法都可以，关键是事先约定并在报告中披露。计入分母并按未成功处理，得到的是偏保守的成功率；从分母中剔除、只算已判定任务，得到的是已判定样本内的成功率，数值通常更高。
推荐做法是把未判定任务单列一行，同时给出两种口径的数值和未判定数量，让读者判断样本是否闭合。缺失关键字段（如任务类型、完成时间）的记录应单独列出，查明原因后再决定是否纳入，不默认按成功或失败填充。
成功率多高才算AI应用有效？
没有通用达标线。不同任务类型的难度差异很大，需求条目拆解和验收标准生成的合理水平并不相同，跨团队套用同一个阈值容易得出错误结论。
可行的做法是以试点期基线作为参照：先统计一个完整周期的成功率，记录当时的任务构成和判定标准，再设定下一期的改进目标，并说明目标依据。目标应绑定具体任务类型和团队，例如“A团队需求拆解任务成功率从75%提升到80%”，而不是给全组织定一个统一数字。
成功率数据从哪里取，需要额外补录吗？
数据来自两类记录：系统侧的任务标识、任务类型、创建与完成时间、状态流转、采纳与回退记录；人工侧的评审结论、修改幅度说明。前者决定任务是否存在、何时完成，后者决定成功等级。
把AI产出直接沉淀在研发管理系统中，可以减少事后补录。例如 ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，把自然语言指令转化为可追踪的工作项或 Wiki 页面，产出结果与状态、评审意见随工作项一并留存，为统计提供原始记录。成功率报表本身仍需按本文口径另行汇总，工具承担的是记录沉淀与追溯环节。
