AI试点评估最容易出错的地方，是把“用了AI之后指标变好”直接当成“AI带来了改善”。要判断效果差异是否来自AI本身，需要先明确验证哪个使用动作、看哪个结果指标，再按相近任务和相近人员能力划分试点组与对照组，让两组除AI使用外尽量保持一致，最后用基线期与试点期的组间差异、协变量控制和剂量关系来归因。本文按设计、分组、执行控制、归因分析、角色分工、示例和验收的顺序，给出可直接套用的做法。
要点总览（TL;DR）
- 先把“AI效果”收敛为具体使用动作和1–2个结果指标，再按任务类型、人员经验、项目复杂度分层随机划分试点组与对照组，避免自愿使用者集中进试点组。
- 执行期让两组只差“是否使用AI”一个变量，同期登记其他工具上线、流程变更和组织调整，并按统一口径采集AI使用强度。
- 归因按四步推进：基线期与试点期的组间变化量对比、控制协变量后的差异、使用强度与改善的剂量关系、替代解释排除；统计显著与业务显著分别判断。
- 只有当差异在统计和业务口径上都稳定、且随使用强度出现梯度时，才可初步判断差异来自AI本身，结论表述应区分相关与因果。
- 评估设计表、变更台账和结论文档需要集中留痕，ONES 的项目、工作项与 Wiki 能力可承载分组记录与结论沉淀。
先定评估对象：验证哪个AI动作、看哪个结果
评估设计的第一步是把“AI效果好不好”收敛成一个可对照的问题：哪类人在什么任务上使用哪个AI动作，预期改善哪个结果。动作描述要具体到使用环节，例如“需求评审前用AI生成需求初稿”“开发过程中使用代码补全”“根据需求描述生成测试用例初稿”“用AI辅助生成评审意见”。动作越具体，试点组和对照组的边界越清楚，后续归因也越容易解释。
指标要区分结果指标与过程指标。结果指标直接反映业务结果，如需求返工率、缺陷逃逸率、测试用例评审通过率、代码评审一次通过率、任务周期时间；过程指标反映使用行为，如AI调用次数、活跃使用天数、生成内容被采纳的比例。过程指标用于解释结果变化，不能替代结果指标。研发效能平台中的交付效率、交付质量等指标可以作为参照口径，但本文不展开一般效能指标体系建设。
观察周期要覆盖基线期和试点期两段。基线期用于记录两组在未使用AI时的自然差异，长度按任务波动大小确定：任务周期短、波动小的场景可以短一些，跨迭代、跨版本的任务需要覆盖完整交付周期。基线期太短，组间差异容易被个别任务带偏。
把上述内容填入评估设计表，作为后续分组和采集的依据。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| AI使用动作 | 具体到环节和产出物 | 需求评审前用AI生成需求初稿 |
| 结果指标 | 1–2个主指标，避免堆指标 | 需求评审返工次数 |
| 过程指标 | 用于解释使用行为 | AI初稿采纳率、活跃使用天数 |
| 口径 | 统计范围、时间窗、计算方式 | 按需求条目统计，评审后两周内 |
| 数据来源 | 系统记录或人工登记 | 工作项流转记录、评审记录 |
| 负责人 | 对该指标数据质量负责的人 | 数据负责人 |
完成标志是：每个指标都能说清分子分母、统计时间窗和数据出处，且主指标不超过两个。指标过多会让归因分析失去焦点。
试点组与对照组怎么划分才可比
分组的目标是让两组在AI使用之外尽量相似。可行做法是先按任务类型、人员经验、项目复杂度做分层，再在层内随机分配或匹配分配。例如按“初级/资深开发”和“简单/复杂需求”交叉分层，每层内一半进入试点组、一半进入对照组。分层变量应选择与结果指标关系最强的因素，通常包括人员经验、任务难度和项目阶段。
同团队内分组与跨团队分组各有取舍。同团队内分组能共享流程、工具和沟通环境，可比性较好，但存在组间互相学习和使用外溢的风险；跨团队分组隔离更彻底，但团队间文化、流程差异会混入结果。条件允许时优先同团队内分层随机，并在执行期记录外溢情况；跨团队分组适合团队数量足够、能匹配相似团队的场景。
样本量和观察时长按指标波动估算，不写死数字。做法是先看基线期该指标的自然波动幅度，再估算需要多少任务或多少个迭代才能让组间差异不被随机波动淹没。波动大的指标需要更长观察期或更多样本；如果试点期内样本量明显不足，应延长观察而不是提前下结论。
要避免把自愿使用者全部放进试点组。愿意主动使用AI的人往往学习意愿更强、经验更匹配，这会高估AI效果。处理方式包括：在分层内随机分配使用资格，或对自愿者与匹配的对照组做倾向匹配，并在分析时记录选择偏差的存在。
分组结果和例外情况要留痕：谁在哪个组、依据什么分层变量分配、中途是否有换组、哪些任务不符合分层条件。可比性检查清单可包括：两组基线指标是否接近、分层变量分布是否均衡、是否存在单组人员集中、观察期是否覆盖完整任务周期。
执行期的控制：让两组只差一个AI变量
试点运行期间，最大的干扰来自同期发生的其他变化。其他工具上线、流程调整、组织架构变动、版本发布节奏变化，都会影响结果指标。执行期应建立变更登记台账，记录变更内容、生效时间、影响范围，并在分析时判断是否与试点期重叠。
AI使用强度需要单独采集，常用口径包括调用次数、活跃使用天数、使用场景覆盖比例，以及生成内容被采纳的比例。使用强度既是过程指标，也是后续剂量关系检验的输入。采集方式可以依托工具自身的调用记录，辅以团队登记，明确采集频率和责任人。
对照组是否可以获得AI，要在试点开始前界定清楚。若对照组也能接触同一AI能力，试点组与对照组的差异会被稀释；若完全隔离，需说明隔离办法，如权限控制、工具入口限制，并记录对照组是否有替代性AI工具使用。隔离不彻底时，应在结论中说明可能低估效果。
中途退出、换人、任务变更要有处理规则。人员调离原组时，其未完成任务如何处理、是否纳入统计，应事先约定；任务难度发生明显变化时，应标记并作为协变量处理。数据采集节奏建议与迭代节奏对齐，每次迭代结束由数据负责人核对一次记录完整性。
这些记录可以放在统一的工作项和文档中留痕。ONES 的项目与工作项管理可以承载试点分组、任务归属和变更登记，ONES Wiki 可用于沉淀评估设计表和结论文档；ONES Assistant 智能助手能够理解项目、工作项和 Wiki 页面等上下文，并可将结果保存为工作项或 Wiki 页面，便于把评估过程中的记录与结论集中管理。是否使用这些能力取决于团队现有的工具环境。
判断差异是否来自AI：归因的四步分析
归因分析从描述统计开始，逐步排除替代解释。四步做完之前，结论只能表述为相关，不能表述为因果。
第一步，基线期与试点期的组间对比。分别计算试点组和对照组在基线期、试点期的指标变化，再比较两组变化量之差，即双重差分思路。如果试点组改善幅度明显大于对照组，说明存在值得进一步分析的差异；如果两组变化方向一致、幅度接近，AI的作用缺乏证据。
第二步，控制协变量后的差异。任务难度、人员经验、项目复杂度、需求类型等会影响结果。用分层比较或回归模型控制这些变量后，再看试点组与对照组的差异是否仍然存在。控制后差异大幅缩小，说明部分差异来自任务或人员构成，而非AI。
第三步，使用强度与效果改善的剂量关系。在同一试点组内，比较高频使用、低频使用和未实际使用的成员或任务，观察效果改善是否随使用强度上升而增加。若使用强度与改善之间没有梯度，或高频使用者与低频使用者结果相近，需要怀疑改善来自其他因素。
第四步，排除替代解释。逐项检查同期变更、学习效应、指标口径漂移、幸存者偏差等。学习效应表现为对照组在后期也自然变好；口径漂移表现为统计规则在试点期发生变化；幸存者偏差表现为表现差的成员或任务中途退出。每一项都要有记录或说明。
| 步骤 | 分析动作 | 判定要点 |
|---|---|---|
| 组间对比 | 计算两组基线期到试点期的变化量之差 | 试点组改善是否明显大于对照组 |
| 协变量控制 | 分层或回归控制任务难度、人员经验 | 控制后差异是否仍然存在 |
| 剂量关系 | 比较不同使用强度下的改善幅度 | 改善是否随使用强度呈梯度 |
| 替代解释 | 核查同期变更、学习效应、口径变化 | 能否逐项排除或说明影响方向 |
统计显著与业务显著要分别判断。统计显著说明差异不太可能由随机波动造成；业务显著说明改善幅度对团队有实际意义。样本量较小时，统计不显著不代表没有效果，应结合效应大小和观察期长度谨慎表述。只有差异在统计和业务口径上都稳定，且能随使用强度变化出现梯度时，才可初步判断差异来自AI本身。
角色分工与各阶段交付物
评估需要明确谁设计、谁采集、谁分析、谁决策，避免数据口径在交接中失真。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 评估发起人 | 确定评估目标、主指标和推广决策问题 | 评估设计表、评估计划 |
| 数据负责人 | 定义指标口径、组织数据采集、核对完整性 | 指标口径说明、数据采集记录 |
| 试点团队负责人 | 执行分组、登记变更、反馈使用情况 | 分组名单、变更登记台账 |
| 分析人员 | 完成四步归因分析、撰写结论 | 归因分析报告、结论模板 |
| 决策人 | 确认结论、决定推广或终止 | 决策记录 |
评审节点建议设在三处：评估设计完成后评审指标与分组方案；基线期结束时确认两组可比性；归因分析完成后评审结论表述。数据权限与隐私处理由数据负责人牵头，明确哪些人可访问原始记录、分析结果以什么粒度呈现。结论由分析人员起草，经评估发起人和试点团队负责人确认后向决策人汇报。
一个完整示例：代码补全试点如何对照
以下为演示情景，用于说明流程，不代表真实客户案例。
某研发团队计划评估代码补全工具对代码评审一次通过率的影响。主指标为代码评审一次通过率，过程指标为补全采纳率和活跃使用天数，观察周期覆盖两个迭代的基线期和两个迭代的试点期。
分组时按开发经验和模块复杂度分层，在每个层内随机分配一半开发人员进入试点组。两组使用相同的代码仓库、评审流程和发布节奏。基线期两组均不使用补全工具，记录各自的一次通过率。
试点期试点组启用补全工具，对照组保持原状。执行期登记了一次代码规范更新和一名成员调岗，采集了试点组每人的补全采纳次数和活跃天数。对照组的工具入口保持关闭，并确认没有使用同类工具。
分析时先比较两组从基线期到试点期的通过率变化量，试点组提升幅度大于对照组；控制模块复杂度和开发经验后差异仍然存在；试点组内采纳率高的成员改善更明显，呈现剂量关系；同期代码规范更新对两组影响相同，学习效应在对照组未观察到明显上升。结论表述为：在本试点条件下，代码补全使用与评审一次通过率改善相关，差异在控制任务和人员因素后仍然稳定，初步判断改善与AI使用有关，建议扩大试点验证。
该示例的适用边界是：单一团队、两个迭代、一个主指标。跨团队推广前需要重复评估，并关注不同模块类型下的效果差异。
完成检查：评估结论能不能站得住
在把结论用于推广决策前，逐项核对以下内容。
- 分组是否按任务类型、人员经验等关键变量分层，两组基线指标是否接近，样本量和观察期是否足以覆盖指标波动。
- 是否避免了自愿者全部进入试点组，选择偏差是否已记录并在分析中处理。
- 执行期的其他工具上线、流程变更、组织调整是否登记，AI使用强度是否按统一口径采集。
- 对照组是否真正隔离，若未完全隔离，结论是否说明了可能的影响方向。
- 归因四步是否完成：组间变化量对比、协变量控制、剂量关系检验、替代解释排除。
- 结论表述是否区分了相关与因果，统计显著和业务显著是否分别说明。
- 推广、扩大试点或终止的判断条件是否事先约定，并由决策人确认。
检查通过后，结论可以作为推广决策的输入；若任一项缺失，应补充数据或延长观察，避免用一次试点结果直接推广到全部团队。
常见问题
试点期内样本量不够，能不能先出结论再补数据？
不建议。样本量不足时，组间差异很容易被个别任务或个别人员的波动带偏，此时得出的“改善”或“无改善”都不可靠。更稳妥的做法是延长观察期，覆盖更多任务或迭代，再重新计算组间变化量。如果业务上必须提前汇报，可以把结论表述为阶段性观察，说明样本量、观察期和置信程度，并明确后续补充数据的计划，避免把阶段性结果直接当作推广依据。
对照组完全接触不到AI，会不会影响团队公平和配合意愿？
隔离对照组是保证可比性的常见做法，但需要在启动前把规则讲清楚：分组依据是分层随机而非绩效评价，试点期结束后对照组会按计划获得同等使用机会，评估结论用于决定是否全面推广。执行中可以让对照组参与数据记录和结果反馈，减少“被排除在外”的感受。如果完全隔离难以执行，也可以接受部分接触，但要在结论中说明效果可能被低估，并记录对照组实际使用替代工具的情况。
试点组改善明显，但使用强度高低与改善没有明显关系，怎么解释？
这种情况说明改善可能并非由AI使用直接带来，需要回到归因的第四步排查替代解释。常见原因包括：试点组成员本身学习意愿更强，同期有流程或工具变更只影响试点组，指标口径在试点期发生变化，或者AI的作用是间接的（例如改变了任务分配方式而非直接提升产出）。可以进一步拆分使用场景，看改善集中在哪些任务类型上，同时核对变更登记台账和基线期数据，确认差异是否在试点开始前就已存在。
评估结论要写到什么程度，才能支撑推广决策？
结论至少要说清四件事：评估的动作和指标是什么、试点组与对照组如何划分、归因四步各自的结果、差异在多大范围内可以成立。表述上区分“相关”和“因果”，说明样本量、观察期和适用边界，例如只在单一团队、特定任务类型下成立。推广决策还应事先约定判断条件，例如改善幅度达到多少、在多少个团队重复验证后进入全面推广。结论由分析人员起草，经发起人和试点团队负责人确认后提交决策人。
评估过程中的分组记录和使用数据放在哪里比较合适？
关键是让分组名单、变更登记、使用强度记录和结论文档有统一出处，避免散落在多个表格里导致口径不一致。可以把试点分组和任务归属放在项目管理工具的工作项中，把评估设计表、变更台账和归因报告放在文档协作空间里，并明确数据负责人的核对节奏。ONES 的项目与工作项管理可以承载分组与任务归属，ONES Wiki 可用于沉淀评估设计表和结论文档，ONES Assistant 智能助手能够理解项目、工作项和 Wiki 页面等上下文，并可将结果保存为工作项或 Wiki 页面，便于集中管理评估记录与结论。具体是否采用取决于团队现有工具环境。
