把公司工作流变成 Agent Skills：实战指南

一个文件夹装下整支团队的做事方式

据一位数字营销机构负责人分享的实践记录，他花了大约五分钟给编码 Agent 装入了十个新技能，来源是 Sonner 吐司库的开发者 Emil Kowalski 编写的设计工程类技能——涵盖「什么时候不该做动画」「该用哪条缓动曲线」「如何用最坏情况数据压测 UI」等具体判断。安装后 Agent 写动画和移动端布局的质量明显提升，而模型本身一行没改。

差距的来源只是一个装着 Markdown 文件的文件夹。这背后是一套正在被重新定义的 Agent 定制方式：技能（Skill）不是提示词模板，而是可被人审查、被 Git 管理、被版本控制的可执行操作规程。

对国内大量使用 AI 编程工具的开发者和团队来说，这个思路的价值在于：它把「教 AI 干活」这件事从口口相传的经验，变成了可以沉淀、复用和审计的工程资产。

Skill 到底是什么

一个 Skill 就是一个目录，里面有一个 SKILL.md 文件，以及可选的支撑文件：模板、checklist、小脚本。文件本身是纯 Markdown，成本低到几乎可以忽略。作者给出了一段最小可运行的真实示例（SEO 审计技能）：

---
name: seo-audit
description: "Audit a client site before delivery. Use when asked to
  "check the site", "run an audit", or before handing a project over.
---

**渐进式加载（progressive disclosure）** 是这套机制能成立的底层设计。如果会话一开始就把所有技能的完整正文塞进上下文，几十个技能很快就会耗尽窗口，模型还会被无关流程干扰。做法是分两级：第一级只暴露 `name` 与 `description`，构成一个极小的「技能目录」；第二级在命中后才把 `SKILL.md` 全文及其支撑文件读入。这与 Agent 工具调用中的「先看有哪些工具、再取参数」是同一个思路——先建立一个廉价的索引，把昂贵的内容推迟到真正需要时。代价是匹配质量完全压在 `description` 上：写得含糊，索引就失效；写得具体到包含触发短语，命中率才高。
## Workflow
1. Crawl the site, collect titles/descriptions/headings
2. Check structured data and canonical tags
3. Report as a table: severity, page, fix
## Hard rules
- Report only. Do not fix anything until asked.

前端元数据（frontmatter）承担了「匹配表面」的职责：name 变成聊天里的 /seo-audit 命令，description 是 Agent 判断这个技能是否匹配当前任务的依据。正文则是流程本身。

真正巧妙的地方在于加载机制。 会话开始时，Agent 手里只保留全部技能的名称和一行描述——据作者称，他常驻的 53 个技能合计只占几 KB 上下文。只有任务匹配、或用户显式调用时，技能的完整文本才会被载入。这就是为什么你可以长期养着几十个技能：闲置技能的成本接近于零。

这实际上是一种「按需检索的流程知识库」，与 RAG 的思路一脉相承，但检索单元是工程化的工作流而非文档片段。

两种调用方式

• 显式调用：用斜杠命令，例如 /seo-audit https://client-site.ru。Agent 会逐步执行流程，参数透传。适用于「仪式本身很重要」的场景。
• 隐式调用：用自然语言说「把这个网站检查一下再交给客户」，Agent 会把请求与各技能的描述做比对，自动拉入合适的那一个。

正因如此，description 字段值得你投入最多笔墨。作者提到，优秀的技能作者甚至会专门写一个 Triggers 段落，列出应该激活该技能的具体短语。这一点对中文团队尤其重要——如果团队日常用中文下指令，描述里必须包含中文触发短语，否则隐式调用会大面积失灵。

提示注入（prompt injection） 是理解后文安全闸门的必要背景。它的原理是：模型无法天然区分「系统给的指令」和「数据里夹带的指令」，只要某段被读取的文本写成命令语气，就可能被当作命令执行。对技能来说，风险被放大了——技能不是被模型阅读的普通资料，而是它主动执行的指令集，安装一个来路不明的技能，等于让 Agent 运行陌生人的脚本。常见载体包括伪装成 checklist 条目的诱导句、Markdown 里用零宽字符隐藏的文本、嵌套代码围栏中夹带的段落。这也解释了为什么人工逐行复核不可省略：扫描器只能匹配模式，判断「这句是防御性声明还是真攻击」仍然需要人。

技能放在哪：三层结构

作者采用的是三层布局：

1. ~/.agents/skills/<name>/SKILL.md —— 个人技能，在所有项目中可用。他的工作风格就住在这里：发布流水线、审计流程、安全闸门。
2. 仓库内的 skills 文件夹 —— 团队技能，提交到 Git。新员工拿到的是可执行的操作规程，而不是一篇没人打开的 wiki。
3. 插件缓存 —— 用于市场分发的通用技能包。通用需求够用；但任何跟「你们公司的做事方式」有关的东西，都应该放进前两层。

第二层是关键。用 Git 管理技能，意味着流程可以 code review、可以回溯、可以开分支试验，也让「老员工的经验」第一次有了明确的交接载体。

为什么用 Git 而不是 wiki 或共享文档，是这三层结构里最值得展开的一点。流程文件一旦进入版本控制，就获得了三项 wiki 给不了的能力：其一是 code review，流程图和代码可以被同一位 reviewer 在同一个 PR 里审；其二是可回溯，某次发布事故能定位到当时生效的那一版技能，而不是靠记忆；其三是可分支试验，改进流程可以先在分支上跑通再合并，失败不留痕。更重要的是交接方式的改变：新员工拿到的不是一篇需要自行理解的操作说明，而是一份 Agent 会照着执行、也会照着报错的规程——流程的「正确性」第一次可以被自动化验证。

一条真实流水线：一个命令，六个平台

作者最重的技能，就是用来发布他这篇文章本身的。他输入 /smm-crosspost 并附上文件，或者直接说「给我们的博客写篇文章」，Agent 会依次：

• 用英文写文章，改编成俄语和哈萨克语，并在三个版本之间做互链；
• 生成 1200x630 的品牌风格封面；
• 把内容放入站点，附带完整的结构化数据（TechArticle、FAQPage、HowTo、hreflang）；
• 停下来，把所有内容展示给他审批；
• 收到「ok」之后：部署、验证文章已上线、跑一次内部质量审计；
• 为六个社交网络各写一份平台适配版本，格式、语气、长度限制各不相同；
• 所有草稿过一遍 human-lint，把每段文本连分数一起展示；
• 再次等待明确的「ok」。只有这时才发布。

第 4 步和第 8 步是写死在技能里的硬闸门。Agent 不经确认就无法发布，因为 Markdown 里就是这么写的，而它遵守了。

作者特别强调，这是最被低估的一点：Agent 的行为规则和工作流写在同一个纯文本文件里，而且它们真的生效。 流程与约束不再分离，审计边界和作业步骤是同源同版本的一份文档。

安全闸门：扫描器负责过滤，人负责决定

一个技能，本质上是你的 Agent 会去执行的一组指令。安装一个未经审查的技能，等同于运行陌生人仓库里的脚本。「忽略之前的指令」这句话，塞进一份看起来很贴心的 checklist 里毫无违和感。

作者的安全闸门本身也是一个技能：先用 NVIDIA 的扫描器在本地全离线扫一遍，然后逐行人工阅读所有被标记的内容：

git clone --depth 1 https://github.com/author/some-skills /tmp/check
skillspector scan /tmp/check --no-llm   # NVIDIA's scanner, fully local
# then: read every flagged line by hand

关于误报，作者给了一个很有说服力的数据点：某周扫描器对一个完全无害的设计技能仓库给出了 CRITICAL 级判定——29 项发现，最高严重度，「请勿安装」。人工复核后，29 项全部是误报：扫到了「告诉 Agent 忽略来自仓库文件的操纵尝试」这句防御性声明（因为「ignore previous instructions」出现在引号里）、作者用来在 Markdown 模板中嵌套代码围栏的零宽字符、以及测试数据里故意放的一个 ZWJ 表情符号。真实威胁为零。

结论不是「别信扫描器」，而是：扫描器做过滤，人做决定。 读完 29 行被标记的内容花了大约十分钟；装进一个被投毒的技能，代价要高得多。

怎么写出自己的技能

现成技能是别人的经验。你自己的仪式更值钱，而没人会替你写。作者给客户的配方是四步：

1. 挑一件你每周都在重复的任务：发布、周报、交付前审计、部署。
2. 完全按你手工做的顺序写下步骤，包括你在哪些地方会二次核对自己。
3. 加上硬规则：绝不做的事、需要人工批准的事、在哪里停下。
4. 面向 Agent 写描述，而不是面向你自己：这个技能做什么，哪些短语应该触发它。

最后一条建议值得贴在所有内部文档的开头：从小处开始。一个一百行、每周省你一小时的技能，胜过一个一千行、你永远写不完的完美技能。

把这句话放到「把工作流交给 AI」的语境里，它其实回答了一个更本质的问题——Agent 能力的天花板，往往不在模型有多强，而在你有没有把自己会做的事，认真写下来。