AI营销技能库marketingskills：Agent Skills实战与SEO内容生产

1. 从“marketingskills”说起一个被低估的AI营销技能库第一次看到marketingskills这个词是在翻 Claude Code 的 Agent Skills 规范文档时。当时我正在给一个做独立站的朋友搭内容生产流水线他抱怨说每次让 AI 写 SEO 文章出来的东西要么是“随着互联网的发展”这种废话要么就是关键词堆得连自己都看不下去。我让他把需求拆成技能包他一脸懵技能包是什么marketingskills本质上就是一套面向营销场景的Agent Skills 集合。你可以把它理解成一个“营销工具箱”里面装着 SEO 审计、关键词聚类、FAQ 结构化数据生成、竞品内容拆解、落地页文案优化等一堆可被 AI Agent 直接调用的技能模块。它不是一个 SaaS 产品也不是某个插件而是一组遵循 Agent Skills spec 的标准化技能定义文件配合 Claude Code 这类支持技能调用的 AI 编程助手使用。为什么这个东西值得单独拿出来讲因为绝大多数人用 AI 做营销还停留在“打开对话框输入 prompt复制结果”的阶段。这种方式的问题很明显每次都要重新描述背景、每次输出质量不稳定、无法沉淀方法论。而marketingskills的思路是把营销工作中反复出现的任务抽象成可复用、可组合、可版本管理的技能单元。你写一次 SEO 审计逻辑后面所有项目都能调用你调好一个 FAQ 结构化数据的生成模板团队里每个人都能用同一套标准。这篇文章适合三类人看一是正在用 Claude Code 或类似 AI Agent 工具做内容营销的从业者二是想把自己的营销经验沉淀成可复用资产的独立开发者或小团队三是对 Agent Skills spec 感兴趣、想搞清楚“技能”到底怎么落地到具体业务场景的技术同学。我会从设计思路、核心细节、实操过程、常见问题四个维度把marketingskills这套东西拆开讲透尽量做到你看完就能动手搭一套自己的版本。2. 内容整体设计与思路拆解2.1 为什么营销场景特别适合做成 Agent Skills营销工作的一个显著特点是任务高度重复但每次的输入和上下文又略有不同。比如写产品页 SEO 文案核心逻辑永远是“目标关键词 用户意图 竞品差距 结构化数据”但每个产品的卖点、受众、竞争环境都不一样。这种“框架稳定、变量丰富”的任务恰恰是 Agent Skills 最擅长的场景。传统做法是写一个超级 prompt把所有要求塞进去。我试过一个完整的 SEO 文章生成 prompt 写到 2000 字很正常而且每次调用都要重新贴一遍。更麻烦的是当你想调整某个环节——比如把 FAQ 部分的生成逻辑从“罗列问题”改成“基于 People Also Ask 数据生成”——你得在那一大坨 prompt 里找到对应段落改完还要担心会不会影响其他部分。Agent Skills 的思路完全不同。它把一个大任务拆成多个独立技能每个技能有自己的触发条件、输入输出定义和执行逻辑。写 SEO 文章这件事可以拆成keyword-research关键词调研、serp-analysis搜索结果页分析、content-outline内容大纲生成、faq-schemaFAQ 结构化数据生成、meta-description元描述优化等。每个技能单独维护单独测试单独迭代。需要哪个调哪个也可以串起来形成工作流。提示Agent Skills spec 的核心思想是“技能即文件”。每个技能通常是一个 Markdown 或 JSON 文件里面定义了技能名称、描述、触发条件、执行步骤和输出格式。Claude Code 在运行时根据当前任务自动匹配并加载相关技能。2.2 技能拆分的粒度怎么把握这是我在实际搭建过程中踩坑最多的地方。一开始我把粒度拆得太细比如“生成 H1 标题”单独做一个技能“生成 H2 标题”再做一个。结果就是技能数量爆炸调用链变得极其复杂AI 在执行时经常搞不清楚该先调哪个。后来我总结出一个原则一个技能应该对应一个完整的、有独立交付价值的子任务。什么叫“独立交付价值”就是你把它的输出单独拿出来是能直接用的不需要依赖其他技能的输出来“补全”。比如faq-schema这个技能它的输出就是一段可以直接嵌入页面的 JSON-LD 结构化数据这就是独立交付价值。而“生成 H1 标题”的输出只是一个标题它必须配合正文才有意义所以它不应该是一个独立技能而应该作为content-outline技能内部的一个步骤。按照这个原则我把marketingskills的技能集重新梳理了一遍最终形成下面这个分层结构层级技能类别代表技能交付物调研层关键词与竞品分析keyword-cluster, serp-gap关键词簇、竞品内容差距报告规划层内容架构设计content-outline, intent-map内容大纲、搜索意图映射表生产层内容生成与优化seo-copy, faq-schema, meta-optimize正文、FAQ结构化数据、元描述审计层质量检查与迭代seo-audit, readability-check审计报告、优化建议这个分层的好处是每一层都可以独立使用也可以按顺序串联。比如你只想优化现有页面的 FAQ 部分直接调faq-schema就行不需要跑完整流程。你要从零做一个新页面就从调研层开始往下走。2.3 为什么选择 Claude Code 作为运行环境市面上支持 Agent Skills 的工具不止 Claude Code 一个但我最终选它作为主要运行环境原因有几个。第一Claude Code 对技能文件的加载机制比较透明。你把它放在项目的.claude/skills/目录下它就能自动识别。技能之间的依赖关系、调用顺序都可以通过文件内的描述来定义不需要额外写胶水代码。第二Claude Code 可以直接执行终端命令。这意味着你的技能可以调用外部工具——比如用curl拉取搜索结果页、用 Python 脚本做关键词聚类、用jq处理 JSON 数据。营销技能经常需要跟外部数据源打交道这个能力很关键。第三它对本地模型的支持比较灵活。如果你不想用云端 API可以通过配置接入本地运行的模型。虽然本地模型在复杂推理上可能不如云端版本但对于一些标准化的营销任务——比如生成 FAQ 结构化数据、检查关键词密度——本地模型完全够用而且数据不出本地对处理客户敏感信息比较友好。注意Claude Code 的技能加载有优先级规则。项目级技能会覆盖全局技能同名技能以项目级为准。这个机制可以用来做“通用技能 项目定制”的分层管理。3. 核心细节解析与实操要点3.1 技能文件的结构与关键字段一个标准的 Agent Skill 文件通常包含以下几个核心部分。我以faq-schema这个技能为例展示它的实际结构--- name: faq-schema description: 基于页面内容和目标关键词生成符合 Google FAQPage 结构化数据规范的 JSON-LD 代码 trigger: 当用户需要为页面添加 FAQ 结构化数据或提到 FAQ schema、FAQPage、结构化数据 时触发 inputs: - page_content: 页面正文内容 - target_keywords: 目标关键词列表 - max_questions: 最大问题数量默认 8 outputs: - jsonld_code: 可直接嵌入 HTML 的 JSON-LD 代码块 - question_list: 生成的问题列表用于人工审核 --- ## 执行步骤 1. 分析 page_content提取用户可能关心的核心问题 2. 结合 target_keywords确保问题覆盖主要搜索意图 3. 按照 FAQPage 规范生成 JSON-LD 结构 4. 验证 JSON-LD 语法正确性 5. 输出代码块和问题列表 ## 注意事项 - 每个问题必须对应一个简洁、准确的答案 - 答案长度控制在 50-150 字之间 - 避免生成与页面内容无关的问题 - 确保 JSON-LD 中的 URL 与页面实际 URL 一致这里有几个关键字段值得展开说。trigger字段决定了技能什么时候被激活。写得太宽泛技能会被频繁误触发写得太窄又可能该用的时候用不上。我的经验是trigger 里要包含三类信息任务描述、用户可能说的关键词、以及典型使用场景。比如faq-schema的 trigger 里既有“添加 FAQ 结构化数据”这样的任务描述也有“FAQ schema”、“FAQPage”这样的关键词还有“为页面添加”这样的场景提示。inputs和outputs字段看起来简单但它们是技能可组合的关键。当你要把多个技能串成工作流时上一个技能的 outputs 必须能匹配下一个技能的 inputs。我在设计时会给每个输入输出定义明确的数据类型和格式比如target_keywords统一用字符串数组jsonld_code统一用带语言标记的代码块。这样在串联时就不需要做额外的格式转换。3.2 SEO 技能的核心逻辑从关键词到结构化数据marketingskills里最核心的一条链路是从关键词调研到最终页面结构化数据的完整流程。我把它拆成四个关键环节每个环节对应一个技能。第一个环节是关键词聚类。很多人做 SEO 的第一步是拉一堆关键词然后按搜索量排序挑大的做。这个做法的问题在于搜索量大的词往往竞争也大而且不同关键词背后的搜索意图可能完全不同。keyword-cluster技能的逻辑是先按搜索意图分组再在每组内部按搜索量排序。搜索意图通常分四类信息型我想了解、导航型我想去某个地方、商业型我想比较、交易型我想买。同一个意图组里的关键词可以用同一篇内容来覆盖不同意图组的关键词需要不同的页面。第二个环节是搜索结果页分析。serp-gap技能会拉取目标关键词的搜索结果页分析排名前五的页面都覆盖了哪些子话题、内容长度大概多少、有没有用结构化数据、FAQ 部分是怎么组织的。然后跟你的内容大纲做对比找出“别人有我没有”和“我有别人没有”的差距。这个分析结果直接决定了你的内容能不能比现有结果更全面。第三个环节是内容大纲生成。content-outline技能接收关键词簇和 SERP 差距分析结果输出一个带 H2/H3 层级的内容大纲。每个 H2 对应一个子话题每个 H3 对应子话题下的具体要点。大纲里还会标注每个部分应该覆盖的关键词以及建议的字数分配。第四个环节是 FAQ 结构化数据生成。这就是前面举例的faq-schema技能。它从正文内容中提取用户可能关心的问题结合目标关键词生成 JSON-LD 代码。这里有个细节FAQ 的问题不应该跟正文的 H2/H3 标题重复而应该是正文没有直接展开、但用户确实会问的补充性问题。比如正文讲了“什么是独立站 SEO”FAQ 里就可以问“独立站 SEO 和平台内 SEO 有什么区别”。提示FAQPage 结构化数据在搜索结果里展示时会占据更多视觉空间对点击率有正向影响。但要注意Google 对 FAQ 内容的审核越来越严格问题必须是对页面内容的真实补充不能为了凑结构化数据而硬造问题。3.3 技能之间的依赖管理与版本控制当技能数量超过十个之后依赖管理就变成一个必须解决的问题。我遇到过的情况是修改了keyword-cluster的输出格式结果下游的content-outline因为输入格式不匹配而报错。更麻烦的是有些技能被多个工作流共用改一个可能影响好几条链路。我的解决方案是引入一个轻量的版本管理机制。每个技能文件里加一个version字段遵循语义化版本规范。当技能的输入输出格式发生不兼容变化时主版本号加一当只是内部逻辑优化、不影响接口时次版本号加一。然后在工作流定义文件里明确指定每个技能依赖的版本范围。# workflow: seo-content-pipeline steps: - skill: keyword-cluster version: ^2.0.0 - skill: serp-gap version: ^1.2.0 - skill: content-outline version: ^3.1.0 - skill: faq-schema version: ^1.0.0这样当某个技能升级到不兼容版本时依赖它的工作流会明确报错而不是静默产生错误结果。对于个人或小团队来说不需要搞复杂的 CI/CD用 Git 做版本控制在技能文件里维护一个 CHANGELOG 段落就够了。另一个实操要点是技能文件里要写清楚“这个技能不做什么”。比如faq-schema技能只负责生成结构化数据不负责把数据嵌入页面。嵌入页面的操作应该由另一个技能或人工完成。明确边界可以避免技能职责膨胀也能让调用者更清楚什么时候该用哪个技能。4. 实操过程与核心环节实现4.1 环境准备从零搭建技能运行环境假设你之前没用过 Claude Code也没接触过 Agent Skills下面是从零开始的完整步骤。我用 Ubuntu 环境做演示macOS 和 Windows 的差异我会在注意事项里说明。第一步是安装 Claude Code。官方提供了多种安装方式我推荐用 npm 安装因为后续升级比较方便# 确保 Node.js 版本在 18 以上 node --version # 全局安装 Claude Code npm install -g anthropic-ai/claude-code # 验证安装 claude --version安装完成后在项目根目录初始化 Claude Code 配置cd your-project claude init这个命令会生成一个.claude/目录里面包含配置文件。技能文件放在.claude/skills/下。如果目录不存在手动创建即可mkdir -p .claude/skills第二步是配置模型接入。如果你用官方订阅直接登录即可。如果你想接入第三方 API 或本地模型需要修改配置文件。以接入本地运行的模型为例在.claude/config.json里添加{ model: { provider: local, baseUrl: http://localhost:1234/v1, modelName: your-local-model } }注意本地模型的上下文窗口通常比云端模型小技能文件里的描述要尽量精简。如果技能逻辑复杂建议拆成多个小技能避免单次加载内容过多导致截断。第三步是创建第一个技能文件。在.claude/skills/下新建faq-schema.md把前面展示的技能结构复制进去。然后启动 Claude Codeclaude在对话里输入“帮我为这个页面生成 FAQ 结构化数据”如果技能配置正确Claude Code 会自动加载faq-schema技能并执行。4.2 关键词聚类技能的完整实现keyword-cluster是我用得最多的技能之一下面展示它的完整实现逻辑。这个技能的核心任务是把一堆原始关键词按照搜索意图和主题相关性分成若干个“内容簇”每个簇对应一篇内容。技能文件的关键部分如下--- name: keyword-cluster description: 将原始关键词列表按搜索意图和主题相关性聚类输出可直接用于内容规划的关键词簇 trigger: 当用户提供关键词列表并需要分组、聚类、按意图分类时触发 inputs: - raw_keywords: 原始关键词列表每行一个 - min_cluster_size: 最小簇大小默认 3 outputs: - clusters: 关键词簇列表每个簇包含意图类型、核心词、长尾词、建议内容标题 --- ## 执行步骤 1. 对每个关键词进行意图分类 - 信息型包含什么是、如何、为什么、教程、指南等 - 商业型包含对比、哪个好、推荐、评测等 - 交易型包含购买、价格、折扣、优惠等 - 导航型包含品牌名、产品名、特定平台名等 2. 在同一意图类别内按主题相关性进行二次聚类 - 提取每个关键词的核心名词短语 - 计算核心短语之间的语义相似度 - 相似度超过阈值的归为一簇 3. 为每个簇生成建议内容标题 - 信息型簇使用什么是X、X完整指南等标题模式 - 商业型簇使用X对比A vs B、2024年X推荐等标题模式 - 交易型簇使用X购买指南、X价格对比等标题模式 4. 输出聚类结果按簇大小降序排列实际运行时我会把从关键词工具导出的 CSV 文件转成纯文本列表然后调用这个技能。输出结果是一个结构化的 Markdown 表格每个簇一行包含意图类型、核心词、长尾词数量和内容标题建议。这里有个实操细节意图分类的准确率直接影响后续所有环节。我试过纯靠 AI 分类准确率大概在 80% 左右主要错误集中在“商业型”和“信息型”的边界上。比如“独立站 SEO 工具推荐”这个词AI 有时会分到信息型但实际上它更接近商业型。我的做法是在技能里加一个“人工复核”步骤让 AI 把分类结果和置信度一起输出置信度低于阈值的标出来人工确认后再进入下一步。4.3 FAQ 结构化数据生成的参数计算与验证faq-schema技能的输出质量很大程度上取决于问题筛选和答案生成的参数设置。下面是我在实际项目中总结的一套参数逻辑。问题数量不是越多越好。Google 官方文档没有明确限制但实际测试下来超过 10 个问题的 FAQ 结构化数据在搜索结果里展示的概率反而下降。我的经验值是 6-8 个问题覆盖 3-4 个核心搜索意图即可。问题长度控制在 10-20 个字之间。太短信息量不足太长在移动端展示会被截断。比如“独立站 SEO 怎么做”是 8 个字可以“独立站 SEO 应该从哪些方面入手才能快速见效”是 20 个字偏长可以精简为“独立站 SEO 快速见效的方法”。答案长度50-150 字。这个范围是经过测试的低于 50 字可能被判定为内容单薄高于 150 字在结构化数据展示时会被截断。答案要直接回答问题不要绕弯子。关键词覆盖每个问题里至少包含一个目标关键词但不要堆砌。比如目标关键词是“独立站 SEO”问题可以是“独立站 SEO 和平台内 SEO 有什么区别”答案里自然带出“独立站 SEO”和“平台内 SEO”的对比。生成完成后必须验证 JSON-LD 的语法正确性。我通常用两种方式一是用在线 JSON 校验工具检查语法二是用 Google 的 Rich Results Test 工具检查是否符合 FAQPage 规范。后者更严格会直接告诉你哪些字段缺失或格式错误。{ context: https://schema.org, type: FAQPage, mainEntity: [ { type: Question, name: 独立站 SEO 和平台内 SEO 有什么区别, acceptedAnswer: { type: Answer, text: 独立站 SEO 需要自己搭建网站、管理域名和技术架构优化自由度更高但门槛也更高。平台内 SEO 则是在已有平台上优化商品或内容排名受平台规则限制较多但起步更快。 } } ] }提示JSON-LD 代码要放在页面的head或body里用script typeapplication/ldjson标签包裹。同一个页面可以有多组结构化数据但 FAQPage 只能有一组。4.4 把技能串成工作流一个完整的 SEO 内容生产案例下面用一个真实案例展示如何把多个技能串成完整工作流。客户是一个做家居用品的独立站目标关键词是“小户型收纳技巧”。第一步关键词聚类。把从关键词工具导出的 200 多个相关词输入keyword-cluster技能。输出结果分成 5 个簇收纳基础概念、收纳工具选择、空间利用技巧、收纳习惯养成、收纳案例参考。其中“空间利用技巧”这个簇最大包含 60 多个长尾词建议作为主攻方向。第二步SERP 差距分析。用serp-gap技能分析“小户型收纳技巧”的搜索结果页。发现排名前五的页面平均字数在 2500 字左右都包含“垂直空间利用”、“多功能家具”、“隐藏式收纳”三个子话题。但都没有覆盖“租房场景下的收纳方案”这个角度。这就是内容差距也是我们的切入点。第三步内容大纲生成。content-outline技能根据关键词簇和 SERP 差距生成如下大纲H1小户型收纳技巧从垂直空间到租房方案的完整指南H2为什么小户型需要专门的收纳策略H2垂直空间利用的 5 个实操方法H2多功能家具的选择与避坑H2隐藏式收纳的设计思路H2租房场景下的低成本收纳方案差异化内容H2常见收纳误区与纠正H2FAQ第四步内容生成与优化。seo-copy技能根据大纲生成正文faq-schema生成 FAQ 结构化数据meta-optimize生成标题标签和元描述。最终产出的页面在发布后第三周进入搜索结果前 20第六周进入前 10。这个案例里技能串联的关键是数据格式的统一。每个技能的输出都遵循同一套 Markdown 结构下一个技能能直接解析。如果格式不统一中间就需要人工转换效率会大打折扣。5. 常见问题与排查技巧实录5.1 技能不触发或误触发怎么办这是新手最常遇到的问题。你明明写了技能文件但 Claude Code 就是不用或者不该用的时候它偏偏用了。排查思路一检查 trigger 描述是否匹配。Claude Code 是根据 trigger 字段和当前对话的语义相似度来决定是否加载技能的。如果你的 trigger 写的是“生成 FAQ 结构化数据”但用户说的是“帮我加个 FAQ 的 schema”语义相似度可能不够高。解决办法是在 trigger 里补充同义词和常见表达方式。排查思路二检查技能文件路径。项目级技能必须放在.claude/skills/目录下全局技能放在~/.claude/skills/下。路径不对技能不会被加载。可以用claude skills list命令查看当前已加载的技能列表。排查思路三检查文件格式。技能文件必须是 Markdown 格式且开头的 YAML front matter 必须用---包裹。YAML 语法错误会导致整个文件被跳过。我遇到过因为description字段里用了冒号但没加引号导致解析失败的情况。误触发的处理如果某个技能被频繁误触发可以在 trigger 里加否定条件。比如faq-schema技能可以加一句“当用户只是询问 FAQ 概念而非要求生成代码时不触发此技能”。5.2 输出质量不稳定的调优方法同一个技能有时候输出很好有时候输出很水。这种不稳定性通常来自三个原因。原因一输入信息不足。比如content-outline技能需要关键词簇和 SERP 分析结果作为输入如果你只给了关键词没给 SERP 分析它就只能靠猜。解决办法是在技能定义里明确标注“必需输入”和“可选输入”必需输入缺失时技能应该报错而不是硬着头皮生成。原因二技能内部步骤太笼统。“分析页面内容”这种描述太模糊AI 每次的理解可能都不一样。要改成具体的操作指令比如“提取页面中所有 H2 和 H3 标题”、“统计每个段落的字数”、“识别包含目标关键词的句子”。原因三缺少输出示例。在技能文件里加一个“输出示例”段落展示期望的输出格式和内容质量。这能显著提升输出的一致性。示例不需要很长一个完整的片段就够了。5.3 常见问题速查表问题现象可能原因排查方法解决方案技能完全不触发路径错误或格式错误用claude skills list查看检查路径和 YAML 格式技能触发但输出为空必需输入缺失查看技能定义的 inputs补充缺失的输入数据输出格式与预期不符输出示例缺失或模糊对比技能定义和实际输出添加明确的输出示例多个技能冲突trigger 描述重叠查看同时加载的技能列表调整 trigger 增加区分度本地模型输出质量差模型能力不足或上下文超限检查模型规格和输入长度换用更大模型或拆分技能JSON-LD 验证不通过字段缺失或格式错误用 Rich Results Test 检查对照官方文档补全字段5.4 几个我踩过的坑坑一技能文件里写太多“背景介绍”。一开始我觉得技能文件应该像文档一样把背景、原理、注意事项都写清楚。结果发现技能文件是给 AI 读的不是给人读的。背景介绍占用了大量上下文窗口反而挤占了真正有用的执行指令。后来我把技能文件精简到只保留触发条件、输入输出定义、执行步骤、注意事项。背景知识放到单独的 README 里给人看。坑二忽略技能的“失败处理”。技能执行失败时应该怎么办是报错停止还是降级处理我一开始没考虑这个问题结果某个技能因为输入数据格式不对而静默失败下游技能拿到空数据继续执行最后产出一堆垃圾。后来我在每个技能里加了“失败处理”段落明确定义什么情况下报错、什么情况下降级、什么情况下跳过。坑三技能版本升级没有通知机制。我改了一个技能的输入格式但忘了更新依赖它的工作流。结果那个工作流跑出来的结果全错了我还花了一下午排查。后来我在技能文件里加了breaking_changes字段记录不兼容变更并在工作流定义里做版本约束。虽然麻烦一点但比事后排查省时间。坑四过度依赖 AI 生成结构化数据。FAQ 结构化数据涉及具体的问答内容AI 生成的问题有时会偏离页面实际内容。我的做法是让 AI 生成候选问题列表人工筛选后再生成最终的 JSON-LD。多这一步但避免了结构化数据与页面内容不符导致的搜索惩罚。5.5 性能优化让技能跑得更快更稳当技能数量多、工作流长的时候性能会成为问题。我总结了几个优化点。减少不必要的技能加载。Claude Code 默认会加载所有匹配当前对话的技能。如果某个技能很少用可以把它移到“归档”目录需要时再移回来。或者用priority字段控制加载优先级低优先级的技能只在明确提及时才加载。缓存中间结果。关键词聚类和 SERP 分析的结果在同一个项目里通常不会频繁变化。可以把这些结果缓存到本地文件下次运行时直接读取避免重复调用。我在技能里加了一个cache_ttl字段定义缓存有效期过期后自动重新生成。并行执行独立技能。如果两个技能之间没有依赖关系可以并行执行。比如meta-optimize和faq-schema都依赖正文内容但彼此不依赖可以同时跑。Claude Code 支持在技能定义里标注parallelizable: true运行时会自动并行调度。控制上下文长度。每个技能加载时都会占用上下文窗口。如果技能文件太大或者输入数据太长会导致上下文超限。我的经验是单个技能文件控制在 500 字以内输入数据超过 2000 字时先做摘要再传入。6. 技能库的扩展与团队协作6.1 从个人工具到团队资产一个人用marketingskills和团队用完全是两回事。个人用的时候技能文件怎么写都行自己能看懂就行。团队用的时候需要考虑命名规范、文档标准、权限管理、变更流程。我们团队的做法是每个技能文件必须包含author、last_updated、reviewer三个字段。新增技能需要经过至少一人 review 才能合并到主分支。修改现有技能的输入输出定义需要通知所有依赖该技能的工作流负责人。这些流程听起来有点重但对于保证技能库的稳定性是必要的。另一个实践是建立“技能注册表”。用一个 Markdown 文件列出所有可用技能包含技能名称、功能描述、输入输出、依赖关系、负责人。新成员加入时看这个注册表就能知道有哪些技能可用不用翻遍整个目录。6.2 技能复用的边界不是所有营销任务都适合做成技能。我判断的标准是这个任务是否足够标准化以至于可以用固定的步骤描述清楚如果每次执行都需要大量人工判断和创意发挥那它更适合作为 prompt 模板而不是技能。比如“品牌调性文案撰写”就不太适合做成技能因为品牌调性很难用固定步骤描述每次都需要根据具体场景调整。但“品牌调性检查”可以做成技能——给定一段文案和品牌调性关键词列表检查文案是否符合调性要求输出符合度评分和修改建议。前者是创作后者是审计审计比创作更容易标准化。6.3 后续可以扩展的方向marketingskills目前主要覆盖 SEO 相关内容生产。后续可以往几个方向扩展。广告投放方向ad-copy-generator广告文案生成、audience-segmenter受众分群、bid-strategy-analyzer出价策略分析。社交媒体方向social-post-scheduler帖子排期、hashtag-researcher话题标签调研、engagement-analyzer互动分析。邮件营销方向subject-line-optimizer主题行优化、sequence-builder邮件序列构建、deliverability-checker送达率检查。每个方向都可以按照同样的思路先拆解任务再定义技能最后串联成工作流。关键是保持技能文件的标准化这样不同方向的技能才能互相组合。比如audience-segmenter的输出可以作为ad-copy-generator的输入engagement-analyzer的结果可以反馈给content-outline做优化。我在实际使用中体会最深的一点是技能库的价值不在于技能数量而在于技能之间的组合方式。十个能互相组合的技能比一百个孤立的技能有用得多。所以每次新增技能时我都会问自己这个技能能跟现有技能怎么配合它的输出能成为谁的输入想清楚这个问题再动手写技能文件。