研发AI场景清单以“一行一个AI应用场景”为基本单位，需要覆盖场景识别、数据与角色、人机分工、度量与风险、推进状态五组信息。首版先保证字段可填、口径统一，再随试点推进补充扩展字段。本文提供可直接粘贴到表格工具的空白模板、逐字段填写口径、必填与选填分级、一条完整示例，以及清单长期维护规则，适合研发管理团队梳理AI应用场景时使用。
要点总览（TL;DR）
- 清单以“一行一个AI应用场景”为行粒度，字段按场景识别、数据与角色、人机分工、度量与风险、推进状态五组排列，先统一口径再扩展。
- 首版必填字段聚焦场景是什么、解决什么问题、AI做什么、谁来用、怎么判断有效；基线值可写“待采集”，但需约定采集责任人和截止时间。
- 字段说明给出每个字段的判断标准，例如场景名称用“动作+对象”、AI动作要可观察可验收、输入来源要定位到具体系统。
- 一条完整示例演示了指标与基线、人机分工与审核点的写法，可按同样对应关系逐项自查记录是否完整。
- 维护上设一名清单维护人，字段增删需有变更记录，状态按识别、评估、试点、推广流转，季度复盘并抽查不少于20%的活跃场景。
可复制空白模板：研发AI场景清单表
清单的行粒度约定为：一行对应一个可独立描述、可独立评估的AI应用场景。同一研发环节下的多个AI动作，如果输入数据、使用角色或输出物不同，应拆成多行；如果只是同一动作在不同项目上重复使用，则合并为一行，在“试点范围”中说明覆盖项目。按这个口径建表，后续统计场景数量、分配负责人和跟踪状态时不会出现重复计数。
下表为完整空白表头，列按五组排列，可直接复制到Excel、在线表格或ONES Wiki表格中，再按需增删行。表头下方保留一行空白行示意填写位置。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 场景识别 | 场景编号 | |
| 场景识别 | 场景名称 | |
| 场景识别 | 所属研发环节 | |
| 场景识别 | 业务问题与现状做法 | |
| 场景识别 | AI承担的具体动作 | |
| 数据与角色 | 输入数据与知识来源 | |
| 数据与角色 | 使用角色 | |
| 数据与角色 | 触发时点 | |
| 数据与角色 | 输出物与交付对象 | |
| 人机分工 | 人机分工 | |
| 人机分工 | 审核方式与审核人 | |
| 度量与风险 | 衡量指标 | |
| 度量与风险 | 基线值与取数口径 | |
| 度量与风险 | 风险与合规约束 | |
| 推进状态 | 试点范围 | |
| 推进状态 | 负责人 | |
| 推进状态 | 上线状态 | |
| 推进状态 | 复盘结论 |
如果表格工具不支持分组列，可把“分组”作为表头第一行的合并单元格，或直接在字段名前加前缀（如“识别-场景名称”），保证复制后列顺序不乱。字段较多时，建议冻结前四列（编号、名称、环节、问题），方便横向滚动查看。
字段说明：每个字段填什么、怎么判断填对了
字段说明的作用是让不同填写人对同一字段给出可比的内容。以下逐项给出含义、填写要求和判断标准，判断标准可作为自查依据。
场景识别组
- 场景编号：建议采用“环节缩写-序号”格式，如“TEST-003”。判断标准：全表唯一，归档后不复用。
- 场景名称：用“动作+对象”命名，如“根据缺陷描述生成复现步骤建议”。判断标准：只看名称能知道AI做什么、对什么做，避免“智能测试”“AI提效”这类无法区分的名称。
- 所属研发环节：从团队既有流程中取值，如需求澄清、方案设计、编码、代码评审、测试设计、缺陷分析、发布、知识沉淀。判断标准：与团队流程文档中的环节名称一致，不临时造词。
- 业务问题与现状做法：写清当前谁在什么情况下遇到什么问题、现在怎么处理、耗时或出错情况如何。判断标准：包含具体角色和具体动作，能看出不解决会带来什么后果。
- AI承担的具体动作：只写AI实际执行的动作，如“汇总历史相似缺陷并生成候选复现步骤”。判断标准：动作可观察、可验收，不写“提升效率”“辅助研发”这类结果性描述。
数据与角色组
- 输入数据与知识来源：列出AI动作依赖的数据和知识，如缺陷库、需求文档、接口文档、历史评审记录，并注明来源系统。判断标准：每项来源可定位到具体系统或文档库，不写“公司数据”这类笼统表述。
- 使用角色：填写实际发起或接收AI输出的人，如测试工程师、开发负责人。判断标准：角色名称与组织内岗位一致。
- 触发时点：说明什么时候调用该场景，如“提交缺陷单时”“迭代评审会前”。判断标准：能对应到流程中的具体节点。
- 输出物与交付对象：写清AI产出什么形式的结果、交给谁，如“复现步骤建议，交付给提交缺陷的测试工程师”。判断标准：输出物有明确形态（文本、列表、草稿页面等），交付对象是具体角色。
人机分工与审核
人机分工字段要说明AI完成哪一步、人完成哪一步、交接点在哪里。审核方式字段要写明审核人角色、审核动作和审核不通过时的处理，如“测试负责人逐条确认后采纳，未采纳的建议记录原因”。判断标准：任何AI输出在进入下游流程前都有明确的人工确认环节，且确认人可追溯。
度量与风险组
衡量指标写一个主要指标加一至两个辅助指标，如“缺陷复现平均耗时”“建议采纳率”。基线值写启用AI前的实际数值，并注明取数口径，如“取最近一个季度缺陷单从提交到复现的平均时长，数据来自缺陷管理系统”。没有基线时写“待采集”，并约定采集周期。风险与合规约束填写数据敏感级别、是否涉及客户信息、输出错误可能造成的后果及对应控制措施。判断标准：指标能用现有系统数据计算，风险项能对应到具体控制动作。
推进状态组
试点范围写明覆盖的团队、项目或时间窗口；负责人写对场景结果负责的具体人；上线状态从“识别、评估、试点、推广、暂停、归档”中取值；复盘结论在试点结束后填写，记录指标变化、主要问题和下一步决定。判断标准：状态取值统一，复盘结论有数据支撑。
必填与选填：最小可用清单与扩展字段
首版清单的目标是让团队能把场景登记进来并开始评估，因此必填字段聚焦“这个场景是什么、解决什么问题、AI做什么、谁来用、怎么判断有效”。以下分级供参考，团队可结合自身流程调整，不必把一种字段组合当作统一要求。
| 字段 | 首版 | 识别期 | 试点期 | 推广期 |
|---|---|---|---|---|
| 场景编号、场景名称、所属研发环节 | 必填 | 必填 | 必填 | 必填 |
| 业务问题与现状做法 | 必填 | 必填 | 必填 | 必填 |
| AI承担的具体动作 | 必填 | 必填 | 必填 | 必填 |
| 输入数据与知识来源 | 必填 | 可简填 | 必填 | 必填 |
| 使用角色、触发时点 | 必填 | 必填 | 必填 | 必填 |
| 输出物与交付对象 | 必填 | 可简填 | 必填 | 必填 |
| 人机分工、审核方式与审核人 | 必填 | 可简填 | 必填 | 必填 |
| 衡量指标、基线值与取数口径 | 指标必填，基线可写“待采集” | 可只填指标 | 必填 | 必填 |
| 风险与合规约束 | 必填 | 可简填 | 必填 | 必填 |
| 试点范围、负责人 | 负责人必填 | 可暂缺 | 必填 | 必填 |
| 上线状态 | 必填 | 必填 | 必填 | 必填 |
| 复盘结论 | 选填 | 不适用 | 试点结束必填 | 按周期更新 |
| 扩展：关联需求或项目编号 | 选填 | 选填 | 建议填 | 必填 |
| 扩展：模型或工具说明 | 选填 | 选填 | 选填 | 建议填 |
| 扩展：成本与资源投入 | 选填 | 不适用 | 选填 | 建议填 |
字段缺失时的处理约定：识别期允许“输入数据”“输出物”“审核方式”暂写初步判断，但需在备注中标注“待细化”；进入试点前，这些字段必须补齐，否则不予立项。基线值允许写“待采集”，但需同时填写采集责任人和采集截止时间。任何必填字段为空且无备注说明的记录，在季度抽查中计为不合格。
填写示例：一条完整场景记录
以下示例为演示情景，用于说明字段之间的对应关系，数值为示意，不代表真实团队数据。
| 字段 | 示例内容 |
|---|---|
| 场景编号 | TEST-003 |
| 场景名称 | 根据缺陷描述生成复现步骤建议 |
| 所属研发环节 | 缺陷分析 |
| 业务问题与现状做法 | 测试工程师提交缺陷时描述不完整，开发需反复沟通才能复现，平均每个缺陷多花约半天。现状靠人工补充截图和口头说明。 |
| AI承担的具体动作 | 读取缺陷标题与描述，检索历史相似缺陷和对应复现记录，生成候选复现步骤列表供提交人参考。 |
| 输入数据与知识来源 | 缺陷管理系统中的历史缺陷单、测试用例库、版本发布记录。 |
| 使用角色 | 提交缺陷的测试工程师 |
| 触发时点 | 缺陷单填写描述后、提交前 |
| 输出物与交付对象 | 候选复现步骤列表，交付给缺陷提交人 |
| 人机分工 | AI生成候选步骤；提交人逐条核对，采纳或修改后写入缺陷单；开发按确认后的步骤复现。 |
| 审核方式与审核人 | 缺陷提交人确认后生效，未采纳的建议记录原因；测试负责人每周抽查采纳情况。 |
| 衡量指标 | 主要指标：缺陷从提交到首次复现的平均耗时；辅助指标：建议采纳率。 |
| 基线值与取数口径 | 基线：上一季度平均耗时1.8个工作日，取缺陷管理系统中“提交时间”到“首次复现记录时间”；采纳率基线待试点首月采集。 |
| 风险与合规约束 | 缺陷描述可能含客户环境信息，输出仅限内部使用；建议错误可能导致误判，要求提交人核对后才写入正式缺陷单。 |
| 试点范围 | 某产品线测试组，试点一个迭代周期 |
| 负责人 | 该测试组负责人 |
| 上线状态 | 试点 |
| 复盘结论 | 试点结束后填写，记录耗时变化、采纳率和主要问题 |
对照字段说明可以看出：场景名称采用“动作+对象”结构；AI动作只描述生成候选步骤这一可观察行为；输入来源均定位到具体系统；人机分工写明了AI生成、人核对、开发复现三个交接点；指标与基线都注明了取数口径。填写时按同样对应关系逐项检查，即可保证记录完整。
调整与维护：清单怎么改、谁来改、多久复盘
清单建好后需要一套轻量机制维持可用性，重点是字段变更可控、状态流转清晰、与既有台账衔接。
字段增删的判断标准与变更记录
新增字段的条件是：现有字段无法表达某类反复出现的信息，且至少有三个场景需要该信息。删除字段的条件是：连续两个季度无场景使用，或该字段信息已由关联台账承载。每次变更在清单末尾或独立变更页记录变更日期、变更人、变更内容和影响范围，历史记录保留不覆盖。
维护角色与更新节奏
建议设一名清单维护人，负责字段口径解释、变更登记和季度汇总；每个场景的负责人负责更新自己场景的状态、指标和复盘结论。日常更新随场景进展进行，季度复盘时统一核对全表：关闭已归档场景、补齐缺失字段、更新基线数据。
场景状态流转与归档规则
状态按“识别→评估→试点→推广”推进，任一阶段可转入“暂停”并注明原因；推广后连续两个季度无使用的场景转入“归档”，归档记录保留在清单中但不再计入活跃场景统计。状态变更需由场景负责人发起，维护人确认。
与需求、项目、知识库等台账的衔接
场景清单定位为AI应用的资源目录，不替代需求池和项目台账。建议在清单中增加“关联需求或项目编号”扩展字段，指向需求池中的需求条目或项目台账中的项目；场景产生的提示词、评估记录和复盘文档放入知识库对应目录，清单中只保留链接或文档编号。这样清单保持轻量，细节信息由相邻台账承载。
在ONES中落地时，可把每个场景登记为工作项，用状态字段承载“识别、评估、试点、推广”流转，把字段说明和复盘记录放在ONES Wiki页面中，使清单条目与需求、项目数据保持关联。ONES Assistant可基于项目、工作项和Wiki页面等上下文回答问题并执行操作，将结果保存为工作项或Wiki页面，便于维护人在季度复盘时直接查询场景进展和关联记录；其知识问答和任务执行基于ONES权限体系，输出过程可追踪、结果可审计，适合需要保留审核痕迹的场景清单管理。
清单质量的抽查方式
每季度抽取不少于20%的活跃场景，按三条标准检查：必填字段是否完整且有具体内容；指标与基线是否注明取数口径；审核方式是否写明审核人和处理规则。抽查结果记录不合格项和整改期限，连续两次不合格的场景由维护人约谈负责人并决定是否暂停。抽查本身也应在变更记录中留痕，便于追溯清单质量变化。
常见问题
场景清单和需求池、项目台账是什么关系，需要合并吗？
三者定位不同，建议分开维护、用编号关联。场景清单是AI应用的资源目录，回答“团队有哪些AI场景、各自推进到哪一步”；需求池承载具体需求条目，项目台账承载交付过程。在清单中增加“关联需求或项目编号”扩展字段指向对应条目，场景产生的提示词、评估记录和复盘文档放入知识库目录，清单中只保留链接或文档编号，清单就能保持轻量。
团队刚开始梳理，很多字段填不出来怎么办？
按阶段放宽要求即可。识别期允许“输入数据与知识来源”“输出物与交付对象”“审核方式”先写初步判断，并在备注中标注“待细化”；进入试点前这些字段必须补齐，否则不予立项。基线值允许写“待采集”，但要同时填写采集责任人和采集截止时间。必填字段为空且无备注说明的记录，在季度抽查中计为不合格。
同一个AI能力用在多个项目上，应该拆成多行还是合并一行？
判断依据是输入数据、使用角色和输出物是否相同。同一动作在不同项目上重复使用、这些要素一致时合并为一行，在“试点范围”中说明覆盖的项目；如果输入数据来源、使用角色或输出物不同，就拆成多行，分别登记负责人和状态。这样统计场景数量和跟踪进展时不会重复计数，也不会漏掉差异化的实施条件。
清单里的指标怎么定才算可计算？
指标要能用现有系统的数据算出来，并注明取数口径。写一个主要指标加一至两个辅助指标，例如“缺陷从提交到首次复现的平均耗时”和“建议采纳率”，并说明数据来自哪个系统、取哪两个时间点之间的差值。基线取启用AI前的实际数值；暂时没有基线时写“待采集”，约定采集周期。指标定义完成后，建议先在一个场景上试算一次，确认数据可取再推广到全表。
清单维护人需要做哪些事，和场景负责人怎么分工？
维护人负责字段口径解释、变更登记和季度汇总，确认状态变更；场景负责人负责更新自己场景的状态、指标和复盘结论。日常更新随场景进展进行，季度复盘时统一核对全表：关闭已归档场景、补齐缺失字段、更新基线数据。抽查也由维护人组织，每季度抽取不少于20%的活跃场景检查必填字段完整性、取数口径和审核规则，结果记录不合格项与整改期限。
