AI流程执行确认要回答的是“这次执行凭什么发生、依据什么判断、由谁放行”。可操作的答案是固定四类依据：触发依据、输入依据、判定依据和处置依据，并用同一执行ID串联成确认链。本文按流程体系建设思路，给出定义表、操作步骤、角色分工、填写示例和合格检查清单，适用于需要对AI执行留痕的研发流程；确定性规则自动化的配置方法不在本文展开。确认链的留存与流转可借助ONES的工作项、文档和状态记录承载。
要点总览（TL;DR）
- AI流程执行确认需要四类依据：触发依据说明执行由哪个事件、规则或人工指令发起；输入依据记录AI读取的对象与版本；判定依据留存输出、置信度与引用条目；处置依据记录复核意见、审批结论与回退动作。
- 四类依据按同一执行ID串联，采集时点从执行启动前延伸到处置完成后，缺任何一类都会让确认链断开。
- 确认链按五步执行：定义需确认的执行范围、执行前登记触发与输入快照、执行中采集判定依据、执行后完成复核与处置、归档并关联执行ID。
- 高风险执行由审批或质量角色放行，复核人与发起人应分离；归档责任人只做完整性检查，缺项退回补录而非自行补写。
- 合格判定看四类依据是否齐全、输入能否还原、判定是否可解释、高风险是否有人工放行；阻断项缺失时执行结果不得进入下游。
确认一次AI流程执行，先固定哪四类依据
确认依据的作用是让一次AI执行在事后可以被还原：为什么启动、读了什么、得出什么结论、人做了什么处置。四类依据分别对应这四个问题，采集时点从触发前延伸到处置完成后，缺任何一类都会让确认链断开。
| 依据类型 | 包含内容 | 采集时点 | 责任角色 | 存放位置 |
|---|---|---|---|---|
| 触发依据 | 触发事件（如变更单提交、缺陷状态变化）、命中的规则编号与版本、人工指令原文及下达人、触发时间 | 执行启动前 | 流程发起人 | 执行记录首段或关联工作项的触发字段 |
| 输入依据 | AI读取的需求、代码提交、工单、文档等对象清单，每个对象的版本号或快照标识，读取时间 | 执行启动时，读取动作发生时同步留存 | AI执行方或平台管理员 | 附件、快照库或文档版本记录 |
| 判定依据 | 模型输出全文、规则命中结果、置信度或评分、引用的上下文条目及其来源位置 | 执行过程中，输出生成时即记录 | AI执行方或平台管理员 | 执行记录正文，引用条目单独列示 |
| 处置依据 | 人工复核意见、审批结论（放行、驳回、附条件放行）、回退或补救动作及执行结果 | 执行后复核与审批环节 | 业务复核人、审批或质量角色 | 复核记录、审批意见字段、补救工作项 |
四类依据通过执行ID关联。执行ID在一次AI执行启动时生成，触发记录、输入快照、判定输出和处置意见都写入同一ID之下，后续检索、复盘和审计都以这个ID为入口。执行ID的编码规则应包含日期与来源系统标识，便于人工识别，例如“AI-20250612-CHG-0031”这类结构，具体格式由团队自定。
从触发到归档：确认链的操作步骤
把四类依据落成流程，关键是每一步都有明确的输入、动作、输出和完成标志。以下五步构成一条完整确认链，团队可按风险等级裁剪复核强度，但步骤顺序不宜颠倒。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、定义需确认的AI执行范围 | 现有AI执行清单、业务影响评估 | 按影响面分级：涉及需求变更、发布、对外交付或不可逆操作的执行列为高风险，必须人工放行；仅生成草稿、建议类输出列为低风险，可事后抽检 | 分级触发条件表 | 每类AI执行都能对应到一个风险等级和确认方式 |
| 二、执行前登记触发与输入快照 | 触发事件或人工指令、待读取的数据对象 | 生成执行ID，记录触发来源与规则版本，对读取对象做版本快照或记录版本号 | 触发记录与输入清单 | 执行ID已生成，输入对象均可按记录还原到当时版本 |
| 三、执行中采集判定依据 | 输入快照、模型或规则配置版本 | 保存完整输出、置信度或评分，逐条列出引用的上下文及来源位置 | 判定记录 | 输出可读、引用可定位，置信度字段非空 |
| 四、执行后完成复核与处置记录 | 判定记录、分级触发条件 | 复核人解读输出并给出意见；高风险执行提交审批，记录放行或驳回结论；需要回退时登记补救动作 | 复核意见与审批结论 | 高风险执行有放行记录，处置动作有结果状态 |
| 五、归档并关联执行ID | 前四步全部记录 | 将四类依据归入同一执行ID，检查完整性后归档 | 完整证据包 | 按执行ID可一次调出全部四类依据 |
分级触发条件是整条链的起点，也是最容易被跳过的一步。建议以“输出被下游直接使用”和“动作不可逆”两条标准划线：输出进入下游流程或被外部使用的，必须人工放行；动作可撤销且影响局限在草稿层面的，可采用事后抽检。分级标准应写成文档并随流程变更同步更新，避免每次执行临时判断。
角色分工与各角色交付的证据
确认责任悬空通常表现为“记录有人写、结论没人签”。按证据类型分配责任，可以让每个角色清楚自己交付什么、什么算交付完成。下表为简化的责任矩阵，R表示负责执行，A表示最终把关，C表示需被咨询，I表示需被通知。
| 角色 | 触发依据 | 输入依据 | 判定依据 | 处置依据 | 归档完整性 |
|---|---|---|---|---|---|
| 流程发起人 | R | C | I | I | I |
| AI执行方或平台管理员 | I | R | R | C | C |
| 业务复核人 | I | C | A | R | I |
| 审批或质量角色 | I | I | C | A | I |
| 归档责任人 | C | C | C | C | R/A |
流程发起人对触发依据的完整性负责，需要写清触发来源和规则版本，不能只写“系统自动触发”。AI执行方或平台管理员负责输入快照与判定记录的留存，重点是快照可还原、引用可定位。业务复核人负责解读判定依据并给出处置意见，其意见应包含明确结论而非仅作描述。审批或质量角色只对高风险执行出具放行结论，放行记录需注明依据了哪些判定内容。归档责任人做最后一道完整性检查，发现缺项时退回补录，而不是自行补写。
角色可以由同一人兼任，但高风险执行中复核人与发起人应分离，避免自己触发、自己放行。团队规模较小时，可由质量角色兼任归档检查，但检查动作仍需留下记录。
示例：一次需求变更类AI执行的确认记录
以下为演示情景，用于说明四类依据如何填写，不代表真实客户案例。场景设定：某需求变更单提交后，AI根据变更单内容生成影响分析，并触发下游测试与发布流程的准备动作。
触发依据。执行ID：AI-20250612-CHG-0031。触发事件为变更单CHG-118状态由“评审中”变为“已批准”，命中规则“需求变更影响分析-规则v2.3”，触发时间2025年6月12日10时15分，发起人为需求负责人李某。
输入依据。AI读取的对象包括：变更单CHG-118（版本3）、关联需求REQ-204与REQ-211（读取时版本分别为v7、v4）、受影响模块的代码仓库提交记录（截至提交哈希a3f9c2）、测试用例集TC-SET-08（版本12）。每个对象均记录版本号或快照标识，快照存放于执行记录附件。
判定依据。模型输出结论为“本次变更影响2个需求、3个测试用例集和1个发布窗口”，置信度0.82；引用条目列出变更单第4节验收标准、REQ-211的接口定义段落和TC-SET-08中用例编号TC-1187至TC-1192。引用条目均标注来源位置，便于复核人逐条核对。
处置依据。业务复核人王某核对引用条目后给出意见：“影响范围判断成立，但发布窗口需与运维确认”，结论为附条件放行；审批角色张某于当日14时确认条件已满足并放行。回退动作登记为“若测试用例补充后影响范围扩大，撤回下游准备动作并重新执行分析”，当前状态为未触发。
归档结果。四类依据归入执行ID AI-20250612-CHG-0031，按该ID可依次调出触发记录、输入快照清单、判定输出与引用条目、复核与审批意见。后续复盘时，以该ID检索即可还原整条确认链。
完成检查：确认依据是否合格的判定标准
判断一次确认是否真正完成，不看记录篇幅，而看能否通过以下检查项。任一带阻断标记的检查项不通过，该次执行应视为确认未完成，不得进入下游或需暂停后续动作。
| 检查项 | 合格标准 | 是否阻断 |
|---|---|---|
| 四类依据齐全 | 触发、输入、判定、处置四类记录均存在，且指向同一执行ID | 阻断 |
| 输入可还原 | 每个读取对象有版本号或快照，能还原到执行时点的内容 | 阻断 |
| 判定可解释 | 输出完整，引用条目可定位到具体来源位置，置信度或评分有记录 | 阻断 |
| 高风险有人工放行 | 按分级条件属于高风险的执行，有审批角色的放行结论及时间 | 阻断 |
| 处置有结论 | 复核意见包含明确结论，回退或补救动作有状态 | 阻断 |
| 归档可检索 | 按执行ID能一次调出全部依据，归档时间与责任人可查 | 不阻断，限期补录 |
缺失依据时的处理规则应事先约定：阻断项缺失时，执行结果不得被下游直接使用，需补录后重新提交复核；非阻断项缺失时，允许在约定时限内补录，超期未补录的转为阻断并通知归档责任人。补录记录需注明补录人和补录原因，与原始记录区分，避免事后修改被误认为原始证据。
把确认依据沉淀到研发管理工具中
确认链要长期可用，需要落到团队日常使用的工具里，让证据随执行自然产生，而不是事后另建台账。承载方式可以按四个层次设计：单次AI执行对应一个工作项，工作项状态反映确认进度；输入快照与判定输出作为文档或附件挂在工作项下；复核与审批通过状态变更和意见字段留下痕迹；检索与复盘以执行ID为入口。
ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把自然语言指令转化为 ONES 中可追踪的工作，执行结果可保存为工作项、Wiki 页面等内容。这一特点适合承载确认链中的记录动作：AI执行产生的输出可以直接沉淀为工作项或文档，减少另行转录。ONES 的 AI 研发管理方案基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，为复核与追溯提供基础。
具体落地时，可将执行ID写入工作项标题或自定义字段，触发依据记录在工作项描述，输入快照与判定输出作为附件或关联 Wiki 页面留存，复核意见和审批结论通过状态流转与评论记录。需要说明的是，执行级确认节点、按执行ID导出完整证据包等具体能力，应结合团队实际版本向厂商核实后再确定实现方式；本文给出的四类依据与检查清单属于通用方法，可独立于工具先行建立。
常见问题
低风险的AI执行是否也要走完整的四步确认？
不必按同一强度执行。分级触发条件的作用就是区分确认方式：输出进入下游流程或被外部使用、动作不可逆的执行列为高风险，必须人工放行；仅生成草稿或建议类输出的执行可事后抽检。抽检仍需保留触发依据、输入快照和判定记录，只是处置环节由逐次复核改为按比例抽查，抽查结论同样要留下记录。
执行ID应该由谁生成，编码需要包含哪些信息？
执行ID在AI执行启动时生成，通常由触发环节的系统或平台管理员负责，流程发起人确认其已写入记录。编码建议包含日期与来源系统标识，便于人工识别和按时间检索，例如“AI-20250612-CHG-0031”这类结构。具体格式由团队自定，关键是全团队统一，且同一执行ID下能调出全部四类依据。
复核人发现判定依据的引用条目对不上，应该怎么处理？
这属于判定依据不合格，应作为阻断项处理：执行结果暂停进入下游，由AI执行方或平台管理员核对引用条目与来源位置，确认是引用错误还是输入快照与执行时点不一致。修正后重新提交复核，修正过程需注明修改人和原因，与原始记录区分。若问题源于输入快照缺失，则回到输入依据环节补录，不能只在判定记录上改结论。
确认记录事后补录，还算不算有效证据？
补录可以存在，但要与原始记录区分。非阻断项缺失时允许在约定时限内补录，补录记录需注明补录人和补录原因；超期未补录的转为阻断并通知归档责任人。阻断项缺失时，执行结果不得被下游直接使用，需补录后重新提交复核。事后修改若与原始记录混在一起，会让复盘时无法判断哪些是执行当时的证据，因此补录痕迹必须单独保留。
用ONES承载确认链时，哪些能力已有官方说明，哪些需要向厂商核实？
依据ONES官方页面资料，ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把自然语言指令转化为 ONES 中可追踪的工作，执行结果可保存为工作项、Wiki 页面等内容；ONES 的 AI 研发管理方案基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计。
执行级确认节点、按执行ID导出完整证据包、可用版本与部署方式等，资料未提及，应结合团队实际版本向厂商核实后再确定实现方式。四类依据与检查清单属于通用方法，可独立于工具先行建立。
