Skill 输出不稳定，先改说明、资料还是脚本

先确定不稳定发生在说明、资料还是脚本

触发错看名称与 description，事实错看 reference 和来源，步骤错看 SKILL.md，确定性操作错看脚本。不要每次失败就重写整个 Skill。

建立固定测试集

正常、缺材料、越界、相邻和故障任务都写预期触发、步骤与结果。

记录客户端版本、Skill 版本、触发输入、实际步骤、工具调用和输出，正例与反例都要保留。

记录失败层

区分未触发、错误触发、输入遗漏、规则误解、工具失败、输出不合格和权限越界。

确认“记录失败层”已经有可回查结果，再进入“只改对应组件”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

只改对应组件

触发改说明，知识改资料，流程改正文，重复计算或文件操作改脚本；一次只动一类。

确认“只改对应组件”已经有可回查结果，再进入“重跑全量回归”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

重跑全量回归

不仅重跑失败例，还检查以前通过的用例，记录客户端和 Skill 版本。

确认“重跑全量回归”已经有可回查结果，再进入“保留兼容说明”；依据仍然来自猜测时，把缺口单列并停在当前步骤。

保留兼容说明

有意改变触发或输出时写迁移与影响，不静默破坏团队旧用法。

脚本、网络、凭证和写操作必须在说明中可见；触发边界不清或结果不可验收时不要扩大使用范围。 完成后把证据归入“正反例测试集、回归结果与修订记录”。

修订记录要能解释改动因果

每版写症状、根因、修改、测试和残余风险。一次随机成功不等于稳定，重复运行和边界测试都通过才发布。