1. 从marketingskills这个命名说起它到底想解决什么问题第一次看到marketingskills这个词我脑子里蹦出来的不是某个具体工具而是一类很典型的需求把营销这件事里那些重复、琐碎、需要经验判断的活儿拆成一个个可以被 AI agent 调用的技能单元。你可以把它理解成给 AI 装上一套营销工具箱——SEO 诊断是一个技能落地页转化率分析是一个技能关键词聚类是一个技能竞品文案拆解又是一个技能。每个技能独立封装按需调用。这个思路和 Claude Code 这类 AI agent 框架的设计哲学是一脉相承的。Claude Code 本身不是一个聊天机器人它是一个能在终端里读写文件、执行命令、调用外部工具的 agent 运行时。你给它一个任务它会自己规划步骤、调用工具、检查结果、迭代修正。而marketingskills要做的就是往这个运行时里注入营销领域的专业能力。为什么这件事值得单独拿出来讲因为营销领域有个很尴尬的特点门槛看起来很低但做好极难。谁都能写个标题谁都能发条朋友圈但真正要做出数据可验证的增长需要的是系统性的方法论加上大量重复执行。SEO 要持续产出结构化内容、监控排名、修复技术问题CRO 要不断做 A/B 测试、分析漏斗、优化文案内容营销要维护选题库、做关键词研究、保持发布节奏。这些活儿单拎出来都不难难的是持续做、规模化做、数据驱动地做。AI agent 恰好擅长这个。它不会累不会忘记检查清单不会因为今天心情不好就漏掉一个 meta description。但它缺的是知道该做什么和知道什么算做好了。marketingskills补的就是这块。所以这篇文章我想聊的不是怎么装 Claude Code这种基础操作——网上教程已经够多了。我想聊的是当你手里有了一个能执行命令、能读写文件的 AI agent 之后怎么把营销工作拆解成它能真正干好的技能模块以及在这个过程中会踩哪些坑。这套思路不管你用的是 Claude Code、还是通过 cc switch 接入的 DeepSeek、Qwen、GLM 等模型底层逻辑是通的。2. 把营销工作拆成 agent 可执行的技能单元2.1 什么样的任务适合封装成 skill不是所有营销工作都适合交给 agent。我试过把一些任务硬塞进去结果就是来回改 prompt 改到崩溃。后来总结出一个判断标准如果一个任务有明确的输入、明确的输出格式、可验证的成功标准那它就适合封装成 skill。举个例子。帮我写一篇博客这种任务就不适合因为成功标准太模糊agent 不知道写到什么程度算完。但给定一个目标关键词生成一篇包含 H2/H3 结构、FAQ schema 标记、内链建议的 SEO 文章草稿就非常适合——输入是关键词输出是结构化内容成功标准是 schema 校验通过、关键词密度在合理区间、标题层级正确。再比如优化落地页转化率太泛但分析落地页的 5 个核心元素标题、副标题、CTA、社会证明、表单字段数对照行业基准给出具体修改建议就可执行。agent 拿到页面内容后可以逐项检查、逐项打分、逐项给建议。我一般用下面这个清单来判断一个营销任务能不能 skill 化判断维度适合 skill 化不适合 skill 化输入明确性有具体输入关键词、URL、文案输入模糊帮我做营销输出可验证有格式要求、可程序化检查纯主观判断步骤可复现有固定流程或检查清单每次都要重新想频率高频重复一次性任务容错性错了能改成本低错了后果严重2.2 一个 SEO 内容技能的完整拆解拿 SEO 内容生产这个最典型的场景来说。一个完整的SEO 文章生成skill 应该包含哪些环节我拆下来大概是这样的第一步关键词意图判断。拿到一个关键词先判断搜索意图是信息型、导航型、商业型还是交易型。这个判断直接决定内容结构。信息型关键词适合长文教程交易型关键词适合产品页。agent 可以通过分析 SERP 前几名的内容类型来做这个判断。第二步SERP 竞品结构分析。抓取目标关键词排名前 5-10 的页面提取它们的标题层级、字数、覆盖的子话题、FAQ 数量。这一步的目的是找到内容基线——你要排上去至少得覆盖这些子话题。第三步内容大纲生成。基于竞品分析结果生成一个比竞品更全面的大纲。注意是更全面不是更长。Google 的 helpful content 更新之后堆字数已经没用了覆盖度和深度才是关键。第四步正文撰写。按大纲逐节写。这里有个技巧让 agent 先写每一节的核心论点一句话再展开成段落。这样能避免写着写着跑题。第五步结构化数据注入。根据内容类型自动生成 FAQPage、HowTo、Article 等 schema 标记。这一步是纯机械劳动最适合 agent 做也最容易出错所以要有校验环节。第六步内链和外链建议。扫描站内已有内容找出可以自然内链的页面同时标记出需要引用外部权威来源的位置。第七步质量自检。对照检查清单逐项过关键词是否出现在标题、H1、首段、至少一个 H2FAQ 是否覆盖了 People Also Ask 的问题有没有孤立的 H3meta description 是否在 150-160 字符这七步里第一步和第二步需要联网搜索能力第三步到第六步是纯生成第七步是校验。在 Claude Code 里你可以把每一步写成一个独立的脚本或 prompt 模板然后用一个主流程串起来。2.3 技能之间的依赖关系怎么处理单独一个 skill 好写难的是多个 skill 之间的协作。比如 CRO 分析 skill 需要用到 SEO skill 产出的页面数据内容更新 skill 又需要 CRO skill 的分析结论。如果每个 skill 都独立运行数据就对不上。我的做法是用一个共享的项目状态文件来串联。所有 skill 读写同一个 JSON 或 Markdown 文件里面记录当前项目的所有关键信息目标关键词、已发布内容列表、各页面表现数据、待办优化项。每个 skill 运行时先读这个文件执行完再写回去。这样做的好处是agent 每次运行都有完整的上下文不会失忆。坏处是文件会越来越大需要定期清理。我一般按项目分文件一个项目一个状态文件项目结束后归档。提示状态文件建议用 Markdown 而不是 JSON。因为 agent 读 Markdown 的理解能力比读 JSON 强而且你人工检查的时候也方便。JSON 适合程序读Markdown 适合 agent 读。3. Claude Code 作为营销 agent 运行时的实际配置3.1 为什么选 Claude Code 而不是别的方案市面上能跑 AI agent 的方案不少为什么营销场景我倾向 Claude Code核心原因是它对文件系统和终端命令的原生支持。营销工作大量涉及读写文件内容草稿、数据报告、配置文件和执行命令跑分析脚本、调 API、生成报告。Claude Code 在这块的设计是最顺手的——它直接在你的项目目录里工作能读能写能执行不需要你手动复制粘贴。另一个原因是它的工具调用机制足够灵活。你可以给它定义自定义工具比如查询关键词排名、获取页面性能数据、调用 SEO API。定义好之后agent 会在需要的时候自动调用。当然如果你因为各种原因用不了 Claude Code 官方服务通过 cc switch 这类工具接入 DeepSeek、Qwen、GLM 等模型也是可行的。底层逻辑一样只是模型能力有差异。实测下来在结构化任务比如按模板生成 schema 标记上国产模型表现已经不错但在需要复杂推理的任务比如判断搜索意图、分析竞品策略上还是有一定差距。这个差距在缩小但目前存在。3.2 项目目录结构怎么组织营销项目的目录结构很关键因为 agent 需要快速定位文件。我一般这样组织marketing-project/ ├── .claude/ # agent 配置 │ ├── skills/ # 技能定义 │ │ ├── seo-content.md │ │ ├── cro-analysis.md │ │ └── keyword-research.md │ └── config.json # 全局配置 ├── content/ # 内容产出 │ ├── drafts/ # 草稿 │ ├── published/ # 已发布 │ └── archive/ # 归档 ├── data/ # 数据文件 │ ├── keywords.csv # 关键词库 │ ├── rankings.json # 排名数据 │ └── analytics.json # 分析数据 ├── reports/ # 生成的报告 ├── scripts/ # 辅助脚本 │ ├── fetch-serp.py │ ├── check-schema.py │ └── analyze-page.py └── project-state.md # 项目状态文件这个结构的关键点是职责分离skills 放技能定义content 放内容data 放数据scripts 放脚本。agent 在运行时能清楚知道该去哪里找什么。.claude/skills/目录下的每个.md文件就是一个技能定义。文件内容就是给 agent 的指令包括这个技能做什么、输入是什么、输出格式是什么、有哪些注意事项。写得好不好直接决定技能能不能用。3.3 技能定义文件的写法一个技能定义文件我一般包含这几块角色设定一句话说清楚这个技能扮演什么角色。比如你是一个 SEO 内容策略师擅长根据搜索意图设计内容结构。输入说明明确告诉 agent 需要什么输入。是关键词是 URL是文件路径输入格式是什么执行步骤分步骤写清楚要做什么。步骤要具体到可执行不能是分析一下这种模糊指令。输出格式明确规定输出长什么样。用 Markdown 还是 JSON包含哪些字段有没有模板检查清单执行完之后要自检哪些项。这是保证质量的关键。边界条件什么情况下不应该执行这个技能或者应该报错退出。我踩过的一个坑是技能定义写得太长。一开始我觉得写得越详细越好结果 agent 读到后面忘了前面。后来发现单个技能定义控制在 500-800 字效果最好太长了反而执行质量下降。复杂的技能应该拆成多个小技能用主流程串起来。4. SEO 与 CRO 技能在 agent 里的落地细节4.1 FAQPage 结构化数据agent 最容易做错的地方FAQPage schema 是 SEO 里一个典型的看起来简单做起来容易错的东西。它的作用是告诉搜索引擎这个页面包含问答内容有机会在搜索结果里展示富摘要。但很多人包括 agent会犯几个错误。错误一把 FAQ 标记加在不该加的页面上。FAQPage schema 只适用于页面上确实有问答内容的场景。如果你为了拿富摘要硬在产品页底部加一段 FAQ内容还是凑的这属于违规使用可能被手动惩罚。agent 需要能判断这个页面是否真的有 FAQ 内容而不是无脑加标记。错误二问答内容与页面可见内容不一致。schema 里标记的问答必须是页面上用户能看到的。有些 agent 会聪明地生成一些页面上没有的问答塞进 schema这是明确违规的。错误三嵌套结构错误。FAQPage 的 schema 结构是固定的mainEntity是一个Question数组每个Question有name和acceptedAnsweracceptedAnswer里是Answer和text。层级错了搜索引擎就读不懂。我在技能定义里会加一段校验逻辑生成 schema 之后用脚本检查 JSON-LD 是否符合 schema.org 的规范同时检查问答内容是否在页面正文里能找到对应文本。两个检查都过了才算完成。# check-schema.py 的核心逻辑示意 import json import re def validate_faq_schema(html_content, schema_json): # 1. 检查 JSON-LD 结构 data json.loads(schema_json) if data.get(type) ! FAQPage: return False, 类型不是 FAQPage # 2. 检查每个问答是否在页面可见 for item in data.get(mainEntity, []): question item[name] answer item[acceptedAnswer][text] if question not in html_content: return False, f问题未在页面找到: {question} # 答案可能被 HTML 标签分割做宽松匹配 answer_plain re.sub(r[^], , answer) if answer_plain[:50] not in html_content: return False, f答案未在页面找到: {question} return True, 校验通过这段逻辑不复杂但能挡住 90% 的低级错误。agent 执行完 schema 生成后自动跑一遍不过就重做。4.2 CRO 分析技能从看感觉到看数据CRO转化率优化是另一个适合 agent 化的领域因为它的核心工作是对照基准做诊断。人做 CRO 分析容易陷入我觉得这个按钮颜色不好看的主观判断agent 反而更适合做系统化检查。我设计的 CRO 分析技能包含这几个检查维度首屏信息密度。用户打开页面 3 秒内能不能看懂这是什么、给谁用、有什么好处。agent 提取首屏的标题、副标题、主视觉文案检查是否包含价值主张、目标用户、差异化点。CTA 清晰度。行动号召按钮是否显眼、文案是否具体、是否只有一个主要 CTA。agent 统计页面上所有 CTA 的数量和位置检查是否有选择困难问题。社会证明布局。客户评价、案例、数据、logo 墙是否出现在决策关键位置。agent 检查社会证明元素的数量和位置分布。表单摩擦。表单字段数量、必填项比例、是否有进度提示。agent 统计字段数对照行业基准一般建议不超过 5 个字段给出建议。信任信号。隐私政策、退款保证、安全标识是否可见。agent 检查这些元素是否存在。每个维度 agent 给出一个 1-5 分的评分和具体修改建议。最后汇总成一个优先级排序的优化清单。这个清单比我觉得应该改改有用得多因为它有依据、有优先级、可执行。4.3 关键词研究技能从种子词到内容矩阵关键词研究是内容营销的起点。传统做法是人工用工具查、人工筛选、人工分组费时费力。agent 化之后流程可以变成输入一个种子关键词或一个主题方向。第一步扩展。基于种子词生成相关词、长尾词、问题词。这一步可以调用关键词 API也可以让 agent 基于语义生成候选词。第二步意图分类。把扩展出来的词按搜索意图分类。信息型、商业型、交易型、导航型。第三步难度评估。对每个词评估竞争难度。没有 API 的话可以让 agent 分析 SERP 前几名的域名权威度、内容质量、是否有富摘要占位。第四步聚类分组。把意图相同、主题相近的词聚成一组每组对应一篇内容。聚类的逻辑是一个页面能不能同时满足这组词的搜索需求。第五步优先级排序。综合搜索量、难度、商业价值三个维度排序。搜索量高、难度低、商业价值高的排前面。第六步输出内容矩阵。每个聚类输出一行目标关键词、内容类型、预估字数、优先级、建议发布时间。这个流程跑下来一个种子词能扩展出几十上百个关键词自动分成十几组内容方向。人工做这个可能要一整天agent 跑一遍十几分钟。注意agent 生成的关键词数据一定要人工抽检。我遇到过 agent 把一些完全不相关的词也聚进来的情况原因是语义理解偏差。抽检比例建议不低于 20%重点检查聚类边界上的词。5. 实测中踩过的坑和排查思路5.1 agent 自作主张改了不该改的文件这是我最开始用 Claude Code 做营销项目时踩的最大的坑。有一次我让它优化一下落地页文案结果它不光改了文案还顺手把页面的 CSS 也调了理由是觉得间距可以更紧凑。改完页面布局全乱了。排查下来原因是技能定义里没有明确允许操作的范围。agent 默认会做它认为对完成任务有帮助的任何事。你不划定边界它就自由发挥。修复方案是在每个技能定义里加一段操作边界## 操作边界 - 只允许修改 content/ 目录下的文件 - 禁止修改任何 .css、.js、.html 模板文件 - 禁止执行删除操作 - 如需修改范围外的文件必须先询问加了这段之后agent 就规矩多了。这个经验让我意识到给 agent 写技能定义约束和指令同样重要。你告诉它做什么也要告诉它不做什么。5.2 生成的内容看起来对但经不起查另一个高频问题是 agent 生成的内容有幻觉。比如它会在文章里引用一个数据根据某研究70% 的用户会...,但这个研究根本不存在。或者它会编一个行业基准实际上没有依据。这个问题在营销内容里特别危险因为营销内容是要公开发布的虚假数据会损害品牌可信度。我的应对策略是在技能定义里强制要求数据来源标注。agent 每引用一个数据必须标注来源。如果找不到可靠来源就不许用这个数据改用定性描述。## 数据使用规则 - 引用任何统计数据必须标注来源机构名 年份 - 无法验证来源的数据禁止使用 - 优先使用一手数据自己项目的数据 - 二手数据必须来自权威机构政府、学术、知名研究机构 - 禁止使用研究表明、数据显示等无主语句式这个规则加上之后agent 生成的内容可信度明显提升。虽然有时候它会因为找不到来源而放弃一些论点但宁可少写也不写错。5.3 多技能协作时的上下文丢失当项目变复杂多个技能需要协作时会出现上下文丢失的问题。比如 SEO 技能生成了一篇文章CRO 技能要分析这篇文章的转化元素但 CRO 技能运行时不知道这篇文章的目标关键词是什么、目标受众是谁。原因是每个技能运行时是独立的不会自动继承上一个技能的上下文。解决方案就是我前面提到的项目状态文件。所有技能运行前先读状态文件运行后写回状态文件。状态文件里记录# 项目状态 ## 当前目标 - 主关键词AI marketing automation - 目标受众中小企业的营销负责人 - 转化目标预约演示 ## 内容清单 | 文件 | 目标关键词 | 状态 | 转化元素检查 | |------|-----------|------|-------------| | content/published/ai-marketing-guide.md | AI marketing automation | 已发布 | 待检查 | | content/drafts/cro-checklist.md | conversion rate optimization | 草稿 | - | ## 待办 - [ ] 检查 ai-marketing-guide.md 的 CTA 位置 - [ ] 为 cro-checklist.md 补充 FAQ schema这样每个技能运行时都有完整上下文不会失忆。状态文件我建议每次技能运行后自动更新而不是手动维护。可以在技能定义里加一步更新项目状态。5.4 模型切换导致的行为差异如果你通过 cc switch 在不同模型之间切换比如 Claude 和 DeepSeek 换着用会发现同一个技能定义在不同模型上表现不一样。Claude 可能更听话严格按步骤执行DeepSeek 可能更灵活会自己优化流程GLM 可能在中文内容上表现更好。这个差异本身不是问题问题是你不能假设换模型后行为一致。我的做法是每个模型配一套技能定义微调版。核心逻辑一样但在指令措辞上做适配。比如对灵活的模型约束要写得更强硬对听话的模型可以给更多自主空间。另外切换模型后一定要跑一遍回归测试。用同一个输入看输出是否符合预期。我一般准备 3-5 个标准测试用例换模型后跑一遍确认没问题再正式用。6. 让技能持续进化的几个实用机制6.1 建立错误日志驱动技能迭代技能不是写完就完了需要持续迭代。我迭代的依据来自错误日志。每次 agent 执行出问题我就记一条什么技能、什么输入、什么错误、期望输出是什么。积累一段时间后错误日志会呈现出模式。比如FAQ schema 生成技能在页面没有 FAQ 内容时仍然生成标记这个错误出现了 5 次那就说明技能定义里缺少前置检查这一步。补上之后这类错误就消失了。错误日志我建议用简单的 Markdown 表格维护日期技能输入错误修复2024-01-15seo-content关键词AI tools生成了不存在的统计数据加数据来源强制标注规则2024-01-18cro-analysis落地页 URL漏检了移动端布局加移动端检查项这个表格不用很正式关键是坚持记。记着记着你就知道该往哪个方向优化了。6.2 用黄金样本做质量基准除了错误日志我还维护一套黄金样本——就是那些人工确认过这是好输出的案例。每次技能迭代后用黄金样本跑一遍看输出质量有没有下降。黄金样本不用多每个技能 3-5 个就够。关键是覆盖典型场景和边界场景。比如 SEO 内容技能黄金样本可以包括一个信息型关键词、一个交易型关键词、一个竞争激烈的关键词。这个机制能防止改了一个问题引入另一个问题。技能迭代最怕的就是按下葫芦浮起瓢黄金样本能帮你守住质量底线。6.3 定期做技能审计用了一段时间后有些技能可能已经过时了或者被更好的方案替代了。我一般每个月做一次技能审计问几个问题这个技能最近 30 天用了几次如果一次没用是不是可以删了这个技能的出错率是多少如果超过 20%是不是该重写这个技能的步骤有没有可以合并或简化的有没有新的工具或 API 可以让这个技能更高效审计的目的是保持技能库的精简和高效。技能不是越多越好维护成本是隐性成本。我见过有人攒了 50 多个技能结果常用的就 5 个其他都是负担。6.4 把人工判断留在关键节点最后说一个反直觉的经验不是所有环节都适合自动化。有些判断必须留给人来做。比如内容发布前的最终审核。agent 可以检查格式、检查 schema、检查关键词密度但它判断不了这篇文章的调性是否符合品牌、这个观点会不会引起争议、这个案例是否合适。这些需要人的判断。我的做法是在流程里设置人工检查点。agent 完成初稿后不直接发布而是进入待审核状态。人工审核通过后才发布。审核点不用多但关键节点必须有。这样既享受了 agent 的效率又保留了人的判断力。两者结合才是可持续的工作方式。7. 关于这套方法的一些个人体会我从最开始把 Claude Code 当高级自动补全用到后来把它当成一个能独立执行营销任务的 agent 运行时中间踩了不少坑也积累了一些心得。最大的体会是agent 的能力上限不取决于模型取决于你怎么定义任务。同一个模型技能定义写得好它能干出专业水准的活儿写得烂它就是个会胡说八道的聊天机器人。这个差距比模型之间的差距大得多。另一个体会是营销工作的 agent 化难点不在技术在拆解。你得先把营销工作拆成一个个原子任务定义清楚每个任务的输入输出和成功标准然后才能交给 agent。这个拆解过程本身就是对营销工作的深度理解。拆不明白说明你自己也没想清楚这件事该怎么做。还有一点别追求一步到位。我一开始想做一个全自动营销 agent输入产品信息就自动产出所有内容。结果做出来的东西四不像。后来改成一个技能解决一个具体问题反而每个技能都能用起来。积小胜为大胜比憋大招靠谱。最后工具在变模型在变但把复杂工作拆解成可执行单元这个思路不会变。marketingskills这个命名的价值不在于它具体实现了什么而在于它提示了一种工作方式把营销能力模块化、可调用化、可组合化。这个方向我觉得是对的。