本文给出一份假设情景下的AI流程执行记录完整样例：需求评审结束后，由AI生成测试要点并提交人工确认。样例逐字段填写，覆盖触发、输入、AI动作、产出、人工确认与结果状态，并解释每个字段的填写依据、可迁移到其他AI流程的规律，以及使用时的边界。读者可以对照改写，用于自己的流程记录。
要点总览（TL;DR）
- AI流程执行记录要回答五个问题：谁触发、AI做了什么、产出是什么、谁确认、结果如何。
- 示例以需求评审后AI生成测试要点并提交人工确认为假设情景，逐字段展示记录填写内容，可直接对照改写。
- 关键字段的填写依据是让记录事后可核对：触发事件带版本与结论、输入锁定文档版本、产出落到具体位置、确认人与修改意见分开记录。
- 这套写法可迁移到缺陷分级建议、发布说明草稿等AI流程，按输入可追溯、产出可定位、确认可追责三条主线增减字段。
- 示例不含真实客户与实测数据，工具能力、版本与集成方式需自行查证，高风险流程应加强确认与留痕。
这份示例要解决什么问题
AI参与研发流程后，团队常遇到一个具体问题：过一段时间回看，只记得“AI帮忙生成过一些内容”，却说不清当时用的是哪版需求、AI依据什么生成、谁看过、最后有没有被采纳。AI流程执行记录就是为回答这些问题而设计的。它需要回答五个问题：谁触发、AI做了什么、产出是什么、谁确认、结果如何。
本文的示例属于假设情景，用于演示记录结构，不涉及真实客户身份、实测数据或量化效果。示例设定在需求评审之后：产品需求文档完成评审，团队希望尽快得到测试要点，于是由测试负责人发起一次AI生成任务，AI输出测试要点草稿，提交给测试与产品角色确认。涉及的角色包括发起人（测试负责人）、AI执行环节、确认人（测试负责人与产品经理）、以及后续承接测试要点的工作项负责人。
读者可以直接借用的部分有三块：一是完整的字段清单，可作为自建记录模板的起点；二是每个字段的填写依据，帮助判断哪些信息必须写、写到什么程度；三是字段增减方法，便于把这份样例迁移到缺陷分级建议、发布说明草稿等其他AI流程。记录的目标清单可以概括为：
- 触发可追溯：能定位到是哪次事件、什么时间发起了这次AI执行。
- 输入可核对：能还原AI当时看到的需求版本与约束条件。
- 产出可定位：能直接找到AI生成的内容存放在哪里。
- 确认可追责：能看出谁确认、确认结论与修改意见。
- 结果可衔接：能判断这次产出是被采纳、退回还是待定，以及后续流向哪里。
完整示例：AI生成测试要点并提交确认
下面是一份填写完整的记录样例。为便于对照改写，先以表格呈现字段与填写内容，再补充说明记录之间的关联关系。
| 字段 | 填写内容 |
|---|---|
| 流程名称 | 需求评审后AI生成测试要点 |
| 记录编号 | AI-EXEC-2024-0312-01（示例编号） |
| 触发事件 | 需求文档《订单退款流程优化》V1.3 通过需求评审，评审结论为“通过，进入测试设计” |
| 执行时间 | 2024-03-12 14:20 至 14:26（示例时间） |
| 发起角色 | 测试负责人（发起人：测试组A） |
| AI输入：需求文档版本 | 《订单退款流程优化》V1.3，评审通过版本 |
| AI输入：上下文范围 | 该需求关联的3条子需求、上一版本V1.2的测试要点、退款模块历史缺陷记录摘要 |
| AI输入：约束提示 | 按“功能、边界、异常、权限”四类组织；每条要点注明对应需求章节；不生成性能与安全专项用例 |
| AI动作 | 读取需求正文与关联上下文，按约束分类提炼测试要点，标注每条要点对应的需求章节号 |
| AI产出 | 测试要点草稿共18条，存放于测试用例库“订单退款流程优化”目录下的《测试要点草稿_V1》文档，状态为“待确认” |
| 人工确认人 | 测试负责人、产品经理（需求作者） |
| 确认结论 | 有条件通过：14条直接采纳，3条需补充边界条件，1条与需求V1.3不一致需删除 |
| 修改意见 | 第7条补充“部分退款多次发起”的边界；第12条补充“退款失败重试”的异常路径；第16条删除，因该规则已在V1.3中取消 |
| 结果状态 | 采纳（修改后） |
| 后续流转 | 修改后的测试要点转为测试用例编写任务，指派给测试组A，关联至迭代“2024-03 第2周” |
| 记录人 | 测试负责人 |
这份记录前后自洽：触发事件是需求评审通过，输入锁定在评审通过的V1.3版本，AI产出落在具体文档位置并标记“待确认”，人工确认给出了可执行的修改意见，结果状态与后续流转对应“采纳后进入用例编写”。如果确认结论是“退回重做”，结果状态应改为“退回”，后续流转写“退回发起人补充约束提示后重新执行”，并保留本次记录不覆盖。
逐字段解释：每个格子为什么这样填
字段的价值在于让记录在事后能被核对和追责，因此每个格子都要回答一个具体问题。下面按记录顺序解释关键字段的填写依据。
触发事件与执行时间
触发事件写的是“什么事件让这次AI执行发生”，示例中写到了需求名称、版本和评审结论，而不是只写“需求评审后”。这样做的原因是：同一需求可能多次评审，只有带上版本和结论，才能定位到具体那一次。执行时间精确到分钟，是因为AI执行往往只有几分钟，精确时间有助于和文档修改记录、工作项操作记录对齐，排查“AI用的是评审前还是评审后的版本”。
输入版本与上下文范围
输入只写文档名不够，因为文档会持续修改。示例中写明“V1.3，评审通过版本”，把AI看到的输入固定在一个可核对的版本上。上下文范围则说明AI还参考了哪些材料，例如关联子需求、上一版测试要点和历史缺陷摘要。范围写得越具体，事后判断“AI漏掉了什么”就越有依据。约束提示是发起人对AI的要求，例如分类方式、是否生成专项用例，它决定了产出的形态，也应一并留存。
AI动作与产出位置
AI动作用一两句话描述AI做了什么，重点是“读取了什么、按什么规则处理、标注了什么”。产出必须落到具体位置：哪个库、哪个目录、哪份文档、什么状态。示例中写“测试用例库‘订单退款流程优化’目录下的《测试要点草稿_V1》，状态为待确认”，任何人拿到记录都能直接打开核对。产出只写“生成了测试要点”而不写位置，记录就失去了核对价值。
人工确认人与修改意见
确认人字段要区分“谁确认”和“确认了什么”。示例中列出测试负责人和产品经理两位确认人，因为测试要点同时涉及测试视角和需求原意。确认结论用“有条件通过”这类明确表述，修改意见逐条对应到具体条目编号，写明补充什么、删除什么、为什么。把确认人与修改意见分开记录，是为了在出现争议时能看出是确认环节放过了问题，还是修改意见没有被执行。
结果状态与后续流转
结果状态是这次AI执行的终点判断，常见取值包括采纳、采纳（修改后）、退回、待定。示例用“采纳（修改后）”，与确认结论中的“有条件通过”对应。后续流转写清楚产出去了哪里：转为测试用例编写任务、指派给谁、关联到哪个迭代。状态与流转要能互相印证，避免出现“状态为采纳但没有承接对象”或“已退回却仍挂在待确认列表”的情况。
在工具层面，这类记录需要依附于可追踪的工作项与文档。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等上下文，并把执行结果保存为工作项、Wiki 页面等内容；其输出过程可追踪、结果可审计。对于本文示例，这意味着AI生成的测试要点草稿可以落在文档或工作项上，确认结论与后续流转也能沿同一对象记录，减少记录与实际工作脱节的情况。具体可用范围需按实际部署与套餐核实。
从这份示例能迁移出哪些规律
这份样例针对的是“生成测试要点”这一种流程，但它的字段设计可以抽象为三条主线，迁移到其他AI流程时按主线保留字段、按场景调整细节。
三条主线：输入可追溯、产出可定位、确认可追责
- 输入可追溯：记录AI执行时的文档版本、上下文范围和约束提示。任何AI流程都需要这一组字段，因为AI输出质量高度依赖输入，事后复盘必须能还原输入。
- 产出可定位：记录产出存放在哪里、以什么形态存在、当前状态。产出可以是文档、工作项、评论或建议列表，但位置必须具体到可打开。
- 确认可追责：记录确认人、确认结论和修改意见。确认环节是AI产出进入正式流程的关口，缺了它，记录无法说明产出是否被认可。
不同AI流程的字段增减
以缺陷分级建议为例：输入部分需要记录缺陷单编号与版本、历史分级数据范围；AI动作写“依据分级规则与历史相似缺陷给出建议等级”；产出写“建议等级与理由，附在缺陷单评论中”；确认人通常是缺陷处理人或模块负责人；结果状态可增加“采纳建议等级”“人工调整等级”两种取值。以发布说明草稿为例：输入记录本次发布包含的需求与缺陷清单版本；产出落在发布文档草稿；确认人包括产品与运营；结果状态区分“直接发布”“修改后发布”。
| 流程 | 输入重点 | 产出形态 | 确认角色 | 状态取值示例 |
|---|---|---|---|---|
| 生成测试要点 | 需求版本、关联子需求、历史测试要点 | 测试要点文档 | 测试负责人、产品经理 | 采纳（修改后）、退回、待定 |
| 缺陷分级建议 | 缺陷单版本、历史分级数据 | 缺陷单评论中的建议与理由 | 缺陷处理人、模块负责人 | 采纳建议、人工调整、退回 |
| 发布说明草稿 | 发布范围清单版本、历史发布说明 | 发布文档草稿 | 产品经理、运营 | 直接发布、修改后发布、退回 |
记录粒度与流程风险的匹配
记录写到多细，取决于这次AI执行出错后的影响范围。影响测试覆盖的产出，输入版本和确认意见要逐条对应；影响对外发布的产出，确认人和发布时间要精确到可追溯；仅用于内部参考的草稿类产出，可以合并记录、减少逐条修改意见。风险越高，确认人数量、修改意见的逐条程度、结果状态的细分都应相应增加。粒度调整的原则是：事后能凭记录判断“当时是否有人认真看过，以及看的人是否有权做这个决定”。
示例的适用边界与使用注意
这份示例是假设情景下的结构演示，不包含真实客户身份、实测数据或量化效果。文中的记录编号、时间、条目数量均为示例值，读者替换为自己的流程信息时，应保持字段之间的对应关系，而不是照抄数值。
使用时有几类内容需要自行核实：涉及具体工具的能力、版本与集成方式，应以实际部署和官方说明为准；AI产出在工具中的保存形态、审计记录的字段与保留期限，不同环境可能存在差异，落地前应确认。示例中的确认流程按中等风险流程设计，高风险流程（例如涉及对外发布、合规判断或安全相关变更）需要更严格的确认要求，例如增加独立复核人、要求确认意见逐条闭环、保留退回与重做的完整记录。
- 示例为假设情景，不代表任何真实客户案例或实测结论。
- 记录编号、时间、条目数量为演示值，替换时保持字段间对应关系。
- 工具能力、版本与集成方式需按实际环境查证后再写入记录规范。
- 高风险流程应增加确认人、逐条闭环修改意见，并保留退回记录。
- 记录一旦提交，修改应留痕，避免覆盖原始执行信息。
常见问题
AI流程执行记录和普通的操作日志有什么区别？
操作日志通常记录系统层面发生了什么，例如谁在什么时间修改了哪个字段。AI流程执行记录面向的是判断与追责：它要说明AI当时依据哪版输入、按什么约束生成、产出放在哪里、谁看过并给出什么结论。两者可以配合使用，操作日志提供时间与动作线索，执行记录提供判断依据。如果团队已有较完整的操作日志，执行记录可以适当精简时间类字段，把重点放在输入版本、约束提示和人工确认上。
如果AI产出被退回重做，原来的记录要覆盖还是保留？
建议保留原记录，不覆盖。退回本身是有价值的信息，它能说明第一次执行的输入或约束提示存在问题。常见做法是把原记录状态改为“退回”，在后续流转中写明退回原因和重新执行的条件，重新执行时新建一条记录并关联原记录编号。这样同一需求的多轮AI执行可以串起来看，也便于复盘约束提示应该如何调整。
团队刚开始用AI流程，记录字段可以精简吗？
可以，但三条主线对应的字段建议保留：输入版本、产出位置、确认人与结论。可以精简的是细枝末节，例如上下文范围的逐项列举、修改意见的逐条编号。随着流程风险上升再逐步加细。判断标准是：事后如果有人质疑这次AI产出，能否凭记录还原当时的情况并找到做决定的人。如果做不到，说明精简过头了。
AI执行记录应该由发起人填还是由确认人填？
通常由发起人填写触发、输入、AI动作与产出部分，确认人在确认环节补充确认结论与修改意见。这样分工与各自掌握的信息对应，也避免发起人代填确认意见造成记录失真。如果团队人手紧张，可以由一人统一整理，但确认结论应来自确认人本人的表述，整理者只做格式归并。
在ONES中落地这类记录，需要额外建一套表单吗？
不一定需要单独建表单。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等上下文，并把执行结果保存为工作项、Wiki 页面等内容，输出过程可追踪、结果可审计。团队可以把记录字段作为工作项的描述模板或 Wiki 页面模板使用，让记录与实际工作对象放在一起。具体可用范围和保存形态需按实际部署与套餐核实。
