AI Skill 怎么写才不翻车：从 mattpocock 的五个失败模式说起
开发者 Matt Pocock 公开了他长期打磨的 Skill 写作指南，提炼了一套让 AI \"按规矩办事\"的系统方法。本文拆解核心框架和五种最常见的翻车模式
开发者 Matt Pocock 昨天公开了他长期打磨的 Skill 写作指南，提炼了一套让 AI "按规矩办事"的系统方法。本文拆解核心框架和五种最常见的翻车模式。
AI Skill 怎么写才不翻车：从 mattpocock 的五个失败模式说起
给 AI 写 Skill（技能指令）的人都有这种经历：花半小时写了一版，第一次跑得挺好。第二次就跑偏了。第三次它直接跳过关键步骤，提前宣布"已完成"。
这不是你的指令写得不好。是 Skill 的写法本身有门道。
昨天，开发者 mattpocock 公开了他长期打磨的 writing-great-skills 指南。一份核心文件加一份术语表，提炼了一套让 AI "稳定执行"的系统方法。核心观点很实在：Skill 的本质，是在一个天生随机的东西里挤出确定性。
本文拆解这套框架的关键设计，以及五种最常见的翻车方式。
一、Skill 的核心问题：要稳定的是过程，不是结果
先说一个很多人混淆的点。
AI 生成的内容每次都不一样——这很正常，也是我们想要的。写文章、头脑风暴、审查代码，本来就不该每次产出相同的结果。
但过程应该一样。
就像一个经验丰富的工程师，每次审查代码时检查的维度是固定的——安全性、正确性、性能、可维护性。至于具体指出什么问题，取决于代码本身。过程不变，结果随代码变化。
mattpocock 把这个叫可预测性：同样的输入，走同样的流程，但不要求同样的输出。
你写的 Skill 翻车，十有八九不是 AI 不够聪明，而是流程上出了漏洞。
二、第一个决策：谁来触发这个 Skill？
写 Skill 的第一个问题不是"写什么"，而是谁能叫它出来干活。
两种选择：
选择 A：AI 自己判断时机
- 在 Skill 文件里写一段触发说明，告诉 AI "遇到什么情况就用这个"
- AI 看到匹配的场景会自动调用
- 代价：这段说明每次对话都占着 AI 的"记忆空间"，等于一直在交房租
选择 B：只有你手动叫它
- 不写触发说明，AI 平时看不到这个 Skill
- 只有你输入 Skill 名字时才会执行
- 代价：你得自己记住有哪些 Skill、什么时候该用
什么时候选 A？ 当你不可能每次都手动操作的时候。比如代码审查——每次改完代码都手动敲一遍指令，不现实。应该让 AI 自己判断时机。
什么时候选 B？ 当这个 Skill 只在你明确需要时才跑——比如"写周报"、"生成发布说明"。不需要 AI 替你判断。
mattpocock 的建议很明确：默认选 B，只有真正需要自动触发的才选 A。 少写一段触发说明，就省一份"记忆空间"。当 B 类 Skill 多到自己记不住的时候，写一个"目录 Skill"——它只列名字和用途，别的什么都不做。
三、信息分层：不是所有内容都该塞进同一个文件
决定了谁来触发之后，第二个问题是：哪些东西写在 Skill 文件里，哪些放到外面？
分三层：
第一层：操作步骤。 放在 Skill 文件里，AI 每次执行必须读。比如"先做类型检查，再做代码规范检查，再跑构建"。关键是每一步必须有一个能判断"做完没做完"的明确标准。模糊的标准（比如"理解项目结构"）是翻车的温床。
第二层：参考资料。 也放在 Skill 文件里，但 AI 按需查阅。比如"代码审查要检查哪些维度"——不用每次都从头读一遍，需要的时候能找到就行。
第三层：外部文件。 放到单独的文档里，只在 Skill 里留个链接。比如术语表、详细规范、长篇示例。AI 真正需要的时候再去加载。
这个分层的逻辑很简单：用到什么才加载什么。 就像你打开一个 App，首页只显示最常用的功能，高级设置藏在二级菜单里。
一条实用的判断标准：所有情况下都会用到的内容放在第一层；某些情况下用到的放在第二层；只有特殊情况才用到的放在第三层。
四、五个失败模式：你的 Skill 最容易在哪里翻车
mattpocock 把最常见的失败归纳为五种。每一种都讲清楚了症状、原因和修法。
失败 1：提前交卷
症状：第三步还没做完，AI 就说"已完成"，跳到第四步去了。
原因：完成标准太模糊。你说"确保代码质量没问题"——AI 不知道什么算"没问题"，于是随便看了一眼就说没问题。
修法：把标准改成能检查的。"确保类型检查 0 个错误，代码规范检查 0 个警告，构建通过"——AI 能判断这三个条件满足了没有。如果你已经写了清晰的标准但还是提前交卷，那就把后面的步骤藏起来——把长流程拆成两个独立 Skill，AI 做完第一个才能看到第二个。
失败 2：啰嗦重复
症状：同一件事在 Skill 里讲了两遍，或者两个 Skill 都写了同一套规则。
原因：你以为"多强调几遍 AI 会更重视"。但事实相反——重复不仅浪费篇幅，还会让 AI 对这条规则的重视程度失准。被强调了两次，AI 以为它比别的规则重要两倍。
修法：每条规则只在一个地方说了算。 如果要改行为，只改一个文件。如果两个 Skill 需要同一套规则，把规则抽出来放到一个公共文件里，两个 Skill 各自引用。
失败 3：垃圾堆积
症状：Skill 文件越来越长，里面有半年前加的规则、三个月前加的特例、上个月加但已经不再适用的说明。没人敢删，因为"万一还用得上呢"。
原因：加东西比删东西安全。删掉一条指令的后果不确定，加一条至少不会出事。于是 Skill 文件像地质层一样越堆越厚。
修法：定期清理，逐行问自己一个问题："这一行现在还影响 AI 的行为吗？" 如果不影响了——删，别犹豫。mattpocock 的建议更直接：大多数不再有用的文字应该直接删掉，别总想着"改写一下还能用"。
失败 4：又长又散
症状：Skill 太长了。不是因为重复或堆积——每行都独一无二、每行都有用——但就是太长了。AI 读完三页才开始干活，注意力早就散了。
原因：什么东西都往里塞，没有用信息分层来瘦身。
修法：把参考资料推到外部文件（前面说的第三层），把不常用的分支拆成独立 Skill。目标是让 AI 每次只需要读跟当前任务相关的内容，而不是把整本手册从头翻到尾。
失败 5：说了等于没说
症状：你写了一条指令，但 AI 本来就会这么做。这条指令占着篇幅，但行为没有任何改变。
原因：你不清楚 AI 本来就会做什么。比如你写"请认真思考"——但 AI 本来就会认真思考。你等于花钱说了句废话。
修法：做"废话测试"——对 Skill 里的每一句话，问自己："把这句话删掉，AI 的行为会变吗？"如果不会，删。mattpocock 的建议是：大多数没通过这句测试的话应该直接删，别想着改写——因为你很可能是在给 AI 本来就会做的事写注释。
五、一个实用技巧：用对关键词
整份指南里最让我有收获的，是一个关于"选词"的洞察。
大模型在训练过程中已经消化了海量文本。有些词它见过无数次，早就"懂"了这个词代表的行为模式。比如 tight——在技术文档里，它天然意味着"紧凑、严格、不拖泥带水"。这个词自带画面感，不需要你再写三句话去定义它。
所以一个很简单的技巧是：想让它做"快速且严格"的检查？别啰嗦，直接说"做一个 tight 的检查"。一个字，比一段描述更管用。AI 会自动调取它对 tight 的全部理解来执行。
反过来也要注意：词选得太弱等于白选。比如你写 thorough（全面），但 AI 的默认行为本来就是全面——加这个词不会改变任何东西。换成 relentless（不留情面），AI 才会真的打起精神。
本质很简单：一个精准的词，比三句解释更有效。 不是因为省了几个字，而是因为这个词触发的是 AI 已经内化的一套行为模式，比你在现场用三句话临时定义要稳定得多。
六、一个自查清单
mattpocock 的框架可以浓缩成一套自查问题。每次写完 Skill 后过一遍：
- 这个 Skill 是 AI 自动触发还是手动触发？手动就够了就别开自动。
- 操作步骤有没有明确的完成标准？AI 能判断"做完了"还是"没做完"吗？
- 哪些内容可以推到外部文件？只有所有情况都需要的才放在 Skill 文件里。
- 有没有同一件事讲了两遍？合并成一个来源。
- 逐行废话测试：删掉这行，AI 的行为会变吗？不会就删。
- 有没有可以用一个精准的词替换掉的三句解释？
这套框架最让人信服的地方不是技巧本身——而是它的设计理念：Skill 写得好不好，不取决于你用了多少技巧，而取决于你有没有认真想过"AI 在每一步到底需要知道什么"。 那些翻车的 Skill，往往不是写得太少，而是写得太多——太多的重复、太多的沉积、太多的废话。删到只剩骨架，AI 反而执行得更稳。
写到这里差不多了。如果你读完有收获，动动手指点个赞和在看，转发给写 AI Skill 的朋友，说不定正好帮他少踩一个坑。还没关注的，可以顺手星标一下⭐，下次更新第一时间收到。
我们下篇文章见。
作者：Hookoon
>
参考：emilkowalski/skills — Emil Kowalski 的设计工程 Skill 集，本文 Skill 写作方法论的另一实践参考。