记录AI建议的采纳情况，难点通常不在定义，而在数据分散：IDE里的补全接受、代码评审里的评论处理、提交记录里的代码变化，各自留下不同信号。可行的做法是把结果统一为直接采纳、修改后采纳、拒绝三类，以既有事件自动写入一张采纳事件表，人工只处理无法自动判定的少量样本。ONES可在工作项与评审环节承接记录动作，本文围绕这套记录方案展开。
要点总览（TL;DR）
- 三类结果按“建议是否被采用、采用后内容是否改动”判定：直接采纳是建议原样进入代码或文档，修改后采纳是采用但有改动，拒绝是建议已展示但未被采用。
- 采集以IDE补全、代码评审、提交记录三个环节的既有事件为数据源，分别映射到三类结果，同一建议以建议ID去重并保留每次触达明细。
- 采纳事件表统一字段包括建议ID、场景、结果类型、修改幅度、时间、人员、关联工作项，由工具自动写入，人工只处理语义级修改等模糊情形。
- 减少人工填报的关键是自动判定覆盖率和抽样复核：先上线基础规则，统计待复核比例，再针对高频模糊情形补充规则，复核结论用于修正规则而非逐条补录。
三类采纳结果怎么定义才可判定
三类结果要能被程序判定，定义必须落到可观察的动作上，而不是停留在“有用”“采纳了”这类主观描述。建议以“建议是否进入最终产物”和“进入后内容是否改动”两个维度划分，判定时以建议展示后的实际行为为准。
| 结果类型 | 定义 | 判定依据 | 边界情形 |
|---|---|---|---|
| 直接采纳 | 建议内容原样进入代码或文档 | 接受事件发生，且后续提交中该段内容与建议一致 | 仅调整缩进或换行，仍计为直接采纳 |
| 修改后采纳 | 建议被采用，但内容有改动 | 接受事件发生，且提交内容与建议存在可计算的差异 | 改动幅度低于阈值时需明确归入哪一类 |
| 拒绝 | 建议已展示给使用者，但未被采用 | 展示事件发生，且无接受行为，产物中不含该建议 | 建议未展示、未触达不计入拒绝 |
修改后采纳的判定阈值需要团队自行校准。常用信号包括改动行数、改动行占建议总行数的比例、是否仅涉及格式调整。阈值不宜直接套用统一数值，代码风格严格、格式化工具自动介入的团队，格式类改动应排除在“修改”之外，否则修改后采纳会被高估。建议先取一批样本人工标注，再反推阈值，使自动判定与人工判断的一致率达到可接受水平。
拒绝必须与未触达、未展示区分开。只有建议实际出现在使用者面前且未被采用，才计入拒绝；因触发条件不满足而未弹出的建议，不进入分母。这一区分直接决定采纳率是否可信，记录方案中应把“展示事件”作为独立字段保留。
统一字段清单建议至少包含：建议ID、场景（IDE补全/评审评论/提交辅助）、结果类型、修改幅度、展示时间、处理时间、人员、关联工作项。字段在三个环节保持一致，后续才能合并统计。
在IDE、代码评审和提交环节分别采集什么
三个环节能拿到的信号不同，采集时要按各自的事件类型映射到三类结果，避免用同一套判断逻辑硬套所有环节。
| 环节 | 可采集信号 | 映射到结果类型 |
|---|---|---|
| IDE补全 | 建议展示、接受、接受后编辑、忽略、超时未处理 | 接受且未编辑→直接采纳；接受后有编辑→修改后采纳；展示后忽略→拒绝；未展示→不计入 |
| 代码评审 | AI评论展示、被采纳并修改、被驳回、无响应 | 按评论修改且内容一致→直接采纳；按评论修改但有调整→修改后采纳；驳回或无响应→拒绝 |
| 提交记录 | 提交内容与建议的文本关联、改动行、提交人、关联工作项 | 用于校验IDE与评审环节的判定，补充修改幅度 |
提交记录本身不直接产生“采纳”判断，它的作用是把IDE和评审环节的行为与最终代码对应起来。通过建议ID或内容指纹把提交中的代码段与建议关联，可以确认建议是否真正落地，也能计算修改幅度。关联方式可以是建议携带唯一标识写入注释或元数据，也可以基于文本相似度匹配，前者更稳定，后者覆盖更广但需要设置相似度下限。
同一建议可能在多个环节多次触达，例如IDE中拒绝的建议在评审中再次以评论形式出现。处理方式是以建议ID为主键去重，同时保留每次触达的环节和结果，统计时按“建议—环节”记录明细，按建议汇总最终结果。这样既不重复计数，也能看出建议在哪个环节更容易被接受。
采纳事件表怎么设计字段与写入流程
采纳事件表是整套方案的核心载体，设计目标是让工具能自动写入、分析人员能直接查询，人工只在异常情况下介入。
| 字段 | 说明 | 写入方式 |
|---|---|---|
| 建议ID | 唯一标识一条建议，跨环节复用 | 工具生成 |
| 场景 | IDE补全、评审评论、提交辅助 | 工具写入 |
| 结果类型 | 直接采纳、修改后采纳、拒绝 | 规则自动判定 |
| 修改幅度 | 改动行数或改动比例 | 提交比对自动计算 |
| 展示时间/处理时间 | 建议出现与被处理的时间 | 事件时间戳 |
| 人员 | 处理建议的研发人员 | 工具账号关联 |
| 关联工作项 | 对应的需求、任务或缺陷 | 从提交或评审记录带入 |
自动写入的触发点设在三个位置：IDE插件在建议被接受、编辑或忽略时上报事件；代码评审工具在AI评论被处理时上报；提交钩子在提交完成时比对建议内容并回填修改幅度。数据流向是各环节事件先进入采集层，按建议ID归并后写入采纳事件表，再由报表读取。关联工作项这一步可以借助ONES承接：提交和评审记录关联到ONES工作项后，采纳事件表通过工作项ID与研发任务对应，分析时能按需求或迭代查看采纳情况。
无法自动判定的情形主要是语义级修改，例如建议被采纳但表达方式整体重写，文本相似度落在模糊区间。这类记录标记为“待复核”，进入抽样队列，由人工确认后回写结果，规则同步调整。数据保留方面，事件表只存行为与关联标识，不保存完整代码内容；人员字段用于分析而非考核个体，保留周期与团队现有研发数据政策保持一致。
角色分工与各环节交付物
方案能否持续运行，取决于每个角色只承担必要的动作。研发人员原则上不新增填报，其余角色围绕数据质量各负其责。
| 角色 | 动作 | 交付物 |
|---|---|---|
| 研发人员 | 正常使用IDE与评审工具，无需额外记录 | 无额外交付，行为事件由工具采集 |
| 评审人 | 处理AI评论时按常规采纳或驳回，必要时确认待复核样本 | 评审处理记录、少量复核结论 |
| 工具管理员 | 维护埋点、建议ID规则、字段定义与采集链路 | 采集配置、字段说明、链路可用性报告 |
| 效能分析人员 | 校准判定阈值，抽查数据质量，输出采纳情况报表 | 口径说明、复核记录、采纳统计报表 |
评审人和提交环节的责任在于让处理动作可被识别：采纳评论时通过工具操作而非口头沟通，提交时保持与工作项的关联。工具管理员负责埋点覆盖三个环节，并在建议ID规则变更时同步更新采集逻辑。分析人员定期比对自动判定与人工复核结果，阈值偏离时提出调整，而不是逐条补录数据。
一个完整示例：从一次补全到一条采纳记录
以下为演示情景，用于说明三类结果如何各自形成一条记录。
直接采纳：研发人员在IDE中编写一个参数校验函数，补全建议给出完整校验逻辑，研发人员按Tab接受且未再编辑，随后提交。插件上报接受事件，提交钩子比对确认内容一致，事件表写入一条记录：场景为IDE补全，结果类型为直接采纳，修改幅度为0，关联到当前迭代的工作项。
修改后采纳：同一研发人员在另一处接受建议后，将校验规则中的边界值从大于改为大于等于，改动2行。提交时比对计算改动比例为可识别范围，事件表写入修改后采纳，修改幅度记录为2行，并保留改动位置供复核参考。
拒绝：评审环节AI评论建议抽取公共方法，评审人查看后认为当前模块即将重构，驳回该评论。评审工具上报驳回事件，事件表写入拒绝，场景为评审评论。该建议未进入提交内容，不产生修改幅度。
同一建议再次出现：若上述被拒绝的抽取建议在后续提交辅助中再次被推荐，研发人员此次接受并修改后落地，事件表新增一条触达记录，按建议ID归并后，该建议的最终结果以最后一次有效触达为准，历史触达保留在明细中，统计时不重复计入分母。
怎么把人工填报压到最低
减少人工填报的核心原则是：能用既有事件推导的字段一律自动生成，人工只处理规则无法覆盖的模糊情形。按这一原则，需要人工确认的字段应压缩到最少。
- 结果类型、修改幅度、时间、人员、关联工作项均由工具写入，不设人工录入入口。
- 语义级修改导致的模糊判定进入待复核队列，由评审人或分析人员确认，复核结果回写并用于修正规则。
- 建议ID规则变更、新增采集环节时，由工具管理员一次性配置，不要求研发人员配合填报。
自动判定覆盖率的提升路径是：先上线基础规则，统计待复核比例；再针对高频模糊情形补充判定规则，例如把仅格式调整自动归入直接采纳、把整体重写自动归入修改后采纳；每轮调整后用同一批样本验证一致率。覆盖率提升后，抽样复核的样本量可以相应下调。
抽样复核建议按固定频率进行，例如每周抽取待复核记录和少量已自动判定记录，样本量按团队数据量设定，保证能发现规则偏差即可。复核的目的是校准口径，不是逐条补录，因此复核结论应转化为规则修改，而不是长期依赖人工确认。必须人工确认的字段通常只有两类：模糊区间的结果类型，以及建议与工作项的关联在自动匹配失败时的归属。
在ONES中，采纳事件可关联到工作项，评审与提交记录也落在同一工作项下，分析人员按需求或迭代查看采纳情况时，不需要再从多个系统拼接数据。ONES Assistant可基于项目与工作项上下文执行操作并保存结果，适合把复核结论、口径说明沉淀为可追踪的记录，减少重复录入。
上线前的完成检查
方案上线前，用以下清单逐项核对，全部通过再进入正式统计。
- 三类结果是否都有明确判定规则，且每条规则都有对应的可观察事件。
- 拒绝是否已与未展示、未触达区分，展示事件是否单独记录。
- 修改后采纳的阈值是否经过样本校准，格式类改动是否已排除。
- IDE、代码评审、提交三个环节是否都已接入自动写入，是否存在遗漏环节。
- 同一建议跨环节出现时，是否按建议ID去重并能查看每次触达明细。
- 待复核队列是否可执行，复核频率与样本量是否已确定，复核结论是否有回写路径。
- 采纳事件表能否直接计算采纳率，分母是否只包含已展示的建议。
- 关联工作项是否可用，能否按需求、迭代维度汇总采纳情况。
- 数据保留范围与人员字段使用方式是否与团队数据政策一致。
检查中发现某环节事件缺失或判定一致率偏低时，应先补齐采集或调整规则，再开放报表，避免用不完整数据形成结论。
常见问题
修改后采纳的判定阈值怎么定，才能避免把格式调整算成修改？
阈值不宜直接套用统一数值，建议先取一批样本人工标注，再反推改动行数或改动比例的合理区间。代码风格严格、格式化工具自动介入的团队，应把仅涉及缩进、换行、空格的改动排除在“修改”之外，否则修改后采纳会被高估。阈值校准后，用同一批样本验证自动判定与人工判断的一致率，一致率可接受再正式使用。
建议在IDE中被拒绝，后来在代码评审中又被推荐并采纳，这条建议算拒绝还是采纳？
按建议ID归并后，以最后一次有效触达的结果作为该建议的最终结果，同时保留每次触达的环节和结果明细。统计时按“建议—环节”记录明细，按建议汇总最终结果，这样既不重复计入分母，也能看出建议在哪个环节更容易被接受。历史触达记录不删除，用于分析建议质量与环节差异。
抽样复核的样本量和频率怎么定，才不会变成变相的人工填报？
抽样复核的目的是校准口径，不是逐条补录。频率可以按周或按迭代设定，样本量按团队数据量取一个能发现规则偏差的最小值，例如每周抽取待复核记录和少量已自动判定记录。复核结论应转化为规则修改，规则稳定后样本量可相应下调。如果复核长期停留在人工确认而不修正规则，说明自动判定覆盖不足，需要优先补充判定规则。
采纳事件表需要保存代码内容吗，人员字段会不会带来隐私顾虑？
事件表建议只存行为与关联标识，例如建议ID、场景、结果类型、修改幅度、时间和人员，不保存完整代码内容。人员字段用于分析建议在哪些环节、哪些场景更容易被采纳，不用于个体考核。数据保留周期与团队现有研发数据政策保持一致，并在方案上线前明确人员字段的使用范围。
三个环节的事件都接入了，但采纳率报表还是对不上，可能是什么原因？
常见原因有三类：一是分母混入了未展示的建议，拒绝与未触达没有分开；二是同一建议跨环节重复计数，没有按建议ID去重；三是修改后采纳的阈值与人工判断偏差较大，导致结果类型分布失真。建议先核对展示事件是否单独记录，再检查建议ID在三个环节是否一致，最后用样本比对自动判定与人工判断的一致率。
