用自然语言触发研发流程，要解决的是把一句口语化指令稳定转换为可执行、可确认、可追溯的研发动作。本文按四层设计展开：动作清单、任务编排、人工确认、异常与回执，并给出试点验证方法。范围聚焦 AI 驱动的执行机制，确定性规则自动化与接口协议实现不在本文展开。
要点总览（TL;DR）
- 先建立自然语言触发动作清单，按高频、输入可结构化、对象可定位三个特征筛选动作，并标注风险等级与确认要求。
- 把一句话拆成多步骤任务时，显式抽取意图、对象、参数、时间与范围，用顺序、条件分支、并行三类依赖描述编排，并写明失败处理路径。
- 人工确认按风险分级设置：低风险免确认，中风险执行前由发起人确认，高风险在结果提交前由模块负责人或审批人确认，确认记录留存为审计证据。
- 执行异常按解析歧义、对象不存在、权限不足、执行中断、结果不一致五类分别处置，每次触发都生成含触发原文与各步状态的执行回执，重复触发做幂等处理。
- 试点选 3–5 个高频低中风险动作，周期 4–6 周，用触发成功率、确认通过率、异常率、平均处理时长验证，高风险动作绕过确认时暂缓推广。
先定清楚：哪些研发动作适合用自然语言触发
动作筛选是整套机制的起点。判断一个研发环节是否值得接入自然语言触发，可以看三个特征是否同时成立：发生频率高，输入信息能被结构化描述，作用对象在系统中唯一可定位。例如“给某个需求补充验收标准”“把某条缺陷指派给模块负责人”“为某个版本创建提测任务”，这类动作每天重复、参数有限、对象明确，适合用一句话发起。反过来，需要复杂技术判断、跨多个系统强一致写入、或结果不可逆的操作，应先保留人工操作或走专门审批，不宜直接由自然语言指令驱动执行。
动作清单建议用表格维护，每个动作一行，字段固定，便于评审和后续扩展。下表给出字段结构与填写要求。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 动作名称 | 动词加对象，唯一且不与其他动作重名 | 创建提测任务 |
| 触发说法示例 | 列出 3–5 种真实说法，覆盖口语与简写 | “给 2.3 版本建提测任务” |
| 输入参数 | 必填与选填分开，标注类型和取值范围 | 版本号（必填）、提测范围（选填） |
| 作用对象 | 写明对象类型与定位方式 | 版本对象，按版本号定位 |
| 产出 | 执行后生成或变更的内容 | 一条提测任务及其关联关系 |
| 风险等级 | 低、中、高三级，按影响范围与可逆性判定 | 中 |
| 确认要求 | 无需确认、执行前确认、提交前确认 | 执行前确认 |
风险分级决定确认策略。低风险且可撤销的动作，如添加标签、补充备注，可以免确认直接执行；中风险动作，如创建任务、变更负责人，建议执行前由发起人确认一次；高风险或不可逆动作，如关闭版本、批量变更状态，应在结果提交前由模块负责人或审批人确认。分级规则要写进清单，避免每次靠临时判断。
把一句话拆成多步骤任务：编排规则怎么写
指令解析的第一步是抽取要素：意图对应动作清单中的哪个动作，对象指向哪个具体记录，参数填什么值，时间与范围限定在哪个区间。解析结果应显式列出，便于确认环节核对。例如“把 2.3 版本未关闭的缺陷转给张工并建一个跟踪任务”，意图是“转派缺陷并创建任务”，对象是版本 2.3 下的未关闭缺陷，参数是负责人张工，范围是未关闭状态。
多步骤编排需要表达三类依赖：顺序依赖，前一步产出是后一步输入；条件分支，按对象状态或参数取值走不同路径；并行步骤，彼此无依赖可同时执行。编排描述建议落到可评审的文档或配置中，字段包括步骤编号、动作、输入来源、依赖步骤、分支条件、失败处理方式。下表是编排说明模板的核心字段。
| 字段 | 说明 |
|---|---|
| 步骤编号 | 按执行顺序编号，并行步骤标注同组 |
| 动作 | 引用动作清单中的动作名称 |
| 输入来源 | 来自指令解析结果或前序步骤产出 |
| 依赖步骤 | 前置步骤编号，无条件依赖则留空 |
| 分支条件 | 触发条件与对应路径 |
| 失败处理 | 回退、暂停或转人工 |
跨对象写入要规定顺序与一致性要求。先写主对象再写关联对象，先创建后关联，避免出现孤立记录。涉及多个对象状态联动时，明确哪一步是提交点，提交点之前失败可整体回退，提交点之后失败则保留已完成部分并记录差异。步骤失败时的处理规则要提前写清：可重试的自动重试一次，参数缺失的暂停并提示补充，权限不足或对象不存在的转人工处理。编排文档需要经过流程负责人评审后才能上线，评审重点是依赖关系是否完整、失败路径是否覆盖。
人工确认放在哪里：确认点与角色分工
确认点的位置按动作风险和执行阶段确定。执行前确认适合中风险动作，让发起人在执行前核对解析结果；关键步骤间确认适合多步骤任务，在跨对象写入前设置检查点；结果提交前确认适合高风险或不可逆动作，由有权限的角色做最终把关。确认信息要展示三部分内容：将要执行的动作、影响的对象清单、变更前后的差异。差异展示比文字描述更有效，能让确认人快速判断是否符合预期。
| 风险等级 | 确认位置 | 确认角色 | 确认记录要求 |
|---|---|---|---|
| 低 | 无需确认 | — | 保留执行回执 |
| 中 | 执行前 | 发起人 | 记录确认人与时间 |
| 高 | 结果提交前 | 模块负责人或审批人 | 记录确认人、时间与差异快照 |
确认超时与拒绝要有明确处理。超时未确认的任务应暂停并通知发起人，不自动放行；确认被拒绝时，任务终止并记录拒绝原因，原始指令保留以便修改后重新发起。确认记录作为审计证据留存，内容包括确认人、确认时间、确认时的差异内容与最终选择。在任务编排与确认流转环节，ONES 的工作项状态流转与审批记录可以承载确认节点，让每次确认留下可查的操作记录，执行结果也能回写到对应工作项上。
执行异常怎么处理：状态、回执与追溯
异常处理的目标是让每次触发都有明确状态和责任人。常见异常分五类，处置方式不同。
| 异常类型 | 典型表现 | 处置动作 | 责任人 |
|---|---|---|---|
| 解析歧义 | 对象匹配到多条记录或参数缺失 | 暂停并列出候选，请发起人选择 | 发起人 |
| 对象不存在 | 版本号或记录已删除 | 终止并提示核对对象 | 发起人 |
| 权限不足 | 执行账号无写入权限 | 转人工处理并通知流程负责人 | 流程负责人 |
| 执行中断 | 步骤超时或系统异常 | 按编排规则重试或回退 | 系统运维 |
| 结果不一致 | 写入结果与预期不符 | 标记异常，保留现场供复盘 | 流程负责人 |
执行回执应包含触发原文、解析结果、执行步骤及每步状态、最终结果、操作人与时间。回执是追溯的基础，异常记录要与回执关联保存，定期复盘高频异常并修正动作清单或编排规则。重复触发需要幂等处理：同一指令在短时间内重复提交时，系统应识别并返回已有执行结果，避免重复创建任务或重复变更状态。幂等键可以用指令原文加对象标识加时间窗口构成。
一个完整示例：从一句话到流程落地
以下为演示情景，用于说明链路，不代表真实项目数据。指令原文：“把 2.3 版本还没关的缺陷转给张工，再建个跟踪任务提醒周五前处理。”
解析结果：意图为“转派缺陷并创建跟踪任务”；对象为版本 2.3 下状态未关闭的缺陷，共 6 条；参数为负责人张工、截止时间本周五；范围为版本 2.3。编排为三步：第一步查询并列出 6 条缺陷，第二步批量转派给张工，第三步创建跟踪任务并关联这 6 条缺陷。第二步依赖第一步的查询结果，第三步依赖第二步完成。风险等级判定为中，确认点设在执行前，确认人为发起人，确认信息展示 6 条缺陷的当前负责人与转派后负责人对比。
执行回执记录：触发原文、解析结果、三步执行状态均为成功、操作人与时间。异常分支演示：若第一步查询到 8 条缺陷而发起人只想转派其中 6 条，确认环节可取消勾选，编排按勾选结果执行；若第二步遇到某条缺陷已被关闭，该条跳过并在回执中标注“状态已变更，未转派”，其余正常执行。可迁移的规律是：先查询后写入、确认时展示差异、部分失败不阻断整体但逐条记录。
试点与完成检查：怎么判断这套机制跑通了
试点从动作清单中选 3–5 个高频、低到中风险的动作，覆盖创建、变更、查询三类，周期建议 4–6 周，覆盖一个完整迭代。试点期间记录每次触发的解析结果、确认情况与执行结果，作为指标计算依据。
| 指标 | 计算口径 | 观察重点 |
|---|---|---|
| 触发成功率 | 成功解析并进入执行的次数除以总触发次数 | 解析歧义集中在哪些说法 |
| 确认通过率 | 确认通过次数除以进入确认次数 | 差异展示是否足够清晰 |
| 异常率 | 异常次数除以执行次数，按异常类型分列 | 哪类异常反复出现 |
| 平均处理时长 | 从触发到回执完成的平均时间 | 与人工操作对比的改善幅度 |
上线完成检查清单：动作清单字段完整且经过评审；每个动作的编排说明可评审、失败路径已覆盖；高风险动作全部设置确认点且确认角色明确；每类异常有处置动作和责任人；回执字段齐全、记录可追溯；重复触发有幂等处理。推广准入条件为试点期内触发成功率与确认通过率达到团队设定阈值、无高风险动作绕过确认的记录。若异常率集中在解析环节或确认环节频繁被拒绝，应暂缓推广，先修正动作清单中的触发说法示例与确认信息展示，再进入下一轮试点。
常见问题
动作清单建好后，新增一个动作要走什么流程？
新增动作建议沿用清单评审机制：先按动作名称、触发说法示例、输入参数、作用对象、产出、风险等级、确认要求七个字段填写完整，再由流程负责人评审。评审重点看三处：触发说法是否覆盖真实口语表达，输入参数是否都能从指令中稳定抽取，风险等级与确认要求是否匹配。评审通过后补写对应的编排说明，覆盖失败路径，再进入试点观察。动作清单是活文档，试点中发现的解析歧义应回写到触发说法示例里。
一句话里包含多个动作时，是拆成多次触发还是一次编排？
取决于动作之间是否存在依赖。如果后一个动作需要前一个动作的产出作为输入，例如先查询缺陷再批量转派，应作为一次编排处理，用步骤依赖表达先后关系；如果几个动作彼此独立、作用对象不同，拆成多次触发更便于分别确认和追溯。混合情况可以一次编排加多个并行分支。无论哪种方式，解析结果都要显式列出每个动作的对象与参数，避免确认环节看不清整体影响范围。
确认环节经常被拒绝，应该调整哪里？
先看拒绝原因集中在哪一类。如果是差异展示不清楚，确认人无法判断变更是否符合预期，应补充变更前后对比和影响对象清单；如果是解析结果与发起人本意不符，问题在动作清单的触发说法示例或参数抽取规则，需要补充更多真实说法并修正解析逻辑；如果是确认角色设置不当，把低风险动作也压给审批人，应重新核对风险分级。确认通过率持续偏低时，暂缓扩大试点范围，先修正上述环节再观察一轮。
执行回执要保存多久，谁来负责复盘？
回执留存时长按团队审计要求确定，至少覆盖一个完整迭代周期，便于异常复盘时有据可查。复盘责任建议落在流程负责人：定期汇总异常类型分布，找出反复出现的解析歧义或权限问题，回写到动作清单和编排规则中。执行中断类异常涉及系统稳定性，需要运维角色参与。回执与异常记录关联保存，复盘结论形成修改项，下一轮试点验证修改是否生效。
试点指标达到阈值后，推广时还需要注意什么？
推广阶段动作数量会增加，重点从单动作正确率转向动作库的整体一致性：新动作是否都经过评审、编排说明是否都有失败路径、高风险动作是否全部设置确认点。同时观察确认环节的负载，确认人角色过多会拖慢流转，需要按风险等级收敛确认范围。推广可以分批进行，先扩展到同类高频动作，再覆盖跨对象的多步骤任务。出现高风险动作绕过确认的记录时，应暂停该批推广并排查配置。
