AI流程执行记录要回答五个问题：谁触发、依据什么、AI做了什么、谁确认、结果如何。本文给出一份已填写的示例记录，设定为虚构团队的缺陷分诊场景，逐项解释字段填写理由，并归纳可迁移到需求评审、发布检查等场景的记录骨架与适用边界。
要点总览（TL;DR）
- AI流程执行记录要回答五个问题：谁触发、依据什么、AI做了什么、谁确认、结果如何，核心价值是让一次AI驱动的执行可追溯、可复核、可复用。
- 本文给出一份虚构团队的缺陷分诊示例记录，覆盖记录编号、触发来源、AI输入、建议与置信依据、人工确认、执行动作、结果状态、失败回退与复盘备注。
- 字段分两类作用：触发、输入、动作、结果承担追溯；依据、置信、人工确认、复盘承担复核，填写时先保证追溯完整，再让复核说清理由。
- 记录骨架可迁移到需求评审、发布检查等场景，稳定结构是触发—输入—建议—确认—动作—结果—复盘，换场景时变的是材料和确认人。
- 示例为演示情景，不构成真实实践或成效证明；确定性规则自动化、接口连接、合规审计与AI建议质量评估需另行处理。
这份示例要解决什么记录问题
AI参与研发流程执行后，团队常遇到一种尴尬：AI给出了建议，工程师采纳并改了缺陷单，几天后有人问“这条为什么被定为低优先级”，现场只剩一句“当时AI说的”。执行过程散落在对话窗口、工单评论和个人记忆里，无法复核，也无法复用。AI流程执行记录的目标，就是把一次AI驱动的执行沉淀成一份可追溯、可复核、可复用的结构化记录。
这份记录主要服务三类角色。执行人用它说明自己采纳或修改AI建议的依据；评审人用它判断当时的判断是否合理；后续接手的人用它了解同类问题此前是怎么处理的。记录的价值不在篇幅，而在于每个关键动作都能找到对应的输入和确认人。
本文示例采用虚构设定：一个名为“示例团队”的研发小组，使用一套虚构的缺陷管理系统，处理一张虚构缺陷单。文中所有人名、编号、时间均为演示用途，标注为“示例”，不代表任何真实客户实践，也不附带量化成效。读者可以把它当作填写模板的参照，替换成自己团队的真实信息。
记录范围限定在“AI驱动执行”这一层：AI读取输入、给出判断或建议、经人工确认后产生动作。确定性规则自动化的流程配置（例如按固定条件自动流转状态）、接口连接与开放接口扩展开发，属于其他主题，本文不展开。这样界定是为了让记录聚焦在“AI判断+人工确认”这条链路上，避免把普通自动化日志混进来。
完整示例：一次AI辅助缺陷分诊的执行记录
示例情景：示例团队的测试人员在回归测试中发现一张缺陷单，现象是“订单列表页在筛选条件为空时偶发加载超时”。缺陷单进入待分诊队列后，AI分诊助手读取缺陷描述、历史相似缺陷和当前版本变更记录，给出严重程度与归属模块的建议，由模块负责人确认后执行分派。以下是这次执行的完整记录。
| 字段 | 填写内容（示例） |
|---|---|
| 记录编号 | EXE-2025-0317-014（示例编号） |
| 触发来源 | 缺陷单 BUG-1042 进入“待分诊”状态，由状态变更自动触发AI分诊助手（示例） |
| 触发时间 | 2025-03-17 10:12（示例时间） |
| AI输入 | 缺陷标题与描述、复现步骤、影响版本号、近30天同模块相似缺陷3条、本版本订单模块变更记录2条 |
| AI输出与建议 | 建议严重程度：中；建议归属模块：订单查询服务；建议处理人：订单模块值班负责人；附相似缺陷 BUG-0987 的处理结论作为参考 |
| 置信与依据 | 置信度：中。依据：现象与 BUG-0987 高度相似（同为筛选条件为空时超时）；但本次仅偶发，缺少稳定复现步骤，影响面尚不明确 |
| 人工确认 | 确认人：订单模块负责人（示例角色）；确认时间：2025-03-17 10:40；确认结论：采纳模块归属，严重程度由“中”上调为“高”，理由是该问题影响下单主链路 |
| 执行动作 | 将缺陷单严重程度字段改为“高”，归属模块设为“订单查询服务”，分派给值班负责人，并在评论中附上本记录编号 |
| 结果状态 | 已完成。缺陷单进入“处理中”，分派成功 |
| 失败与回退 | 无。首次执行即成功；若分派对象不存在，记录中应写明回退到人工指定处理人 |
| 复盘备注 | AI对“偶发”类缺陷的严重程度上调偏保守，建议在分诊规则中补充“影响主链路则至少定为高”的提示；相似缺陷检索有效，可保留 |
这条记录的时间线是：10:12 状态变更触发AI执行，10:13 AI完成建议输出，10:40 人工确认并修改严重程度，10:41 系统执行字段更新与分派，随后记录归档并回写到缺陷单评论。状态变化依次为“待分诊→AI建议已生成→待人工确认→已确认→处理中”。把状态节点写进记录，是为了让复核人一眼看出人工确认发生在执行之前，而不是事后补签。
记录落到工作项与文档中流转时，ONES 可以把缺陷单、评审意见与执行记录放在同一工作项下，确认动作以字段变更和评论留痕，记录随工作项状态推进而保留，便于后续按记录编号回溯。这一衔接只解决“记录存在哪里、如何随状态交接”，不改变记录本身的字段设计。
逐项解释：每个字段为什么这样填
记录字段可以分成两类作用：一类承担追溯，回答“当时发生了什么”；一类承担复核，回答“当时的判断站不站得住”。填写时先保证追溯字段完整，再让复核字段说清理由。
触发与输入：记录AI看到了什么
触发来源要写到“什么事件、由什么机制触发”，例如“缺陷单进入待分诊状态，由状态变更触发”。只写“AI自动执行”无法回答是谁发起的。AI输入字段列的是AI实际读取的材料清单，包括缺陷描述、相似缺陷、变更记录等。填写要点是列全但不粘贴全文，用“材料名称+范围”表达，例如“近30天同模块相似缺陷3条”。输入清单决定了建议的可解释性：复核人看到输入里缺少稳定复现步骤，就能理解为什么置信度只给到“中”。
判断依据与置信说明：表达建议的来源与不确定度
这一组字段是记录里最容易被写空的地方。常见填法是只写“AI建议严重程度为中”，复核时无从判断。示例中的写法包含三层：结论（建议为中）、依据（与历史缺陷相似、缺少复现步骤）、不确定点（偶发、影响面不明）。置信度用“高/中/低”加一句理由即可，不必追求精确数值。依据要指向具体材料，例如引用相似缺陷编号，而不是笼统写“根据历史数据”。
人工确认：确认人、时点与修改内容
人工确认字段承担复核作用的核心。需要写清三件事：谁确认、什么时候确认、确认时改了什么。示例中负责人采纳了模块归属，但把严重程度从“中”上调为“高”，并给出理由“影响下单主链路”。这条修改记录比“已确认”三个字有价值得多，它说明人工判断在哪些点上覆盖了AI建议，后续复盘AI建议质量时可以直接对照。确认时点要早于执行动作时点，顺序在记录中应能看出来。
执行动作与结果：动作、对象、状态、失败与回退
执行动作要写成“对什么对象做了什么变更”，例如“严重程度字段改为高、归属模块设为订单查询服务、分派给值班负责人”。结果状态用有限枚举，如“已完成/部分完成/失败/已回退”，并说明对象当前所处状态。失败与回退字段即使本次为空也要保留，写明“无”或写明回退路径，例如“分派对象不存在时回退到人工指定处理人”。保留这个字段的意义在于：出问题时团队知道当时设计了什么兜底方案。
复盘备注：可复用经验与待改进点
复盘备注不是必填的感想栏，而是把本次执行中可迁移的经验和暴露的问题写下来。示例中写了两条：AI对偶发缺陷的严重程度上调偏保守，建议补充规则；相似缺陷检索有效，可保留。前者指向规则改进，后者指向保留有效做法。填写时尽量一条备注对应一个具体动作或判断，避免写成“整体效果不错”这类无法执行的结论。
可迁移规律：换到需求评审、发布检查怎么记
把示例拆开看，记录结构有一条稳定骨架：触发—输入—建议—确认—动作—结果—复盘。这七个环节对应七个问题：谁发起、AI看了什么、AI给出什么、谁拍板、做了什么、结果如何、下次怎么改。换场景时骨架不变，变的是每个环节里填什么材料、由谁确认。
| 环节 | 缺陷分诊示例 | 需求评审场景 | 发布检查场景 |
|---|---|---|---|
| 触发 | 缺陷单进入待分诊 | 需求单提交评审 | 发布单进入待检查 |
| 输入 | 缺陷描述、相似缺陷、变更记录 | 需求文档、历史同类需求、相关接口说明 | 变更清单、测试报告、回滚预案 |
| 建议 | 严重程度与归属模块 | 完整性、冲突点与影响范围提示 | 检查项通过情况与风险提示 |
| 确认 | 模块负责人 | 产品负责人与相关研发 | 发布负责人 |
| 动作 | 改字段、分派 | 标注评审意见、退回补充 | 放行或挂起发布 |
| 结果 | 进入处理中 | 评审通过或待补充 | 发布继续或暂停 |
| 复盘 | 规则调整建议 | 需求模板改进点 | 检查项遗漏与补充 |
场景适配时，字段取舍遵循两条原则。第一，凡是影响后续动作的输入必须列全，例如发布检查中的回滚预案，缺了它复核人无法判断放行是否稳妥。第二，确认人必须是有权改变结果的角色，需求评审里由产品负责人确认影响范围，发布检查里由发布负责人确认放行，记录才有约束力。可以增补的字段包括“关联记录编号”（同一需求多次AI执行时串联）和“超时处理”（确认迟迟未发生时如何升级）。
记录粒度与留存周期按风险定。影响主链路、涉及对外发布的执行，记录写到字段级变更并长期留存；日常低风险分诊可以只保留建议、确认人与结果三项，留存一个迭代周期。判断标准是：如果三个月后有人质疑这次执行，现有记录能否支撑一次复核。能支撑就够，不必为每条记录写成长文。
适用边界：哪些情况这份记录不适用
这份示例是演示情景，用于说明字段怎么填、骨架怎么迁移。它不代表任何真实客户的实践，也不构成对AI建议准确率或流程效率的证明。读者参照填写时，应替换为团队自己的角色、系统和编号，并明确标注哪些内容是示例。
以下情形不适合直接套用这份记录：
- 确定性规则自动化：按固定条件自动流转状态、自动关闭工单等，执行过程由规则配置决定，记录重点在规则版本与命中日志，归属其他主题。
- 接口连接与扩展开发：涉及系统间数据同步、开放接口调用的执行，记录重点在调用参数与返回结果，同样不在本文范围。
- 需要合规审计的场景：如果组织对AI参与决策有审计要求，记录字段、留存期限和访问权限需按实际制度另行确认，本文示例不构成合规依据。
- AI建议质量评估：本文只记录单次执行，不提供准确率统计方法；要评估AI建议质量，需要基于多条记录做对照分析。
使用前还需确认两个前提：团队已明确每个环节的确认人角色，且执行动作能在系统中留痕。缺少这两点，记录容易退化为事后补写的说明文档。满足前提后，从一条真实执行开始试填，再根据复核时实际用到的字段逐步精简，比一次性设计完整模板更稳妥。
常见问题
AI流程执行记录和普通的操作日志有什么区别？
操作日志记录系统发生了什么，例如字段被改、状态被流转；AI流程执行记录还要回答为什么这样改。它需要保留AI读取了哪些材料、给出了什么建议、置信度如何、人工确认时改了什么以及理由。两者可以并存：日志提供事实底稿，执行记录提供判断依据。如果团队已有完善的操作日志，执行记录可以只补充输入清单、建议依据和人工确认理由这几项，不必重复记录系统已自动留痕的字段变更。
人工确认环节经常变成走过场，记录上怎么体现确认是有效的？
有效的确认在记录上通常有两个特征：确认人有权改变结果，且确认内容包含对AI建议的取舍。填写时要求确认字段写清三件事——谁确认、何时确认、改了什么及理由。示例中负责人采纳了模块归属、把严重程度上调为高并说明“影响下单主链路”，这类修改痕迹说明人工判断真实介入了。若确认长期只写“已确认”而无修改，可以抽查几条记录回问确认人当时的判断依据，判断确认是否流于形式，再决定是否调整确认人角色或确认时点。
低风险场景也要按完整字段填写吗？记录粒度怎么定？
不必。记录粒度按风险定：影响主链路、涉及对外发布的执行，写到字段级变更并长期留存；日常低风险分诊可以只保留建议、确认人与结果三项，留存一个迭代周期。判断标准是设想三个月后有人质疑这次执行，现有记录能否支撑一次复核。能支撑就够。团队可以先从完整字段试填几条，再根据复核时实际用到的字段逐步精简，比一开始就设计精简版更稳妥。
同一张单子被AI多次执行，记录怎么组织才不混乱？
建议为每次执行单独生成记录编号，并在记录中增加“关联记录编号”字段，把同一工作项下的多次执行串联起来。这样复核时既能看单次执行的输入与确认，也能看到整条处理链路上AI介入了几次、每次结论是否一致。如果多次执行结论出现冲突，冲突本身也是复盘材料，应在复盘备注中写明以哪次确认为准及原因。记录归档时按工作项聚合展示，比按时间平铺更便于回溯。
参照这份示例落地时，最容易出问题的地方是什么？
常见问题有三个：一是输入字段只写“AI自动分析”，复核人无法判断建议的可解释性；二是置信与依据写空，只留结论；三是失败与回退字段被删掉，出问题时不知道当时设计了什么兜底。落地前还需确认两个前提：每个环节的确认人角色已明确，执行动作能在系统中留痕。缺少这两点，记录容易退化为事后补写的说明文档。建议从一条真实执行开始试填，跑完一次复核再调整模板。
