自然语言指令没有按预期触发研发流程，问题通常集中在四个环节：输入表述与触发词不匹配、意图解析把动作或对象归错、字段与参数抽取缺失、权限或流程状态导致执行被拦截。排查时先固定一条可复现的原始指令，按“输入—解析结果—抽取字段—执行回执”逐段比对，找到第一处偏离预期的地方，再针对性修正并做回归验证。
要点总览（TL;DR）
- 识别错误集中在四个环节：输入表述与触发词不匹配、意图解析归错动作或对象、字段与参数抽取缺失、权限或流程状态拦截执行。
- 排查按“输入—解析结果—抽取字段—执行回执”逐层比对，找到第一处偏离预期的地方就停止，不要跳层猜测。
- 修正要针对原因：补充触发词与示例、拆分多意图指令、补齐必填字段提示与格式约束、按最小权限原则核对执行账号。
- 修正前备份原配置，先在小范围指令上验证；回归覆盖原失败指令、同类变体指令和边界指令三类。
- 复发预防靠指令示例库、误识别样本记录和触发规则定期复核，并设定误触发上升时的回退条件。
识别错误的表现与影响范围
排查的第一步是把“识别错误”拆成可以观察的症状。用户反馈“指令没反应”时，背后可能是完全不同的原因：系统根本没有识别到触发意图，也可能识别到了但选错了流程，还可能识别正确却在执行阶段被权限或流程状态拦下。症状归错类，后面的排查方向就会偏。
常见的识别环节症状可以归为五类，见下表。
| 症状 | 可观察现象 | 通常所属环节 |
|---|---|---|
| 未触发 | 指令发出后没有任何流程启动，也没有回执 | 输入层：触发词或表述未命中 |
| 触发到错误流程 | 启动了流程，但目标流程与预期不一致 | 意图解析层：流程选择错误 |
| 动作或对象识别错 | 流程对了，但执行的动作（新建、流转、关闭）或业务对象（需求、缺陷、任务）不对 | 意图解析层：动作与对象归类错误 |
| 字段抽取为空或错位 | 工作项创建成功，但负责人、优先级、日期等字段为空或填到了别的字段 | 字段抽取层 |
| 参数值错误 | 字段有值，但单位、枚举值、日期格式不符合流程要求 | 字段抽取层：格式与枚举映射 |
需要与识别问题区分开的是执行环节的失败。执行报错、账号权限不足、流程当前状态不允许该操作、审批节点未完成导致无法流转，这些情况说明指令已经被正确理解，卡点在执行前置条件。判断方法是看系统是否给出了与目标流程相关的回执或错误提示：有明确指向目标流程的报错，优先按执行问题处理；完全没有反应或反应指向别的流程，才回到识别环节排查。
界定影响范围同样重要。先确认问题出现在单条指令、某一类表述（例如带时间范围的指令）、某个人群的账号，还是某个流程的特定触发入口。范围信息直接影响后续修正的生效范围：单条指令的问题可能只需补充一条示例，某类表述普遍失败则要考虑触发词覆盖和字段映射规则。
按环节定位原因：从输入到执行回执
定位原因的基本方法是逐层比对，找到第一处与预期不一致的地方就停止，不要跳层猜测。四层排查顺序和每层需要的证据如下。
第一层：输入文本与触发条件
先保留用户原始指令的完整文本，包括标点、口语化表达和上下文。检查指令中是否包含系统约定的触发词，同义表述是否被覆盖，一条指令里是否混写了多个意图（例如“把这个需求转给测试并顺便建个缺陷”），以及指令是否依赖前文上下文而当前会话缺少该上下文。这一层的证据是原始输入记录和触发规则配置，比对指令文本与触发词、示例指令的匹配情况。
第二层：意图解析结果
查看系统对这条指令给出的解析结果：识别出的动作是什么、业务对象是什么、选择了哪个流程、是否存在多个候选意图。如果解析结果与用户预期不一致，问题就在这一层。多意图混写是常见诱因，系统可能只取了其中一个意图，或者把两个意图合并成了一个错误的动作。这一层需要解析结果快照或候选意图列表作为证据；如果系统没有提供可视化查看入口，可以通过构造更短、更单一的指令做对照实验，观察结果是否随表述变化而改变。
第三层：字段与参数抽取
解析正确之后，检查抽取出的字段快照：必填字段是否齐全，枚举值是否落在流程允许的范围内，日期、人员、单位是否按流程要求的格式填充。字段抽取失败往往表现为工作项创建成功但关键字段为空，或者值填进了相邻字段。这一层的证据是抽取字段快照与流程字段定义的比对结果。
第四层：执行前置条件
如果前三层都与预期一致，问题就在执行前置：执行账号是否具备目标流程的操作权限，流程当前状态是否允许该动作，是否还有未完成的审批节点，重复提交是否被幂等规则拦截。这一层的证据是执行回执和错误码。把这一层放在最后，是因为它最容易与识别问题混淆，而排查成本又相对可控。
整个排查过程建议只改动一处配置再复测，避免同时调整触发词和字段映射后无法判断是哪项改动起了作用。每次复测都保留输入原文、解析结果、字段快照和回执四类记录，形成可回溯的排查链路。
常见原因与对应的修正动作
定位到具体环节后，修正动作要针对原因，并明确改动会影响哪些指令。下表按原因给出处置方向。
| 定位到的原因 | 修正动作 | 影响范围与注意事项 |
|---|---|---|
| 触发词或表述覆盖不足 | 补充同义说法和示例指令；对容易误命中的词收窄触发范围，必要时要求指令包含业务对象词 | 新增触发词可能带来误触发，需同步检查是否与已有流程的触发词冲突 |
| 意图与对象混淆 | 在示例中明确动作词与业务对象的搭配；把多意图指令拆成多条单一意图指令，或在提示中要求用户分步表达 | 拆分多意图会改变用户习惯，需同步更新使用说明 |
| 字段抽取失败 | 补齐必填字段的追问提示；固定枚举值与日期、人员格式；为可缺省字段设定默认值策略 | 默认值策略会影响所有未显式给出该字段的指令，需确认默认值符合流程规范 |
| 权限与状态拦截 | 核对执行账号在目标项目中的角色与权限；确认流程状态和审批前置条件；对重复提交检查幂等设置 | 权限调整涉及安全边界，应按最小权限原则处理，不宜为绕过问题放宽权限 |
修正时的风险边界需要提前交代。改动触发规则、字段映射或默认值之前，备份原配置，记录改动内容和时间；先在小范围指令上验证，例如选取该流程近期的若干条真实指令和若干条构造的变体指令，确认解析与执行结果符合预期后再扩大生效范围。如果一次修正涉及多个流程共用的触发词，要评估对其他流程的影响，必要时分批上线。
在团队协作层面，误识别样本和修正过程需要有承载的地方。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把自然语言指令转化为 ONES 中可追踪的工作项、Wiki 页面等内容；其 AI 能力基于 ONES 权限体系执行，输出过程可追踪、结果可审计。排查时可以借助这一机制，把误识别的原始指令、解析偏差和修正结论记录为工作项或 Wiki 页面，让触发规则的调整有评审依据，也方便后续复核时追溯当时的判断。需要说明的是，解析中间结果的查看入口、触发规则与字段映射的具体配置位置，以及识别失败的错误码与日志明细，需以实际部署环境中的功能为准，选型或上线前应先行核验。
验证恢复与复发预防
修正完成后，验证要覆盖三类指令，每类都比对解析结果与执行结果是否一致。
- 原失败指令：使用排查开始时固定的原始文本原样复测，确认症状消失。
- 同类变体指令：更换表述方式、调整语序、替换同义词，确认修正后的规则对同类表达同样有效，而不是只对原句生效。
- 边界指令：包含多个意图、缺少可选字段、使用边界日期或特殊枚举值的指令，确认系统给出合理的追问或默认处理，而不是静默失败或错误执行。
验证期间可以观察四个指标：触发成功率、误触发率、字段抽取完整率、人工纠正次数。触发成功率上升而误触发率同步上升，说明触发词放得过宽；字段抽取完整率没有改善，说明字段映射或追问提示还未覆盖主要缺失场景。指标的变化应结合具体指令样本看，避免只看汇总数字。
复发预防依赖三项日常机制。第一，维护指令示例库，把验证通过的典型指令和变体指令沉淀下来，作为后续调整触发规则的回归基线。第二，记录误识别样本，每条样本保留原始指令、解析结果和修正动作，形成可检索的问题库。第三，定期复核触发规则与字段映射，尤其是在流程字段定义变更、新增流程入口或团队使用习惯变化之后，及时检查原有规则是否仍然匹配。
还需要设定停止与回退条件。修正上线后如果误触发率明显上升，或者新规则影响了其他流程的正常触发，应回退到上一版配置，重新评估修正范围。回退前保留当前版本的配置和验证记录，便于分析失败原因后再次尝试。
常见问题
用户说“指令没反应”，怎么快速判断是识别问题还是执行问题？
先看系统有没有给出与目标流程相关的回执或错误提示。有明确指向目标流程的报错，例如权限不足、流程状态不允许、审批节点未完成，说明指令已被正确理解，卡点在执行前置条件，按执行问题处理。完全没有反应，或者反应指向了别的流程，才回到识别环节排查。
如果两种迹象都不明显，可以用一条更短、更单一的指令做对照实验：表述简化后能正常触发，说明原指令在输入或解析层存在问题；简化后依然无反应，再检查执行账号与流程状态。
同一条指令时好时坏，排查时应该固定哪些信息？
先固定一条可复现的原始指令，保留完整文本，包括标点、口语化表达和当时的上下文，复现过程中不要改写表述，否则问题可能消失。每次复测都保留四类记录：输入原文、解析结果、抽取字段快照、执行回执与错误码。
时好时坏通常与上下文缺失、多意图混写或流程状态变化有关。可以对比成功与失败两次的输入差异和流程状态差异，找出变化点后再决定修正触发规则还是补充示例。
补充触发词之后误触发变多了，应该怎么处理？
误触发上升说明触发词放得过宽，或与已有流程的触发词发生冲突。先回退到上一版配置，保留当前版本的配置和验证记录，再重新评估修正范围。
调整方向是收窄触发范围：要求指令同时包含业务对象词，或对容易误命中的词限定适用流程。改动后先在小范围指令上验证，同时观察触发成功率与误触发率两个指标，确认误触发没有随成功率一起上升再扩大生效范围。
字段抽取失败和字段值错误，修正方式有什么不同？
字段抽取失败表现为工作项创建成功但关键字段为空，修正重点是补齐必填字段的追问提示，并为可缺省字段设定默认值策略。字段值错误表现为有值但单位、枚举值或日期格式不符合流程要求，修正重点是固定枚举映射与日期、人员格式。
两类修正的影响范围不同：默认值策略会影响所有未显式给出该字段的指令，需要确认默认值符合流程规范；格式与枚举映射的调整则要同步检查已有指令的抽取结果是否仍然正确。
修正上线后，用什么标准判断可以结束排查？
用三类指令做回归：原失败指令原样复测确认症状消失，同类变体指令确认规则对同类表达同样有效，边界指令确认系统给出合理追问或默认处理。三类结果都符合预期，才认为问题已解决。
同时观察触发成功率、误触发率、字段抽取完整率和人工纠正次数。如果误触发率明显上升，或新规则影响了其他流程的正常触发，应回退到上一版配置，重新评估修正范围后再尝试。
