麦式参考 MickerBook Reference

Skill

Skill

也常被叫作:技能方法说明书给AI的攻略

你可能会这么说

「我有一套做事的固定方法,想让 AI 每次都照着做,不用我每次重新讲一遍。」

Skill Skill

把「这类事应该怎么做」写成一份 AI 能读的说明书,需要时自动加载并照着执行。

Skill 是一份给 AI 看的方法说明书:什么时候该用、按什么步骤做、每一步要注意什么、做完算数要看到什么。它和系统提示词的分工不同:系统提示词全局底线,每轮都占位;Skill 是某一类任务的攻略,按需加载——遇到匹配的任务才被翻出来,平时不占上下文。

一份能用的 Skill 长这样:有触发条件(什么任务该用它、什么情况别用)、有步骤(每步是一个可验证的动作,不是「认真分析」)、有验收标准(怎么算做完,具体到能看到什么)、有常见坑(这类任务每次都错在哪)。它跟普通提示词模板的区别是:模板是给人复制粘贴的,Skill 是写给 AI 按规则执行的——写得越像「可执行的分支指令」越好用。

要小心一个误区:Skill 只是文字,没有强制力。 它不像代码那样保证被执行。模型可能漏读、跳过某步、或者在你没注意时偏离方法。所以每一步都应该自带「怎么确认这一步做了」的动作,验收标准要具体到能看到什么。没有验收的 Skill,只是一篇写得不错的文章。

长什么样 真实可交互,不是截图

一份 Skill 的结构

名称:审查合同风险
触发:用户粘贴合同文本时
步骤:
1. 先列条款清单,不做评价
2. 逐条标风险等级:高 / 中 / 低
3. 高风险条款配一句大白话解释
4. 最后给 3 条最该改的
验收:能指出至少 3 个具体条款号
按需加载文字无强制力

看步骤每一条是不是都能打勾:步骤 1 的结果是「清单」,步骤 2 的结果是「等级」。写不出结果的动作,AI 只会照着念。

拆开看,里面有这几块

  1. 1
    触发条件 Trigger

    什么任务该加载它。写得太宽会误用,太窄会永远用不上。

  2. 2
    步骤 Steps

    先做什么后做什么,每步是一个可验证的动作,而不是「认真分析」。

  3. 3
    验收标准 Acceptance

    怎么算做完,具体到能看到什么输出——这是 Skill 和散文的分界线。

  4. 4
    常见坑 Gotchas

    这类任务最容易错的 2-3 件事,写进去让 AI 主动避开。

常见的有哪几种

简单提示型Prompt-style

一段说明文字,步骤少、依赖少,本质上是一份结构化提示词。

用在:输出格式、文风、小流程

分支指令型Branching

带条件和分支,AI 按情况走不同路径。

用在:多场景的复杂流程

工具配套型Tool-backed

配合 MCP 或脚本,方法之外还有真实执行能力。

用在:需要读文件、跑命令、调接口

容易搞混?这样区分

Skill MCP MCP

Skill 是说明书(教方法,本身不做事);MCP 是执行通道(能真的读文件、调接口)。Skill 给方法,MCP 给手脚,最成熟的搭配是两个一起用。

看 MCP
Skill 系统提示词 System Prompt

系统提示词是全局底线,每轮都占位;Skill 是某类任务的攻略,按需加载。把每件事都塞进系统提示词,窗口会被迅速占满。

看 系统提示词
Skill 提示词模板 Prompt template

模板是给人复制粘贴后带进对话的;Skill 是给 AI 按规则执行的,自带触发条件和验收标准。能自动加载、能被引用步骤的才是 Skill。

什么时候用得上

同一类任务反复做

把做法固化成 Skill,下次触发词一说就自动按方法走。

团队统一做法

把内部流程写成 Skill,所有 AI 客户端共用同一套标准。

和工具配合

Skill 定步骤,MCP 提供读文件 / 调接口能力,组合成能真正干活的自动化。

你可以这样跟 AI 说

直接复制下面这段,把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了:改哪里、不许动啥、做完交什么。

【任务】把 [这类任务] 的固定做法写成一份 Skill
【目标】以后我一说 [触发词 / 场景],你自动按这套方法执行
【方法】按下面 4 点写:
  1. 触发条件:什么情况该用、什么情况不该用
  2. 步骤:5 步以内,每步是一个可验证的动作,禁止写「认真分析、充分思考」这类空话
  3. 验收标准:怎么算做完,具体到能看到什么输出
  4. 常见坑:这类任务最容易错的 2-3 件事
【边界】不要改任何工具配置和权限;不要为了「完整」写超过一屏;不要写和方法无关的建议
【交付】
  1. Skill 全文,以及我该放在哪个目录、怎么命名
  2. 一段测试输入,让我发给你看它有没有按步骤执行
  3. 如果某一步依赖外部工具或文件,明确标出来并告诉我怎么补

「每步是一个可验证的动作」是整份要求的灵魂——Skill 写得好不好,就看步骤能不能打勾。要求它交付测试输入,等于把验收方法一起要过来。

它说「做好了」,你怎么自己验

这是本站的重头戏。AI 最会的不是写代码,是说「已完成」。这一条,它通常最多做到「测试」这层:有自动检查通过,但不一定是真实入口。

要亲眼看到这些,才算数

  • 打开 Skill 文件,确认有触发条件、步骤、验收标准三样,而不是一段散文。
  • 用交付的测试输入触发一次,对照步骤逐条打勾,看它有没有跳过。
  • 故意发一个「不该触发」的问题,确认它没有误加载。
  • 执行完后让它引用自己实际用了哪几步,和文件里写的对照。

它常这么糊弄你

  • 「Skill 已创建」——但内容全是正确的废话,步骤没法打勾。检查每步是不是动作、有没有结果。
  • 「它应该会自动加载」——没验证过。自己发一次触发输入,看它到底加载没有。
  • 把系统提示词和 Skill 混写在一起,声称「都在里面」——定位不同,混在一起要么每轮浪费窗口,要么加载混乱。
  • 「已按步骤执行」——但它跳过了第 2 步,输出看起来还一样完整。对照清单逐条看,别只看结论。

Skill 只是文字,最高只能验到「测试」层:用触发输入确认它真的按步骤走。真正的保障,是每一步都自带可验证的结果。

考考你 选一个你觉得对的

判断一份 Skill 写得好不好,最该看什么?