制定AI试点评估标准，核心是从试点要支持的决策倒推：先明确试点要回答“是否推广、是否扩大范围、是否调整用法”，再把效果拆成采纳与使用、任务质量、交付节奏、风险与合规四类可观测指标，为每个指标写清定义、取数来源、基线值、目标值和判定规则，并在试点启动前定稿。标准要能被不同角色复现执行，评审结论才有依据。试点过程中的指标口径、取数记录与评审结论需要统一承载，ONES 可在项目与文档层面承接这部分管理动作。
要点总览（TL;DR）
- 评估标准从试点要回答的决策倒推：是否推广、是否扩大范围、是否调整用法，先写清试点问题与范围，再决定测哪些指标。
- 指标按采纳与使用、任务质量、交付节奏、风险与合规四类拆分，每项写清定义、公式、数据来源、统计周期、基线值、目标值和判定规则。
- 基线取试点前同口径数据，目标值参考历史水平、试点假设与可接受波动，判定规则预设达标、部分达标、未达标三档，并明确一票否决项。
- 标准制定、取数留痕、评审判定三类职责落实到人，按启动前定稿、周期采集、中期检查、结束评审的节奏推进，结论限定为推广、调整后继续、停止。
- 发布前逐项核对指标字段完整性、基线可复现、阈值明确、角色与时间点落实、口径变更记录方式，缺项补齐后再公示。
先定试点问题：评估标准从要回答的决策开始
评估标准容易写成指标清单，原因通常是先想“能测什么”，而不是先想“要决定什么”。更稳妥的起点是把试点要回答的业务问题写清楚，再决定测哪些指标。常见的问题有三类：这套AI应用方式是否值得在更大范围推广；是否先在当前团队扩大使用角色或任务类型；是否需要调整使用方式，例如改变提示模板、限定适用任务或增加人工复核环节。问题不同，指标取舍和判定阈值也不同。
与问题配套的是试点范围说明。范围至少写清四件事：参与团队与角色、纳入的任务类型、试点时间窗、样本量或任务数量的下限。范围写得越具体，基线取数和结论适用范围就越清楚。例如“在两个后端小组、为期六周、覆盖需求拆解与单元测试生成两类任务”比“在研发团队试点AI编码”更可评估。
评估对象需要明确为AI应用方式与使用效果，包括工具在具体任务中的使用方式、产出被采纳的情况、对交付节奏的影响以及风险控制措施是否到位。技术模型基准测试、模型能力跑分属于另一类工作，一般研发效能指标体系建设也有独立的方法，二者不纳入本标准，避免试点结论被无关数据稀释。完成标志是一页《试点评估目标与范围说明》，包含试点问题、范围、评估对象和不纳入的指标清单，由试点负责人确认后作为标准的第一部分。
指标怎么拆：四类可观测口径与字段定义
指标按四类拆分，每类只保留能支撑试点决策的少数几项。指标过多会拉高取数成本，也会让评审时难以聚焦。下表给出分类、典型指标和观察目的，可作为筛选起点。
| 指标类别 | 典型指标 | 观察目的 |
|---|---|---|
| 采纳与使用 | 使用人数、周活跃频次、生成内容被采纳比例 | 判断工具是否真正进入工作流，而非只在启动期试用 |
| 任务质量 | 一次通过率、评审意见数、缺陷或返工情况 | 判断AI参与后的产出质量是否稳定 |
| 交付节奏 | 任务前置时间、评审等待时间 | 判断环节耗时是否发生可观察的变化 |
| 风险与合规 | 敏感信息处理记录、人工复核覆盖率 | 判断使用边界是否被遵守，复核机制是否落地 |
每个指标都要落到统一字段，缺一项就难以复现。建议的字段表如下：
| 字段 | 填写要求 |
|---|---|
| 指标名称 | 简短、无歧义，避免一个名称包含两个概念 |
| 定义 | 说明统计对象和边界，例如“采纳”指生成内容未经实质修改即进入提交或评审 |
| 计算公式 | 分子分母写清，注明去重和排除规则 |
| 数据来源 | 具体到系统、报表或记录表，注明由谁维护 |
| 统计周期 | 按周、按迭代或按试点阶段，全标准统一 |
| 基线值 | 试点前同口径数据，注明取数区间 |
| 目标值 | 与试点假设对应，注明设定依据 |
| 判定规则 | 达标、部分达标、未达标的具体阈值 |
定义环节最容易出问题的是“采纳”和“返工”这类词。采纳可以按“生成内容被直接使用”“修改后使用”“未使用”三档记录，返工可以按“因AI产出导致的返工”单独标记，避免把常规返工计入。字段表完成后，应组织业务与研发代表逐项确认口径，确认记录随标准一起归档。
基线与目标值怎么取：对照设置与判定规则
基线取试点启动前一段时间的同口径数据，区间长度与试点周期大致相当，并避开版本发布高峰等异常时段。基线数据要能按同一公式重算，取数脚本或查询条件应留档。若试点前没有留存相应数据，应在标准中写明替代方案，例如用试点首两周的对照小组数据补位，并标注这一替代对结论强度的影响。
对照设置有前后对比和对照组两种常见做法。前后对比实施成本低，适合任务类型稳定、外部干扰较少的场景，局限是难以区分AI带来的变化与季节、版本节奏等因素。对照组更严谨，但需要划分可比的任务和人员，管理成本更高。选择哪种方式，应在标准中写明理由和局限，而不是默认某一种更优。
目标值设定可参考三个来源：团队历史水平、试点假设、可接受波动。历史水平给出下限参考，试点假设说明期望改善的方向和幅度，可接受波动决定阈值区间。判定规则建议预设三档，例如“达标：核心指标达到目标值且风险类指标无违规记录；部分达标：核心指标达到目标值的八成以上，或风险类指标存在可整改问题；未达标：核心指标低于部分达标线，或出现需停止使用的风险事件”。具体数值按试点实际设定，关键是阈值在启动前写死。
结论不以单一指标下结论。采纳率高但质量指标恶化，或节奏改善但复核覆盖率不足，都应触发评审组的综合判断。标准中可以规定“一票否决项”，例如出现敏感信息外泄事件即判定未达标，其余指标再综合评估。
角色分工与交付物：谁定标准、谁取数、谁判定
标准能否执行，取决于职责是否落到人。建议区分四类角色，各自交付物和时间点如下表。
| 角色 | 主要职责 | 交付物 | 时间点 |
|---|---|---|---|
| 试点负责人 | 确定试点问题与范围，组织标准定稿和评审 | 目标与范围说明、标准定稿、评审结论 | 启动前、中期、结束 |
| 业务与研发代表 | 确认指标口径与样本范围，提供任务侧判断 | 口径确认记录、样本清单 | 启动前 |
| 数据提供方 | 按周期取数，记录异常与口径变更 | 周期数据表、取数留痕、异常说明 | 试点期间按周期 |
| 评审组 | 按判定规则给出结论，处理争议 | 评审纪要、结论与处理建议 | 中期、结束 |
数据提供方需要保留取数过程记录，包括查询条件、数据快照时间和处理步骤，便于复核。口径变更必须走记录与审批，写明变更原因、影响范围和生效时间，避免同一试点前后数据不可比。评审组的结论应引用具体指标值和判定规则条款，减少事后解释空间。
在工具层面，试点的问题说明、指标字段表、周期数据和评审纪要需要有稳定的存放位置和版本记录。ONES 的项目与 Wiki 能力可以承载这类文档与工作项，ONES Assistant 智能助手能够理解项目、工作项、迭代和 Wiki 页面等上下文，并可将结果保存为工作项或 Wiki 页面，便于把评审结论与后续整改任务关联起来。涉及测试质量类指标时，ONES TestCase 支持测试用例与需求、任务关联，并提供质量统计报表和缺陷分布统计，可作为任务质量数据的一个来源。
执行节奏：从启动到结论的评估流程
试点评估按阶段推进，每个节点有明确动作和完成标志。
- 启动前：标准定稿并公示。试点负责人组织业务与研发代表确认指标口径，数据提供方确认取数可行性，标准连同目标与范围说明一起公示到参与团队。完成标志是标准版本号确定、口径确认记录归档。
- 试点中：按周期采集数据。数据提供方按约定周期取数并留痕，记录异常事件，例如数据缺失、口径临时调整、使用中断。完成标志是每期数据表按时提交并附异常说明。
- 中期检查：核对数据完整性与偏差。评审组检查各指标数据是否齐全、与基线是否同口径，对偏差较大的指标要求说明原因。中期不急于下结论，重点是发现取数问题和执行偏差，必要时按预设规则调整后续安排。完成标志是中期检查纪要。
- 结束评审：按判定规则形成结论。评审组对照三档判定规则逐项核对，形成综合结论，对存在争议的指标记录判断依据。完成标志是评审纪要与结论文件。
- 结论输出：三类处理。结论限定为推广、调整后继续、停止三类，分别对应资源安排：推广进入扩大范围方案，调整后继续明确整改项和下一轮周期，停止则记录原因并释放资源。
流程节点表应写明每个节点的负责人、输入、输出和时间要求，与角色分工表相互对应。中期检查发现数据不可用时，标准中应预设处理方式，例如延长采集周期或缩小结论适用范围，避免到结束评审时才临时补救。
示例：一个AI编码辅助试点的评估标准片段
以下为演示情景，数值仅用于说明填写方式，实际取值需按团队历史数据和试点假设确定。
试点问题与范围：在两个后端小组试点AI编码辅助，为期六周，覆盖接口开发和单元测试编写两类任务，回答“是否在研发团队扩大使用范围”。评估对象为使用方式与产出效果，不包含模型能力评测。
| 指标 | 定义与公式 | 数据来源 | 基线 | 目标值 | 判定规则 |
|---|---|---|---|---|---|
| 周活跃使用率 | 当周至少使用一次的人数 ÷ 试点参与人数 | 工具使用记录，按周导出 | 试点前无使用，记为0 | ≥70% | 达标≥70%，部分达标50%–69%，未达标<50% |
| 生成内容采纳率 | 直接使用或修改后使用的生成内容数 ÷ 生成内容总数 | 使用记录加抽样标注，每周抽样50条 | 试点前四周同类任务人工编写为参照 | ≥60% | 达标≥60%，部分达标45%–59%，未达标<45% |
| 任务一次通过率 | 首次评审通过的任务数 ÷ 提交评审任务数 | 项目工作项评审记录 | 试点前六周同口径数据 | 不低于基线 | 达标≥基线，部分达标低于基线3个百分点以内，未达标低于基线3个百分点以上 |
| 人工复核覆盖率 | 经过人工复核的AI产出数 ÷ AI产出总数 | 复核记录表 | 不适用，按制度要求设定 | 100% | 达标100%，出现未复核即判定未达标 |
数据采集方式为：使用记录每周五导出，采纳情况由小组负责人按抽样表标注，评审记录从项目工作项中按迭代汇总，复核记录由复核人当日登记。结论形成方式为：四项指标中人工复核覆盖率为一票否决项，其余三项按达标项数量综合判断，两项及以上达标且无否决项，结论为推广；一项达标或存在可整改问题，结论为调整后继续；出现否决项或两项以上未达标，结论为停止。该示例展示了标准如何从问题走到判定，实际填写时应替换为团队自己的基线和阈值。
完成检查：标准发布前的核对清单
标准定稿后，按以下清单逐项核对，全部通过再发布。
- 每个指标都有名称、定义、计算公式、数据来源和统计周期，抽查两项能按公式独立重算。
- 基线数据与试点数据同口径，取数区间和查询条件已留档，可由他人复现。
- 每个指标都有基线值、目标值和三档判定规则，阈值写到具体数值或明确比较关系。
- 一票否决项已列明，综合判定方式写清，不依赖评审时的临时解释。
- 角色分工表覆盖标准制定、取数留痕、评审判定三类职责，每项交付物有负责人和时间点。
- 流程节点表与角色分工表一致，中期检查和结束评审的输入输出明确。
- 口径变更的记录方式与审批人已写明，变更对数据可比性的影响有处理规则。
- 不纳入的指标范围已声明，避免评审时被无关数据干扰。
- 标准版本号和公示范围已确定，参与团队已知悉获取位置。
核对中发现缺项，回到对应章节补齐后再发布。标准发布后，试点期间只按预设规则调整口径，调整记录随评审材料一并归档，确保结论可追溯。
常见问题
试点启动后才发现某个指标取不到数，标准还能调整吗？
可以调整，但要按标准中预设的变更规则走。建议在标准里提前写明：口径变更需记录变更原因、影响范围和生效时间，并经试点负责人审批。若某指标确实无法取数，可缩小结论适用范围或延长采集周期，同时在评审材料中说明该指标缺失对结论强度的影响。关键是变更留痕，让前后数据仍可对照解释。
团队规模较小、任务类型又杂，是否一定要设置对照组？
不强制。前后对比实施成本低，适合任务类型相对稳定、外部干扰较少的场景；对照组更严谨，但需要划分可比的任务和人员，管理成本更高。小团队任务类型杂时，可以退一步：固定几类高频任务作为观察样本，用试点前同口径数据做前后对比，并在标准中写明这一选择的局限，评审时据此控制结论的适用范围。
采纳率这类指标靠人工标注，如何保证不同人标得一致？
先统一判定口径，再抽样校准。标准中把“采纳”拆成直接使用、修改后使用、未使用三档，并给出每档的判断示例；标注前由业务与研发代表共同确认口径，标注初期安排双人交叉标注少量样本，比对分歧并补充规则。标注记录随周期数据一并归档，评审时若对某条数据有疑问，可回溯原始记录核对。
试点结论是“调整后继续”，下一轮评估标准要重新制定吗？
不必整套重写，但需要明确整改项与下一轮周期。沿用原标准的指标框架和判定规则，把中期或结束评审中发现的取数问题、口径歧义、执行偏差逐项修正，并将整改目标写入下一轮的目标值。若调整涉及使用方式变化，例如限定适用任务或增加复核环节，应同步更新试点范围说明，保证新一轮数据与上一轮可比。
评估标准里的数据记录和评审结论，放在哪里便于后续追溯？
建议集中存放并保留版本。试点的问题说明、指标字段表、周期数据和评审纪要放在同一项目空间内，按周期归档，口径变更单独记录。ONES 的项目与 Wiki 能力可以承载这类文档与工作项，ONES Assistant 智能助手能够理解项目、工作项、迭代和 Wiki 页面等上下文，并可将结果保存为工作项或 Wiki 页面，便于把评审结论与后续整改任务关联起来。涉及测试质量类指标时，ONES TestCase 支持测试用例与需求、任务关联，并提供质量统计报表和缺陷分布统计，可作为任务质量数据的一个来源。
