研发AI场景清单把团队零散的AI使用想法整理成一张可评估、可试点、可复盘的台账。本文提供可直接复制的空白表格、逐字段填写口径、必填与选填划分、一行完整示例，以及清单上线后的调整与维护方法，帮助研发团队用统一格式记录每个AI场景。
要点总览（TL;DR）
- 研发AI场景清单按“场景—角色—输入—AI动作—产出—验收”逐行填写，一行只放一个可独立评估的AI场景。
- 必填字段覆盖场景编号、名称、所属研发环节、使用角色、输入材料、AI动作、产出物、验收指标、状态和负责人；价值假设、风险关注点、试点范围可按阶段设为选填。
- 填写示例以“需求评审前的PRD完整性检查”演示字段对应关系，属于演示情景，试点范围和指标口径需按团队实际替换。
- 清单维护围绕字段增删判断、与例会结合的评审节奏、四段状态流转，以及与需求池和迭代计划的编号对应展开。
可复制空白模板：研发AI场景清单表
清单以“一行一个场景”为基本规则。每个场景应当是能够独立评估、独立试点的一项AI应用，例如“需求评审前用AI检查PRD完整性”或“迭代结束后用AI汇总缺陷分布”。把“需求分析+测试用例生成+发布说明撰写”塞进同一行，后续就无法判断哪一段有效、哪一段需要调整。
建议按以下顺序填写：先写场景名称与所属研发环节，再确定使用角色和输入材料，然后描述AI承担的动作与产出物，最后补充价值假设、风险关注点、试点范围、验收指标、状态和负责人。前六列构成场景的基本轮廓，后几列用于评估与推进。
以下空白表可直接粘贴到表格工具中，列之间用制表符分隔：
场景编号 场景名称 所属研发环节 使用角色 输入材料 AI承担的动作 产出物形态 价值假设 风险与合规关注点 试点范围 验收指标 状态 负责人 备注
如果表格工具支持表头，可将第一行设为标题行并冻结；场景编号建议采用“AI-001”这类短编号，便于在需求池、迭代计划中引用。空白表只提供结构，各字段的具体填写口径见下一节。
字段说明：每个字段填什么、为什么填
字段说明的目标是让不同角色填出的记录具备可比性。同一个字段，产品经理、测试负责人和研发主管应当按同一口径填写，否则汇总时会出现“有的写工具名、有的写动作”的混乱。
| 字段 | 填写内容 | 填写口径 |
|---|---|---|
| 场景编号 | 唯一短编号，如AI-001 | 建立后不复用，归档场景保留编号 |
| 场景名称 | 一个动宾短语，说明AI在什么任务上做什么 | 写“PRD完整性检查”，不写“AI辅助需求”这类宽泛表述 |
| 所属研发环节 | 需求、设计、开发、测试、发布、运维、知识沉淀等 | 选一个主要环节；跨环节场景以主要价值发生点为准 |
| 使用角色 | 实际使用该场景的岗位 | 写岗位而非人名，如“测试工程师”“产品经理” |
| 输入材料 | AI处理前需要提供的文档、数据或记录 | 写明材料类型和来源，如“迭代内的缺陷记录”“PRD文档” |
| AI承担的动作 | 提炼、分类、生成、检查、汇总等具体动作 | 一行只写一个主要动作，避免“分析并生成并推送” |
| 产出物形态 | 清单、报告、草稿、问题列表、建议等 | 说明产出交给谁、以什么形式呈现 |
| 价值假设 | 预期改善的具体环节和可观察结果 | 写“减少评审返工轮次”，不写“提升效率” |
| 风险与合规关注点 | 数据敏感度、输出准确性、权限范围等 | 只写与本场景直接相关的风险，不套通用条款 |
| 试点范围 | 试点团队、项目或时间窗口 | 范围宜小到可在一两个迭代内观察结果 |
| 验收指标 | 判断场景是否有效的可核验标准 | 写指标名称、统计方式和观察周期 |
| 状态 | 待评估、试点中、已推广、已归档 | 按统一状态值填写，不自行造词 |
| 负责人 | 对该场景推进和复盘负责的人 | 写具体责任人，便于跟进 |
| 备注 | 依赖条件、关联链接、补充说明 | 保持简短，详细材料放在关联文档中 |
价值假设和验收指标需要成对填写。价值假设说明“希望改善什么”，验收指标说明“用什么观察是否改善”。例如价值假设写“缩短需求澄清时间”，验收指标就应写明统计哪个环节的耗时、对比试点前后几个迭代的数据。两者脱节时，场景在复盘阶段很难得出结论。
必填与选填：哪些字段不能空
必填字段的作用是保证每条记录都能被独立理解和评估。以下字段建议设为必填：场景编号、场景名称、所属研发环节、使用角色、输入材料、AI承担的动作、产出物形态、验收指标、状态、负责人。缺少其中任何一项，评审者都无法判断这个场景在做什么、由谁推进、如何算有效。
价值假设、风险与合规关注点、试点范围、备注可作为选填。团队处于想法收集阶段时，可以先记录场景轮廓，价值假设在进入评估前补齐；试点范围在场景获批后再确定。风险与合规关注点对于涉及客户数据、代码仓库或未公开需求文档的场景应当转为必填。
| 字段 | 建议属性 | 说明 |
|---|---|---|
| 场景编号、场景名称、所属研发环节、使用角色 | 必填 | 构成场景的基本身份，缺失则无法检索和归类 |
| 输入材料、AI承担的动作、产出物形态 | 必填 | 说明AI在什么材料上做什么、交付什么 |
| 验收指标、状态、负责人 | 必填 | 保证场景可评估、可跟踪、有人负责 |
| 价值假设 | 选填，评估前补齐 | 想法收集阶段可先留空 |
| 风险与合规关注点 | 选填，涉敏感数据时必填 | 按输入材料的数据属性判断 |
| 试点范围 | 选填，试点启动前补齐 | 获批后确定团队、项目和时间窗口 |
| 备注 | 选填 | 用于依赖条件和关联信息 |
必填字段出现空缺时，处理规则应当明确：空缺记录保留在清单中但状态标记为“待评估”，不进入试点排期；由负责人在约定时间内补齐，逾期未补齐的记录转入归档或在评审会上决定是否删除。这样既不会因为字段不全而丢失想法，也不会让不完整的记录占用试点资源。
必填范围可以随团队阶段调整。刚开始收集场景时，可只要求场景名称、所属环节、使用角色和负责人四项，降低填写门槛；进入试点评审前，再将输入材料、AI动作、产出物和验收指标设为必填。调整时应在清单说明中记录变更日期和适用范围，避免新旧记录口径混用。
填写示例：一行完整场景记录
以下为演示情景，用于说明字段之间的对应关系，不代表任何真实项目数据或产品实测结果。
| 字段 | 示例内容 |
|---|---|
| 场景编号 | AI-007 |
| 场景名称 | 需求评审前的PRD完整性检查 |
| 所属研发环节 | 需求 |
| 使用角色 | 产品经理 |
| 输入材料 | 待评审的PRD文档，含背景、目标、功能描述和验收标准 |
| AI承担的动作 | 检查PRD中缺失的边界条件、异常流程和验收口径，列出待澄清问题 |
| 产出物形态 | 待澄清问题清单，附在PRD评审记录中 |
| 价值假设 | 减少评审会上因信息缺失产生的返工，缩短需求从提交到进入开发的周期 |
| 风险与合规关注点 | PRD可能包含未公开的产品规划，需限制在项目权限范围内使用；AI列出的问题需人工确认后再采纳 |
| 试点范围 | 一个产品小组，连续两个迭代的PRD评审 |
| 验收指标 | 评审会上因信息缺失产生的待办数量；PRD从提交到评审通过的平均天数，对比试点前后两个迭代 |
| 状态 | 试点中 |
| 负责人 | 该产品小组的需求负责人 |
| 备注 | 问题清单模板存放在团队知识库，评审前由产品经理确认采纳范围 |
逐项看，场景名称限定了动作发生的位置是“需求评审前”，动作是“完整性检查”，对象是“PRD”，三者合起来构成一个可独立评估的场景。输入材料写明了PRD包含的章节，AI动作聚焦在“列出待澄清问题”这一项，产出物说明交付形式和存放位置。验收指标与价值假设对应：价值假设关注返工和周期，指标就统计待办数量和评审通过天数。
这条示例的适用边界在于：它假设团队已有相对规范的PRD模板和评审流程，AI检查才有明确的比对基准。如果PRD格式不统一，需要先补充输入材料的规范，再评估该场景。示例中的试点范围、指标口径和负责人角色需按团队实际情况替换，不能直接照搬为统一标准。
调整与维护方法：让清单持续可用
清单上线后最常见的两个问题是字段越加越多、记录长期不更新。维护规则应围绕“字段是否影响决策”和“状态是否反映真实进展”来设计。
字段增删的判断标准可以归纳为三条：新增字段必须对应一个实际发生的决策，例如增加“依赖工具”是因为试点排期需要确认工具开通情况；删除字段的前提是该字段连续多个评审周期无人使用；合并字段适用于两条记录总是同时填写、分开没有意义的情况。每次调整保留变更记录，注明调整原因和生效范围。
评审节奏建议与团队现有例会结合，不必单独增设会议。可以在迭代规划会上用十分钟过一遍新增场景和状态变更，在迭代回顾时复盘试点中场景的指标表现。状态流转按“待评估—试点中—已推广—已归档”推进：待评估场景在评审会上决定是否进入试点；试点中场景在约定周期结束后依据验收指标决定推广或归档；已归档场景保留记录，供后续类似场景参考。
清单需要与需求池、迭代计划等既有台账建立对应关系。场景进入试点时，在迭代计划中创建对应的工作项，并在清单备注中记录工作项编号；场景推广后，将沉淀的模板、检查规则放入团队知识库，清单中保留链接。这样清单承担场景台账的角色，具体执行仍落在原有的计划和协作流程中。
当清单需要承载在工作项或文档中并随状态流转时，可以借助 ONES 的表格与工作项管理能力。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，并基于相关项目数据和团队知识回答问题、执行后续操作。围绕需求澄清，ONES Assistant 可对PRD做质量检查，提炼要点、待澄清问题与拆解建议；围绕项目进展与缺陷分布，可生成进展分析和根因判断。这些能力可以作为清单中“需求”“测试”“风险洞察”类场景的候选记录对象，具体是否纳入试点，仍按本文的验收指标和试点范围评估。ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，涉及敏感材料的场景可将权限范围写入“风险与合规关注点”字段。
常见问题
团队刚开始收集AI想法，必填字段可以放宽到什么程度？
可以先只要求四项：场景名称、所属研发环节、使用角色和负责人。这四项能保证每条记录可检索、可归类、有人跟进。进入试点评审前，再把输入材料、AI承担的动作、产出物形态和验收指标补为必填。调整必填范围时，在清单说明中记录变更日期和适用范围，避免新旧记录口径混用。
一个场景同时涉及需求分析和测试用例生成，应该拆成几行？
按可独立评估、独立试点的粒度拆分。需求分析和测试用例生成发生在不同环节、由不同角色使用、验收指标也不同，建议拆成两条记录，各自填写输入材料、AI动作和验收指标。如果强行合并成一行，试点结束后无法判断是哪一段产生了效果，也无法分别决定推广或归档。
价值假设和验收指标可以只填一个吗？
两者需要成对使用。价值假设说明希望改善什么，验收指标说明用什么观察是否改善。只写价值假设，复盘时缺少判断依据；只写指标，评审时不清楚这个场景为什么值得做。例如价值假设写“缩短需求澄清时间”，验收指标就应写明统计哪个环节的耗时、对比试点前后几个迭代的数据。
清单里的场景和需求池、迭代计划是什么关系？
清单承担场景台账的角色，记录想法、评估结论和状态；具体执行落在原有的计划和协作流程中。场景进入试点时，在迭代计划中创建对应工作项，并在清单备注中记录工作项编号；场景推广后，把沉淀的模板和检查规则放入团队知识库，清单中保留链接。这样两边的记录能互相对照，又不会出现两套重复的推进流程。
涉及客户数据或未公开需求文档的场景，填写时要注意什么？
这类场景的“风险与合规关注点”应从选填转为必填，写明数据敏感度、使用范围和权限边界，例如限定在项目权限范围内使用、AI输出需人工确认后再采纳。清单承载在工作项或文档中时，可借助 ONES 基于自身权限体系进行知识问答和任务执行、输出过程可追踪、结果可审计的能力，把权限范围同步写入该字段。具体认证与合规资质需另行核验。
