自定义技能靠描述被调用，回归就要测该触发没触发
一、只有两个字段必填，等于把触发判定压在描述上
来源那篇教程描述的配置形态是这样的：入口在助手侧的管理技能里新建自定义技能，必填项只有名称与描述两项，指令是可选的补充；描述承担”什么时候被调用”的判定，指令承担”具体怎么做”；使用时还可以用名称前缀直接点名调用。这个结构对我们做交付的人有一个直接后果：一个能力会不会被用起来，取决于一段散文写得好不好，而这段散文从来没进过任何测试集。
需要先说明一句，不同产品的字段划分与调用方式差别不小，上面那套是来源给出的形态，具体到你手上的工具要以它的实际行为为准。但”由描述文本决定何时启用”这件事已经足够普遍，值得单独建一套回归。
传统用例只测产出：给定输入，看返回内容对不对。它完全覆盖不到两类新缺陷：该被调用时没调用，以及不该被调用时调用了。前者的表现是用户抱怨”这个功能不好用”，但系统里没有一条错误；后者的表现是用户没打算用它，它却插进来改写了内容，代价比前者更大。两类缺陷都没有异常码，只能靠用例主动去撞。
二、把能力拆成三层，配置里每一段只承担一层
我们现在的做法是把任何一项自定义技能拆成三层，并且在评审时逐层确认它由哪个字段承担。
| 层 | 承担字段 | 验收问什么 | 失败的样子 |
|---|---|---|---|
| 触发条件 | 描述 | 哪些说法该进、哪些不该进 | 漏触发、误触发 |
| 执行流程 | 指令 | 步骤是否逐项发生、顺序能否被打断 | 跳步、半途改道、重复执行 |
| 输出约束 | 指令与描述混合 | 长度、结构、禁项、必含来源 | 内容对但形态不可用 |
三层混写是这类配置最常见的坏味道。把”请生成一份专业、高质量的总结”这样一句话同时塞进描述和指令，触发层拿不到可判的条件，执行层拿不到可核对的步骤，输出层拿不到可度量的边界，最后所有问题都归成”效果不稳定”。拆开的成本很低：描述里只写适用与不适用，指令里按有序流程写动作，输出约束单独列出必须满足与禁止出现的条目。
来源给的指令示例正好是可拆的写法：读取全部页、明确目标、提炼成果、列风险、列待决策事项、生成一页、保持原有风格、插到首页之后。前六步是可观测的动作，第七步是软约束，第八步是对结果的落位要求。这三类要分开验收，混在一起测就会得出”大体上能用”这种无法改进的结论。
三、描述要写成可判的句子，四要素缺一个就不可测
描述这一段散文要能被判定，我们要求它写清四件事，并且逐条对着检查。
- 动作对象：这项技能处理的是什么东西，一整份文档、一段讨论记录、还是一份表格。
- 使用场景：用户在做什么的时候该想到它，用一句能听出来的意图描述，而不是抽象类目。
- 不适用场景：明确列出容易混淆但不该走这条路的情况，这一条最容易被人省略，也最关键。
- 可核对的产出特征：产出是什么形态、大致多长、给谁看。
反面清单同样重要：”专业””高质量””精准””有洞察力”这类形容词要全部删掉。它们不携带任何判定信息，只会让触发条件变成一次主观匹配，之后既没法解释为什么这次没调用，也没法解释为什么上次调用了。写”生成一页决策摘要，列出风险与待决策事项”比写”生成高质量汇报材料”更能被稳定命中，原因很朴素：前者含有可与用户请求比对的名词。
名称也要管。名称前缀可以点名调用，所以名称是第二触发入口。两个技能的名称取得语义相近，用户点名时就会打错，误触发会直接归到这一条上。命名规则里要禁止同一批技能共用关键词。
四、触发回归集：正例、反例、多轮边界三类样本
这一套用例只问一件事：调用有没有发生。产出内容一律不判。
正例取应当调用的说法，并且必须做变体。同一条意图至少覆盖四种写法：完整句、省略主语的短语、口语化带杂字的说法、把对象说错但意图清楚的近似说法。变体的意义在于，用户不会按你写文档的措辞说话。
反例是语义相邻但不该调用的说法。这一组最费脑子也最有价值，因为误触发的代价主要来自这里。有效反例的三个来源：与其他技能共享动词但对象不同的请求；对象相同但意图是查询而非生成的请求；同一话题下更该走原生问答而不该走技能的浅层问题。反例数量不应该少于正例，否则测出来的只是命中率而不是精度。
边界样本是多轮的：前一句已经把意图改掉，后一句只给一个短促的追问。比如用户先要求生成摘要，紧接着说”再短一半”，这时不该重新触发一次生成，而该在同一份结果上继续操作。这类样本是漏触发与误触发共同的来源，单轮用例永远测不到。
用例集要落成一张表，一行一个输入样本，字段固定：样本原文、轮次上下文、期望是否调用、命中的技能名、实际是否调用、失败类型。失败类型只有两个取值，漏触发与误触发，不许写”效果不佳”。
五、两类失败要分桶度量，执行层与输出层各自另测
度量只有两个：漏触发率与误触发率。两个都不能看总体值。按场景分桶之后才有意义，因为一个技能在”周报”场景漏触发是可用性损失，在”对外材料”场景误触发是风险事故。我们的门槛是分桶后任一类的比例超过约定线就阻塞发布，总体值只用于对外汇报，不用于决策。
执行层的验收和触发层完全分开。要问三件事：每个步骤是否逐项可观测，能不能从一次运行的记录里看出六步各自有没有发生；顺序被打断时的行为，用户中途插话或改了要求，剩下的步骤是继续、重来还是停下；软约束怎么变成可核对项。”保持原有风格”这一条无法直接判定，我们的做法是把它拆成可数的东西：沿用原文件的标题层级、不改动已有的术语写法、列表项符号与原有一致、不新增原文没有的小节。拆完就能测，测不过就是不过。
输出层测三类：长度与结构的上下限、禁止出现的内容类别、必须引用的数据来源。第三类在办公场景尤其容易被忽略：摘要里的结论如果没有指向原文位置，用户就要重读全文去核，这项技能的价值当场抵消。
六、把技能定义当配置资产：治理三问与观测四字段
多人共用一项技能会立刻出现三个治理问题：谁可以改这段描述与指令；改了之后怎么让使用的人知道；历史版本能不能回看、能不能一键退回。这三件事没有答案时，团队会看到一种典型现象——上周还能稳定命中的技能这周不灵了，没有人知道谁动过，也没人说得清改动前后的差别。
我们的处置和普通配置一样：把技能定义当配置资产纳入版本库，一次改动一条记录，记录里带改动人、改动原因与用例集的回归结果。版本库解决的是可追溯与可回退，这两样正是靠界面直接编辑给不了的。需要说明边界：这一层管的是单个能力自身的触发与验收；团队级批量下发、生效范围与多份定义的冲突合并是另一件事，判据和回滚方式都不同，不要混在同一套流程里处理。
上线后的观测字段取四个：触发次数、被名称点名的次数、结果被用户手工改动的比例、撤回率。第三个是最好的质量代理指标——用户接受了产出就不会动它，动了就说明没做到点上。点名占比偏高说明描述没承担住触发，用户宁愿手动；点名占比接近零但改动比例很高，说明触发过宽。这两个信号合起来才能指到具体的修改动作上。
培训里要专门教一句话：怎么让它别自作主张。用户知道可以点名调用，也知道能要求不启用，才会把这些能力放进有真实风险的环节。洹拓在内部推这几项技能时，最有效的一步不是写使用手册，而是把触发回归表公开挂在技能定义旁边——谁能看到自己的描述被哪些句子测过，谁就不再随手往描述里加形容词了。