把业务 Skill 当软件工件：manifest、输出 Schema 与回归测试

团队里常见一个现象：同一个业务，张三有一套问法，李四有一套提示词，产出质量忽高忽低；人一走，经验带走；业务变了，没人知道该改哪一句。

多数人的解法是"把提示词写长一点、写细一点"。这条路走不通，原因很具体：

散文规则不可执行，也不可测试。 你写了"要专业、要简洁、结论先行"，但运行时没有任何东西能判定这次输出是否满足它。既然判定不了，就无法回归，也无法交给别人维护。

所以真正的问题不是"提示词怎么写更好"，而是：怎么把业务能力做成一个可执行、可测试、可版本化的软件工件。

一、Skill 的四个组成部分

一个能交付的 Skill，至少由四样东西构成，缺一样都会退化成"一次性提示词"：

二、Manifest：声明式定义，且本身可被校验

两个细节值得注意：

• temperature: 0 不是"更准"，而是让同一输入可复现——没有确定性，回归测试就无从谈起。
• rules 里存的是函数引用，不是散文。这一条是整个设计的分水岭。 三、把规则变成断言：散文 vs 代码 同样一条"风险项必须写责任人"：
  
  
  在"写得更狠"，而在于：代码版会在每次运行时给出明确的是/否，散文版只能靠人眼抽查。 这一步做完，"规则没拆细"这个老问题就有了技术定义：规则只要不能被写成返回布尔值的函数，就说明它还没被想清楚。 四、输出契约：Schema + 修复循环
  
  了 schema，就能做带止损的重试，而不是"再问一遍试试"：
  
  点工程含义：
• 校验在模型之外。结构对不对、引用真不真，由代码判，不由模型自述"我已完成"。
• 修复是有信息的重试。把失败项回灌给模型，而不是盲目重跑。
• 超限即失败，不降级输出。宁可报错，也不返回一个"看起来像"的结果。 五、回归测试：把验收变成 CI 没有测试集的 Skill，等于没有验收标准。最小可用形态就是 golden set + pytest：
  
  标只看三个，都能自动化统计：
  
  三条必须是 100%：引用不在召回集里，就是幻觉，没有讨论空间。 六、版本：没有 semver 的 Skill 不是资产 Skill 一旦是资产，就必须可追溯。做法很朴素：
• 语义化版本：规则变化升 minor，输出契约变化升 major，措辞微调升 patch；
• 产物哈希：manifest + checks + schema 一起算 hash，运行时记录，出问题能定位到具体版本；
• 灰度与回滚：新版本先切 10% 流量，指标不达标即刻回滚旧 tag。 没有版本的 Skill，出问题时你连"上一版是什么样"都说不上来，只能推倒重写。这正是它和提示词的本质区别。 七、三类返工，都能落到具体技术原因 原来靠经验判断的三类返工，工程化之后可以直接归因：
  
  三条最容易忽略：空召回时必须显式拒答，而不是让模型"尽力回答"。加一行判断，就能把大部分幻觉挡在输出之前。