如何写好 Skill：来自腾讯的实战经验

前两天腾讯技术工程发了一篇文章，《如何写好 Skill：一份终极实战经验手册》，里面有大量实操干货。我从里面挑了之前没展开讲过的内容，结合自己的实战体会，分成「人人都能用」和「编程专属」两个板块。

如果你对 Skill 还不熟悉，建议先看完知识星球的视频课和之前的 Skill 日课。

【人人都能用】写好 Skill 的实战技巧

1. 用触发评估检验 description

你的 Skill 能不能在合适的时机被自动触发，完全取决于 description 字段。腾讯文章里提供了一个检验方法：准备 20 个问题，一半应该触发，一半不应该触发，然后看 AI 能不能每次判对。

比如一个「会议纪要整理 Skill」，description 写「将会议录音整理成结构化会议纪要」。用测试一跑就会发现：用户说「帮我整理一下桌面文件」也会误触发，因为 description 里有「整理」这个泛词。去掉泛词，改成「将会议录音或文字转录处理成交付级会议纪要，只在用户提供原始会议素材时触发」，准确率就会明显提升。

花几分钟做一次触发评估，比反复措辞半小时有效。

2. 直接下指令，同时解释为什么

写 Skill 时最容易犯的错误是语气太软。「你应该检查 Go 版本」「你需要选择合适的方案」——「应该」「需要」在 AI 看来只是建议。正确的写法是「检查 Go 版本。根据版本号选择对应方案」。

另一个常见问题是只禁止不解释。你说「必须使用参数化查询」，AI 照做了，但遇到你没写到的边界情况，它不知道变通。如果你加上原因——「字符串拼接会导致 SQL 注入漏洞」，AI 理解了原理，遇到新场景也能自己判断。

3. 用 3-5 个示例代替长篇描述

纯文字描述容易让 AI 理解偏，但给 3-5 个输入/输出成对出现的示例，输出的稳定性会高很多。要点是：覆盖正常、边界、错误三类情况；示例之间要有差异；最重要的放第一个。

比如你写「用户反馈分类 Skill」，三个示例分别放投诉类怎么标严重等级、建议类怎么提取有价值信息、夸赞类怎么总结正面反馈。AI 看完这三个，遇到混合反馈也能处理。

4. SKILL.md 超过 500 行就拆

一个 Skill 不要超过 500 行。如果你发现写着写着超了，或者一个 Skill 里包含了几个可独立执行的流程，或者不同部分的改动频率差异很大——就是该拆的信号。

拆的原则：每个子 Skill 只做一件事，写清楚先后依赖关系，且每个子 Skill 要能单独使用、不离了主流程就活不了。比如「内容创作」Skill 可以拆成 research、outline、write、review 四个子步骤，主 SKILL.md 只负责编排流程。你改大纲规则只动 outline 文件，不影响其他步骤。今天只想搜集资料？单独用 research 文件就行。

5. 提前标出容易踩的坑

AI 也会掉进人类靠经验才能避开的坑。而且它掉进去后往往意识不到，会继续往下编。你要在容易出错的地方提前标清楚。

比如翻译 Skill 要写「只翻译正文，不要动标题编号、目录结构、表格框架」。周报生成 Skill 要写「不要虚构数据，用户没提供的指标标注待补充」。AI 默认会省略没说的东西，你提前告诉它哪里最容易错，它就会主动去检查。

6. 六个常见反模式