AI研发效能分析的依据由四层构成：可信的原始数据、统一的口径定义、可追溯的证据链，以及人工复核与解释机制。四层缺一不可，否则结论容易停留在推测层面。本文按数据采集、口径编写、证据追溯、角色交接的顺序给出可执行做法，适用于希望用AI辅助分析研发过程、但仍需团队确认后再做改进决策的场景。
要点总览（TL;DR）
- AI研发效能分析的依据分四层：可信的原始数据、统一的口径定义、可追溯的证据链、人工复核与解释机制，缺一层结论就只能当线索。
- 数据依据要覆盖需求、任务、缺陷、代码提交、评审、构建、测试与发布记录，每类记录保留唯一标识、状态变更时间与关联关系字段。
- 口径文档至少写明指标名称、业务含义、计算公式、统计范围、排除规则、统计周期与版本号，变更需留痕并注明生效时间。
- 证据链以工作项、提交、构建与测试记录为锚点，抽样复核记录样本量、方法与复核人，结论与原始记录一一对应。
- 数据提供、口径维护、分析执行、结果复核四类角色各有交付物；复核与执行不宜由同一人独自完成，出现阻断项时结论只能作为线索。
先明确分析要回答的问题与依据分层
开展AI研发效能分析前，先把问题限定在可验证的范围内。适合交给AI辅助分析的问题包括：某个迭代的交付周期为何延长、缺陷集中在哪些环节、评审等待时间是否异常、资源投入与计划是否匹配。这类问题有过程记录支撑，结论可以被追溯和复核。不适合直接交给AI下结论的问题包括：个体绩效评定、跨团队能力排名、缺少记录的主观评价。这些判断涉及管理决策与人事规则，需要另行设计流程。
四层依据之间是递进关系。数据层解决“有没有记录”，口径层解决“怎么算”，证据层解决“结论能否回到原始记录”，复核层解决“谁来确认结论可用”。任何一层缺失，分析结果都只能作为线索，不能作为改进决策的依据。
| 层级 | 最小可用输入 | 产出物 | 负责人 |
|---|---|---|---|
| 数据层 | 需求、任务、缺陷、代码提交、评审、构建、测试、发布记录 | 数据来源与字段清单 | 数据提供方（项目管理或研发管理岗） |
| 口径层 | 指标名称、计算公式、统计范围、排除规则、统计周期 | 版本化的指标口径文档 | 口径维护方（效能或质量岗） |
| 证据层 | 结论与工作项、提交、构建记录的关联关系 | 结论—证据追溯清单 | 分析执行方 |
| 复核层 | 分析结果、证据清单、复核人意见 | 复核记录与改进建议 | 结果复核方（团队负责人或指定评审人） |
四层的最小输入可以先从现有工具中已有记录起步，不必等数据平台建设完成。关键是每层都有明确产出物和负责人，后续章节分别展开。
数据依据：需要采集哪些研发过程记录
效能分析的数据来源应覆盖研发过程的主要环节。需求记录提供范围与优先级，任务记录提供执行粒度，缺陷记录反映质量分布，代码提交与评审记录反映开发与协作节奏，构建、测试与发布记录反映交付链路。每类记录至少保留唯一标识、所属项目或团队、创建时间、状态变更时间、负责人和关联关系字段。
| 记录类型 | 必备字段 | 时间戳要求 | 常见采集方式 |
|---|---|---|---|
| 需求 | 需求ID、标题、优先级、状态、关联迭代 | 创建、进入开发、完成时间 | 项目管理工作项导出或接口同步 |
| 任务 | 任务ID、所属需求、负责人、工时、状态 | 创建、开始、完成时间 | 工作项记录 |
| 缺陷 | 缺陷ID、严重级别、发现阶段、修复版本 | 发现、修复、验证关闭时间 | 缺陷管理模块 |
| 代码提交 | 提交ID、分支、作者、关联工作项 | 提交时间 | 代码仓库同步 |
| 评审 | 评审ID、评审人、结论、关联提交 | 发起、完成时间 | 代码评审记录 |
| 构建与测试 | 构建ID、结果、用例数、通过率 | 执行时间 | 流水线与测试管理记录 |
| 发布 | 发布单ID、版本、环境、结果 | 开始、完成时间 | 发布管理记录 |
数据缺失时，先记录缺失范围再决定处理方式。某类记录整体缺失，应在分析报告中标注该指标不可计算，不用估算值替代。口径不一致时，例如两个团队对“完成”的定义不同，应先回到口径文档统一，再合并统计；无法统一时按团队分别呈现，并在结论中说明不可直接比较。
当工作项、文档和测试记录已在同一平台中流转时，采集会简单很多。以ONES为例，ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项、迭代和Wiki页面等工作上下文，围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与根因判断。这类能力的前提是相关记录已在平台中沉淀，分析前仍需按上表核对字段与时间戳是否齐全。
口径依据：指标定义与统计规则怎么写
口径文档的作用是让不同周期、不同团队的数据可以放在一起比较。每个指标至少写明七项内容：指标名称、业务含义、计算公式、统计范围、排除规则、统计周期、版本号与生效时间。缺少任何一项，后续换人计算或换周期对比时就容易产生分歧。
编写时先写业务含义，再写公式。例如“需求交付周期”的业务含义是从需求进入开发到发布上线所经历的时间，公式为发布时间减去进入开发时间，统计范围限定为当期已发布的需求，排除规则写明被取消、合并或拆分后重新立项的需求如何处理。统计周期要明确按自然周、迭代还是发布批次统计，时间窗口的起止点以哪个时间戳为准。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 指标名称 | 唯一且稳定，避免同义多名称 | 需求交付周期 |
| 业务含义 | 一句话说明衡量什么 | 需求从进入开发到发布上线的时长 |
| 计算公式 | 写明字段与运算关系 | 发布时间 − 进入开发时间 |
| 统计范围 | 项目、团队、需求类型 | 某产品线当期已发布需求 |
| 排除规则 | 列出不计入的情形 | 取消需求、测试环境发布不计入 |
| 统计周期 | 按周、迭代或发布批次 | 按双周迭代统计 |
| 版本与生效时间 | 每次修改留痕 | v1.2，2025年某迭代起生效 |
口径变更要有记录。建议在文档中保留变更日志，写明修改人、修改原因、生效时间和受影响的指标，历史数据按旧口径计算的部分在报告中注明。这样跨周期对比时，读者能判断差异来自实际变化还是口径调整。
证据依据：让每个结论可回溯到工作项
AI辅助分析给出的结论需要能回到具体记录。做法是在分析输出中为每条结论标注关联的工作项ID、代码提交ID、构建或测试记录ID，以及对应的时间点。例如“某迭代测试阶段耗时增加”，应能列出该迭代内进入测试的工作项清单、各工作项的测试开始与结束时间，以及对应的构建记录。
抽样复核用于验证结论的可靠性。样本量按结论涉及的工作项数量确定：涉及数十条记录时可抽取十到二十条逐条核对，涉及少量记录时全部核对。抽样方法写明随机或按状态分层，复核人记录核对结果与偏差原因。发现偏差时，先修正数据或口径，再重新生成结论。
证据留存期限与访问权限按团队管理要求设定。建议至少覆盖一个完整的规划周期，便于后续复盘时调取。访问权限沿用项目原有权限体系，分析报告与原始记录对同一批人可见，避免结论扩散到无权查看原始数据的范围。ONES的AI能力基于ONES权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；在指定Wiki页面组内提问时还可附上引用来源，便于把结论与依据文档对应起来。
角色分工与各环节交付物
四类角色分别对应四层依据。数据提供方负责保证记录完整、字段齐全；口径维护方负责指标定义与版本管理；分析执行方负责生成结论并附证据；结果复核方负责确认结论可用于改进决策。组织规模较小时可以合并角色，但复核与执行不宜由同一人独自完成。
| 角色 | 职责边界 | 交接时点 | 交付物 |
|---|---|---|---|
| 数据提供方 | 维护记录完整性，标注缺失范围 | 分析启动前 | 数据来源与字段清单 |
| 口径维护方 | 编写与更新指标口径，处理口径争议 | 分析启动前及口径变更时 | 版本化口径文档 |
| 分析执行方 | 按口径计算，生成结论与证据清单 | 分析完成后 | 分析报告与追溯清单 |
| 结果复核方 | 核对证据，确认结论适用范围 | 报告提交后、改进决策前 | 复核记录与改进建议 |
出现争议时按顺序裁决：先查证据能否对应到原始记录，再查口径文档是否有明确规定，最后由结果复核方组织数据提供方与口径维护方共同确认。裁决结论记入口径文档或复核记录，作为下次分析的依据。
示例：一个迭代周期的分析依据如何组织
以下为演示情景，用于说明四层依据如何组合运行，不代表真实项目数据。
某团队按双周迭代开发，迭代结束后希望分析交付周期延长的原因。第一步，数据提供方在迭代结束当天导出该迭代的需求、任务、缺陷、提交、评审、构建与发布记录，核对时间戳字段，标注两条缺少测试开始时间的记录。第二步，口径维护方确认本期使用v1.2口径文档，需求交付周期按发布时间减进入开发时间计算，排除取消需求。第三步，分析执行方按口径计算，发现测试阶段耗时占比上升，输出结论并附上涉及的工作项清单、构建记录和测试记录。第四步，结果复核方抽取其中十五条工作项逐条核对，确认两条缺失记录不影响整体判断，在复核记录中注明后，将结论提交团队讨论改进措施。
这个流程可以迁移到其他团队：先固定数据导出时点，再确认口径版本，然后生成带证据的结论，最后经复核再使用。关键节点的输入与输出与前述各章一致，差异主要在统计周期和排除规则的具体取值。
完成检查：依据是否足以支撑结论
在把分析结论用于改进决策前，逐项核对以下检查清单。全部通过可视为依据充分；出现阻断项时应先补齐再使用结论。
- 数据完整性：分析涉及的每类记录均有来源说明，缺失记录已标注范围，未用估算值替代。
- 字段与时间戳：必备字段齐全，关键状态变更时间可查，关联关系（工作项与提交、构建）可对应。
- 口径一致性：使用统一版本的口径文档，跨团队比较前已确认定义一致，口径变更已留痕并注明生效时间。
- 证据可追溯：每条结论均能列出关联工作项与时间点，抽样复核记录包含样本量、方法与复核人。
- 复核完成：结果复核方已确认结论适用范围，争议已按裁决路径处理并记录。
阻断项包括：关键指标缺少口径定义、结论无法对应到原始记录、复核与执行由同一人独自完成且无第二人确认。出现任一阻断项，结论只能作为线索使用。复核记录与口径文档应随迭代持续维护，下一周期分析前先确认版本与数据范围，避免沿用过期口径。
常见问题
团队规模较小、没有专职效能岗，四层依据怎么落地？
可以合并角色，但保留交付物。数据提供由项目管理或研发管理岗兼任，口径维护交给最熟悉指标计算的人，分析执行与结果复核由不同成员承担。最小做法是先选三到五个核心指标，写清口径并固定版本，再按迭代导出记录、生成带证据的结论，最后由团队负责人确认。角色合并后，复核环节仍要留下书面记录，避免结论只停留在口头讨论。
历史数据字段不全，还能开展AI辅助分析吗？
可以，但要先划定可用范围。对整体缺失的记录类型，在报告中标注该指标不可计算，不用估算值替代；对部分缺失的记录，标注缺失条数与占比，并判断是否影响结论方向。口径不一致时，先回到口径文档统一，无法统一就按团队分别呈现并注明不可直接比较。分析结论的适用范围应随数据完整度一起说明。
AI给出的分析结论，什么情况下可以直接用于改进决策？
需要同时满足几个条件：关键指标有明确口径定义，结论能对应到具体工作项与时间点，抽样复核已完成并记录样本量与复核人，复核与执行由不同人承担。出现关键指标缺口径、结论无法回溯、复核缺失等阻断项时，结论只能作为线索，先补齐依据再使用。涉及人员评价的判断，应另行设计流程，不直接采用分析输出。
口径调整后，跨周期的数据还能直接对比吗？
不能直接对比，需要先做说明。口径文档保留变更日志，写明修改人、原因、生效时间与受影响指标；报告中注明历史数据按旧口径计算的部分。读者据此判断差异来自实际变化还是口径调整。若确需连续对比，可按新口径重算历史数据，并在报告中标注重算范围。
用ONES承载研发过程记录时，分析前要核对什么？
ONES Assistant可连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项、迭代和Wiki页面等工作上下文，围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与根因判断。使用前仍需核对：分析涉及的记录类型是否齐全，必备字段与状态变更时间是否完整，工作项与提交、构建的关联关系是否可对应。ONES的AI能力基于ONES权限体系运行，输出过程可追踪、结果可审计；在指定Wiki页面组内提问时可附引用来源，便于把结论与依据文档对应起来。
