AI建议采纳率的基本算法是“被采纳的AI建议数 ÷ 有效AI建议总数 × 100%”。真正影响结果可信度的是口径：什么算一条建议、什么算采纳、重复与撤回如何处理、统计时间窗多长。本文给出一套可复算的定义、取数与复核方法，并说明结果该怎么读。在研发管理场景中，ONES 的工作项与 Wiki 页面可作为建议落地结果的承载记录，便于把采纳行为对应到具体产出。
要点总览（TL;DR）
- AI建议采纳率 = 采纳建议数 ÷ 有效建议数 × 100%，分母要先剔除重复、过期和非研发场景建议，否则结果会被系统性低估。
- 采纳判定按证据强度分三档：直接应用、修改后应用、显式标记采纳；仅浏览不计入分子，分母为零时标注“不适用”而非0%。
- 计算流程为确定范围、导出记录、去重清洗、按口径计算、抽样复核五步，抽样比例建议不低于10%且不少于30条，并保留清洗日志便于复算。
- 采纳率只反映建议被接受的程度，需与建议覆盖率、采纳后返工率、缺陷率等指标联合解读，跨团队对比前先对齐口径。
- 采纳率适合用于定位改进点，直接作为个人考核指标容易诱导机械点击，破坏数据可信度。
这个指标要回答什么问题
AI建议采纳率衡量的是AI给出的建议在研发流程中被实际接受和使用的程度。它回答的是“团队是否在用、用到什么程度”，而不是“模型本身有多强”。模型能力通常由基准测试、离线评测集来回答；采纳率回答的是建议进入真实工作流之后的落地情况。两者不能互相替代：一个在评测集上表现良好的模型，其建议可能因为不符合团队规范、上下文不足或呈现时机不对而很少被采用。
计算前需要把两层问题分开。第一层是“建议是否被看见”：建议是否被展示、是否被打开、是否进入相关人员的视野。第二层是“建议是否被采纳”：看到建议的人是否实际应用了它。这两层的分母不同，混在一起会让指标失真。只统计被看见的建议，得到的是“可见建议的采纳率”；统计全部生成建议，得到的是“生成建议的采纳率”。前者更接近使用体验，后者更接近整体产出效率，选择哪一层要在指标定义卡中写明。
这个指标与研发效能指标也有边界。交付周期、缺陷率、需求吞吐量反映的是研发结果，采纳率只反映AI建议这一环节的接受程度。它适合作为AI应用效果评估中的一个过程指标，与结果指标配合使用，单独拿出来不足以说明AI带来了多少改进。
分子分母怎么定：建议与采纳的口径
指标定义卡需要固定五件事：公式、分子、分母、时间窗、统计单位。公式为：采纳率 = 采纳建议数 ÷ 有效建议数 × 100%。分母为零时，结果标注为“不适用”，不计为0%，否则会被误读为“建议全部未被采纳”。
分母：有效AI建议总数
分母不是系统生成的全部建议条数，而是经过纳入与排除规则清洗后的有效建议数。建议在指标定义卡中明确以下规则：
- 纳入：在统计时间窗内生成、面向研发场景、内容完整可执行的建议。
- 排除重复建议：同一会话内对同一对象反复生成的近似建议，按一条计；去重规则要写明是按内容相似度还是按建议对象加建议类型。
- 排除过期建议：生成时对应的任务已关闭、需求已变更，建议失去应用前提的，不计入分母。
- 排除非研发场景建议：与研发流程无关的通用问答、闲聊类输出，不计入。
- 撤回建议：系统或用户主动撤回的建议，按约定处理——若撤回发生在展示前，不计入分母；展示后被撤回，计入分母并在备注中标记。
分子：采纳的判定方式
采纳判定建议分三档，按证据强度从高到低：
| 采纳类型 | 判定依据 | 计入分子 |
|---|---|---|
| 直接应用 | 建议内容被原样写入工作项、文档或代码，有系统操作记录 | 是 |
| 修改后应用 | 建议被部分采用并经过人工修改，需有修改前后对照或操作记录 | 是，建议单独标记以便区分 |
| 显式标记采纳 | 使用者主动点击采纳或标注，记录确认人与时间 | 是 |
| 仅浏览未操作 | 无应用痕迹 | 否 |
统计单位要在定义卡中固定：按建议条数计数，还是按会话或任务计数。按条数计数适合评估建议质量分布，按任务计数适合评估“每个任务平均获得多少可用建议”。两种单位算出的比率不可直接比较，跨期对比前必须确认单位一致。
数据从哪里来、如何保证可核对
采纳判定的可信度取决于证据能否逐条回溯。建议按证据等级组织数据来源：系统操作记录为第一证据，人工标注为补充证据，主观印象不作为计算依据。
- 建议生成记录：工具侧记录的建议ID、生成时间、建议类型、关联对象（需求、缺陷、任务等）、建议内容摘要。
- 采纳操作日志：建议被应用时的操作记录，包括操作人、操作时间、应用到的目标对象。这是判定“直接应用”和“修改后应用”的主要依据。
- 人工标注表：对无法从系统日志判定的记录，由指定人员逐条确认，表中需包含建议ID、判定结论、确认人、确认时间、判定理由。
数据质量检查至少覆盖三类问题：重复记录（同一建议被多次写入）、跨系统对不齐（建议ID在生成侧与采纳侧不一致）、时间错位（采纳时间早于建议生成时间，说明关联错误）。发现异常记录时标注为“待核”，不直接计入分子或分母。确实无法取得的数据，标注为缺失并在报告中说明缺失比例，不用默认值填补。
在研发管理工具中，建议落地后的结果往往体现为工作项状态变化、文档版本更新或评审记录。以 ONES 为例，ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把自然语言指令转化为可追踪的工作，结果保存为工作项、Wiki 页面等内容。这意味着建议被应用后留下的工作项和页面变更，可以作为采纳证据的载体；建议ID与工作项的关联字段是否可用，需要在具体版本中确认后再设计取数方案。
计算与验证步骤
计算流程按五步走，每步留下可复算的中间产物：
- 确定统计范围：写明时间窗起止、建议类型、涉及团队或项目、统计单位。范围一旦确定，本期计算不再调整。
- 导出建议与采纳记录：从工具侧导出建议生成记录和采纳操作日志，保留原始字段，导出时间一并记录。
- 去重与清洗：按定义卡中的排除规则处理重复、过期、非研发场景建议，生成清洗日志，记录每条被排除记录及原因。
- 按口径计算：分别计算清洗前后的采纳率，保留分子、分母的明细表，便于核对差异来源。
- 抽样复核：抽取一定比例记录人工核对采纳判定，建议抽样比例不低于10%且不少于30条；样本量不足时全量核对。
复核时重点看三类记录：修改后应用的判定是否准确、显式标记采纳是否有确认人、跨系统关联是否存在错位。复核结果与初次计算不一致的，回到清洗环节修正并记录修正原因。交叉验证方面，可将计算结果与工具侧已有统计、团队访谈结论比对；差异较大时优先检查口径是否一致，而不是直接采信某一方。计算脚本或表格需保留版本号，注明计算日期与口径版本，便于他人复算。
一个可复算的例子
以下为演示情景，数字仅用于说明计算过程。某团队统计一个月内需求拆解类AI建议的采纳情况：
| 项目 | 数量 | 说明 |
|---|---|---|
| 系统生成建议 | 500条 | 原始导出记录 |
| 重复建议 | 60条 | 同一需求反复生成，按一条计 |
| 过期建议 | 40条 | 对应需求已关闭 |
| 非研发场景建议 | 20条 | 通用问答类输出 |
| 有效建议 | 380条 | 500 − 60 − 40 − 20 |
| 直接应用 | 120条 | 有系统操作记录 |
| 修改后应用 | 80条 | 有修改前后对照 |
| 显式标记采纳 | 30条 | 有确认人与时间 |
| 采纳合计 | 230条 | 120 + 80 + 30 |
清洗前按500条计算，采纳率为230 ÷ 500 × 100% = 46.0%；清洗后按380条计算，采纳率为230 ÷ 380 × 100% ≈ 60.5%。差异来自分母中剔除了120条无效建议。这个对比说明：如果直接拿系统生成总数当分母，采纳率会被系统性低估，且不同团队的去重力度不同会导致结果不可比。
若某周有效建议为0，该周采纳率标注为“不适用”，不写0%。若抽样复核发现10条“修改后应用”中有2条实际未应用，则分子修正为228条，采纳率约为60.0%，修正记录需写入计算日志。解读时，60.5%只说明该月需求拆解建议的接受程度，不能直接推断需求交付质量提升，需要结合返工率和缺陷数据一起看。
结果怎么解读、有哪些限制
采纳率高不等于效果好。建议被采纳后如果频繁返工，说明建议质量或适配性存在问题；采纳率上升但缺陷率同步上升，也需要排查建议是否引入了新的风险。解读时应至少配套三个指标：建议覆盖率（有多少任务获得了建议）、采纳后返工率（采纳建议的产出被修改或退回的比例）、结果指标（缺陷率、交付周期）的变化趋势。
口径变化会导致结果不可比。跨团队、跨时间对比前，先对齐建议类型划分、去重规则、采纳判定标准和统计单位。团队规模、任务类型分布、AI使用熟练度都会影响采纳率，样本量小的团队单周数据波动大，建议按月度或季度汇总后再比较。
采纳率适合用于改进：定位哪类建议采纳低、哪个环节建议未被使用，据此调整建议的呈现方式或生成策略。把它直接作为个人考核指标，容易诱导使用者为凑采纳而机械点击，反而破坏数据可信度。指标定义卡、清洗日志和复核记录应随报告一同留存，让每次计算结果都能被复算和追溯。
常见问题
同一会话里AI对同一需求反复给出建议，分母应该按几条算？
按一条计，但去重规则要在指标定义卡里写明：是按内容相似度判定近似建议，还是按“建议对象＋建议类型”判定。两种规则算出的分母不同，跨期对比前要确认规则一致。去重过程建议保留被合并记录的清单，方便复核时还原原始条数。
建议被采纳后又撤回或回滚，分子要不要扣减？
建议在指标定义卡中约定处理方式。常见做法是：采纳后在同一统计周期内被回滚的，从分子中扣减并在计算日志中标记；跨周期回滚的，在回滚发生的那一期做修正记录，不追溯修改已发布的历史结果。无论选哪种，规则固定后不要中途更换，否则前后数据不可比。
没有系统操作日志，只能靠人工确认采纳，这样的数据能用吗？
可以用，但要降低结论强度。人工标注表需包含建议ID、判定结论、确认人、确认时间和判定理由，并记录标注覆盖率。人工判定比例过高时，建议在报告中说明证据等级，同时抽样核对标注一致性，避免不同确认人对“修改后应用”的理解不一致。
在ONES里做采纳统计，建议和工作项的关联怎么落地？
ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把自然语言指令转化为可追踪的工作，结果保存为工作项、Wiki 页面等内容。建议被应用后留下的工作项和页面变更，可以作为采纳证据的载体。建议ID与工作项之间的关联字段是否可用，需要在具体版本中确认后再设计取数方案。
团队规模小、建议量少，采纳率波动很大怎么办？
按月度或季度汇总后再看趋势，避免用单周数据下结论。样本量过小时，可以同时报告分子分母的绝对数，让读者判断比率背后的实际条数。若某期有效建议为零，标注“不适用”，不计为0%。
