跳到主要内容

YingClaw 技能创建教程：把常用任务存成一键技能

2026 年，AI 智能体的能力边界正在从「能聊天」转向「能按你的标准干活」。驱动这一转变的关键，就是「技能」（Skill）——把特定任务的工作流、上下文和最佳实践打包成可复用的资源，让通用智能体变成某个领域的专家。

对使用数字员工的企业来说，技能化的意义更直接：不用每次重复交代「怎么干」，而是把团队的流程、格式规范和判断标准固化下来，让数字员工一键复用。今天这篇教程，就从行业通行的 Agent Skills 规范出发，讲清楚技能是什么、怎么组织、怎么写才不会让智能体关键时刻「失灵」。

为什么技能能改变数字员工的使用方式​

没有技能的智能体，每次执行任务都要靠用户重新描述需求、反复纠正、再现场教学。效率低，结果还不可控。技能的本质是把「做事的方法」从对话里抽离出来，变成智能体可以独立加载的知识资产。

一个技能就是一个文件夹，核心只有一个 SKILL.md 文件，其余目录按需补充。这种设计的巧妙之处在于「渐进式加载」：智能体启动时只读取所有技能的 name 和 description 做匹配判断，元数据开销只有约 100 个 token；只有当某个技能被激活，才加载完整的 SKILL.md 正文；scripts、references、assets 里的资源则在实际执行到相关内容时才按需读取。

这意味着一个工作区可以存放几十个技能，但智能体的上下文窗口不会被撑爆。每个技能只贡献约 100 个 token 的元数据开销，这正是技能可以在团队里大量沉淀的前提。

技能目录结构：一个文件夹解决一个问题​

标准的技能目录长这样：

skill-name/
├── SKILL.md        # 必需：元数据 + 指令
├── scripts/        # 可选：可执行代码
├── references/     # 可选：参考文档
├── assets/         # 可选：模板、资源
└── ...             # 其他文件或目录

文件夹名就是技能名。SKILL.md 是智能体读取技能的唯一入口，其他目录都是按需补充：

  • scripts/：存放可以运行的代码，脚本应当自包含或清晰注明依赖，包含有用的错误信息。
  • references/：存放按需读取的补充文档，比如详细技术参考、表单模板、领域专用文件。关键是单个文件保持聚焦，文件越小，上下文浪费越少。
  • assets/：存放模板、示意图、查找表等静态资源。

SKILL.md 怎么写的三个要点​

SKILL.md 由 YAML 前置元数据和 Markdown 正文两部分组成。三个最关键的要点：

第一，name 字段要规范。 技能名最长 64 字符，仅限小写字母、数字、连字符，不能以连字符开头或结尾，不能出现连续连字符，还必须与父目录名一致。pdf-processing 正确，PDF-Processing、-pdf、pdf--processing 都是错的。

第二，description 是决定技能会不会被调用的关键。 智能体在启动时只读 name 和 description 来判断是否激活技能，描述写得好不好，直接决定技能会不会在关键时刻被调用。好的描述用祈使句、聚焦用户意图、明确列出适用场景，比如「Use this skill when the user has a CSV, TSV, or Excel file and wants to explore, transform, or visualize the data」——而不是干巴巴的「Helps with CSV files.」

第三，正文控制在 500 行以内。 推荐包含分步指令、输入输出示例和常见边界情况。内容太多时，把详细参考挪到 references/ 目录下的独立文件，保持 SKILL.md 精简。

描述优化的几个实用技巧​

  • 用祈使句：写「Use this when…」而不是「This skill does…」。
  • 聚焦用户意图而非实现细节：用户说「帮我分析这份报表」就该触发分析技能，而不是等用户提到具体工具名。
  • 宁可激进也不要保守：明确列出适用场景，甚至包含用户可能没意识到的使用场景。
  • 保持简洁但覆盖全面：一句话能说清楚，就不要写三段。

从实操中提炼技能，而不是凭空生成​

最常见的失败模式是：让大模型凭空生成一个技能，结果往往是泛泛而谈的「处理错误」「遵循最佳实践」，而不是真正有价值的领域知识。正确的方法有两种：

从实操任务提取：跟数字员工一起完成一个真实任务，把过程中有效的步骤、你纠正过的地方、输入输出格式、你提供的上下文，提炼成技能。这是最可靠的来源——因为它基于你团队真实的 schema、故障模式和恢复流程。

从现有资产合成：把团队内部文档、故障报告、API 规范、代码评审记录喂给大模型，让它合成为技能。基于你自己的规范生成的技能，比基于通用「最佳实践」文章生成的技能有价值得多。

技能迭代与上下文分配的原则​

技能的第一版通常需要改进。用真实任务跑一遍，然后把结果——不只是失败的，成功的也一样——反馈到修改过程中。特别注意智能体的执行轨迹而不仅是最终输出：如果它浪费了很多时间在无效步骤上，原因通常是指令太模糊、指令不适用、或给了太多选项却没有明确默认值。

分配上下文时，反复问自己一个问题：「没有这条指令，智能体会把这事做错吗？」如果答案是否定的，删掉它。不需要告诉智能体「PDF 是一种文件格式」——它本来就知道。

粒度设计上，技能应该封装一个内聚的工作单元，能与其他技能良好组合。范围太小，一个任务要加载多个技能，增加上下文开销还可能指令冲突；范围太大，description 无法精确定位触发场景，智能体难以判断何时激活。一个「查询数据库并格式化结果」的技能是内聚的，一个「同时涵盖数据库管理」的技能就太大了。

几个容易忽略但价值很高的细节​

给出默认值，不要给菜单。 当有多个工具或方法可选时，挑一个默认的，然后简单提一下替代方案，不要把一堆选项平等地摆出来。这能显著减少智能体犹豫和试错。

教方法，不要给答案。 技能应该教智能体如何解决一类问题，而不是为某个具体场景提供现成答案。方法可复用，答案只对一次查询有用。

保留 Gotchas 章节。 这是很多技能中价值最高的内容——那些违背合理假设的环境特定事实，比如「users 表使用了软删除，查询必须包含 WHERE deleted_at IS NULL，否则结果会包含已停用的账号」。这些是智能体没有被告知就会犯错的具体纠正，比泛泛的「正确处理错误」有用得多。

从零开始创建第一个技能​

第一步，选一个真实的高频任务，比如整理周报或批量处理文件。第二步，跟数字员工完整跑一遍，记录有效步骤、踩过的坑和最终格式。第三步，创建技能文件夹和 SKILL.md，用祈使句写清「何时用」和「怎么用」。第四步，用真实任务测试，根据执行轨迹迭代，删掉多余指令。第五步，沉淀到团队共享位置，让所有人都能复用。

技能的本质是把个人经验变成团队资产。当每个高频任务都被固化成技能，数字员工就不再是「每次都要从头教的新人」，而是一个「按团队标准稳定交付的老手」。这也是 2026 年智能体工程化最值得投入的方向之一。

参考来源：TendCode《智能体 Skill 创建标准完全指南 — 基于 Agent Skills 规范》（2026-07）；Agent Skills 规范（agentskills.io）；Anthropic《The Complete Guide to Building Skills for Claude》；OpenAI Codex Agent Skills 文档