AI不是写完Skill就结束了,真正的活在后面-夜雨聆风

AI不是写完Skill就结束了,真正的活在后面

我第一版Skill写出来的时候，觉得效果不错。结构清楚，风格对味，跑通了几个测试case。于是交给同事用。

反馈来了：”我输入的格式稍微不一样，它就开始编东西了。”

又过了两天，另一个反馈：”它有时候会跳过中间的分析步骤，直接给一个最终结果，看起来像那么回事但经不起推敲。”

那一刻我意识到一个道理：让AI做对一次不难，让它在任何人手里、任何输入条件下都不出大错，才是真正的工程。

这两件事之间的距离，比我以为的大得多。局长开始花时间去填这个gap，过程中踩了很多坑，也慢慢摸索出了一些方法。现在回头看，我觉得这套方法有一个更准确的名字，就是Harness Engineering。

Skill写好只是起点

先说说”写好一个Prompt”和”做好一个Skill”之间的区别。

Prompt解决的是单次交互的问题。你描述清楚意图，AI给你一个不错的输出。这件事依赖的是你当下表达得够不够好，以及模型当下状态够不够聪明。它是一次性的、即兴的。

Skill要解决的是完全不同的问题：在你不在场的情况下，在别人使用的情况下，在输入千奇百怪的情况下，AI依然能给出稳定的、符合标准的输出。

这两者之间的差距，和写一段能跑的demo与写一个能上线的服务之间的差距一模一样。后者需要考虑的东西多出十倍：输入异常怎么办？中间步骤出错怎么兜？输出格式怎么校验？下次再出同样的错怎么避免？别人接手时怎么理解你的设计意图？

最初局长以为把Skill写详细、把约束条件列清楚就够了。但现实很快教育了我：AI是一个有”动机”的执行者。它有天然的倾向去完成任务、去给出答案、去让自己看起来”做好了”。当信息不足的时候，它不会停下来说”我缺信息”，它会自己编一个看起来合理的东西糊上去。

这就是为什么单纯写Skill不够。你需要的是一整套”脚手架”把AI围住，让它在正确的轨道上运行，在该停的地方停下来，在该追问的时候追问，在该拒绝的时候拒绝。

局长从踩坑里总结出的四个设计原则

经过反复的翻车和修复，局长逐渐形成了四个做Skill harness的核心原则。

第一个原则是反模式先行。这是对我冲击最大的一个认知转变。我做方案输出Skill的时候，最先写的不再是”它该做什么”，而是”它最容易在哪里塌”。比如最常见的崩坏模式是：信息不足时AI不追问、直接编造一个看起来合理但完全没有依据的内容。另一个高频崩坏是：它会跳过中间的分析阶段，直接给出结论，省略了推导过程。

我把这些反模式写在Skill配置的最前面，用”不要做什么”来约束它，比写十条”要做什么”的正向指令都管用。有个AI虾友的朋友跟我说了一句话让我印象深刻：告诉AI要做什么效果一般，告诉它前人最容易在哪里塌效果更好。这句话完全改变了我写Skill的思路。

第二个原则是门禁不能靠AI自己说了算。我做简报生成Skill的时候，早期让AI在输出前”自检一遍，确认格式和内容符合要求再提交”。结果它每次都”自检通过”。无一例外。后来我想明白了：AI在这件事上有天然的利益冲突。它既是选手又是裁判，它有动机让自己通过。

所以我改成了硬门禁：输出必须符合一个预定义的结构化Schema，字段缺失或类型错误就自动打回重来。判定通过还是不通过的是规则，不是AI的”判断”。这个改动之后，输出质量有了质的提升。因为AI知道它糊弄不过去了，反而会老老实实地做。

第三个原则是分阶段流程。我做会议纪要Skill的时候，把整个处理拆成了明确的阶段：接收预处理、口语清洗、结构化整理、待办提取、摘要生成。每个阶段有自己的输入、输出和验收标准。

好处是什么？当某个阶段出了问题，你能精确定位是哪一步塌了。是口语没洗干净？还是结构化的逻辑链断了？还是摘要和正文矛盾了？你不用面对一整坨输出去猜哪里出了问题。同时，每个阶段之间形成了天然的”检查点”，你可以在任何一个阶段拦下来看一眼，确认没问题再让它继续。

第四个原则是Self-Refinement沉淀。用了一段时间之后，我发现同样的坑会反复出现。同一类输入总是在同一个地方翻车。于是我加了一个机制：每次Skill翻车，我不是只修这一次的问题，而是先判断这个问题是”单次偶发”还是”规律性会重现”。如果是后者，我就把踩坑经验写进一个专门的参考文件里，下次Skill执行前先读一遍历史教训。