把自然语言触发研发流程做成可运行的机制，关键是把一句口语请求拆成可核对的意图、字段和动作，再决定哪些直接执行、哪些先预览确认，最后留下可查询的记录。本文面向研发管理者与流程负责人，按“选流程—搭步骤—定角色—跑示例—做检查”的顺序给出落地方法，并说明ONES Assistant在解析结果落到工作项与文档时可承担的角色。
要点总览（TL;DR）
- 自然语言触发研发流程可拆成四层：意图入口、意图解析与结构化、执行与确认、留痕与复盘；落地时按“选流程—搭步骤—定角色—跑示例—做检查”推进。
- 首轮试点优先选高频、字段可枚举、结果可校验的流程，例如缺陷登记与分派、需求澄清记录；跨系统写操作、审批链复杂、结果难判定的流程暂不纳入。
- 五个动作要逐一定义输入、输出与完成标志：入口设计、意图解析、结构化预览、确认与执行、留痕与回写；低风险动作可直接执行，高影响动作先预览再显式确认。
- 机制运行需要提出方、规则维护方、执行与验收方、管理方四类角色，各自交付原始请求与确认预览、字段映射与动作白名单、验收与异常记录、复盘报告。
- 上线前按入口与权限、字段映射与动作白名单、异常处理路径、留痕可查询、试点范围与退出条件逐项核对，先收集两周触发记录再决定是否扩展。
先定边界：哪些研发流程适合用自然语言触发
自然语言触发适合从“说一句话就能说清楚、结果能当场核对”的流程切入。判断一条流程是否适合试点，可以看三个特征：触发频率高、字段可枚举、结果可校验。频率高意味着试点能快速积累样本；字段可枚举意味着对象、动作、责任人、时间等要素有固定取值范围；结果可校验意味着生成的工作项或文档能被提出方一眼判断对错。
反过来，涉及跨系统写操作、审批链复杂、结果难以判定的流程，先不纳入首轮试点。跨系统写操作一旦解析偏差，修正成本高；审批链复杂意味着一次触发要串联多个角色和状态，自然语言难以完整表达前置条件；结果难以判定则缺少验收依据，误触发无法被及时发现。这些流程可以等机制稳定后再评估。
还需要区分自然语言触发与确定性规则自动化、接口连接的分工。确定性规则自动化处理“条件满足就执行”的固定逻辑，例如状态流转、字段联动；接口连接解决系统之间的数据传递。自然语言触发解决的是“人用口语表达意图，系统理解后生成结构化请求”这一段，三者可以组合，但本文只讨论自然语言触发这一层。
试点前建议先填一张流程筛选清单，逐条标注触发频率、字段清晰度与风险等级，再按“高频、字段清晰、风险低”优先排序。
| 候选流程 | 触发频率 | 字段清晰度 | 风险等级 | 是否纳入首轮试点 |
|---|---|---|---|---|
| 缺陷登记与分派 | 高 | 高：模块、严重程度、复现步骤可枚举 | 低：生成后可修改 | 是 |
| 需求澄清记录 | 中高 | 中：需补充背景与待澄清问题 | 低 | 是 |
| 迭代任务拆解 | 中 | 中：依赖目标与范围输入 | 中：影响排期 | 第二批 |
| 发布审批发起 | 低 | 低：审批链与前置条件复杂 | 高 | 暂不纳入 |
| 跨系统工单同步 | 中 | 低：涉及外部系统字段映射 | 高 | 暂不纳入 |
核心步骤：从一句话到可执行工作项的五个动作
把自然语言触发做成稳定机制，可以拆成五个动作。每个动作都要明确输入、做法、输出和完成标志，避免“说完了但没落地”或“生成了但没人认”。
第一步：入口设计
输入是提出方的口语请求，做法是确定在哪个界面或对话中接收请求，输出是一条可被系统读取的原始语句。完成标志是请求进入统一入口，而不是散落在聊天工具、邮件和口头沟通里。入口应尽量靠近提出方日常工作的位置，减少额外跳转；同时要能识别提出方身份，为后续权限判断提供依据。
第二步：意图解析
输入是原始语句，做法是抽取对象、动作、字段、责任人与时间要求。对象指涉及的项目、模块、工作项类型；动作指新建、更新、分派、关闭等；字段指严重程度、优先级、截止时间等可枚举项；责任人指提出方指定或系统按规则推荐的处理人。输出是一份结构化请求。完成标志是每个必填字段都有取值或明确标记为待补充，解析结果能被人读懂。
第三步：结构化预览
输入是结构化请求，做法是把解析结果回显为待确认的工作项或文档草稿，让提出方看到“系统理解成了什么”。输出是一份可编辑的预览。完成标志是提出方能在一屏内核对对象、动作、字段和责任人，并对错误项直接修改。预览环节是降低误触发的关键，尤其对字段较多或表述含糊的请求。
第四步：确认与执行
输入是确认后的预览，做法是按影响程度分流：低风险动作，例如生成草稿、登记缺陷、补充备注，可以在预览通过后直接执行；高影响动作，例如变更排期、关闭工作项、触发跨角色流转，要求提出方显式确认后再执行。输出是已创建或已更新的工作项、文档。完成标志是执行结果有明确的状态，提出方能收到“已生成”或“已更新”的反馈。
第五步：留痕与回写
输入是原始语句、解析结果和执行结果，做法是把三者关联记录，并把执行状态回写到对应工作项或文档。输出是一条可查询的触发记录。完成标志是事后能回答“谁在什么时候说了什么、系统解析成什么、最后执行成什么、人工改了什么”。这条记录既是复盘依据，也是误触发追查的起点。
在承载环节上，ONES Assistant智能助手连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项、迭代和Wiki页面等真实工作上下文，把自然语言指令转化为ONES中可追踪的工作，并将结果保存为工作项、Wiki页面等内容。这意味着解析后的请求可以落到具体工作项状态和文档页面上，提出方不必在多个页面间重复录入。围绕需求澄清场景，ONES Assistant还可提炼要点、待澄清问题与拆解建议，帮助团队更快完成需求录入。执行前的预览与确认交互形式，需在试点时按实际配置核验。
角色与交付物：谁提需求、谁定规则、谁验收
机制能否持续运行，取决于四类角色是否各有明确交付物。职责悬空时，最常见的结果是解析错了没人改规则、生成错了没人验收、误触发没人复盘。
| 角色 | 主要职责 | 交付物 | 完成标志 |
|---|---|---|---|
| 提出方 | 用自然语言描述需求，核对并确认解析结果 | 原始请求语句、确认后的预览 | 预览中的对象、动作、字段与责任人经其确认 |
| 规则维护方 | 维护字段映射、动作白名单与提示模板 | 字段映射表、动作白名单、提示模板库 | 试点流程涉及的字段与动作均有明确归属 |
| 执行与验收方 | 核对生成结果，处理异常与修正 | 验收记录、异常处理记录 | 每条生成结果有“通过/修正/退回”结论 |
| 管理方 | 定期复盘触发记录与误触发情况 | 复盘报告、规则调整建议 | 按固定周期输出误触发率与改进项 |
规则维护方的工作容易被低估。字段映射决定口语词能否落到正确字段，动作白名单决定哪些操作允许直接执行，提示模板决定解析的稳定性。这三项需要随试点反馈持续更新，而不是一次配置后长期不动。执行与验收方则要区分“生成正确但字段不全”和“解析错误”两类问题，前者补字段，后者改规则。
示例：一条缺陷修复流程的自然语言触发全过程
以下为演示情景，用于说明五个动作如何串起来，不代表任何真实项目记录。
原始请求：“登录页在iOS 17上点验证码按钮没反应，今天下午测出来的，麻烦派给移动端，优先级高一点，这周内修掉。”
解析结果：对象为“登录页验证码按钮”，工作项类型为“缺陷”，动作为“新建并分派”；字段包括平台“iOS 17”、发现时间“今天下午”、优先级“高”、截止时间“本周内”；责任人为“移动端”对应处理人。解析后系统回显一份缺陷草稿，其中“本周内”被标记为待确认具体日期，“移动端”被标记为按规则推荐的处理人。
确认环节的修正：提出方把截止时间改为具体日期，把处理人从推荐值改为当周值班的移动端负责人，并补充一条复现步骤。预览更新后提交确认。
执行与留痕：系统创建缺陷工作项并完成分派，状态为“待处理”。触发记录中保存了原始语句、解析出的字段、提出方的两处修正以及最终工作项编号和状态。事后复盘时，管理方可以据此判断“本周内”这类相对时间表述是否需要加入提示模板，引导提出方直接给出日期。
这个示例说明两点：相对时间和团队名称是解析中最容易含糊的部分，预览环节要重点提示；修正动作本身也是规则维护的输入，重复出现的修正应转化为字段映射或提示模板的调整。
完成检查：机制上线前要逐项确认的事项
试点上线前，按下表逐项核对。每项都要有通过标准和负责人，未通过的项不进入试点范围。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 入口与权限 | 提出方只能在自己有权访问的项目内触发；入口位置对试点成员可见 | 规则维护方 |
| 字段映射与动作白名单 | 试点流程涉及的必填字段全部有映射；允许直接执行的动作已列入白名单，其余动作强制预览确认 | 规则维护方 |
| 异常与误触发处理路径 | 解析失败、字段缺失、执行报错均有明确提示和人工兜底方式；误触发可撤回或修正 | 执行与验收方 |
| 留痕记录可查询 | 原始语句、解析结果、执行结果与人工修正可关联查询，能按时间与提出方筛选 | 执行与验收方 |
| 试点范围与退出条件 | 写明试点流程、参与人员、试点周期；约定误触发率或修正率超过阈值时暂停扩展并调整规则 | 管理方 |
检查通过后，建议先用两周收集触发记录，统计解析准确率、人工修正比例和平均确认耗时，再决定是否扩展动作范围。扩展时每次只增加一类动作或一条流程，保持规则可回溯。ONES基于其权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，可作为留痕与复盘环节的承载平台之一；具体记录载体与查询方式需结合试点配置确认。
常见问题
试点时只允许低风险动作直接执行，高影响动作怎么处理？
高影响动作建议统一走“预览—显式确认—执行”的路径，例如变更排期、关闭工作项、触发跨角色流转。具体做法是：解析结果先回显为可编辑的草稿，提出方核对对象、动作、字段与责任人后再提交；执行后返回明确状态。动作白名单只收录允许直接执行的低风险动作，其余动作默认强制确认。哪些动作算高影响，需要结合团队实际流程在试点前逐条列明。
提出方用“本周内”“尽快”这类相对时间表述，解析结果不稳定怎么办？
相对时间属于解析中最容易含糊的部分，建议在预览环节把这类表述标记为待确认，要求提出方改为具体日期。重复出现的修正应转化为提示模板的调整，例如在入口提示中引导直接给出日期。示例中的“本周内”被标记为待确认，正是这一处理方式。规则维护方可以定期统计因时间表述产生的修正次数，判断是否需要更新模板。
自然语言触发和已有的确定性规则自动化会冲突吗？
两者处理的是不同层面，可以组合使用。确定性规则自动化处理“条件满足就执行”的固定逻辑，例如状态流转、字段联动；自然语言触发解决的是人用口语表达意图、系统理解后生成结构化请求这一段。落地时建议明确分工：固定逻辑继续由规则自动化承担，自然语言触发只负责把口语请求转成结构化请求并落到工作项或文档，避免同一动作出现两套执行路径。
试点运行一段时间后，判断是否扩展动作范围的依据是什么？
建议先用两周收集触发记录，统计解析准确率、人工修正比例和平均确认耗时，再决定是否扩展。扩展时每次只增加一类动作或一条流程，保持规则可回溯。同时要约定退出条件：误触发率或修正率超过阈值时暂停扩展并调整规则。判断依据应来自留痕记录，而不是个别使用者的主观感受。
ONES Assistant在这套机制里承担什么角色，留痕记录存在哪里？
ONES Assistant智能助手连接ONES Project、ONES Wiki与ONES TestCase，理解项目、工作项、迭代和Wiki页面等真实工作上下文，把自然语言指令转化为ONES中可追踪的工作，并将结果保存为工作项、Wiki页面等内容。ONES基于其权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计。触发记录的具体保存位置与查询方式，需结合试点配置确认。
