很多人开始写 AI Skill 的时候，都会犯同一个错误：上来就写正文，把步骤、禁区、语气、输出格式全塞进去，洋洋洒洒写了一两百行，感觉这张卡很完整了。

但"看起来完整"跟"真的能稳定干活"，完全是两回事。

有人专门研究过怎么写好一张 Skill，总结出来的核心思路是这样的：一张 Skill，本质上就是一个微型工作系统。这个系统有六层，每一层管一件事。写卡的时候，你要把这六层都想清楚，而不是把说明书堆得越厚越好。

这六层对应六个步骤，而且下笔顺序很有讲究，不能按层号从 1 写到 6。

第一步先写 description。 这是整张卡的开关。AI 平时只能看到卡的名字和这段约 100 词的说明，正文是被叫起来之后才加载的。所以"何时使用"如果只写在正文里，等于没写。description 要落到具体动作，列出用户可能会说的原话。模型天生欠触发，多列几种说法，比写"用于内容创作"更容易被真正命中。另外，description 里如果有冒号，记得加引号，否则文件可能被静默丢掉，目录里还在，但对话里一次都点不到。

第二步写正文，关键是想清楚松紧。 任务越脆弱，指令就要写得越死。写文案的卡不用锁死用词，但涉及付款、删文件这类操作的卡，绝对不能只写"小心一点"。用祈使句，解释为什么这样做，少堆 ALWAYS/NEVER 这种大写词。给 AI 理由，它才能在你没写到的场景里自己做判断。

第三步是拆参考文件。 上下文窗口是公共资源，塞进去的废话越多，AI 干活时能用的空间就越少。正文超过大约 500 行，或者有大段示例和表格，就把它拆出去单独放。信息只放一处，偶尔才查的内容全部搬走。

第四步配脚本，原则是先有重复再有脚本。 同一件事被 AI 反复现写，才值得固化成脚本。脚本执行前要校验输入，成功失败都要打印清楚，而且必须真实跑过成功路径和失败路径各一次，没测过的脚本不要绑进流程。

第五步写失败处理，这一层决定了一张卡的下限。 缺信息时停下来问，超出边界时不碰并汇报，执行失败时把报错原文保留下来停止运行。大多数卡只写了顺利的情况，缺信息时如果没有默认动作，AI 会自己猜，猜完还继续往下做，就翻车了。

第六步是验证迭代。 写完不等于能用。最低配是做触发测试，说一句该触发的话看卡会不会加载，再说一句不该触发的看会不会误触。中配是提前写 3 到 5 个评测用例。高配是带卡和不带卡各跑一遍对比效果。改卡时要注意，别为某一次翻车加一条只适用那次的规矩，要补的是那一类判断能力，不是打一个只管这次的补丁。

总结成一句话：卡的下限由失败处理决定，上限由你肯不肯拿真实任务打回去反复打磨。

科技先锋官How I AI