基于 Claude Code 的营销技能包：SEO 审计与 CRO 分析自动化实践

1. 项目缘起：为什么我要把营销方法论塞进 Claude Code

做增长和独立站这行的朋友大概都有同感：SEO 和 CRO 的知识体系极度碎片化。关键词研究在 Ahrefs 里，结构化数据在 Search Console 里，落地页转化分析在 Clarity 里，文案 A/B 测试又在另一个表格里。每次做一轮完整的营销诊断，光是在工具之间来回切换、复制粘贴数据，就能耗掉大半天。更麻烦的是，很多判断依赖经验——比如“这个 FAQ 结构化数据到底该不该加”“落地页首屏的 CTA 位置要不要动”——这些决策没有标准答案，全靠人脑去权衡。

marketingskills这个项目，就是想把上面这套东西固化下来，变成 Claude Code 能直接调用的技能包。简单说，它是一组面向 AI agents 的营销技能定义文件，覆盖 SEO 审计、CRO 分析、结构化数据生成、内容策略等场景。你把它挂到 Claude Code 里，就能用自然语言让 AI 按预设的方法论去干活，而不是每次从零开始写 prompt。

这个项目适合谁？三类人最受益：一是独立站站长，尤其是做谷歌 SEO 但没预算请专职优化师的小团队；二是增长方向的从业者，想把重复性的诊断工作自动化；三是已经在用 Claude Code 但不知道怎么把它用到营销场景的开发者。哪怕你之前没接触过 AI agents，只要会装 Claude Code、能看懂 YAML 和 Markdown，就能上手。

我自己的使用场景很典型：手上管着几个独立站，每个月要做一轮 SEO 健康检查和落地页转化复盘。以前这活儿要花两三天，现在把marketingskills挂上去，大部分数据整理和初步诊断能压缩到几个小时。下面我把这套东西的设计思路、核心细节、实操流程和踩过的坑，完整拆一遍。

2. 整体设计思路：为什么是“技能包”而不是“一个大 prompt”

2.1 从“万能 prompt”到“模块化技能”的转变

早期我用 Claude Code 做营销分析，习惯写一个超长的系统 prompt，把 SEO 规则、CRO 原则、输出格式全塞进去。结果很糟糕：prompt 越长，模型越容易顾此失彼，让它分析结构化数据时它跑去讲关键词密度，让它做转化诊断时它又开始背 SEO 常识。而且每次调整一个环节，整个 prompt 都要重写，维护成本极高。

marketingskills的思路完全不同。它把营销能力拆成一个个独立的 skill，每个 skill 只负责一件事，有自己的触发条件、输入规范、执行步骤和输出模板。Claude Code 在运行时根据你的指令，自动判断该调用哪个 skill。这就像从“雇一个什么都懂但什么都不精的顾问”，变成“组建一个各司其职的小团队”。

这种模块化设计有三个直接好处。第一，可维护性：SEO 规则变了，只改 SEO 那个 skill 文件，不影响 CRO 部分。第二，可组合性：做一次完整诊断时，可以让 SEO skill 先跑站点审计，再把结果喂给 CRO skill 做落地页分析，形成流水线。第三，可解释性：每个 skill 的决策逻辑都写在文件里，你能清楚看到 AI 为什么给出某个建议，而不是面对一个黑盒输出。

2.2 目录结构与文件组织

一个典型的marketingskills仓库，目录结构大致是这样组织的：

marketingskills/ ├── skills/ │ ├── seo-audit/ │ │ ├── SKILL.md │ │ └── references/ │ ├── cro-analysis/ │ │ ├── SKILL.md │ │ └── references/ │ ├── structured-data/ │ │ ├── SKILL.md │ │ └── templates/ │ └── content-strategy/ │ ├── SKILL.md │ └── references/ ├── shared/ │ ├── glossary.md │ └── output-format.md └── README.md

每个 skill 目录下的SKILL.md是核心，里面定义了技能的元信息（名称、描述、触发词）、执行流程、输入输出规范。references/放的是该技能依赖的参考资料，比如 SEO 审计里会引用谷歌搜索质量评估指南的要点，CRO 分析里会放转化率基准数据。shared/目录放跨技能共用的东西，比如术语表和统一输出格式，避免每个 skill 各写一套。

提示：目录名和 skill 名称建议用英文小写加连字符，因为 Claude Code 在匹配技能时对命名规范比较敏感，中文名或驼峰命名容易导致识别失败。

2.3 为什么选择 Claude Code 作为运行载体

市面上能跑 AI agents 的工具不少，选 Claude Code 有几个现实考量。一是它对本地文件系统的访问很自然，skill 文件直接放在项目目录里就能被读取，不需要额外搭服务。二是它的终端命令执行能力成熟，做 SEO 审计时经常需要跑curl抓页面、用grep过滤 HTML，这些它都能直接干。三是它的上下文管理相对稳，处理长文档和多次工具调用时不容易丢状态。

当然也有代价。Claude Code 对网络请求的处理需要你显式授权，抓取外部页面时要配置好权限，否则会卡在确认环节。另外它的模型调用是按量计费的，跑大规模站点审计时成本要心里有数。这些在后面实操部分会细说。

3. 核心细节解析：一个 SEO 审计 skill 是怎么写出来的

3.1 SKILL.md 的骨架结构

拿seo-audit这个 skill 举例，它的SKILL.md大致长这样：

--- name: seo-audit description: 对指定网站执行谷歌 SEO 健康检查，覆盖技术 SEO、页面 SEO、内容质量三个维度 trigger: 当用户提到 SEO 审计、站点健康检查、谷歌收录问题时激活 --- ## 执行流程 1. 确认目标 URL 和审计范围 2. 抓取 robots.txt 和 sitemap.xml 3. 抽样抓取核心页面，检查 meta 标签、标题层级、内链结构 4. 检查结构化数据部署情况 5. 输出分级问题清单 ## 输入规范 - 必填：目标域名 - 选填：重点页面 URL 列表、竞品域名 ## 输出格式 见 shared/output-format.md，按 P0/P1/P2 分级

这个骨架里，description和trigger决定了 Claude Code 什么时候会调用它。写得越具体，误触发越少。我一开始把 trigger 写成“SEO 相关”，结果用户随便问一句“什么是 SEO”它也去跑审计流程，浪费 token。后来改成“SEO 审计、站点健康检查、谷歌收录问题”这种具体动作词，准确率明显提升。

3.2 技术 SEO 检查项的设计逻辑

技术 SEO 这块，我列了十几个检查项，但并不是每个都同等重要。按影响面和修复成本，我把它们分成三档：

为什么把 robots.txt 放 P0？因为它是最容易被忽略、后果又最严重的。我见过一个站点，开发在测试环境加了Disallow: /，上线时忘了删，结果整站被搜索引擎拒之门外，流量归零。这种问题必须在审计第一步就查。

canonical 标签放 P1 是因为它影响的是权重分配，不会立刻致命，但长期不处理会导致重复内容问题累积。URL 结构放 P2 是因为改 URL 涉及 301 跳转和权重传递，动一次伤筋动骨，除非问题特别严重，否则不建议轻易改。

3.3 结构化数据检查：FAQPage 到底怎么判断

热词里有人问“谷歌 SEO 的 FAQPage 结构化数据是怎么回事”，这正好是structured-dataskill 要处理的核心场景。FAQPage 结构化数据的本质，是告诉搜索引擎“这个页面上的问答内容是一组 FAQ”，从而有机会在搜索结果里展示折叠问答的富媒体摘要。

但这里有个坑：不是所有页面都适合加 FAQPage。谷歌的规范里明确说了，FAQPage 标记的内容必须是页面上真实可见的问答，不能是隐藏的、也不能是为了骗富媒体摘要硬凑的。我见过有人把产品参数表硬改成问答形式去标记，结果被判定为垃圾结构化数据，反而吃了惩罚。

structured-dataskill 的判断逻辑是这样的：

1. 先扫描页面，识别是否存在真实的问答区块
2. 检查问答内容是否对用户可见（不是display:none）
3. 验证问答是否与页面主题相关
4. 生成符合 schema.org 规范的 JSON-LD 代码
5. 用谷歌富媒体测试工具的逻辑做本地校验

第 5 步很关键。很多人写完 JSON-LD 直接上线，结果格式错误导致标记无效。skill 里内置了一套校验规则，能在本地先跑一遍，把常见的语法错误、必填字段缺失、类型不匹配都揪出来。

3.4 CRO 分析 skill 的差异化设计

CRO 和 SEO 的 skill 设计思路差别很大。SEO 偏规则驱动，检查项相对客观；CRO 偏启发式判断，很多结论依赖对用户心理和行业基准的理解。所以cro-analysisskill 里，我放了一份转化率基准数据作为参照系：

有了基准，AI 给出的诊断才有锚点。比如它看到某个 SaaS 落地页转化率 1.5%，就能判断“低于行业平均，首屏价值主张可能不够清晰”，而不是笼统地说“转化率有待提升”。

CRO skill 的另一个特点是强调“一次只改一个变量”。很多新手做 A/B 测试，一次改标题、改按钮、改配色，最后转化率涨了也不知道是哪个改动起的作用。skill 里会强制要求输出“单变量测试建议”，把可能的改进点按影响力和实施成本排序，让你逐个验证。

4. 实操过程：从零把 marketingskills 跑起来

4.1 环境准备与 Claude Code 安装

先说环境。我用的是 macOS，Windows 和 Ubuntu 的流程大同小异，差异主要在路径和权限处理上。Claude Code 的安装方式，官方推荐的是通过 npm 全局安装：

npm install -g @anthropic-ai/claude-code

装完之后在终端输入claude就能启动。第一次运行会让你登录账号，这里有个常见问题：热词里有人提到“your organization has disabled claude subscription access for claude code”，这通常是账号所属组织在管理后台关闭了 Claude Code 的访问权限。遇到这种情况，要么找管理员开通，要么用个人账号。还有一种情况是所在地区不支持，官方会提示“claude code might not be available in your country”，这个没有绕过的办法，只能等官方开放。

如果你不想用官方账号，Claude Code 也支持接入第三方模型。热词里提到的“使用 cc switch 接入 deepseek、qwen、glm 等模型”就是这条路子。原理是通过配置环境变量，把模型请求指向兼容 OpenAI 接口的第三方服务。具体做法是在~/.claude/settings.json里配置：

{ "env": { "ANTHROPIC_BASE_URL": "你的第三方接口地址", "ANTHROPIC_API_KEY": "你的密钥" } }

注意：接入第三方模型后，部分依赖 Claude 原生能力的特性（比如某些工具调用格式）可能表现不稳定。做营销分析这种需要长上下文和复杂推理的任务，建议还是用原生模型，第三方模型适合做轻量级的文本处理。

4.2 在 VS Code 里配置 Claude Code

我日常在 VS Code 里干活，所以重点说下编辑器集成。Claude Code 有官方 VS Code 插件，装完之后在侧边栏会出现一个面板，可以直接在编辑器里对话，不用切终端。

配置的关键是让插件知道你的项目目录。打开marketingskills所在的文件夹，插件会自动读取目录下的 skill 文件。如果没识别到，检查两点：一是skills/目录是否在项目根目录下，二是SKILL.md的 frontmatter 格式是否正确。YAML 的 frontmatter 对缩进很敏感，多一个空格都可能导致解析失败。

VS Code 插件的另一个好处是能直接看到文件改动。当 skill 生成结构化数据代码或修改配置文件时，你能在编辑器里实时看到 diff，方便审查。我习惯让 AI 先输出建议，我确认后再让它写入文件，避免它自作主张改错东西。

4.3 挂载 marketingskills 并跑第一轮审计

把marketingskills仓库克隆到本地后，在 Claude Code 里进入该目录，然后直接下指令：

对 example.com 执行 SEO 审计，重点关注技术 SEO 和结构化数据

Claude Code 会先匹配到seo-auditskill，然后按流程执行。第一步是抓取 robots.txt 和 sitemap.xml，这一步需要网络访问权限，它会弹出确认，你选允许。抓取完成后，它会抽样几个核心页面，检查 meta 标签和标题层级。

这里有个实操细节：抓取页面时，Claude Code 默认用的是简单的 HTTP 请求，对于依赖 JavaScript 渲染的页面，抓到的 HTML 可能是空的。遇到这种情况，需要在 skill 里配置用无头浏览器抓取，或者手动把渲染后的 HTML 保存下来喂给它。我在seo-audit的 references 里加了一段说明，提醒使用者注意 SPA 站点的抓取问题。

第一轮审计跑完，输出是一份分级问题清单。我拿一个真实站点测试，它揪出了三个 P0 问题：一个核心产品页返回 404、robots.txt 里误屏蔽了/blog/目录、sitemap 里有一批失效 URL。这三个问题如果靠人工查，至少得花一两个小时，它十分钟内就定位完了。

4.4 结构化数据生成与校验

跑完审计，接着让structured-dataskill 生成 FAQPage 标记。指令可以写得很自然：

给 https://example.com/faq 这个页面生成 FAQPage 结构化数据

它会先抓取页面内容，识别出问答区块，然后生成 JSON-LD。生成结果大概是这样：

{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "你们的退货政策是什么？", "acceptedAnswer": { "@type": "Answer", "text": "自收到商品起 30 天内，商品未使用且包装完好，可申请全额退款。" } } ] }

生成之后，skill 会自动跑一遍校验，检查必填字段、类型匹配、URL 格式等。校验通过后，它会提示你把代码插入页面的<head>或<body>里。我一般建议放在<head>里，加载更早，搜索引擎抓取时不容易漏掉。

提示：FAQPage 标记上线后，不要指望立刻在搜索结果里看到富媒体摘要。谷歌需要重新抓取和索引，通常要几天到几周。而且不是所有标记都会展示，谷歌会根据查询意图和内容质量决定是否展示。

5. 常见问题与排查技巧实录

5.1 skill 不触发或触发错误

最常见的问题是 Claude Code 没调用你想要的 skill。原因通常有三个：trigger 关键词不匹配、skill 文件格式错误、或者多个 skill 的触发条件重叠。

排查方法：先在对话里明确说出 skill 名称，比如“用 seo-audit 技能帮我检查”，看它能不能正确调用。如果能，说明是 trigger 写得不够具体；如果不能，检查SKILL.md的 frontmatter 是否有语法错误。我踩过一次坑，description里用了中文冒号，YAML 解析直接失败，skill 完全加载不了。改成英文冒号就好了。

多个 skill 触发条件重叠时，Claude Code 会按优先级选一个。你可以在 frontmatter 里加priority字段来控制。比如seo-audit和structured-data都可能被“检查结构化数据”触发，把structured-data的优先级调高，它就会优先匹配。

5.2 抓取外部页面失败

抓取失败的原因五花八门，我整理了一张速查表：

反爬这块要特别注意分寸。有些站点明确禁止自动化抓取，硬抓可能违反其服务条款。我的原则是：只抓公开的、允许索引的页面，遵守 robots.txt，控制请求频率，不给对方服务器造成压力。

5.3 输出结果太泛、不够具体

AI 给出的诊断容易流于表面，比如“建议优化标题标签”“提升页面加载速度”这种正确的废话。要让它给出具体建议，关键在于喂给它的上下文要足够丰富。

我的做法是在 skill 里加一段“输出质量约束”，明确要求：每个问题必须附带具体证据（哪个页面、哪个标签、当前值是什么）、修复建议要可执行（改成什么、怎么改）、预期影响要量化（预计提升多少）。加了这段约束后，输出质量明显提升，从“优化标题”变成“产品页标题当前是‘产品中心’，建议改为‘XX 产品系列 | 品牌名’，长度控制在 60 字符内，预计点击率提升 5-10%”。

5.4 成本控制与 token 消耗

跑大规模站点审计时，token 消耗是个现实问题。一个几百页的站点，如果每页都完整抓取分析，成本会很高。我的优化策略是分层抽样：P0 检查项全量跑，P1 抽 20% 页面，P2 抽 5%。这样既覆盖了关键问题，又控制了成本。

另外，把重复性的检查逻辑写成脚本，让 Claude Code 调用脚本而不是逐页分析，也能省不少 token。比如检查全站 meta 标签，写个 Python 脚本跑一遍，把结果汇总成表格喂给 AI 做判断，比让 AI 一页页看效率高得多。

5.5 结构化数据校验的坑

JSON-LD 校验有几个高频错误点。一是@context写错，必须是https://schema.org，少个 s 或者用 http 都不行。二是嵌套结构错误，mainEntity里必须是 Question 对象数组，不能直接放字符串。三是日期格式，datePublished要用 ISO 8601 格式，写成2024/01/01会校验失败。

还有一个隐蔽的坑：如果页面上有多个 FAQ 区块，要合并成一个 FAQPage 标记，而不是写多个。多个 FAQPage 标记会导致搜索引擎困惑，可能全部忽略。skill 里内置了合并逻辑，会自动把多个区块的问答整合到一个 JSON-LD 里。

6. 进阶玩法：把 skill 组合成营销工作流

单个 skill 解决单点问题，真正体现价值的是把它们串起来。我现在的月度营销复盘流程是这样的：

第一步，seo-audit跑全站健康检查，输出问题清单。第二步，把问题清单里涉及落地页的部分，喂给cro-analysis做转化诊断。第三步，structured-data针对内容页生成或修复结构化数据。第四步，content-strategy根据前几步的发现，输出下个月的内容选题建议。

这四步可以在 Claude Code 里用一条指令串起来：

对 example.com 执行完整营销诊断：先做 SEO 审计，再分析核心落地页的转化问题，检查结构化数据，最后给出内容策略建议

Claude Code 会依次调用四个 skill，把前一个的输出作为后一个的输入。整个过程大概跑十几分钟，产出一份综合诊断报告。以前这活儿要两三天，现在压缩到半小时以内，而且报告的结构一致性比人工写的还好。

不过要提醒一句：AI 的输出始终需要人工复核。它擅长的是数据整理、规则检查和初步判断，但涉及品牌调性、商业策略这些需要深度思考的部分，还是得人来拍板。我的定位是把它当成一个高效的初级分析师，而不是替代决策者。

最后分享一个我用了很久的小技巧：每次跑完诊断，把 AI 的输出和你的最终决策都记录下来，定期回看。时间长了你会发现，AI 在某些类型的判断上越来越准，在另一些类型上总是跑偏。根据这些反馈去调整 skill 里的规则和约束，整个系统的准确率会持续提升。这套东西不是一次配置就完事的，它需要你像养一个团队成员一样，不断给它反馈和调教。