自然语言触发研发流程，目标是把一句描述需求、缺陷或测试安排的话，稳定转成研发系统里可追踪、可确认、可回退的任务。落地关键在四层设计：先划定适合触发的场景，再把意图拆成带输入、动作、输出和完成标志的步骤，接着设置人工确认点与权限边界，最后建立异常处置和日志回放。建议从一条高频、低风险、对象明确的流程试点，用执行记录验证准确率与返工率后再扩展。ONES 可作为承载工作项、确认状态与执行记录的协作平台。
要点总览（TL;DR）
- 首批场景按对象明确度、步骤可变性、风险等级三项筛选，优先选缺陷分派、需求补字段、测试任务生成这类对象明确、步骤固定、风险可控的流程。
- 把每个意图拆成带操作对象、依赖和可观察完成标志的步骤，再按风险给每步设定自动执行、确认后执行、仅生成草稿三档。
- 执行异常分三级处置：槽位缺失回到补问、对象定位失败终止并留痕、写入失败按预设方式回退，每级都要有责任人和回退路径。
- 机制由流程负责人、业务角色、研发管理者、平台维护角色分工维护，意图清单、确认记录、异常台账和日志各有固定交付频次。
- 上线前用检查清单逐项核对，试点运行两到四周按周回放样本，误判集中的意图优先修订，再逐步扩展意图库。
先划清边界：哪些研发流程适合用自然语言触发
首批场景的选择直接决定试点能否跑通。判断标准可以收敛为三个条件：对象是否明确、步骤是否相对固定、风险是否可控。三个条件同时满足的场景，适合进入首批；任一条件明显不满足的，先放一放。
对象明确度指一句话里能识别出操作对象和关键属性，例如“把登录超时这个缺陷分给张伟，优先级调高”，对象是具体缺陷，属性是负责人和优先级。步骤可变性指从指令到完成之间的动作数量是否稳定，缺陷分派通常两到三步，跨模块的需求重构可能涉及十几个对象，步骤随情况变化，就不适合首批。风险等级看执行错误造成的后果，改字段、加评论、生成草稿属于低风险，关闭缺陷、变更发布范围、调整迭代承诺属于高风险。
| 场景名称 | 涉及对象 | 步骤是否固定 | 风险等级 | 是否纳入首批 |
|---|---|---|---|---|
| 缺陷分派与优先级调整 | 缺陷工作项、负责人 | 固定，2–3 步 | 低 | 纳入 |
| 需求补充字段与验收标准 | 需求工作项、Wiki 页面 | 较固定，3–4 步 | 低 | 纳入 |
| 测试任务生成 | 测试用例、测试任务 | 较固定，2–4 步 | 低至中 | 纳入，先只生成草稿 |
| 迭代范围调整 | 迭代、多个需求工作项 | 不固定 | 高 | 暂不纳入 |
| 发布计划变更 | 发布单、里程碑、通知对象 | 不固定 | 高 | 暂不纳入 |
需要说明的是，确定性规则自动化（如字段变更自动流转状态）和通过 MCP 或开放接口连接外部工具，属于相邻主题。前者解决“条件满足就执行”，后者解决“系统之间怎么通”，本篇讨论的是自然语言如何被理解并转成研发任务，两者不在本篇展开。
核心操作步骤：从一句话指令到可执行任务
端到端设计可以按五步推进，每一步都产出可检查的文档或配置，避免停留在口头约定。
步骤一：建立意图清单与触发语句样例
输入是首批场景清单和一线人员的真实说法。做法是为每个场景定义一个意图，写明意图名称、触发语句样例（至少 5 条不同说法）、必填槽位和可选槽位。槽位指指令中必须补齐的信息，例如缺陷分派意图的必填槽位是缺陷标识和负责人，可选槽位是优先级和备注。输出是一份意图清单。完成标志是：任意一条样例语句都能对应到唯一意图，且必填槽位缺失时能明确提示补问。
步骤二：把意图拆成多步骤任务
输入是单个意图。做法是把它拆成有序步骤，每步标注操作对象、前置依赖和完成标志。以缺陷分派为例：第一步定位缺陷，完成标志是返回唯一缺陷记录；第二步校验负责人是否在当前项目成员中，完成标志是校验通过或给出候选；第三步写入负责人字段，完成标志是字段值变更成功；第四步添加处理说明，完成标志是评论生成。输出是一张步骤表。完成标志要可观察，避免写成“处理完成”这类无法核对的描述。
步骤三：设定人工确认点
按风险把执行方式分三档：自动执行、确认后执行、仅生成草稿。低风险且可逆的写操作可以自动执行；涉及状态流转、跨项目影响的操作用确认后执行，由业务角色在确认界面核对槽位和步骤结果再放行；高风险或信息不完整的场景只生成草稿，由人补充后手动提交。输出是每个意图的确认档位表。完成标志是：每个步骤都能对应到唯一档位，且档位与风险分级一致。
步骤四：配置执行异常的分级处置与回退方式
异常至少分三级：槽位缺失或歧义，回到补问，不执行任何写操作；对象定位失败或校验不通过，终止当前步骤并保留已完成步骤的记录；写入失败或结果与预期不符，按预设回退方式处理，例如撤销本次字段变更或保留草稿待人工修正。输出是异常处置表，写明每级异常的触发条件、处理动作和通知对象。完成标志是：每类异常都有明确的责任人和回退路径。
步骤五：用执行日志回放核验并迭代
输入是一段时间内的执行记录。做法是抽取成功、确认后执行、失败三类样本各若干条，逐条回放：原始指令是什么、识别出哪些槽位、执行了哪些步骤、在哪个确认点被放行或拦截、最终结果与预期是否一致。输出是核验记录和意图描述修订项。完成标志是：抽样回放中，意图识别准确率和步骤完成率达到试点前设定的阈值，且失败样本都有对应的处置记录。
在 ONES 中，这一步可以借助 ONES Assistant 的能力落地：它连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等上下文，把自然语言指令转化为可追踪的工作，并将结果保存为工作项、Wiki 页面等内容；其知识问答和任务执行基于 ONES 权限体系，输出过程可追踪、结果可审计。多步骤执行中的确认节点与异常回退细节，建议在试点时结合实际配置逐项验证。
角色与交付物：谁定义意图、谁确认、谁维护
机制能否持续运行，取决于四类角色是否各有明确产出。角色不必是专职岗位，可以由现有人员兼任，但交付物和频次需要固定下来。
| 角色 | 主要职责 | 交付物 | 频次 |
|---|---|---|---|
| 流程负责人 | 维护意图清单与触发语句样例，组织意图评审 | 意图清单、样例库、修订记录 | 每两周评审一次，场景变化时即时更新 |
| 业务角色 | 提供真实场景样例，承担确认点判断 | 场景样例、确认记录、误判反馈 | 日常确认；每月汇总一次反馈 |
| 研发管理者 | 设定权限边界与风险分级，审批确认档位 | 风险分级表、权限边界说明、档位审批记录 | 试点启动前一次，之后每季度复核 |
| 平台维护角色 | 维护执行日志、异常记录与版本变更 | 执行日志、异常台账、版本变更说明 | 每周检查日志完整性，异常即时登记 |
分工中容易出问题的是确认点判断：如果业务角色只点“通过”而不核对槽位，确认就失去意义。可以把确认界面设计成必须查看关键字段变更前后对比，确认记录中保留确认人和时间，便于后续回放时区分“系统判断错误”和“人工确认放行”。
示例：一条缺陷处理流程的自然语言触发设计
下面用缺陷处理演示设计单如何填写，可直接对照改写为其他场景。
触发语句示例：“登录页超时那个缺陷分给张伟，优先级提到高，顺便说明是复现三次都出现。”需要补齐的槽位包括缺陷标识（登录页超时缺陷）、负责人（张伟）、优先级（高）、备注（复现三次）。如果指令只说“把那个超时缺陷分给张伟”，缺陷标识存在歧义，系统应列出候选缺陷请用户选择，而不是自行猜测。
| 步骤 | 操作对象 | 依赖 | 完成标志 | 确认档位 |
|---|---|---|---|---|
| 1. 定位缺陷 | 缺陷工作项 | 缺陷标识槽位 | 返回唯一记录，或列出候选待选 | 自动执行 |
| 2. 校验负责人 | 项目成员列表 | 负责人槽位 | 校验通过，或给出候选成员 | 自动执行 |
| 3. 写入负责人与优先级 | 缺陷工作项字段 | 步骤 1、2 完成 | 字段值变更成功并留痕 | 确认后执行 |
| 4. 添加处理说明 | 缺陷评论 | 步骤 3 完成 | 评论生成且内容与指令一致 | 自动执行 |
确认点设在步骤 3 之前，理由是负责人和优先级变更会影响分派结果和统计口径，属于可逆但需要留意的写操作；步骤 1、2 只读，步骤 4 是附加信息，可以自动完成。若执行失败，例如步骤 2 发现张伟不在当前项目成员中，异常记录应写明：原始指令、识别出的槽位、失败步骤、失败原因、候选成员列表，处理方式为终止后续步骤并提示用户改选负责人，已完成的定位结果保留在会话中供重新发起。若步骤 3 写入后用户发现优先级设错，回退方式为按变更前值恢复字段，并在评论中记录本次修正。
在 ONES 中承载这条流程时，缺陷本身是工作项，确认动作可以对应到工作项状态或评审环节，执行结果和评论留存在工作项上，便于按缺陷追溯整条触发链路。ONES 的 AI 研发管理方案也覆盖需求澄清与录入环节，可提炼要点、待澄清问题与拆解建议，适合把“补充需求字段”这类意图与缺陷处理放在同一套机制里管理。
完成检查：上线前逐项核对
上线前用下面这份清单逐项判断，每项给出通过标准，避免“基本可用”式的模糊结论。
| 检查项 | 通过标准 |
|---|---|
| 意图与槽位覆盖首批场景 | 首批每个场景至少有一个意图，每个意图不少于 5 条触发语句样例，抽样语句均能命中唯一意图 |
| 样例可复现 | 由未参与设计的人员按样例语句操作，结果与设计单一致 |
| 步骤完成标志明确 | 每个步骤都有可观察的完成标志，不存在“处理完成”类描述 |
| 确认档位与风险匹配 | 高风险步骤均落在确认后执行或仅生成草稿档位，档位表经研发管理者审批 |
| 权限边界清晰 | 每个意图写明可发起角色和可操作对象范围，越权请求有拦截记录 |
| 异常处置可执行 | 三级异常均有触发条件、处理动作、责任人和回退路径，且经过至少一次演练 |
| 日志足以支撑回放 | 执行日志包含原始指令、识别槽位、执行步骤、确认记录和结果状态，可按时间或对象检索 |
| 试点指标已设定 | 明确意图识别准确率、步骤完成率、返工率的基线值和目标值，并约定复核周期 |
清单全部通过后，建议先在小范围内运行两到四周，按周回放样本，把误判集中的意图优先修订。意图库的扩展节奏应与确认记录和异常台账的积累同步，每新增一个场景，都重新走一遍意图定义、步骤拆解和档位设定的流程，机制才能随使用逐步稳定。
常见问题
一句话指令里信息不全，比如只说“把那个超时缺陷分给张伟”，系统应该怎么处理？
这类指令缺少唯一可定位的缺陷标识，属于槽位缺失或歧义，处理原则是回到补问，不执行任何写操作。系统应列出候选缺陷请用户选择，确认后再进入后续步骤。设计意图时就要把必填槽位写清楚，例如缺陷分派意图的必填槽位是缺陷标识和负责人，缺任何一个都先补问。补问记录也应进入执行日志，便于回放时区分“用户没说清”和“系统识别错”。
确认后执行会不会拖慢一线人员的操作节奏？
确认档位按风险设定，只读步骤和附加信息类写操作可以自动执行，确认点集中在影响分派结果、统计口径或状态流转的写操作上。以缺陷处理为例，定位缺陷、校验负责人、添加评论可以自动完成，只有写入负责人和优先级需要确认。确认界面建议展示关键字段变更前后对比，业务角色核对一次即可放行，确认记录保留确认人和时间，后续回放时能区分系统判断错误与人工放行。
试点阶段用哪些指标判断这套机制可以继续扩展？
建议至少设定三个指标：意图识别准确率、步骤完成率、返工率，并在试点启动前写明基线值和目标值。核验方式是抽取成功、确认后执行、失败三类样本逐条回放，核对原始指令、识别槽位、执行步骤、确认记录与最终结果是否一致。抽样回放达到设定阈值，且失败样本都有对应处置记录，再考虑新增场景。每新增一个场景，重新走一遍意图定义、步骤拆解和档位设定。
执行到一半失败，已经完成的步骤要不要撤销？
按异常级别区分处理。槽位缺失或歧义时尚未产生写操作，直接补问即可；对象定位失败或校验不通过，终止当前步骤并保留已完成步骤的记录，已定位的结果留在会话中供重新发起；写入失败或结果与预期不符，按预设回退方式处理，例如按变更前值恢复字段，并在评论中记录本次修正。每级异常都要写明触发条件、处理动作、通知对象和责任人，上线前至少演练一次。
ONES 在这套机制里承担什么角色？
ONES 可作为承载工作项、确认状态与执行记录的协作平台。ONES Assistant 连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等上下文，把自然语言指令转化为可追踪的工作，并将结果保存为工作项、Wiki 页面等内容；知识问答和任务执行基于 ONES 权限体系，输出过程可追踪、结果可审计。多步骤执行中的确认节点与异常回退细节，建议在试点时结合实际配置逐项验证。
