AI流程执行记录要能回答四个问题：谁或什么触发了这次执行、AI按什么步骤做了什么、哪些节点需要人工确认、异常时如何处置和留痕。下面给出一份演示情景下的完整填写样例，覆盖从自然语言触发、多步骤编排、跨对象写入到人工确认与异常回退的全过程，并逐字段说明填写理由，方便你对照改成自己流程的记录。
要点总览（TL;DR）
- AI流程执行记录按“触发—步骤—确认—异常—结果”五段组织，每段保留原始输入与解析/执行结果两栏，事后可逐项回溯。
- 触发段并列保留原始指令与解析出的意图、对象、范围，用于判断AI理解是否偏离原意。
- 步骤段写清每步的输入对象与输出对象，异常时才能准确圈定检查与回退范围。
- 换流程时五段骨架不变，替换对象类型、确认角色与异常类型即可迁移；确定性规则自动化与接口连接配置不套用此结构。
示例目标：这份记录要留下什么
这份示例演示的是一份“可回溯”的执行记录：事后任何人拿到它，都能还原这次AI执行的全貌，判断结果是否可信、责任落在哪里。它围绕四个问题组织字段：触发来源（谁在什么上下文下发出了什么指令）、执行步骤（AI按什么顺序做了什么、每步读写哪些对象）、人工确认（哪些节点必须由人拍板、依据是什么）、异常处置（哪一步失败、错误信息是什么、如何回退或补救）。
示例覆盖的流程范围是一次需求变更：从一句自然语言指令开始，经多步骤编排，向需求、任务、文档等多个对象写入内容，中途设置人工确认点，并包含一次失败步骤的回退处理，最终落到可查的状态与留痕位置。需要说明的是，本文为演示情景，指令、对象名称、人员角色均为虚构，用于展示填写方法，不代表任何真实客户案例，也不附带实测效果或量化收益。
记录字段可按五段骨架总览如下，后文完整示例即按此顺序展开：
| 段落 | 核心字段 | 回答的问题 |
|---|---|---|
| 触发 | 原始指令、触发人、触发时间、解析出的意图/对象/范围 | 这次执行为什么发生 |
| 步骤 | 步骤序号、动作、输入对象、输出对象、执行状态 | AI做了什么、按什么顺序 |
| 确认 | 确认点、确认人、确认依据、确认结论 | 哪些节点由人拍板 |
| 异常 | 失败步骤、错误信息、处置动作、回退结果 | 出问题时怎么处理 |
| 结果 | 最终状态、耗时口径、留痕位置 | 收尾落在哪里、怎么查 |
完整示例：一次需求变更的AI流程执行记录
以下为一份已填写的记录样例，五段齐全、前后自洽。为便于阅读，用表格承载字段与内容，实际填写时可放在同一份文档或工作项描述中。
触发段
| 字段 | 填写内容 |
|---|---|
| 原始指令 | “把‘登录页支持手机号验证码登录’这条需求的范围改成只做国内手机号，拆成开发任务分配给后端组，并在需求文档里补一段变更说明。” |
| 触发人 / 时间 | 产品负责人 李某 / 2025-03-11 10:20 |
| 解析意图 | 修改需求范围 + 拆解任务 + 分配负责人 + 更新文档 |
| 解析对象 | 需求“登录页支持手机号验证码登录”；关联需求文档页 |
| 解析范围 | 仅限国内手机号；任务归属后端组；文档追加变更说明，不改动原有章节 |
编排段
| 步骤 | 动作 | 输入对象 | 输出对象 |
|---|---|---|---|
| 1 | 读取需求当前内容与关联文档 | 需求条目、需求文档页 | 上下文摘要 |
| 2 | 修改需求范围描述 | 需求条目 | 更新后的需求条目 |
| 3 | 拆解为开发任务并分配 | 更新后的需求条目 | 3条开发任务（负责人：后端组） |
| 4 | 在文档追加变更说明 | 需求文档页、变更要点 | 更新后的文档页 |
执行段
| 步骤 | 执行动作与状态变化 | 状态 |
|---|---|---|
| 1 | 读取需求与文档，生成上下文摘要 | 成功 |
| 2 | 需求范围字段由“国内外手机号”改为“国内手机号”，状态保持“进行中” | 成功 |
| 3 | 生成3条开发任务并写入负责人字段，任务状态为“待开始” | 成功 |
| 4 | 向文档追加“变更说明”段落 | 失败（见异常段） |
人工确认段
| 确认点 | 确认人 | 确认依据 | 结论 |
|---|---|---|---|
| 需求范围修改（步骤2后） | 产品负责人 李某 | 变更后的范围描述与原始指令一致 | 通过 |
| 任务拆解与分配（步骤3后） | 后端组长 王某 | 3条任务覆盖需求要点、负责人正确 | 通过 |
异常段
| 字段 | 填写内容 |
|---|---|
| 失败步骤 | 步骤4 文档追加 |
| 错误信息 | 目标文档页处于锁定状态，写入被拒绝 |
| 处置动作 | 暂停后续写入，通知文档负责人解锁；解锁后重试追加 |
| 回退结果 | 步骤1–3结果保留；步骤4重试成功，文档追加完成 |
结果段
| 字段 | 填写内容 |
|---|---|
| 最终状态 | 需求已更新、3条任务已创建并分配、文档已追加变更说明 |
| 耗时口径 | 从触发到全部完成，含人工确认等待时间；具体数值按系统记录填写 |
| 留痕位置 | 需求条目变更历史、任务创建记录、文档版本历史 |
逐项解释：每个字段为什么这样填
字段填得对不对，取决于它能否支撑事后回溯。下面挑出容易出错的关键字段，说明填写依据与常见填法差异。
触发段为何保留“原始指令”与“解析结果”两栏
原始指令是判断AI是否理解正确的唯一基准。只写解析结果，事后无法区分“AI理解偏了”还是“人本来就这么说”。两栏并列，一旦结果与预期不符，可以直接比对是解析环节出错还是指令本身有歧义。常见错误是只留一句概括，导致争议时无从核对。
步骤记录为何要写清输入对象与输出对象
输入输出对象决定了这次执行的影响面。写清“读了什么、写了什么”，才能在出问题时准确圈定需要检查或回退的范围。只写动作（如“拆解任务”）而不写对象，等于没有留下可追溯的边界。填写时注意对象用可定位的名称，避免“相关文档”这类模糊表述。
人工确认点如何标注责任人与确认依据
确认段的价值在于责任可查。每个确认点要写清三件事：在哪一步之后确认、由谁确认、依据什么判断通过。依据要具体到可核对的材料（如“范围描述与指令一致”），而非“已确认”三个字。常见错误是把确认人和执行人混为一谈，或只记录结论不记录依据。
异常记录为何要保留错误信息与处置动作
错误信息是复现和排查的线索，处置动作是判断影响是否收敛的依据。两者缺一，异常段就退化成一句“出错了”。填写时保留系统返回的原始错误描述，处置动作写清是重试、跳过还是回退，以及回退后哪些步骤结果仍然有效。
状态字段与时间字段的口径说明
状态字段要区分“执行状态”（成功/失败/待确认）与“业务对象状态”（如需求“进行中”、任务“待开始”），两者不要混填。时间字段需注明口径：是纯执行耗时，还是含人工确认等待的总时长。口径不写清，不同记录之间无法比较。
| 字段 | 推荐填法 | 常见错误填法 |
|---|---|---|
| 原始指令 | 保留原话 | 只写概括结论 |
| 输入/输出对象 | 可定位的具体对象名 | “相关文档”等模糊表述 |
| 确认依据 | 可核对的具体材料 | 只写“已确认” |
| 错误信息 | 系统原始错误描述 | “出错了” |
| 耗时 | 注明是否含确认等待 | 不写口径直接填数 |
可迁移规律：换一个流程怎么改这份记录
这份记录的可复用部分在骨架，不在具体内容。换流程时，五段结构保持不变，替换的是每段里的对象类型、角色和异常类型。
- 固定骨架：触发、步骤、确认、异常、结果五段始终保留，每段都维持“原始输入 + 解析/执行结果”的双栏对照。
- 替换对象类型：需求变更换成缺陷处理、发布准备或测试用例评审时，输入输出对象相应改为缺陷、发布单、用例等，字段结构不变。
- 替换确认角色：确认人随流程调整，如缺陷流程由测试负责人确认、发布流程由发布经理确认，确认依据仍要具体到可核对材料。
- 替换异常类型：文档锁定、权限不足、对象不存在等错误类型按实际流程替换，处置动作仍写清重试、跳过或回退。
步骤粒度需要按流程复杂度取舍：步骤越多、跨对象写入越多，记录越要细；单一对象内的简单操作可以合并步骤，但输入输出对象仍要写清。记录与工作项、文档状态联动时，建议把留痕位置直接指向对象自身的变更历史或版本记录，让记录与业务对象互相印证，而不是另建一份孤立台账。
当执行记录需要落到具体的工作项与文档状态上时，ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，把自然语言指令转化为 ONES 中可追踪的工作，并将结果保存为工作项、Wiki 页面等内容。其 AI 能力基于 ONES 权限体系执行，输出过程可追踪、结果可审计，便于把上述触发、执行与留痕对应到实际对象上。人工确认节点的具体配置方式与异常回退能力，需以产品实际配置为准。
适用边界：哪些情况不适合这样记录
这套记录方法适用于“AI参与判断与多步骤执行、结果需要人确认”的流程。以下情形需要区别对待：
- 确定性规则自动化：由固定规则触发的自动流转（如状态机自动推进），执行路径确定、无需AI判断，用系统日志即可，不必套用本记录的五段结构。
- 接口连接与集成配置：MCP 接口连接、扩展开发等配置类工作属于搭建环节，其变更管理另有方式，不在本文记录范围内。
- 高风险不可逆动作：删除、批量覆盖、对外发布等动作一旦执行难以撤回，需要更严格的确认层级与更完整的留痕，本文示例的确认强度不足以覆盖。
- 记录详细度与团队能力匹配：字段过细会加重填写负担，若团队难以持续维护，可先保留触发、步骤、结果三段，待流程稳定后再补确认与异常段。
判断是否套用，可以问一句：这次执行是否需要人事后判断“AI做得对不对、责任在谁”。需要，就按五段记录；只是系统按规则自动完成、结果确定，则用常规日志即可。
常见问题
AI流程执行记录和系统运行日志有什么区别？
系统日志记录的是系统层面的调用与状态变化，适合排查技术故障。AI流程执行记录面向业务回溯，重点回答四件事：谁在什么上下文下发出指令、AI按什么步骤读写哪些业务对象、哪些节点由人确认、异常如何处置。两者可以互相印证，但记录的对象是业务动作与责任，日志的对象是系统事件。若流程由固定规则自动推进、执行路径确定，用常规日志即可，不必套用五段结构。
团队刚开始用AI执行流程，记录字段可以精简吗？
可以。字段过细会加重填写负担，若团队暂时难以持续维护，可先保留触发、步骤、结果三段，把“谁触发、做了什么、最终落到哪里”记清楚；待流程稳定、出现需要追责或复盘的场景后，再补上确认段与异常段。精简时仍建议保留原始指令原话和输入输出对象名称，这两项是后续补全记录的基础。
人工确认点应该设在哪一步之后？
判断依据是这一步的结果是否影响后续动作的正确性，以及出错后能否低成本撤回。示例中需求范围修改完成后设确认点，因为后续任务拆解依赖修改后的范围；任务分配完成后由组长确认，因为分配结果直接影响执行。涉及删除、批量覆盖、对外发布等难以撤回的动作，确认层级应更高，确认依据也要更具体。确认人与执行人应分开记录，避免责任混淆。
执行中途失败，已经完成的步骤要全部回退吗？
不一定。先判断已完成步骤的结果是否仍然有效、是否被失败步骤依赖。示例中文档追加失败，前三步的需求修改与任务创建结果有效，因此保留并只对失败步骤重试。若失败步骤的输入依赖前序结果且前序结果本身有误，则需要回退到出错点之前。记录中要写清保留了哪些步骤结果、回退了哪些，以及重试后的最终状态，避免事后误判影响范围。
在ONES中执行这类流程，记录能自动留痕吗？
ONES Assistant 可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，把自然语言指令转化为 ONES 中可追踪的工作，并将结果保存为工作项、Wiki 页面等内容；其 AI 能力基于 ONES 权限体系执行，输出过程可追踪、结果可审计。需求变更历史、任务创建记录、文档版本历史可作为留痕位置。是否提供固定的执行记录字段模板、人工确认节点如何配置，需以产品实际配置为准。
