让自然语言稳定触发研发流程，关键是把一句口语指令补成可执行的任务包：明确做什么、在哪个项目与流程里做、由谁发起和审批、依据什么规则、允许执行到什么程度。上下文可按“身份与权限—对象与位置—动作与参数—规则与约束—确认与回执”五层组织，简单查询可少给，涉及写入与流转时应尽量齐全。
要点总览（TL;DR）
- 自然语言触发研发流程，需要把一句口语指令补成可执行任务包，按“身份与权限—对象与位置—动作与参数—规则与约束—确认与回执”五层逐项检查缺口。
- 简单查询通常给足身份与对象即可；一旦涉及创建、更新、状态流转或对外通知，五层都应补齐，判断标准是指令会改变系统数据或触发他人动作。
- 补齐顺序建议为：识别动作类型、锁定唯一对象、补字段参数、过流程规则与权限校验、生成执行预览并等待确认，缺失项回问而非猜测。
- 上下文由发起人、流程负责人、系统管理员和审批人分工提供，各自交付原始指令、字段清单、权限矩阵和审批记录，交接时点需提前约定。
- 上线前按对象、字段、权限、规则、回执五类检查项核对，越权写入、对象歧义、关键字段缺失应作为阻断项，先小范围试运行并确认回退方式。
一句话触发流程，最少要补齐哪五层上下文
自然语言指令本身通常只包含“意图”，缺少执行所需的定位信息与约束条件。把上下文拆成五层，可以逐层检查缺口，也便于判断哪些场景可以简化。下面这张清单可以直接对照填写。
| 层级 | 需要提供的内容 | 缺失后的典型后果 |
|---|---|---|
| 身份与权限 | 发起人身份、所属团队、可执行的动作范围、审批角色 | 越权写入、操作被拒，或由错误角色发起流转 |
| 对象与位置 | 目标项目或空间、工作项类型、具体对象（需求、缺陷、任务等）及其标识 | 指错对象、在错误项目下创建记录、更新到同名条目 |
| 动作与参数 | 动作类型（查询、创建、更新、流转、通知）、字段取值、优先级、负责人、截止时间 | 字段留空、优先级误填、责任人不明，任务包无法直接执行 |
| 规则与约束 | 流程类型、当前状态与目标状态、必填字段、完成标准、状态流转限制 | 跳过必经状态、违反流程规则、完成标准模糊导致反复返工 |
| 确认与回执 | 执行前预览、确认方式、执行后回执（单号、链接、变更记录） | 误操作无法拦截，执行结果无法追溯，交接时缺少凭据 |
五层并非每次都要全部给足。只做信息查询时，身份与对象两层通常足够；一旦涉及创建、更新、状态流转或对外通知，五层都应补齐。判断标准可以简化为一句话：指令会改变系统里的数据或触发他人动作，就需要完整的上下文。
从口语指令到可执行任务包：逐步补齐的操作步骤
补齐上下文可以按固定顺序推进，每一步都有明确的输入、动作、输出和完成标志。顺序的意义在于先锁定对象再填参数，避免在错误对象上反复修改。
步骤一：识别动作类型
输入是原始口语指令，动作是判断它属于查询、创建、更新、流转还是通知，输出是动作类型标签。完成标志是指令能被归入其中一类，且不混淆“查看某个缺陷”和“把某个缺陷转给测试”。一条指令包含多个动作时，拆成多个任务包分别处理。
步骤二：解析并确认目标对象与所在项目
输入是动作类型和指令中的名词，动作是提取项目、工作项类型和对象标识，输出是“项目—类型—对象”的定位三元组。完成标志是对象唯一可定位，例如通过编号、标题加项目名确认，而不是仅凭“那个登录问题”这类描述。存在同名对象时，必须回问而不是任选其一。
步骤三：补齐字段与参数
输入是定位三元组和流程要求的字段清单，动作是逐项比对已有信息与必填项，输出是字段填写表。完成标志是所有必填字段有值或有明确的默认规则。缺失项应回问，例如“这个缺陷的严重程度按什么级别填”，而不是由系统猜测一个值。
步骤四：套用流程规则与权限校验
输入是字段填写表和发起人身份，动作是检查当前状态是否允许目标动作、发起人是否具备该操作权限、状态流转是否符合流程定义，输出是通过或阻断的校验结论。完成标志是每条规则都有明确的通过或拒绝结果，拒绝时说明原因和可行的替代路径。
步骤五：生成执行预览并等待确认
输入是校验通过的任务包，动作是生成可读的执行预览，列出将要创建或修改的对象、字段变化和通知对象，输出是待确认的执行单。完成标志是发起人确认预览内容与实际意图一致，确认后才执行，执行后返回单号或链接作为回执。
上下文由谁提供：角色分工与交付物
上下文补齐不是发起人一个人的工作。流程规则、权限范围和审批职责分散在不同角色手中，提前约定分工可以减少来回追问。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 发起人 | 说明意图、目标对象和期望结果 | 原始指令与对象定位信息 | 流程启动时 |
| 流程负责人 | 定义字段、状态、必填项与完成标准 | 流程规则说明与字段清单 | 流程设计与变更时 |
| 系统管理员 | 维护权限、集成配置与可用动作范围 | 权限矩阵与动作白名单 | 上线前及权限调整时 |
| 审批人 | 确认高风险流转与批量操作 | 审批意见与确认记录 | 执行预览生成后 |
在工具层面，这些上下文需要有承载位置：项目与工作项承载对象和字段，状态流转承载流程规则，权限体系约束可执行的动作。以 ONES 为例，ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并把自然语言指令转化为可追踪的工作；其知识问答和任务执行基于 ONES 权限体系进行，输出过程可追踪、结果可审计。这意味着发起人提供的对象与意图、流程负责人定义的字段与状态、管理员配置的权限，可以在同一套工作项和文档体系中衔接，减少在多个页面之间搬运背景信息。
示例：一条自然语言指令的上下文补全过程
以下为演示情景，用于说明补全方法，不代表真实客户案例。
原始指令：“把昨天测试提的那个支付失败问题转给后端，顺便告诉产品经理。”
这条指令包含流转和通知两个动作，但对象、字段和接收人都不明确。补全过程如下：
- 动作识别：拆为“更新缺陷状态并指派”和“发送通知”两个任务包。
- 对象定位：“昨天测试提的支付失败问题”需要回问：“请确认是哪个项目下的缺陷，提供缺陷编号或标题。”假设确认为“支付中心项目、缺陷 #2317、标题为‘订单支付偶发失败’”。
- 字段补齐：回问“转给哪位后端负责人，严重程度和优先级按什么填”。补入负责人、严重程度、优先级和期望修复时间。
- 规则校验：检查该缺陷当前状态是否允许直接指派，必填字段是否齐全，发起人是否具备修改权限。
- 预览确认：生成预览：“将缺陷 #2317 指派给某某，严重程度改为高，并通知产品经理某某。”发起人确认后执行，返回变更记录作为回执。
可迁移的规律是：先拆动作，再锁定唯一对象，然后补字段、过规则、出预览。凡是“那个”“昨天提的”这类指代，都应转化为编号或标题加项目名；凡是涉及他人的动作，都应明确接收人和通知方式。
上线前的完成检查：上下文是否足够触发流程
在把自然语言触发流程投入日常使用前，可以按五类检查项逐项核对，每项都需要有可查看的证据，而不只是口头确认。
| 检查类别 | 检查内容 | 通过标准与证据 |
|---|---|---|
| 对象 | 目标项目、工作项类型、对象标识是否唯一可定位 | 用编号或标题加项目名能唯一定位，抽查若干条指令无歧义 |
| 字段 | 必填字段、默认值、完成标准是否明确 | 字段清单与流程定义一致，缺失项有回问话术 |
| 权限 | 发起人可执行的动作范围是否与职责匹配 | 权限矩阵可查，越权操作被拒绝并有提示 |
| 规则 | 状态流转限制与审批要求是否生效 | 违规流转被阻断，高风险操作进入审批 |
| 回执 | 执行结果是否可追溯 | 每次执行返回单号、链接或变更记录，可事后查询 |
其中三类问题应作为阻断项处理：越权写入、对象歧义、关键字段缺失。出现任一项时，流程不应直接执行，而应停在预览或回问环节。上线前建议先做小范围试运行，选取若干条典型指令走完整流程，记录回问次数和校验失败原因；同时确认回退方式，例如误创建的工作项可以关闭或删除、误流转的状态可以按流程回退，并明确由谁执行回退。试运行结果满足上述通过标准后，再逐步扩大使用范围。
常见问题
一句话里包含多个动作时，应该合成一个任务包还是拆开处理？
建议拆开处理。像“把这个缺陷转给后端，顺便告诉产品经理”这类指令，实际包含状态流转和通知两个动作，两者的对象、权限和确认要求并不相同。拆成多个任务包后，每个包单独做对象定位、字段补齐和规则校验，出错时也更容易定位是哪一步出了问题。拆分后可以约定执行顺序，例如先完成流转再发送通知，避免通知内容与实际变更不一致。
发起人说不清具体对象，只记得“上周那个登录问题”，流程还能继续吗？
可以继续，但应停在回问环节，不能由系统任选一个对象执行。可行的做法是让发起人补充项目名，再用标题关键词或时间范围检索候选对象，把候选列表交回发起人确认。若检索出多条同名或相似记录，必须由发起人指定唯一对象，例如提供缺陷编号。对象歧义属于阻断项，在确认之前不应进入字段补齐和流转环节。
流程规则和权限由谁维护，发起人需要了解多少？
流程规则通常由流程负责人定义，包括字段、必填项、状态流转限制和完成标准；权限范围由系统管理员维护，决定哪些角色可以执行哪些动作。发起人不需要记住全部规则，但需要知道自己的操作会触发哪些校验，以及被拒绝时找谁确认。团队可以把常见拒绝原因和对应联系人整理成一页说明，减少每次执行时的来回询问。
执行预览和回执在实际使用中分别解决什么问题？
执行预览解决“做之前看清楚”，把将要创建或修改的对象、字段变化和通知对象列出来，由发起人确认与意图一致后再执行，误操作可以在这一步拦下。回执解决“做完能追溯”，执行后返回单号、链接或变更记录，便于事后查询和交接。两者配合使用，才能让自然语言触发的操作既有拦截点又有凭据；只做预览不留回执，事后追查变更来源会比较困难。
试运行阶段应该观察哪些指标，才判断可以扩大使用范围？
可以重点记录三类情况：回问次数，反映指令本身的信息完整度；校验失败原因分布，反映字段定义或权限配置是否合理；阻断项出现频次，尤其是对象歧义和越权写入。试运行选取的指令应覆盖查询、创建、更新、流转等典型动作。当回问集中在少数可优化的话术或字段默认值上、阻断项能被稳定拦截、回退方式经过实际验证后，再逐步扩大使用范围。
