全栈修行手册修习心得 · 随记成卷 订阅手记
慢慢写,认真生活。 / NOTES ON THE EVERYDAY

AI Skill 怎么用?从安装、调用到验证的一次上手指南

AI 与大模型 AZ 4浏览

用 AI 写代码或者整理资料时,经常会遇到一个问题:同样的要求,每次都要重新交代。

例如检查一个网页,不只是问一句“好不好看”,还需要提醒它:看看手机端有没有溢出,检查夜间模式的对比度,不要随便改文章链接,最后说明哪些问题真的验证过。

这些要求如果每次都临时拼接,很容易遗漏;如果全塞进长期提示词,又会让不相关的任务也背上同样的负担。

Skill,也就是技能,解决的正是这类“重复工作如何形成稳定流程”的问题。

这篇手记不从技能数量和排行榜讲起。先做一个小技能,知道它在哪里、什么时候被加载、到底有没有发挥作用,再考虑收集更多。

本文主要讨论采用 Agent Skills 结构的技能,以 Claude Code 的本地安装和调用方式为例。不同客户端的目录、权限及触发方式并不完全相同,不要把某一个工具的操作方法当成通用规则。

一、Skill 是什么?先别把它当成给模型安装新知识

可以先把 Skill 理解成:

一份有名称、有使用条件、能附带参考资料和脚本的任务操作手册,供 AI 助手在合适的时候读取和执行。

它通常包含这些内容:

  • 适用场景:什么任务应该使用它。
  • 操作步骤:先检查什么,再处理什么。
  • 执行约束:哪些地方不能动,哪些操作需要确认。
  • 交付标准:最后要输出什么,怎样证明任务完成。
  • 配套材料:示例、参考文档,以及可选的辅助脚本。

Skill 不会自动训练模型,也不保证模型突然具备原本没有的能力。如果客户端不能打开浏览器,技能里写一句“检查真实页面”也不会凭空变出浏览器。

它更像是给助手提供一套工作方法,而不是给助手换一个大脑。

和提示词、项目规则、MCP 有什么区别?

方式 更适合解决的问题 例子
普通提示词 交代当前这一次任务 “把这段说明改得更容易读”
项目规则 约定项目长期遵守的要求 不改历史 URL、统一代码风格
Skill 复用某一类任务的工作流程 网页验收、文章校对、故障复盘
MCP 服务 通过协议提供工具、资源或提示等能力 访问某个数据源或连接外部系统

几者可以配合:项目规则负责守住边界,Skill 提供检查步骤,具体工具负责获取证据和完成操作。它们不是非此即彼。

二、一个技能,最少需要哪些文件?

按 Agent Skills 规范,一个技能以目录组织,核心文件叫 SKILL.md:

web-page-review/
├── SKILL.md
├── references/       # 可选:检查清单、参考资料
├── scripts/          # 可选:辅助脚本
└── assets/           # 可选:模板等资源

最简单的技能只有 SKILL.md 就够了,不需要为了形式先写脚本。

文件开头是 YAML 元数据,后面是 Markdown 正文:

---
name: web-page-review
description: 检查网页的阅读体验、响应式布局和交互细节;在用户要求网页验收或界面检查时使用。
---

# 网页检查

先确认要检查的页面、设备尺寸和允许修改的范围。

检查布局、可读性、交互状态与日夜配色。

输出问题、证据、建议,以及尚未验证的部分。

为了符合 Agent Skills 规范并方便迁移,建议显式填写 name 和 description,且名称与目录一致。 某些客户端有自己的宽松规则或扩展字段,不能反过来理解成标准不需要这些信息。

其中,description 不只是给人看的简介。在支持自动选择技能的客户端里,它也是助手判断“这次任务是否需要这个技能”的重要依据。

相比“一个很强大的网页技能”,写清楚“检查什么、什么时候使用”更有价值。

三、先安装一个自己看得懂的技能

这里以 Claude Code 为例。它支持的常见位置有:

范围 路径
当前项目 .claude/skills/<技能目录>/SKILL.md
当前用户的多个项目 ~/.claude/skills/<技能目录>/SKILL.md

第一次尝试建议放在项目里。这样作用范围明确,也方便和项目一起进行版本管理。

在项目根目录创建:

mkdir -p .claude/skills/web-page-review

然后新建:

.claude/skills/web-page-review/SKILL.md

上面的命令适用于 Bash 等支持该写法的终端;Windows 用户也可以直接用编辑器创建目录和文件。注意文件确实叫 SKILL.md,不是隐藏扩展名后的 SKILL.md.txt。

安装其他客户端的技能前,应先查它的官方文档,确认:

  1. 是否支持 Agent Skills。
  2. 扫描哪些目录。
  3. 新增文件后是否需要重新加载会话。
  4. 支持自动选择,还是需要显式调用。
  5. 哪些扩展字段、脚本环境和工具可用。

复制到磁盘,不等于已经被客户端发现;被发现,也不等于这次任务已经使用。

四、如何调用,以及如何确认它真的生效?

在 Claude Code 中,可以在消息开头用技能名直接调用:

/web-page-review 检查当前项目的文章详情页,重点看手机菜单、长标题和夜间配色。本次只检查,不修改。

也可以自然语言提出任务,由客户端和助手判断是否匹配技能:

检查这个网页的阅读体验,重点看手机端、夜间模式和键盘操作,先给报告。

两种方式的稳定性不同。初次调试技能时,优先显式调用,方便确认是发现问题、触发问题,还是流程本身写得不清楚。

不要只问“你用了技能吗”

助手回答“用了”,并不足以证明它执行了检查。更可靠的办法是看交付物和执行过程:

  • 是否先确认了检查范围。
  • 是否按技能要求区分问题、证据和建议。
  • 是否遵守“只检查、不修改”。
  • 是否给出了实际检查的页面和尺寸。
  • 没有浏览器时,是否明确写了“未实测”。
  • 客户端是否提供技能调用、文件读取或工具执行记录。

具体记录形式取决于客户端,不是每个产品都有同样的可视化界面。

验证技能有没有生效,最终还是要验证它要求的工作有没有完成。

五、一份可以直接改用的网页检查技能

下面这个例子刻意不附带脚本,默认只读,适合先熟悉工作流程。

将以下内容保存为 web-page-review/SKILL.md:

---
name: web-page-review
description: 检查网页的响应式布局、阅读体验和交互状态。在用户要求网页验收、检查移动端或核对日夜配色时使用;默认只报告问题,不修改代码。
---

# 网页阅读与交互检查

## 先确认边界

- 确认页面地址或本地项目,以及本次检查范围。
- 默认只读;没有明确授权,不修改文件、提交表单或发布内容。
- 不登录未知账户,不修改线上设置,不操作支付和删除功能。

## 检查步骤

1. 阅读与当前页面相关的项目规则。
2. 有浏览器工具时,检查桌面和手机布局,并注明实际尺寸。
3. 检查长标题、导航小字、页面横向溢出和内容遮挡。
4. 页面支持日夜模式时,检查文字、链接、表格和边框的可读性。
5. 检查键盘聚焦、可操作元素的名称,以及按钮反馈。
6. 区分真实页面发现的问题、代码推测和设计建议。
7. 没有工具或访问失败时,写明限制,不编造截图和验证结果。

## 输出格式

### 检查范围
页面、尺寸、配色模式、工具限制。

### 问题清单
每条包含位置、现象、证据、影响和修改建议。

### 未验证项
列出需要人工或其他环境继续核对的部分。

### 修改情况
默认写“本次未修改”;有明确修改授权时,只处理授权范围,
并说明变更文件、验证方式和仍存在的风险。

这份技能并不神奇。它的作用,是把容易省略的检查动作写成明确步骤,同时要求助手把“看到了什么”和“猜测什么”分开。

它不能替代正式的无障碍审计,也不能只检查几个尺寸就保证兼容所有设备。

六、为什么不把所有要求都塞进一个大技能?

Agent Skills 的一个设计思路是按需加载,也叫渐进式披露:

  • 先提供名称和描述,帮助判断是否相关。
  • 确定使用后,再读取主要说明。
  • 需要时才继续读取参考资料、使用配套资源或运行脚本。

这样不必一开始就把所有资料都放进上下文。但具体加载方式和开销,仍由客户端实现决定,不能直接等同于“必然节省多少 Token”。

实际整理技能时,可以遵循一个简单原则:

主文件写流程和边界,长资料放参考目录,确定性操作再考虑脚本。

例如网页检查与文章校对,交付标准不同,就应分别组织;不要做一个同时负责写博客、改主题、部署服务和处理数据库的万能技能。

七、第三方技能,先当代码审查,再谈一键安装

技能看起来像文档,但它可能要求助手执行脚本、安装依赖、联网或读取本地文件。因此,不能因为入口是 Markdown,就认为没有风险。

使用第三方技能前,至少看一遍:

  • SKILL.md 是否有与任务无关的操作。
  • 脚本会读写哪些目录、执行什么命令。
  • 是否要求读取密钥、浏览器资料或其他敏感信息。
  • 是否向不明地址上传内容。
  • 是否把检查、修改、提交和发布绑成一个动作。
  • 来源、许可证与更新变更是否清楚。

“请忽略原有规则”“为了检查必须先上传整个项目”这类指令,不应因为藏在技能里就获得更高权限。

涉及发布和删除时,保留人工确认

以 Claude Code 为例,disable-model-invocation: true 可以禁止助手自行调用某个技能,保留用户显式调用的入口。它是客户端支持的调用控制,不是所有客户端都通用的字段。

更重要的是:限制调用不等于建立沙箱。 工具权限、网络权限和文件访问范围,仍需要在宿主客户端和运行环境中配置。

对初次使用的技能,优先采用:只读目录、测试数据、最小权限,以及“生成草稿后审核”,不要直接连接生产环境。

八、常见问题排查

现象 先检查什么
看不到技能 目录是否属于客户端扫描范围;文件名与元数据是否正确;是否需要重新加载
显式调用有效,自然语言不触发 描述是否写清适用任务;是否存在自动调用限制
读取了说明,但没有按流程输出 步骤是否具体;是否缺少交付格式;是否与项目规则冲突
脚本执行失败 解释器、依赖、工作目录和权限是否满足要求
能列出问题,却没有实际检查证据 是否缺少工具;技能是否允许用猜测冒充验证
安装很多后选择不稳定 描述是否重复、范围是否重叠;先停用不常用技能再对照测试

如果想判断一个技能值不值得留下,可以选同一个小任务,分别做一次不使用技能和显式使用技能的对照。观察遗漏项、修改范围、证据质量和结果可复现性,而不是只比较回答长短。

测试时也要尽量控制模型、工具和任务输入,否则差异未必来自技能本身。

写在最后

Skill 的价值,不在于让助手多背几个名字,而是将反复交代的经验变成一套能检查、能维护的工作方法。

第一次上手,可以尝试做一个很小的技能:检查网页、校对手记,或者整理一次故障复盘。把使用条件、操作边界和交付标准写清楚,再用真实任务检验。

先读懂,再安装;先能验证,再自动化;先交草稿,再谈发布。

技能少一点没有关系,能持续帮你减少遗漏,才值得留下。

参考资料

目录、调用控制和客户端支持会随版本变化,安装时请以所用客户端的官方文档为准。

转载请注明:TUTERM.COM » AI Skill 怎么用?从安装、调用到验证的一次上手指南

这卷宗是你需要的?请宗主喝杯灵茶。

打赏宗主,支付宝(左)或微信(右)。

alipay weichat