Skill 写完以后，怎样知道它真的有用

先写预期，再让 AI 检查#

如果看完结果才决定什么算通过，验收标准很容易跟着输出走。

比如，模型没有检查发布日期，你可能觉得“正文分析得不错，也可以”。但如果发布日期原本就在检查范围内，这次就是漏项，不能因为另一部分写得好看而消失。

我会先做一小组测试材料，每份只放几个容易核对的条件。测试副本放在专门目录里，不把故意留错的内容混进正式文章。要用真实稿件测试，也应先确认它可以交给当前工具读取。

起步可以用这五种情况：

正常稿件同样重要。只测错误稿，可能得到一个“什么都说有问题”的检查器。元数据和链接是否正常，要先按项目规则核对，不能靠模型第一次的判断给它们贴上标签。

用一个小样例看清完成态#

假设给出的检查材料包含下面两句话：

1
建议上线前执行 pnpm check。
2
目前还没有运行这项检查。

这两句话没有互相矛盾。检查器应该保留“建议执行、尚未执行”的状态。如果报告写成“已通过 pnpm check”，就出现了可直接判定的错误。

再把第一句改成“上线前已通过 pnpm check”，其他材料保持不变。这时应指出文章前后状态冲突，并建议补充实际执行记录，或按真实情况修改表述。

这样的成对样例比一大篇混杂的错误稿更容易定位原因：检查器究竟没读到后一句，还是把“建议”自动理解成“完成”？等这一点稳定，再增加更复杂的文章。

引用里也可能出现“已通过”，因此不能只搜索关键词就宣布有错。检查还要判断这句话是在讲作者的当前状态，还是引用别人的示例。这部分需要阅读上下文。

同输入对照，减少其他变量#

要知道 Skill 有没有带来帮助，可以用同一份输入做两组检查：一组只给基本任务，一组在同样任务下加载 Skill。保存双方的原始报告，再按事先写好的预期核对。

尽量保持客户端、模型、工具权限和输入材料一致。把每组放在独立的新对话中，不把前一组的反馈带给后一组。否则第二次表现更好，可能只是因为你刚刚告诉了它答案。

如果外部查询也参与测试，资料更新或搜索排序变化会影响结果。可以先使用固定的授权材料比较检查规则，再单独测试实时查询，记录查询时间和材料版本。

一次对照能发现问题，却不足以估计长期稳定性。对容易漏报的样例重复几次，记录每次结果；不必为了一个小 Skill 搭建评测平台。新对话减少旧聊天的影响，但客户端仍可能读取共享的项目规则或记忆，这些条件也应记下来。

尤其要确认“加载 Skill”这件事本身。若工具根本没发现文件，后面的表现就无法用来评价文件里的规则。能看到加载记录时保留记录；手动调用和自动触发最好分开测试。

把固定校验与阅读判断分开#

发布日期是否合法、必填字段是否存在，通常能给出明确结果。推理是否完整、建议有没有改偏作者意思，则需要人阅读评判。

这两类结果混成一个总分，会掩盖关键错误。一次检查漏掉了不存在的站内链接，即使语言建议写得很好，固定校验仍然失败。反过来，语句不够顺口，也不等于元数据检查不可靠。

核对报告时，重点看四件事：

• 明确放入的问题有没有被发现，位置能否对应回原文。
• 没有问题的内容有没有被误报，依据是否来自实际规则。
• 缺资料和工具失败有没有被标成未完成。
• 阅读建议是否保留原意，是否提供了可以选择的具体修改。

这些项目不必强行折算成百分数。只有少量样例时，“三份错误稿里有一份漏掉完成态冲突”比“准确率较高”更有用。

记录错误，不只收藏好结果#

一份简单的记录就够起步：

1
样例：completion-state-02
2
规则版本：article-preflight v1
3
输入版本：test-copy-02
4
调用条件：新对话，手动指定 Skill，本地读取可用
5
预期：指出“已通过”与“尚未运行”冲突
6
实际：只给出表达建议，遗漏状态冲突
7
判断：未通过
8
下一步：要求逐项对照完成态与证据，再复测本例

这里的版本号是你自己的记录标记，不要求 Skill 格式提供特定的版本机制。若客户端和模型会变，补上当时的实际信息。记录保存最少的必要材料，避免把私人内容、凭证或完整外部响应塞进日志。

一次失败也不一定要改 Skill。可能是输入没提供项目规则、链接校验脚本不支持当前路由，或者查询工具超时。先分清哪一层出了问题，再修改对应部分。

如果是描述不清导致没有触发，调整 description。如果已经加载，却遗漏完成态检查，就改执行步骤。如果脚本误判有效链接，应修正脚本或适用说明，而不是要求模型无条件相信输出。

一次修一个问题，再看有没有影响其他样例#

不要在看到失败后同时重写描述、报告格式和全部步骤。改动太多，即使下次通过，也很难知道是哪一条发挥了作用。

先修改与错误直接相关的规则，重跑失败样例；通过后，再跑正常稿和资料不足的稿件。前者检查误报，后者检查它有没有为了满足规则而编造证据。

如果修正“必须列出数字”后，连章节编号也被当成效果数据，就需要把数字的范围写清楚。修改规则可能引入新问题，复测的目的正是看到这种变化。

复测还应保留至少一份没有用来改规则的新稿。只在同一组样例上反复调整，可能得到一个擅长回答测试材料、却不会处理新文章的 Skill。

什么时候可以留下来日常使用#

我会先确认固定检查没有已知的关键漏项，未完成状态能如实报告，而且人工核对时能快速定位问题。再比较相似任务中反复解释和返工的情况。

如果每次仍需重新说明原意，或者报告很长却找不到依据，就继续缩小范围。一个只稳定检查元数据与完成态的 Skill，也可能比包办全文审校更有用。

这一步通过之后，仍不等于可以自动发布。它只说明检查规则在记录过的条件下有用；模型、工具或规则变化后，相关样例还需要复测。

下一篇转向 MCP：当检查确实缺少某项读取或查询能力时，怎样从连接成功走到实际可用。