研发AI场景清单是一张按“场景—角色—输入—AI动作—产出—人工把关—验证指标”逐行填写的空白表，用来盘点研发各环节可引入AI助手或智能体的候选场景，并筛出可试点项。先复制空白表，再按字段说明逐项填写，最后用必填/选填规则和优先级评分确定试点顺序。清单登记与评审流转可以依托ONES的工作项与文档承载，本文不展开具体产品功能。
要点总览（TL;DR）
- 清单按四组字段组织：场景基本信息、AI动作与产出、人机分工、验证，每个候选场景占一行。
- 先复制空白表，按字段说明填写；必填字段齐全的行才进入评审，选填字段可在试点前补齐。
- 填写顺序建议从“当前做法与痛点”开始，再写输入材料、AI动作和产出物，最后确定把关点与验证指标。
- 示例记录显示，进入试点候选的场景需同时满足数据可得、收益可计量、人机边界清晰三个条件。
- 清单需固定评审节奏与维护责任人，新增、关闭和字段变更都留痕，避免退化为一次性表格。
可复制空白模板：研发AI场景清单表
下表是清单本体，按四组字段排列：场景基本信息、AI动作与产出、人机分工、验证。复制表头到表格工具或文档中，每个候选场景占一行。字段顺序与后文说明、示例保持一致，便于对照填写。
| 组别 | 字段 | 填写内容（空白） |
|---|---|---|
| 场景基本信息 | 场景编号 | |
| 场景名称 | ||
| 所属研发环节 | ||
| 提出人 / 责任角色 | ||
| 当前做法与痛点 | ||
| AI动作与产出 | 输入材料 | |
| AI动作 | ||
| 产出物 | ||
| 使用方式 | ||
| 人机分工 | 人工把关点 | |
| 把关责任角色 | ||
| 异常处理方式 | ||
| 验证 | 验证指标 | |
| 数据来源 | ||
| 观察周期 | ||
| 优先级评分 |
表格按行登记场景，按列横向比较。场景数量较多时，可以在“场景编号”前增加“登记日期”列，或在表尾增加“状态”列（候选、试点中、已关闭），这两列属于选填扩展，不影响主表结构。
字段说明：每个字段填什么、怎么判断
字段说明解决“同一张表不同人填出不同口径”的问题。以下按四组逐一说明填写口径，判断标准以可核对为准，避免写成主观评价。
场景基本信息
- 场景编号：按“环节缩写-序号”编写，如“需求-01”“测试-03”，编号一经登记不再复用，关闭的场景保留编号。
- 场景名称：写“对象+动作”，如“用户反馈聚类提炼”“缺陷报告归并去重”，避免只写“AI辅助需求”这类无法判断范围的名字。
- 所属研发环节：从需求、计划、设计、开发、测试、发布、运维、知识沉淀中选择，跨环节场景填主环节，并在名称中注明衔接对象。
- 提出人 / 责任角色：提出人写姓名，责任角色写岗位，如“测试负责人”，保证场景有人跟进。
- 当前做法与痛点：用一两句写清现在怎么做、耗时或出错点在哪里，作为后续验证的对照基线。
AI动作与产出
- 输入材料：列出AI实际读取的对象，如需求文档、会议录音、缺陷列表、Wiki页面，注明来源系统。
- AI动作：用动词描述，如“转录并提炼要点”“按模块归并重复缺陷”“生成拆解建议”，一个场景写一个主要动作。
- 产出物：写清交付形态，如“待澄清问题清单”“归并后的缺陷分组”“计划草案”，并说明落到哪个工作项或文档。
- 使用方式：说明产出由谁在什么时点使用，是一次性生成还是随迭代持续更新。
人机分工
- 人工把关点：写明AI产出在哪个节点必须由人确认，如“拆解建议进入迭代前由产品负责人确认”“缺陷归并结果由测试负责人抽检”。
- 把关责任角色：把关点对应到具体岗位，不写“团队共同确认”。
- 异常处理方式：写AI产出不可用时的退路，如“退回人工整理”“标记后转人工复核”。
验证
- 验证指标：选可量化的指标，如“需求澄清问题数”“缺陷重复率”“单场景处理耗时”，与“当前做法与痛点”对应。
- 数据来源：注明指标从哪个系统或记录取数，如工作项字段、迭代回顾记录、测试报告。
- 观察周期：写清验证覆盖的时间范围，如“两个迭代”或“四周”。
- 优先级评分：按团队约定维度打分，常见维度为业务价值、实施难度、数据可得性，各1–5分，加权后排序。
必填与选填：哪些字段不能空
首次填写时不必追求字段全满，先保证最小可用集，其余字段在场景进入试点前补齐。必填字段缺失时该行不进入评审，选填字段缺失不影响登记。
| 字段 | 属性 | 理由与补齐时机 |
|---|---|---|
| 场景编号 | 必填 | 用于追踪与去重，登记即填 |
| 场景名称 | 必填 | 评审时识别场景的唯一依据 |
| 所属研发环节 | 必填 | 用于按环节汇总和分配评审人 |
| 责任角色 | 必填 | 保证场景有人推进 |
| 当前做法与痛点 | 必填 | 作为验证对照基线，缺失则无法判断收益 |
| 输入材料 | 必填 | 判断数据是否可得的前提 |
| AI动作 | 必填 | 界定场景范围，防止范围漂移 |
| 产出物 | 必填 | 决定产出落到哪里、由谁接收 |
| 人工把关点 | 必填 | 明确人机边界，避免产出直接流入下游 |
| 把关责任角色 | 必填 | 与把关点配套，缺一则把关落空 |
| 验证指标 | 必填 | 试点准入条件，缺失不进入试点排序 |
| 数据来源 | 必填 | 保证指标可复核 |
| 提出人 | 选填 | 登记时可后补，评审前补齐 |
| 使用方式 | 选填 | 试点方案确定后补充 |
| 异常处理方式 | 选填 | 试点前补充，与把关点一起评审 |
| 观察周期 | 选填 | 进入试点排期时填写 |
| 优先级评分 | 选填 | 评审会上统一打分后填入 |
字段缺失的处理规则：必填字段为空的行标记为“草稿”，不进入评审队列；选填字段为空的行可以进入评审，但涉及试点的场景在评审结论中注明待补字段和补齐责任人。若某场景的输入材料暂不可得，保留该行并在“异常处理方式”中写明获取计划，不直接删除。
填写示例：一条完整场景记录
以下为演示情景，用于说明字段如何配合，数据为示意，不代表真实项目。
| 字段 | 填写内容 |
|---|---|
| 场景编号 | 需求-02 |
| 场景名称 | 用户反馈聚类提炼待澄清问题 |
| 所属研发环节 | 需求 |
| 提出人 / 责任角色 | 示例提出人 / 产品负责人 |
| 当前做法与痛点 | 每周人工阅读约200条用户反馈，整理耗时约半天，遗漏和重复归类较多 |
| 输入材料 | 用户反馈记录、历史需求文档（来自需求管理工具与Wiki） |
| AI动作 | 按主题聚类反馈，提炼高频诉求与待澄清问题 |
| 产出物 | 待澄清问题清单与需求拆解建议，落到需求工作项 |
| 使用方式 | 每周需求评审前生成一次，供产品负责人会前阅读 |
| 人工把关点 | 拆解建议进入迭代前，由产品负责人逐条确认 |
| 把关责任角色 | 产品负责人 |
| 异常处理方式 | 聚类结果明显偏离时退回人工整理，并记录偏差原因 |
| 验证指标 | 需求澄清问题数、整理耗时、评审会上被采纳的建议比例 |
| 数据来源 | 需求工作项字段、迭代回顾记录 |
| 观察周期 | 两个迭代 |
| 优先级评分 | 业务价值4、实施难度2、数据可得性4，加权后排序靠前 |
该场景进入试点候选的理由有三点：输入材料已在系统中留存，数据可得性高；痛点是可计量的整理耗时，验证指标能直接对照；人工把关点清晰，产出只作为评审输入，不直接改动需求状态。这三点分别对应数据条件、收益可验证和人机边界，也是评审其他场景时可以复用的判断顺序。
在ONES中，这类场景的登记与评审可以落到具体工作项：场景记录作为需求类工作项维护，字段对应工作项属性，评审结论和试点进展随状态流转留痕；相关背景资料放在Wiki页面，与工作项关联。ONES Assistant可围绕需求澄清环节提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求澄清和录入，产出的建议仍需按清单中的把关点由人确认。
调整与维护：清单如何随团队变化更新
清单是持续使用的台账，需要固定的新增、关闭和评审规则，否则会退化为一次性表格。
新增与关闭场景
- 新增场景随时登记，编号顺延，必填字段齐全后进入下一次评审；同一环节重复场景先合并再登记。
- 关闭场景时保留整行记录，在状态列标注“已关闭”并写明原因，如“验证未达预期”“输入数据不可得”“已并入其他场景”。
- 试点结束的场景把验证结果回填到验证组字段，作为后续同类场景的参考。
字段增删的评审方式
字段调整影响所有在填记录，按变更处理：提出人说明新增字段要解决的问题，列出受影响的存量行和补填方式，由清单责任人在例行评审会上确认后统一修改表头，并记录变更日期。删除字段前先确认没有场景依赖该字段做验证或把关判断。字段名称保持稳定，含义调整写入字段说明而不是改名。
更新频率与责任人
| 事项 | 节奏 | 责任人 |
|---|---|---|
| 新增场景登记 | 随时 | 提出人 |
| 必填字段完整性检查 | 每次评审前 | 清单维护人 |
| 场景评审与优先级排序 | 每两周或每迭代一次 | 研发负责人主持，各环节责任角色参加 |
| 试点结果回填 | 观察周期结束时 | 场景责任角色 |
| 字段与模板变更 | 按需，随例行评审确认 | 清单维护人 |
清单维护人建议由研发管理或项目管理岗位兼任，职责是保证字段口径一致、评审按时进行、变更留痕。团队规模或研发流程调整时，先复核“所属研发环节”的取值是否仍匹配现有流程，再决定是否增删字段；环节划分变化时同步更新字段说明，避免新旧口径混用。
常见问题
团队第一次填清单，应该先填哪些场景？
建议从输入材料已经在系统中留存的环节开始，例如需求澄清、缺陷归并、测试报告整理。这类场景的数据可得性高，验证指标容易取数，首次填写时不必额外协调数据源。跨系统或需要新采集数据的场景可以先登记为草稿，等输入材料落实后再补全必填字段进入评审。
一个场景涉及多个研发环节，所属研发环节怎么填？
按主环节填写，在场景名称中注明衔接对象，例如“需求-测试：验收标准一致性检查”。评审时由主环节的责任角色牵头，衔接环节的角色参与把关点确认。若两个环节的工作量接近，可以在评审会上决定归属，避免同一场景重复登记。
验证指标暂时定不下来，这条记录还能进入评审吗？
验证指标属于必填字段，缺失时该行标记为草稿，不进入试点排序。可以先在“当前做法与痛点”中写清耗时或出错点，再据此选一个可量化的指标，例如整理耗时、重复率、澄清问题数。指标的数据来源同步写明，保证试点结束后能复核。
清单填好后，试点顺序怎么定？
按团队约定的维度打分排序，常见维度为业务价值、实施难度、数据可得性，各1–5分加权后排序。排序前先确认必填字段齐全，避免把数据不可得的场景排进试点。评审结论中记录入选理由和待补字段，便于下一轮复盘时对照。
清单运行一段时间后场景越来越少，需要调整吗？
场景减少通常说明新增登记没有跟上或评审节奏中断。先检查新增场景是否仍按编号顺延登记、关闭场景是否写明原因，再确认评审会是否按节奏召开。若团队研发流程已调整，同步复核“所属研发环节”的取值，必要时按字段变更流程统一修改表头和字段说明。
