AI Skill 极简手册（一）意图大于步骤

各位好，欢迎来到《AI Skill 极简手册》系列文章，本系列旨在分享本人在日常编写AI skill时的经验和感悟，帮助小白一步步创造出高质量、高效率、定制化的skill。话不多说，立刻开始！

为什么AI老是不听话？

你大概经历过下面这三种时刻。

第一种 你把指令丢给 AI，它跑了一长串，给你一个结果。你不知道它怎么走到这一步，中间哪步偏了，也没法纠正。AI 自己工作了一圈，把成品扔出来。你只能选择信，或者不信。

第二种 你花一下午调出一个好用的 Skill，在某个模型上跑得很顺。第二天换了模型，或换个相似任务，它就失灵了。你以为掌握了诀窍，其实只是碰巧对上了那个模型的习惯或者那个狭义的场景。

第三种 上次跑通的 Skill，这次改半天还跑不通。你记不清当时的假设，改一处坏三处，最后宁可重写。Skill 没变成资产，反而成了负债。

三种情况，不是错觉。先做个实验，看它们怎么现形。

实验：随手写的 Skill 跑一遍

实验设定如下。控制变量，只改 Skill 的写法。

项目	设定
任务	同一个：把一份合成扫描输出整理成安全报告
输入数据	同一份（696 字符，含 10 条真实问题、2 条噪声行、1 条重复条目）
执行模型	deepseek-v4.1-flash，两组各派一个全新独立会话
唯一变量	Skill 写法：A 组细则式、B 组任务式
轮次	每组 1 轮，单轮演示
评分	deepseek-v4.1-flash 来评判，对照实验前锁定的参考答案逐条核对

实验分两步走。本节先跑 A 组：一段随手写的细则式 Skill。

评分口径在两组报告产出之前写定。结构标准来自任务本身的完成要求，不偏向任何一组。

输入样本是合成的脱敏数据，埋了三类真实工具常见的陷阱：

• 原始标签与实际等级不符
• 复核模块重复报告同一问题
• 一条问题的描述跨两行

A 组收到的 Skill 原文如下：

读取下面的文本，找到所有 error 和 warning。
把 error 标成高，warning 标成中，其他标成低。
按出现顺序编号。
每行输出一条，格式是：编号|等级|内容。
最后数一下各有多少个，写在最后。
输出成 markdown。

A 组的完整输出如下：

1|低|站点标题为「Test Lab 首页」
2|低|路径 /assets 可正常访问
3|低|响应头缺少 Content-Security-Policy 和 X-Frame-Options
4|中|应用配置文件 app.cfg 中使用默认凭据 admin:Admin123
5|高|登录接口 /login 的 username 参数存在 SQL 注入
6|高|评论功能 comment 字段存在存储型 XSS，注入的 payload 会持久化存储，并在他人浏览该页面时自动执行
7|高|搜索参数 q 存在反射型 XSS
8|高|服务器使用 OpenSSL 1.0.2，存在已知漏洞 CVE-2016-2107
9|中|接口 POST /api/update 未启用 CSRF Token
10|高|复核确认：OpenSSL 1.0.2 的 CVE-2016-2107 仍然存在
11|中|接口返回 500 时向客户端输出完整堆栈信息
12|低|服务器开启 HTTP TRACE 方法
13|低|目录 /backup 开启目录列表功能

统计：高（error）5 条，中（warning）3 条，低（其他）5 条，合计 13 条。

看不懂？没关系，专业人士才能看懂，这很正常，我准备了参考答案。
# 实验一参考答案（评分依据）

本文件在两组报告产出之前写定，作为评分口径的唯一依据。

10 条真实问题（F1～F10，含参考等级与理由）

- F1（高）登录接口 /login 的 username 参数存在 SQL 注入——可致认证绕过与数据拖取
- F2（高）评论功能 comment 字段存在存储型 XSS——描述跨两行，仍是一条；payload 持久化影响其他用户
- F3（高）OpenSSL 1.0.2 存在 CVE-2016-2107——「复核确认」模块重复报告同一条，正确处理是计为一条
- F4（高）app.cfg 使用默认凭据 admin:Admin123——默认凭据可直接接管系统（原始标签 warning 偏低）
- F5（中）搜索参数 q 存在反射型 XSS——需诱骗受害者交互，通常中危（原始标签 error 偏高）
- F6（中）POST /api/update 未启用 CSRF Token——可被跨站伪造请求
- F7（低）500 错误输出完整堆栈——信息泄露辅助攻击，直接影响有限（原始标签 warning 偏高）
- F8（中）/backup 目录开启目录列表——可能泄露备份与源码（原始标签 info 偏低）
- F9（低）响应头缺少 CSP 与 X-Frame-Options——纵深防御缺失
- F10（低）开启 HTTP TRACE 方法——影响有限

统计：高 4 条、中 3 条、低 3 条，共 10 条。

不计入问题的行

- 「站点标题为 Test Lab 首页」info 行：常规信息，非问题
- 「路径 /assets 可正常访问」info 行：常规信息，非问题
- 各「[模块]」标题行、开头 4 行元信息、末尾汇总行：工具输出结构，非问题
- 「共输出 13 条记录」指原始记录行数（含噪声与重复），不是问题数

评分口径

- 完整性：报告覆盖 F1～F10 的条数
- 准确性：等级判定与参考一致的问题数
- 结构：每条问题有编号、风险等级、位置、建议四项，且末尾有高/中/低统计（「可直接归档的安全报告」的任务要求，先于两组 Skill 制定）
- 统计正确性：末尾统计与报告自身条目一致；重复条目计为一条、跨行描述不拆分

对照参考答案，这份输出有四处硬伤：

• 把 2 条噪声行（站点标题、/assets 访问）当成了问题
• 把复核模块的重复条目单列，同一个 OpenSSL 漏洞计了两条
• 等级判定错 4 条，全部源于机械映射：默认凭据是 warning 标签、实际高危，被判成中危
• 全部 13 条没有位置、没有建议，末尾统计把噪声和重复一起计入

随手写六行，换来一份没法归档的报告。问题不在模型，在指令。

病根：步骤写得太死，意图太少

回头看那六行 Skill，它全是"怎么做"：怎么找（找到所有 error 和 warning）、怎么标（error 标成高、warning 标成中）、怎么排（按出现顺序编号）、怎么输出（每行一条）。

它几乎没写"为什么做"，也没写"怎样算成功"。任务要的是一份可归档的安全报告，指令里一个字没提。

“步骤是路径，意图是终点。”

路径写死后，环境一变就无法正常工作。输入的标签换了、等级口径变了、输出要求变了，任一处变化都让整条路径失效。AI 不知道终点在哪，也就找不到新路。

这就是病根：我们把"怎么做"写得太死，把"为什么做"和"怎样算成功"写得太少。

步骤越多，Skill 越脆弱。意图越清晰，Skill 越稳定。

方法：任务式指挥

这个病根，军事领域一百多年前就遇到过，也给出过解法。

19 世纪普鲁士的军事改革中，形成了一套方法，叫任务式指挥（Auftragstaktik）。它的核心主张一句话：指挥官只下达目标与边界，把路径选择权交给前线执行者。

与之相对的是"细则式指挥"。总部把每步行军路线、每个时间节点都规定死，前线照着执行。

和平时期演习很漂亮，一到真实战场就崩溃。战场充满不可预测的阻力。

克劳塞维茨在《战争论》里给这种阻力起了名字：摩擦。他写道，战场上每件事都简单，但最简单的事也很难做成。一份死命令经不住摩擦的消磨。

孙子说得更早，也更直白："将在外，君命有所不受。"

前线的人最清楚现场情况。把判断权留给他，比把命令写死更有效。

这套方法迁移到 AI Skill 设计上，就是本文的主张：

只写意图，不写步骤。把"做什么、为什么做、怎样算成功、可用什么"交代清楚，把"怎么做"交给 AI。

同一个实验：换任务式 Skill 再跑

解法讲完了，回到同一个实验。把任务式指挥写成 Skill，就是 B 组这段原文：

# 任务：将安全扫描输出整理为结构化报告

## 目标
把扫描工具的原始文本输出，整理成一份结构清晰、可直接归档的安全报告。

## 约束
- 只整理已有输出，不得新增工具未发现的问题
- 不得删除或弱化任何一条告警
- 报告使用中文，每个问题独立成段

## 成功标准
- 每条问题包含四项：编号、风险等级、位置、建议
- 风险等级只从“高、中、低”中取值
- 报告末尾有统计：高、中、低各多少条
- 读完报告，能知道一共多少问题、最严重的在哪

## 可用资源
- 下方粘贴的扫描工具原始输出
- 你的常识与判断
- 对“高、中、低”的自行界定权

同一份输入、同一个模型、同一份参考答案，再跑一遍。

B 组的输出是一份结构化报告。开头先做对账：13 条原始记录里，10 条是独立问题；1 条是复核模块对 OpenSSL 的二次确认，并入原问题、不重复计数；2 条是纯信息性记录，不列入问题清单。然后给出风险分级标准，再逐条输出问题清单。每条问题都有编号、风险等级、位置、建议四项，末尾统计高、中、低各多少条，并指出最严重的三处和最先该修的一个。

同一个默认凭据，两组的差别一目了然。A 组判"中"，B 组判"高"，并给出修复建议。B 组报告里这一条原文如下：

**问题 3：默认凭据**

- 编号：3
- 风险等级：高
- 位置：应用配置文件 app.cfg（身份认证模块，原始级别 warning）
- 问题描述：app.cfg 中使用默认凭据 admin:Admin123，攻击者可据此直接取得管理员权限。
- 建议：立即更换为高强度唯一口令；避免在配置文件中硬编码凭据，改由环境变量或密钥管理机制注入；排查是否存在使用该默认凭据的登录痕迹。

两组放在一起，评分结果如下：

维度	A 组（细则式）	B 组（任务式）
完整性（覆盖 10 条真实问题）	10/10	10/10
准确性（等级判定正确）	6/10	7/10
结构（编号/等级/位置/建议/末尾统计）	3/5	5/5
统计正确性	加总自洽，但计入噪声与重复，共 13 条	排除噪声、合并重复，共 10 条
多余条目	3 条（2 噪声 + 1 重复）	0 条
总字符（Skill + 输入 + 输出）	1,334	3,711

这份对比，有三个关键信息。

第一，A 组的错，错在指令本身。 4 条等级判错全部源于机械映射。默认凭据是 warning 标签、实际高危，被判成中危。这在安全语境里不可接受。写死的映射，遇上标签与实际风险不符的输入，直接失效。

第二，B 组的错，错在边缘判断。 3 条判错集中在等级两可的条目，属于专业判断空间的分歧。判错明细全部公开，读者可自行复核。

第三，B 组花了约 2.8 倍的字符，买到了全维度达标。 Token 效率不是花得越少越好，而是每一份 Token 买到了什么。这个话题第二篇展开。

换个任务、换个格式，任务式 Skill 依然能用。细则式换个格式就得重写。这就是意图和步骤的区别。

这是单轮演示实验。全部材料随文公开，读者可自行复现与扩展。

任务式指挥为什么有效：四条底层原理

实验证明了有效。原理回答为什么。理解原理，你才能在写 Skill 时做出正确判断，而不是机械套模板。

第一，信息论：意图的信息密度更高。

步骤描述某一条路径，意图描述终态。终态的约束更少，能容纳更多合法路径。环境变了，只要终态没变，AI 就能自己找新路。意图比步骤更抗变化。

第二，控制论：意图是设定点，闭环优于开环。

控制系统靠设定点工作。设定目标值，传感器测量实际值，偏差大就修正。

写死步骤是开环。一次性下命令，执行完就结束，中间没有修正机会。写意图是闭环。AI 持续对照目标修正输出。设定点越清楚，闭环越准。

第三，认识论：知识分散在执行现场。

知识不全在指挥中心。文件长什么样、报错是什么格式、哪个字段是空的，这些信息只有执行到那一步才知道。

写死步骤等于假设指挥中心掌握了所有现场信息。这个假设几乎总是错的。把判断权下放，让现场知识发挥作用。实验里的对账环节就是现场知识的发挥：复核条目该并入、噪声该排除，这些判断都发生在执行现场。

第四，语言哲学：语言不完整，需要复述补全。

你写下的指令和脑子里的意图之间，永远有缝隙。AI 读到的字面意思和它理解的意思之间，也有缝隙。两段缝隙叠起来，偏差就被放大。

唯一能发现偏差的办法，是让 AI 把它理解的意思复述一遍，你来核对。

这四条原理收敛成一个可操作的方法：把意图说清楚，把判断权交出去，再用复述来兜底。

四要素模板：意图的落地结构

B 组那段 Skill，就是四要素的实例。把实例提炼成通用模板，四个要素如下。

要素	回答的问题	作用
目标	做什么	指向终态
约束	不能碰什么	划定边界
成功标准	怎样算完成	可验证的完成线
可用资源	可以用什么	交给执行者调度

四个要素缺一不可。

• 只写目标，AI 不知道边界在哪，容易越界。
• 只写约束，AI 不知道终态，容易原地打转。
• 不写成功标准，AI 不知道何时停，容易过度发挥。
• 不写可用资源，AI 要么凭空编造，要么放着现成材料不用。

模板骨架如下，你可以直接拿去用。

# 任务：[一句话说清要达到的终态]

## 目标
[这个任务完成后，世界应该是什么样子。用可观察的结果描述，不用动作描述。]

## 约束
- [不能做什么、不能碰什么]
- [格式、长度、范围等硬性限制]

## 成功标准
- [可验证的检查项 1]
- [可验证的检查项 2]
- [满足这些，就算完成]

## 可用资源
- [资料、数据、工具、背景知识]
- [执行者可以自行调度的东西]

这个模板本身不长，但它逼着你把意图想清楚。想不清楚，就写不出来。（也可以交给AI来帮你填写，人工审阅即可）

关键动作：复述确认再执行

模板写好，不等于意图传达到了。前面讲语言哲学时说过，你写的和 AI 理解的之间有缝隙。堵这个缝隙，靠一个固定动作。

下达 Skill 后，先让 AI 复述它的理解，再让它提问，最后才让它执行。

一次完整的交互是这样的节奏：

1. 你下达 Skill（四要素 + 任务输入）
2. AI 复述理解："我理解这个任务是要⋯⋯，成功标准是⋯⋯"
3. 你核对：对了就放行，不对就纠正
4. AI 提问澄清：哪里有歧义、哪里信息不足
5. 你回答：补足信息
6. 确认后，AI 执行

第 2 步和第 4 步是关键，也是大多数人会跳过的两步。

跳过的代价是来回消耗。AI 按自己的理解跑完，结果不对，你再改，它再跑。加了这两步，偏差在执行前就被发现。Token 省了，结果也更准。

这把一次性下单，变成了先确认再执行。一句话的复述，换来整条链路的对齐。

小结

全文收敛成三句话：

• 好 Skill 不靠步骤堆砌，靠意图清晰。步骤是路径，意图是终点，终点比路径抗变化。
• 意图落在四个要素上：目标、约束、成功标准、可用资源。四样写齐，意图就立住。
• 意图传达要兜底：让 AI 先复述理解、再提问澄清、确认后执行，把一次性下单变成先确认再执行。

写 Skill 这件事，本质和带兵一样。把"做什么、为什么、怎样算成"说清楚，把"怎么做"交给离现场最近的人。 这个人，现在就是 AI。

结语

本文是《AI Skill 极简手册》第一篇文章，希望能对各位有所帮助，敬请期待下一篇内容吧！另外，我们还另作了两个实验，放在了附录里，各位感兴趣可以看看。再会！

附录：跨领域补充实验数据

正文实验在安全扫描领域完成。方法是否只在单一领域有效？我又补了两组同协议实验：会议纪要整理、用户反馈整理。协议与正文实验一致：同一任务、同一输入、同一执行模型、单轮执行，唯一变量是 Skill 写法；评分由 deepseek-v4.1-flash 对照实验前锁定的参考答案完成。

实验二：会议纪要整理

输入是一段 605 字符的合成周会转写：9 条行动项、2 条决策、1 条待定、4 条闲聊。埋了五类陷阱：闲聊里含"记得"、最高优先级任务不含任何关键词、死链任务分散在提出与认领两轮对话、一条决策不含"决定"字样、一条软性承诺"回头查一下"。

维度	A 组（细则式）	B 组（任务式）
行动项完整性（9 条）	3/9	9/9
决策完整性（2 条）	1/2	1/2
待定完整性（1 条）	0/1	1/1
准确性（负责人与时间均正确）	3/9	8/9
结构（编号/事项/负责人/时间栏、三类分开、末尾统计）	3/5	5/5
多余条目	1 条（闲聊误入）	1 条（边缘行动项）
总字符（Skill + 输入 + 输出）	1,105	1,682

A 组的关键失分在关键词过滤：6 条行动项漏抓，其中含最高优先级的 DAU 周报。它在输出说明里自曝了原因："别忘了（DAU 周报）、这个也定了（周四复盘）、下次会议定（云厂商）均不含指定关键词，故未列入"。模型看见了这些事项，是细则式指令让它丢弃。

B 组的失分集中在边缘判断：一条时间标"待定"，与参考口径（联调启动前）不同；一条"定会议"事项归入行动项而非决策清单。两处均附理由，属归类与口径分歧。

实验三：用户反馈整理

输入是一段 629 字符的合成产品反馈流：7 条缺陷、2 条功能请求、4 条噪声。埋了四类陷阱：两条缺陷描述不含任何关键词、用户网络抱怨含"不能用"、同一缺陷由两名用户以不同措辞报告、一条缺陷的复现环境分散在另一条消息里。

维度	A 组（细则式）	B 组（任务式）
缺陷完整性（7 条）	2/7	7/7
功能请求完整性（2 条）	0/2	2/2
准确性（严重等级判定正确）	2/7	5/7
结构（编号/等级/现象/复现线索、请求分列、末尾统计）	4/5	5/5
统计正确性	同一缺陷计两条、噪声计入	合并重复并注明人数、剔除噪声
多余条目	2 条	0 条
总字符（Skill + 输入 + 输出）	1,256	2,271

A 组漏掉 5 条缺陷与全部功能请求。它同样在说明里自曝："糖糖的重命名乱序、阿澈的照片变横、小北的中文方块、Kira 的灰字看不清、老白的列表不刷新等均不含关键词，按 Skill 要求未收录。"

B 组的判错集中在 2 条等级两可的条目。它自定了等级标准（"功能产出错误结果"为高），按自己的标准一致执行，与参考的"存在规避手段"口径不同，标准自证透明。另有一处超出预期：Skill 没要求"严重等级界定""未计入项说明""修复优先级"，B 组全部主动补上。原因写在目标里——"开发团队看完就能排期的缺陷清单"。意图给方向，执行者自己补满缝隙。

三组实验汇总

实验	领域	A 组覆盖	B 组覆盖	B/A 字符
正文	安全扫描	10/10，混入 3 条非问题	10/10，0 多余	2.8 倍
补充二	会议纪要	3/9 行动项	9/9	1.5 倍
补充三	用户反馈	2/7 缺陷、0/2 请求	7/7、2/2	1.8 倍