为数字营销写 Agent Skills：30 个生产级 Skill 总结出的 6 条规则

我永远不会忘记那个早晨，我意识到自己那个表现最好的 ChatGPT 对话窗口其实没法规模化。我花 40 分钟调整了一条 prompt——把一段一行的 brief 变成 12 封邮件的生命周期序列——结果不到一周，我在三个新会话里都粘过同一条 prompt，三次输出都不太一样。

那其实是一条 prompt 冒充了一个工作流。我真正想复用的，是那个工作流本身——它本来就该是一个 skill。

如果你 2026 年在用 AI agents，「skill」这个词你应该已经听过太多遍了。Anthropic 在 2025 年 10 月推出 Claude Skills、2026 年开源了整套规范；Andrew Ng 开了一门课；几乎每个 agent 平台现在都有自己的「skills 系统」。但对营销人来说，这恰恰是 agent 技术栈里真正能赚到钱的那一层：skill 是「复用」的最小单位——你把一条你信得过的工作流打包起来，让 agent 明天、换一家客户还能再跑一遍，而你不用再重新输入那条 system prompt。

我自己现在参与写过超过 30 个数字营销 skill——包括这个博客自己跑着的那几个（写文章、生成封面图、规划 90 天内容日历）。绝大多数让 skill 好用的东西都很不性感：克制的边界、对触发条件的清晰定义、以及对自己会写错什么事的诚实。下面是浓缩版。

一、先写 description，再写正文

一个 skill 由两部分组成：YAML frontmatter（接口）和 Markdown 正文（执行）。大多数人——包括第一天上手的我——都想直接写正文，去写那些具体的指令。不要。先写 name 和 description。

description 就是这个 skill 的「触发器」。它是 agent 不读正文就能看见的唯一一段元数据。当一个用户的请求是「给我写个欢迎序列」的时候，agent 是扫过所有 skill 的 description 来挑的。一个模糊的 description（"writes marketing emails"）一定输给一条具体的（"drafts a 7-email SaaS welcome series, 14-day cadence, subject lines use the HML 框架, with send-time optimization baked in"）。

我现在用的检验方法是这样：一个称职的初级营销人只读这一句 description，能不能知道什么时候该用、什么时候不该用？如果他说「只有当…才用」，那你就在 description 里把那层约束写进去。

二、一个 skill 只做一条工作流

早期 skill 设计里最常见的错误就是「打包」。大家想做「一个 SEO skill」——既做关键词研究，又做 on-page 优化、内链、内容刷新。然后写一份 4000 字的 SKILL.md，到第十一步就开始跑偏。

拆。Skill 应该对应一条 工作流（输入 → 转换 → 输出），即便底层能力是宽的。如果你的「SEO」工作流里有一条分支要做关键词研究、另一条分支要做内链规划，那就是两个 skill。每个变成 200–600 行专注的 Markdown，而不是一个又长又糊的文件。Agent 推理起来更准，你 debug 起来更快，你单独甩一个给同事的时候也不用背着别的包袱。

在做营销的时候有一个挺好用的判断标准：如果一个工作流的 输出物 不同（一份内容 brief vs. 一份内链计划 vs. 一张内容刷新工单），那就是不同的 skill。

三、把品牌（具体地说，是你的客户的声音）烤进去

通用 skill 一个季度就过时了。我今年 2 月写的那条「12 封生命周期邮件」工作流是有用的——但只是「大致上」。同一个工作流，加上 200 字的品牌定义（禁用词：synergy、ecosystem、unlock；偏好开场：「快问一句——」、「我注意到…」），出来的邮件听起来像那个品牌，而不是像一个 LLM。

模式是这样的：SKILL.md 里保留通用工作流指令，把品牌相关的输入（禁用/必用词列表、范例段落、产品类目）放在一份旁路文件里，让 skill 按条件加载。这样一套 skill 能服务五个客户而不用 fork 代码。

这也是你能去掉「AI 味」的方式——那些节奏套话和烂大街词。把你自己的写进去。

四、确定性部分用脚本，判断部分用 prompt

这一条我承认想明白用了我太长时间。在一个营销 skill 里，有些事永远不该被重新决策（JSON-LD schema 模板、RSA headline 的 pin 数量、UTM 参数的标准顺序），有些事是真的能让模型去判断（邮件标题、meta description、hook）。别让 LLM 每跑一遍都重新算第一组。给它一个脚本——Python、shell、哪怕是 Notion 的公式——prompt 只接管那些「变一下零成本」的部分。

这能省 token，能让输出更稳，让失败模式更可调试。Skill 出问题的时候，确定性脚本是「砰」一下响的（栈追踪），prompt 是悄悄变差的（标题略微没那么好）。

五、把失败模式也写进去

这一条几乎没人写。一个好的 skill 要告诉 agent：事情 不 走 happy path 的时候怎么办。没有 GSC 权限？SKILL.md 里写上 fallback 用这个格式。数字低于 50？输出这一段免责声明。工具调用被限速？排队重试，不要死循环。

失败模式那一段，也是你把团队经验固化下来的地方。「如果品牌是英式英语，把美式拼写改过来。」「如果输入是 YouTube 链接，永远先取字幕；如果是播客 RSS，取最近 5 集；如果是文章 URL，取正文再跟读前 3 个外链。」这些都是人脑默认会做的、LLM 不会自动做的判断——你得钉进去。

六、给 skill 打版本号，像代码一样管

Skill 是活的东西。我 4 个月前写的某个 skill，被改过 20 多次——看完一次真实翻车、改过一次模型默认值、换过一次工具 API。文件夹结构（SKILL.md + scripts/ + references/）天然适合干这件事：diff Markdown、给脚本存版本、淘汰过期引用。

我在 frontmatter 里加一行 last-updated，在 SKILL.md 里塞一个一行 CHANGELOG 备注。成本是每次多几秒钟编辑时间；收益是 6 个月后同事接手的时候，他能读懂哪些试过、哪些被放弃、哪些被替换。

现在该写哪一条 skill

如果你这季度只想造一个，就造那个你一直在手工反复干的事。我的是内容生产。付费团队可能是 PMax 素材刷新。SEO 是 4 步内容 brief 流水线。

一个 skill 不需要脚本。不需要 references。它只需要一条精确的 frontmatter description、一段清晰的工作流正文，和一个诚实的名字告诉你它能做什么、不能做什么。从这开始。

等你写完第一条，后面三条很快就会来——因为 AI 工作真正能规模化，靠的不是给 ChatGPT 多开标签页，而是把你已经赢了的工作流打包起来。