营销Skill怎么写SKILL.md：从触发词到输出契约的完整编写指南

SKILL.md 不是一个随便写的说明书，而是一份可被 Agent 解析、执行和验收的契约文件。一个写得好的 SKILL.md 能让同一个 Skill 在 WorkBuddy、Claude Code、ZCode 等不同 Agent 上稳定运行；一个写得差的 SKILL.md 轻则输出跑偏，重则误删文件或泄露密钥。本文从营销从业者的视角，拆解一份合格 SKILL.md 的完整写法和每个模块的关键决策点。

SKILL.md 解决什么问题——先搞清楚要不要写

不是每个营销任务都需要写成 Skill。如果你只是偶尔需要 AI 帮忙想一句广告语，一段 Prompt 就够了。只有当你发现同一个任务反复做、每次输入变量不同但流程固定、而且输出的质量判断标准可以明确时，才值得把它封装成 Skill。常见的高价值场景包括：SEO 文章从选题到发布的批量生产、竞品内容矩阵的定期扫描、多平台社媒文案的适配改写、冷邮件模板的个性化填充。

如果任务每次都需要大量人工判断且无法用规则约束——比如判断一个创意概念是否"高级"——那么写成 Skill 的价值有限，更适合保留为 Prompt + 人工审核的协作模式。

SKILL.md 的整体结构：七个必需模块

一份面向营销任务的 SKILL.md 至少包含七个模块。顺序不必死板，但每个模块的信息都不能缺失。以下按推荐顺序逐一拆解。

模块一：Skill 身份卡。这是 Agent 判断"该不该调用我"的第一关。至少写清三行：Skill 的准确名称（与文件名一致）、一句话说明它解决什么营销任务、适用的 Agent 平台列表。如果只适配了 WorkBuddy 但没测试过 Claude Code，就只写 WorkBuddy，不要写"全平台兼容"。

模块二：触发词与触发条件。这是整个文件中最容易被写坏的模块。触发词不是"跟营销相关的词都写上去"。好的触发词应该精确到"用户说了这句话，大概率就是想执行这个任务"。例如一个"SEO 标题生成 Skill"的触发词可以写"SEO标题、搜索标题、文章标题怎么起"，但不要写"SEO、搜索引擎、数字营销"这种过于宽泛的词——那会触发误调用。

模块三：输入契约。明确告诉使用者和 Agent：调用这个 Skill 之前必须准备好哪些信息。每个输入变量都要写清格式、示例和必填/选填标记。营销 Skill 中最常被遗漏的输入包括：品牌禁忌词清单、目标搜索地域、内容发布渠道的具体格式要求。

模块四：执行流程。用有序步骤描述 Skill 的工作过程。每一步写清楚动作、输入来源、输出目标。如果某一步依赖外部 API 或文件系统，必须标注。不要写"然后 AI 分析数据"这种模糊描述——写"读取上一步输出的 CSV，按'搜索量'列降序排列，取前 20 行，对每行的关键词生成一个标题方案"。

模块五：输出契约。这是最容易被写成"输出一篇好文章"的模块。输出契约必须回答三个问题：输出什么格式（JSON、Markdown、HTML 还是纯文本）、包含哪些必需字段、怎样判断输出合格。例如一个 SEO 文章 Skill 的输出契约可以写："输出为两段式 HTML：cms-metadata 块（含 title、seo_title、seo_description、seo_keywords 数组）和 article-content 块（正文以 p 标签开头，不包含 h1，H2 数量不少于 4 个）。"

模块六：安全与权限规则。这一模块的缺失是生产事故的常见原因。如果 Skill 会写文件、调 API、发邮件或操作 CMS，必须声明：需要的具体权限、不可逆操作（如公开发布、删除数据）的确认机制、密钥和 Token 的处理方式。一个好的安全规则示例："Skill 不得在未收到用户明确'发布'指令时调用 CMS 发布接口；默认行为是保存为草稿。"

模块七：自检与排错。内置一套 Skill 执行完毕后的自检规则。至少覆盖：标题是否包含核心关键词、正文长度是否达标、输出格式是否与契约一致、是否出现禁止使用的品牌词或空泛表达。还可以附加常见失败模式，例如"输出标题超过 30 个汉字"时要求自动截断并提示用户确认。

触发词的写法：精确比多更重要

触发词的设计遵循"窄入口"原则。以"竞品内容分析 Skill"为例。不要这样写触发词："竞品、竞争对手、分析、市场"。这会导致用户每次提到"竞品"这个词，Skill 就被激活，哪怕用户只是想问"竞品最近发了什么文章"——这个任务可能需要的是网页采集 Skill，不是分析 Skill。

正确写法是列出用户真正要执行这个任务时会说的完整短语："分析竞品内容矩阵、竞品文章都有哪些主题、对比我们和竞品的内容策略、竞品SEO关键词覆盖分析"。每条触发词都是一个完整意图，不是孤立的关键词。

触发词还有个隐藏坑：中英文混合。如果 Skill 面向中文用户但涉及英文工具名（如 Google Ads、Meta），触发词可以同时包含中英文表达，但要确保同一意图的中英文版本都被覆盖。"Google Ads 文案怎么写"和"怎么写谷歌广告文案"应该都触发同一个 Skill。

输入输出契约：Skill 质量的硬指标

输入契约写得好不好，直接影响 Skill 的使用率。好的输入契约让人一眼就知道"我要准备什么"，而不是需要读完整个文件才能开始。每个输入变量推荐用表格呈现：变量名、类型、示例值、为空时的默认行为。

输出契约中有一个经常被忽略的点：失败时的输出格式。Skill 不可能 100% 成功——API 可能超时、文件可能不存在、密钥可能过期。输出契约中应该定义失败时返回什么：是返回一个错误码和原因，还是降级输出一个简化版结果，还是直接中断并提示用户下一步操作。

举个具体例子。一个"Google Ads 关键词拓展 Skill"的输出契约可以写："成功时返回 JSON 数组，每个元素包含 keyword、search_volume_range、competition_level、suggested_match_type。当 Google Ads API 返回 429（配额超限）时，返回 {"error": "rate_limited", "retry_after_seconds": 60}，并提示用户等待后重试，不要自动循环请求。"

安全规则：最容易出事故的模块

营销 Skill 涉及的安全问题集中在外发和写入两类。外发风险包括：自动发送邮件给真实客户、在社媒平台自动发布内容、将内部数据上传到第三方 API。写入风险包括：覆盖已发布的 CMS 文章、修改正在投放的广告、删除历史数据。

安全规则的核心原则是"默认不执行不可逆操作"。具体做法：将"读操作"和"写操作"明确分开，读操作（查关键词、生成草稿、拉取数据）可以自动执行，写操作（发布、发送、删除、覆盖）必须有显式确认。如果 Skill 涉及费用——比如调用付费 API 或修改广告出价——必须在安全规则中声明费用上限或确认机制。

密钥管理是另一个重灾区。不要在 SKILL.md 中写死任何 Token、密码或 API Key。安全规则应写："Skill 从运行环境的配置文件中读取凭据，不在指令正文中暴露密钥。若凭据缺失，Skill 应提示用户配置，而不是用空值尝试连接。"

本站原创 SKILL.md 完整模板

以下是一份可直接修改使用的营销 Skill 模板。将中括号中的内容替换为你的实际信息即可。

Skill 名称：[你的Skill名称] 适用平台：[WorkBuddy / Claude Code / ZCode / 其他] 一句话描述：[这个Skill解决什么营销任务]

触发词：[列出5-10个用户会说出的完整短语] 不适用场景：[什么情况下不应调用这个Skill]

输入变量： - [变量名1]：[类型]，[示例值]，[必填/选填]，[为空时的默认行为] - [变量名2]：[类型]，[示例值]，[必填/选填]，[为空时的默认行为]

执行流程： 步骤1：[读取输入变量，校验必填项是否完整] 步骤2：[核心处理逻辑] 步骤3：[格式化输出] 步骤4：[执行自检]

输出契约： 成功时：[输出格式和必需字段] 失败时：[降级策略或错误提示] 质量门槛：[输出需满足的最低标准]

安全规则： - [写操作需用户确认] - [凭据从配置文件读取] - [不可逆操作清单及确认机制]

自检清单： - [ ] [检查项1] - [ ] [检查项2] - [ ] [检查项3]

常见失败及处理： 问题1：[症状] → [原因] → [修复] 问题2：[症状] → [原因] → [修复]

五个常见错误及修正方法

错误一：把 SKILL.md 写成了使用说明书。说明书告诉人怎么用这个 Skill，SKILL.md 告诉 Agent 怎么执行这个任务。两者信息结构不同：说明书可以有"点击右上角按钮"这种 UI 描述，SKILL.md 只能有"读取输入变量中的 target_url 字段"这种程序化描述。

错误二：触发词太宽泛。一个只做"小红书文案改写"的 Skill，触发词写了"小红书、内容、文案、改写、营销"。结果用户在讨论小红书投放策略时也会触发这个 Skill，产生不相关输出。修正方法：只保留包含完整动作的词组，如"帮我改写小红书文案、把这篇改成小红书风格、小红书种草文案润色"。

错误三：输出契约只描述了"好"的情况。没有定义输出不达标时怎么办。修正方法：在输出契约中增加"最低通过标准"，例如"正文不得包含'在当今快速发展的时代''赋能''颠覆'等空泛表达；若检测到，自动替换为具体表述并标记修改位置"。

错误四：安全规则只写"注意安全"四个字。没有具体场景。修正方法：把安全规则写成"当 Skill 尝试以下操作时必须暂停并请求确认：修改 status 字段为 2（即公开发布）、调用邮件发送接口、删除任何文件或数据、向第三方域名发送请求"。

错误五：没有写核验日期和版本。一个半年前写的 Skill，依赖的 API 已经升级、Agent 平台已经改版，但文件里没有任何时间信息。使用者无法判断这个 Skill 是否还能用。修正方法：在文件顶部写清"核验日期：2026-08-05，适用环境：[具体Agent平台及版本]"，每次重大修改后更新日期。

Skill 写完后的验证方法

写完之后不要直接投入使用。先用三组测试验证：第一组是典型任务，输入最常见的变量组合，检查输出是否满足契约；第二组是边界任务，输入极端值（空关键词、超长品牌名、全英文输入），检查 Skill 是合理降级还是崩溃；第三组是误触发测试，输入与 Skill 任务不相关的指令，检查 Skill 是否被错误激活。

三组测试都通过后，找一位不熟悉这个 Skill 的同事读一遍 SKILL.md，看他能否在不额外解释的情况下理解输入要准备什么、输出会得到什么。如果同事需要追问三个以上问题，说明文件还需要补充信息。