把团队交付流程写成 Agent 技能

昨天晚上，我给自己的 coding agent 安装了十个新 skill。它们出自 Sonner toast 库背后的开发者 Emil Kowalski，教 Agent 如何做好设计工程：什么时候根本不该加动画、该用哪些缓动曲线，以及如何用最糟糕的数据对 UI 做压力测试。整个安装过程大约花了五分钟，大部分时间都用来阅读安全扫描结果。今天，Agent 写出的动画和移动端布局明显更好了。没有人改过模型。带来变化的，只是一个装着 Markdown 文件的文件夹。

Skill 到底是什么

Skill 是一个目录，里面有一个 SKILL.md 文件，还可以放一些辅助文件：模板、检查清单、小脚本。这个文件就是普通的 Markdown。下面是一个精简的真实示例：

---
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.
---
## 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 命令，而 Agent 会读取 description，判断这个 skill 是否适合当前任务。正文则是操作流程。巧妙之处在哪里？加载方式。会话开始时，我的 Agent 只保留我那 53 个 skill 的名称和一句话描述，合计只占几 KB 的上下文。只有任务匹配，或者我明确调用时，才会加载某个 skill 的全文。所以，你完全可以保留几十个 skill：不用的那些几乎没有成本。

显式调用，用斜杠命令：/seo-audit https://client-site.ru。Agent 会逐步执行流程，并传入参数。当流程本身很重要时，我会采用这种方式。隐式调用，则靠描述匹配：我用自然语言写下“在把这个网站交给客户之前检查一下”，Agent 就会将请求与各个 skill 的描述进行比较，加载合适的那个。这也是为什么 description 字段最值得你花时间打磨。优秀的 skill 作者甚至会专门添加一个 Triggers 章节，列出应该触发这个 skill 的确切措辞。

在我的配置里，skill 分为三层：

• ~/.agents/skills/<name>/SKILL.md 存放个人 skill，在每个项目中都可用。我的工作方式就放在这里：发布流水线、审查流程、安全关卡。
• 仓库里的 skills 文件夹存放团队 skill，并提交到 git。新员工拿到的是可执行的流程，而不是一篇没人打开的 wiki 页面。
• Plugin 缓存存放 marketplace 的技能包。它们适合通用需求；凡是与我的公司具体工作方式有关的内容，都应该放在前两层。

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

我最复杂的 skill，就是负责发布你正在读的这篇文章的那个。我输入 /smm-crosspost 并附上一个文件，或者直接说“给我们的博客写一篇文章”，Agent 就会：

1. 用英文撰写文章，再改编成俄语和哈萨克语，并在三个版本之间添加相互链接；
2. 按品牌风格生成一张 1200x630 的封面；
3. 将所有内容放入网站，补齐结构化数据（TechArticle、FAQPage、HowTo、hreflang）；
4. 停下来，把所有内容展示给我审批；
5. 在我回复“ok”后：部署，检查文章是否已经上线，并执行内部质量审查；
6. 为六个社交平台分别改编文案，每个平台都有自己的格式、语气和篇幅限制；
7. 对草稿执行一轮 human-lint 检查，把每一份文案及其评分展示给我；
8. 再次等待我明确回复“ok”。只有这时，它才会发布。

第 4 步和第 8 步是写进 skill 的硬性关卡。没有我的确认，Agent 就不能发布任何内容，因为 Markdown 里就是这么规定的，而它会遵守。这一点常被低估：约束 Agent 行为的规则，与工作流程写在同一份纯文本里，而且确实有效。

安全关卡

Skill 是一组 Agent 会遵循的指令。安装一个未经你审查的 skill，就像运行陌生人仓库里的脚本。“Ignore previous instructions” 完全可以藏进一份看起来很有帮助的检查清单。我的安全关卡本身也是一个 skill：

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

这里得说说误报，因为这件事很重要。本周，扫描器给那个无害的设计 skill 仓库报出了 CRITICAL：29 项发现，最高严重级别，建议“不要安装”。人工审查后发现，每一项都是误报。它误判了一条防御性指令：这条指令要求 Agent 忽略仓库文件中试图引导其行为的内容，因为引用文本里出现了“ignore previous instructions”；它还误判了作者为在 Markdown 模板中嵌套代码围栏而使用的零宽字符，以及特意放进测试数据中的一个 ZWJ emoji。真正的威胁是零。这里的教训不是“忽略扫描器”，而是：扫描器负责筛选，人负责判断。读完被标记的 29 行，我花了大约十分钟。安装一个被恶意污染的 skill，代价会大得多。

现成的 skill，承载的是别人的经验。你自己的固定工作流程更有价值，而且没人会替你写出来。下面是我给客户的方法：

1. 选一项你每周都会重复的任务：发布内容、写周报、交付前审查、部署。
2. 按你手动操作时的实际做法，准确写下每一步，包括你会在哪些地方再次核查。
3. 加上硬性规则：哪些事绝对不能做，哪些事需要人工审批，应该在哪里停下来。
4. 为 Agent 写 description，而不是为自己写：说明这个 skill 做什么，以及哪些措辞应该触发它。

从小处开始。一份能让你每周省下一小时的百行 skill，胜过一份永远写不完的千行完美 skill。

---

本文在 AI 辅助下完成起草和改编，并由作者在发布前审阅。

最初发表于 automata.sale 的文章《如何使用 Zcode skills 和命令》。

标签：aiagents、automation、webdev、productivity

如需进一步采取措施，你可以考虑屏蔽此人和／或举报滥用行为。