AI应用评估报告需要把“用了多少、产出如何、风险是否可控、下一步做什么”写在同一张表里，避免只凭印象判断效果。下面这份模板按评估对象、使用场景、投入与使用数据、效果指标、风险与合规、结论与下一步六个区块组织，附字段口径、必填规则、一份完整填写示例和维护方法。评估范围聚焦AI应用在研发场景中的实际使用与产出，一般研发效能指标和技术模型基准测试不在本篇展开。
要点总览（TL;DR）
- 模板按报告基本信息、评估对象、投入与使用数据、效果指标、风险与合规、结论与下一步六个区块组织，可直接复制到文档或表格工具中填写。
- 字段说明给出每个字段的含义、填写口径和取数来源；使用数据需写明统计周期与去重规则，效果指标需给出对比基准，无对照数据时标注为描述性数据。
- 必填字段覆盖评估成立与结论可信所需的信息，配套投入、质量指标、返工情况等按试点、推广、复盘阶段取舍；留空统一标注为未采集、样本不足或不适用。
- 填写示例演示了从效率指标与采纳率推导结论、从问题记录推导待改进项的完整路径，示例为演示情景，可对照修改。
- 模板可按团队规模与场景数量裁剪，口径变更时升版本并留痕，按试点月度、推广季度的节奏维护，定期回看字段有效性。
可复制空白模板：AI应用评估报告表
下表可直接复制到文档或表格工具中。字段名在后续字段说明、填写示例中保持一致，复制后按行填写即可。每个区块的字段顺序固定，便于不同团队横向对比。
| 区块 | 字段名 | 填写内容 |
|---|---|---|
| 一、报告基本信息 | 报告名称 | |
| 评估周期 | ||
| 评估人 | ||
| 版本 | ||
| 二、评估对象 | AI应用名称 | |
| 使用场景 | ||
| 使用团队/角色 | ||
| 上线时间 | ||
| 三、投入与使用数据 | 使用人数 | |
| 使用频次 | ||
| 调用量或使用时长 | ||
| 配套投入 | ||
| 四、效果指标 | 效率指标及口径 | |
| 质量指标及口径 | ||
| 采纳率及口径 | ||
| 返工情况及口径 | ||
| 五、风险与合规 | 数据范围 | |
| 输出审核方式 | ||
| 问题记录 | ||
| 六、结论与下一步 | 结论 | |
| 待改进项 | ||
| 责任人 | ||
| 计划时间 |
六个区块对应一条完整链路：先说明评估谁、在什么场景用，再用使用数据说明规模，用效果指标说明产出，用风险与合规说明边界，最后落到结论和行动。填写时保持区块顺序，评审人可以从上往下读完一份报告。
字段说明：每个字段填什么、按什么口径填
同一字段在不同团队填出不同含义，是评估报告最常见的失效原因。下表逐字段给出含义、填写口径和取数来源，填写前先约定口径，再开始取数。
| 字段名 | 含义 | 填写口径 | 取数来源 | 示例值 |
|---|---|---|---|---|
| 报告名称 | 本次评估的标识 | 应用名＋场景＋周期，便于检索 | 评估人拟定 | 代码助手-单元测试生成-2025年第二季度评估 |
| 评估周期 | 数据覆盖的时间范围 | 写明起止日期，与使用数据统计周期一致 | 评估计划 | 2025-04-01 至 2025-06-30 |
| 评估人 | 报告负责人 | 写姓名与角色，多人时注明主责 | 团队分工 | 张明（研发效能负责人） |
| 版本 | 报告修订版本 | 主版本.次版本，口径变更时升主版本 | 文档版本记录 | v1.2 |
| AI应用名称 | 被评估的AI应用 | 使用团队内部统一名称，含接入方式 | 工具台账 | 代码助手（IDE插件接入） |
| 使用场景 | AI应用承担的具体任务 | 写到任务级，不写“提升研发效率”这类概括 | 试点方案 | 单元测试用例生成与补全 |
| 使用团队/角色 | 实际使用者范围 | 写团队名与角色，注明是否含外包或跨部门 | 组织架构与授权记录 | 支付服务组，后端开发12人 |
| 上线时间 | 正式对使用者开放的时间 | 试点与推广分开时，分别注明 | 发布记录 | 2025-03-15（试点） |
| 使用人数 | 周期内实际使用过的人数 | 按账号去重，至少使用一次计入 | 工具后台使用日志 | 10人 |
| 使用频次 | 使用密集程度 | 写明口径，如人均周活跃天数或周使用次数 | 使用日志 | 人均每周活跃3.8天 |
| 调用量或使用时长 | 使用规模 | 二选一并注明单位，跨周期对比时保持同一口径 | 工具后台统计 | 周期内调用4,200次 |
| 配套投入 | 为使用该应用投入的资源 | 写人力、采购、培训等可计量项，注明是否折算金额 | 采购与工时记录 | 接入开发5人日，培训2场 |
| 效率指标及口径 | 任务耗时或产出速度的变化 | 写明指标定义、统计样本和对比基准 | 工时记录、任务系统 | 单测编写平均耗时由42分钟降至28分钟 |
| 质量指标及口径 | 产出质量的变化 | 写明缺陷口径与统计范围 | 缺陷系统、评审记录 | 单测覆盖行数提升，漏测缺陷数由7个降至4个 |
| 采纳率及口径 | AI输出被实际采用的比例 | 写明“采纳”的判定标准，如未修改直接提交或小改后提交 | 工具后台、代码评审记录 | 生成用例采纳率61%（未修改或仅改断言） |
| 返工情况及口径 | 因AI输出导致的返工 | 写明返工定义与统计方式 | 任务系统、评审记录 | 因用例错误返工6次，占生成量1.4% |
| 数据范围 | AI应用可接触的数据 | 列出数据类型与敏感级别 | 接入配置、安全评审 | 仅代码仓库，不含生产数据与客户信息 |
| 输出审核方式 | AI输出的把关机制 | 写审核环节、审核人和抽检比例 | 流程规范 | 生成用例须经代码评审，评审人抽查全部新增用例 |
| 问题记录 | 周期内出现的问题 | 逐条记录问题、影响和处理结果 | 问题台账 | 2次生成用例引用不存在的工具类，已修正并反馈 |
| 结论 | 基于指标的整体判断 | 每条结论对应具体指标，不写泛泛评价 | 由前四区块推导 | 效率与采纳率达到推广条件，质量指标需继续观察 |
| 待改进项 | 需要处理的问题 | 写具体动作和预期结果 | 结论推导 | 补充项目内工具类上下文，降低无效引用 |
| 责任人 | 改进项负责人 | 一项一名责任人 | 团队分工 | 李华 |
| 计划时间 | 改进完成时间 | 写日期，跨季度时注明复盘节点 | 排期 | 2025-08-15 |
效果指标需要给出对比基准。常用做法有两种：与引入前的历史数据比较，或设置未使用该应用的对照组。两种方式都要在报告中写明样本量和统计周期。没有对照数据时，在指标后标注“仅描述性数据”，结论中相应降低判断强度，例如写“趋势向好，尚不足以支撑全面推广”。
使用数据的统计口径要一次写清：统计周期与评估周期一致；使用人数按账号去重；调用量以工具后台导出为准，手工估算的数据单独标注来源。口径写进报告，下一次评估沿用同一口径，数据才可比较。
必填与选填：哪些字段不能空、哪些按需补充
模板要在轻量和完整之间可调节。基本规则是：缺少后无法判断评估是否成立、结论是否可信的字段为必填；只影响分析深度的字段为选填。
| 类别 | 字段 | 缺失时的处理方式 |
|---|---|---|
| 必填 | 报告名称、评估周期、评估人、版本 | 补齐后再提交评审，不接受空缺 |
| 必填 | AI应用名称、使用场景、使用团队/角色、上线时间 | 场景写到任务级；上线时间不明时写首次可用的日期并注明 |
| 必填 | 使用人数、使用频次、调用量或使用时长 | 至少提供一项规模数据；后台无统计时写“无系统统计”并说明估算方法 |
| 必填 | 效率指标及口径、采纳率及口径 | 无法计算时写“本期未采集”，并在待改进项中安排采集 |
| 必填 | 数据范围、输出审核方式 | 涉及数据接入的应用必须填写，缺失时报告不予通过 |
| 必填 | 结论、待改进项、责任人、计划时间 | 结论至少对应一项指标；改进项须有责任人和时间 |
| 选填 | 配套投入 | 试点期可只写人力投入，推广期补充采购与培训成本 |
| 选填 | 质量指标及口径、返工情况及口径 | 小范围试点样本不足时标注“样本不足，暂不结论” |
| 选填 | 问题记录 | 无问题时写“本期无记录”，不留空白 |
不同评估阶段的字段取舍可以按下表执行：
| 评估阶段 | 建议保留字段 | 可暂缓字段 | 说明 |
|---|---|---|---|
| 试点 | 基本信息、评估对象、使用人数与频次、采纳率、数据范围、输出审核方式、结论与下一步 | 配套投入明细、返工情况 | 重点判断是否值得扩大范围，样本少时结论写“待验证” |
| 推广 | 全部必填字段＋配套投入、质量指标 | 无 | 投入产出需要可比较，质量指标开始纳入判断 |
| 复盘 | 全部字段，补充与上期数据的对比 | 无 | 重点看趋势和口径是否变化，结论对应多期数据 |
字段留空要显式标注，避免空白被误读为“无效果”。统一使用三种标注：“本期未采集”“样本不足，暂不结论”“不适用（说明原因）”。评审时先看标注，再判断结论是否成立。
填写示例：一份完整的AI应用评估报告
以下为演示情景，用于说明字段如何联动，不代表任何真实客户或真实评估结果。
示例背景：某支付服务组在2025年第二季度对代码助手的单元测试生成能力做试点评估，评估周期为2025-04-01至2025-06-30，使用团队为后端开发12人，实际使用10人。
| 区块 | 字段名 | 填写内容 |
|---|---|---|
| 一、报告基本信息 | 报告名称 | 代码助手-单元测试生成-2025年第二季度评估 |
| 评估周期 | 2025-04-01 至 2025-06-30 | |
| 评估人 | 张明（研发效能负责人） | |
| 版本 | v1.2 | |
| 二、评估对象 | AI应用名称 | 代码助手（IDE插件接入） |
| 使用场景 | 单元测试用例生成与补全 | |
| 使用团队/角色 | 支付服务组，后端开发12人 | |
| 上线时间 | 2025-03-15（试点） | |
| 三、投入与使用数据 | 使用人数 | 10人（按账号去重，周期内至少使用一次） |
| 使用频次 | 人均每周活跃3.8天 | |
| 调用量或使用时长 | 周期内调用4,200次 | |
| 配套投入 | 接入开发5人日，培训2场，无额外采购 | |
| 四、效果指标 | 效率指标及口径 | 单测编写平均耗时由42分钟降至28分钟，样本为周期内新增的180个测试任务，与第一季度同口径数据比较 |
| 质量指标及口径 | 漏测缺陷数由7个降至4个，统计范围为该组负责模块的线上缺陷，样本量较小 | |
| 采纳率及口径 | 生成用例采纳率61%，判定标准为未修改或仅修改断言后提交 | |
| 返工情况及口径 | 因用例错误返工6次，占生成量1.4%，返工定义为提交后需重写超过一半用例 | |
| 五、风险与合规 | 数据范围 | 仅代码仓库，不含生产数据与客户信息 |
| 输出审核方式 | 生成用例须经代码评审，评审人抽查全部新增用例 | |
| 问题记录 | 2次生成用例引用不存在的工具类，已修正并反馈；1次生成重复用例，已删除 | |
| 六、结论与下一步 | 结论 | 单测编写耗时下降33%，采纳率61%，达到扩大试点条件；质量指标样本不足，暂不结论 |
| 待改进项 | 补充项目内工具类上下文，降低无效引用；建立缺陷数据按月统计 | |
| 责任人 | 李华（工具接入）、王芳（质量数据） | |
| 计划时间 | 2025-08-15 |
示例中结论的推导路径是：效率指标下降33%且样本量180个，采纳率61%高于试点前约定的60%门槛，两项共同支撑“扩大试点”；质量指标只有4个与7个的对比，样本不足，因此写“暂不结论”而不是直接判定质量提升。待改进项分别对应问题记录中的无效引用和统计口径缺失，责任人与计划时间逐项落实。
核对一致性时，检查三点：示例中出现的字段名与空白模板完全一致；每个效果指标都写明了口径和对比基准；结论中的每个判断都能在指标区找到对应数据。
调整与维护：让模板适配团队并持续可用
模板需要按团队情况裁剪，并随评估周期维护版本，否则字段会越填越多、口径越走越散。以下操作清单可直接执行。
- 按团队规模裁剪：10人以下团队可合并“使用人数”与“使用频次”为一栏，保留规模数据即可；跨多个团队评估时，在评估对象区增加“团队清单”子表，每个团队一行使用数据。
- 按场景数量裁剪：一个AI应用覆盖多个场景时，每个场景单独出一份报告，或在一份报告内按场景拆分行，避免把不同场景的指标混算。
- 口径变更留痕：指标定义、统计周期或去重规则变化时，在版本号上升主版本，并在报告末尾增加“口径变更说明”，写清变更内容、原因和生效周期，旧数据不追溯改写。
- 设置评估节奏：试点期按月评估，推广期按季度评估，重大变更后追加一次专项评估。每次评估结束即确定下次复盘时间，写入结论区。
- 存放与权限：模板和已填报告存放在团队共用的文档空间中，模板设为只读、由评估负责人维护，已填报告按项目或团队分目录存放，评审人可评论、评估人可编辑。
- 定期回看有效性：每两个评估周期检查一次：哪些字段连续多期为空、哪些指标从未影响结论、哪些口径反复被追问。连续两期无用的选填字段可移入附录，被反复追问的口径应写进字段说明。
当评估报告需要在团队协作工具中承载时，可以把模板放在 ONES Wiki 的文档空间中统一维护，已填报告作为页面留存版本；报告中的待改进项可以转为 ONES 项目中的工作项，指定责任人和计划时间，让结论区的行动与项目执行保持关联。ONES Wiki 支持管理项目规范、操作说明、复盘记录等需要长期沉淀的内容，并可与项目、任务等研发管理场景结合使用。若团队使用 ONES Assistant，也可以基于项目与 Wiki 上下文整理评估所需的信息，并将结果保存为工作项或 Wiki 页面，减少在多个页面之间切换和重复录入。
模板的价值在于让不同周期的评估可比较。字段可以裁剪，口径必须写清；结论可以保守，依据必须对应指标。按上述清单维护，一份模板可以在多个团队、多个评估周期中持续使用。
常见问题
评估周期内使用人数很少，报告还能作为推广依据吗？
可以使用，但结论强度要相应降低。使用人数少时，先确认统计口径是否按账号去重、是否覆盖完整评估周期，再在报告中写明样本量。效率与采纳率等指标可以照常填写，结论区建议写“趋势向好，样本量有限，建议扩大试点后再判断”，并把扩大样本列入待改进项，注明责任人和计划时间。
团队没有引入前的历史数据，效果指标怎么填？
可以设置未使用该应用的对照组，与使用组在同一统计周期内比较；也可以只填描述性数据，在指标后标注“仅描述性数据”，结论中不写“提升”这类判断，改为记录当前水平作为后续评估的基线。两种方式都要写明样本量和统计周期，下一次评估沿用同一口径，数据才可比较。
一个AI应用覆盖多个使用场景，应该出一份报告还是多份？
按场景拆分更利于判断。每个场景的任务、指标口径和对比基准往往不同，混在一份报告里容易把不同场景的数据加总，得出失真的结论。常见做法是每个场景单独一份报告，或在同一份报告内按场景拆分行，共用报告基本信息和评估对象区，使用数据与效果指标按场景分别填写。
评估报告和待改进项如何在协作工具中流转？
可以把模板放在 ONES Wiki 的文档空间中统一维护，已填报告作为页面留存版本；报告结论区的待改进项转为 ONES 项目中的工作项，指定责任人和计划时间，让改进动作与项目执行保持关联。ONES Wiki 支持管理项目规范、操作说明、复盘记录等需要长期沉淀的内容，并可与项目、任务等研发管理场景结合使用。若团队使用 ONES Assistant，也可以基于项目与 Wiki 上下文整理评估所需信息，并将结果保存为工作项或 Wiki 页面。
指标口径中途调整，之前的报告需要重写吗？
旧数据不追溯改写。口径变化时在版本号上升主版本，并在报告末尾增加口径变更说明，写清变更内容、原因和生效周期。跨期对比时注明两期口径不同，只做趋势参考，不直接相减。这样既保留了历史记录，也避免新旧数据被误当成同一口径比较。
