基于AI Agent的营销自动化：marketingskills技能包设计与SEO/CRO/数据分析实战

1. 从“marketingskills”说起：一个被低估的营销自动化切口

第一次看到marketingskills这个标题，我脑子里蹦出来的不是某个具体工具，而是一类正在悄悄成型的东西——把营销动作拆成可被 AI agent 调用的“技能包”。这个词本身很朴素，直译就是“营销技能”，但它背后指向的是一套很实在的工程思路：把 SEO、CRO、数据分析这些原本靠人肉堆时间、靠经验拍脑袋的活儿，封装成结构化的、可复用的、能被自动化流程调度的能力单元。

为什么这个切口值得聊？因为过去两年我接触过不少做独立站、做内容站、做 SaaS 增长的朋友，大家卡在同一个地方：工具太多，动作太碎。关键词研究用一个工具，页面优化用另一个，转化率分析再换一个，数据对不上，动作接不上，最后变成“工具用了一堆，增长还是靠感觉”。而marketingskills这类思路要解决的，恰恰是把这个断裂的链条重新接起来——让 AI agent 不只是聊天，而是真正能执行营销任务。

这篇文章适合谁看？如果你是独立站站长、SEO 从业者、增长负责人，或者正在折腾 Claude Code、AI agents 这类工具想往营销场景落地的人，那接下来的内容应该能给你一些可以直接抄作业的东西。我会从整体设计思路讲到具体实操，包括 SEO 审计、CRO 分析、数据埋点这些环节怎么拆成 skill，怎么让 agent 调用，以及我在实际配置过程中踩过的坑。全文基于常见工程实践展开，涉及参数和步骤的地方我会把计算逻辑和选择理由讲清楚，不搞黑箱。

先说清楚一个前提：marketingskills不是一个现成的商业产品，它更像是一种架构模式或者项目组织方式。你可以把它理解成一个“营销技能仓库”，里面每个 skill 是一个独立的能力模块，比如“抓取页面标题和 meta 描述”“分析关键词密度”“生成 A/B 测试变体”“拉取 GA4 数据并计算转化率”。这些模块通过统一的接口暴露给 AI agent，agent 根据任务目标自动编排调用顺序。这种设计的好处是解耦——你可以单独替换某个 skill，而不影响整体流程；也可以单独测试某个 skill，而不需要跑完整条链路。

我之所以对这个方向感兴趣，是因为它把“营销”从“人的经验活”往“可工程化的系统活”推了一步。这一步不一定适合所有团队，但对于那些已经有稳定流量、需要精细化运营的站点来说，价值非常明显。接下来我会分几个层面拆解：整体架构怎么设计、核心 skill 怎么实现、实操流程怎么跑通、以及遇到问题怎么排查。

2. 整体架构设计：为什么要把营销动作拆成 skill

2.1 核心设计思路与选型考量

把营销动作拆成 skill，本质上是在做一件事：降低 agent 执行复杂任务时的认知负荷。你可以想象一下，如果让一个 AI agent 直接面对“帮我优化这个页面的转化率”这种指令，它需要同时处理太多变量——页面结构、文案、CTA 位置、加载速度、用户意图匹配度等等。但如果把任务拆成“分析当前页面转化漏斗”“识别高流失环节”“生成三个 CTA 变体”“计算每个变体的预期提升”，agent 每一步只需要聚焦一个具体问题，成功率和可解释性都会高很多。

这种拆分方式借鉴了软件工程里的“单一职责原则”。每个 skill 只做一件事，做好一件事。比如一个叫extract-page-seo的 skill，它的职责就是给定 URL，返回标题、meta 描述、H1-H3 结构、图片 alt 文本、内链外链数量这些结构化数据。它不负责判断这些数据好不好，也不负责给出优化建议——那是下一个 skill 的事。这种边界清晰的设计，让调试和替换变得非常容易。

选型上我倾向于用Claude Code 作为 agent 运行时，原因有几个。第一，它对终端命令的直接执行支持比较自然，你可以让 agent 跑脚本、调 API、读写文件，而不需要额外搭一层中间件。第二，它的 skill 组织方式比较灵活，可以通过配置文件或者目录结构来定义可用技能。第三，社区里已经有相当多关于 Claude Code 安装、配置、接入不同模型的讨论，遇到问题比较容易找到参考。当然，如果你用的是其他 agent 框架，思路是通用的，只是具体配置方式需要调整。

另一个关键选型是数据层怎么组织。我的做法是用轻量级本地存储加 API 拉取结合。高频访问的静态数据（比如页面结构快照）存本地 JSON 或 SQLite，实时性要求高的数据（比如 GA4 转化数据）通过 API 按需拉取。这样既避免了每次调用都走网络，又保证了关键指标的时效性。存储格式统一用 JSON，因为 agent 解析起来最自然，不需要额外做格式转换。

注意：不要一上来就追求“全自动”。我见过太多团队想一步到位搞全自动优化闭环，结果因为某个环节数据不准导致整个流程输出垃圾建议。建议先从“半自动”开始——agent 负责分析和建议，人负责审核和执行，跑顺了再逐步放开。

2.2 目录结构与 skill 注册机制

一个可维护的marketingskills项目，目录结构应该让人一眼看懂哪个 skill 干什么。我常用的结构是这样的：

marketingskills/ ├── skills/ │ ├── seo/ │ │ ├── extract-page-seo/ │ │ │ ├── skill.json │ │ │ └── index.js │ │ ├── analyze-keyword-density/ │ │ │ ├── skill.json │ │ │ └── index.js │ │ └── check-internal-links/ │ │ ├── skill.json │ │ └── index.js │ ├── cro/ │ │ ├── analyze-funnel/ │ │ └── generate-cta-variants/ │ └── analytics/ │ ├── fetch-ga4-metrics/ │ └── calculate-conversion-rate/ ├── config/ │ ├── agent.json │ └── credentials.example.json ├── data/ │ └── snapshots/ └── README.md

每个 skill 目录下的skill.json定义这个技能的元信息：名称、描述、输入参数 schema、输出格式、依赖项。index.js是实际执行逻辑。agent 启动时扫描skills/目录，读取所有skill.json，构建可用技能列表。当用户发出指令时，agent 根据技能描述匹配最合适的 skill 来执行。

这种注册机制的好处是可扩展性。你想加一个新 skill，只需要新建一个目录，写好skill.json和index.js，重启 agent 就能用。不需要改核心代码，也不需要重新打包。对于营销这种变化快的领域来说，这种灵活性很重要——今天需要分析页面 SEO，明天可能需要分析短视频脚本，后天可能需要分析邮件标题，都能快速加上。

skill.json的 schema 我一般这样写：

{ "name": "extract-page-seo", "description": "给定 URL，抓取页面并返回 SEO 相关结构化数据，包括标题、meta 描述、标题层级、图片 alt、内外链数量", "input": { "type": "object", "properties": { "url": { "type": "string", "description": "目标页面完整 URL" }, "timeout": { "type": "number", "default": 10000 } }, "required": ["url"] }, "output": { "type": "object", "properties": { "title": { "type": "string" }, "metaDescription": { "type": "string" }, "headings": { "type": "array" }, "imageAlts": { "type": "array" }, "internalLinks": { "type": "number" }, "externalLinks": { "type": "number" } } } }

这个 schema 不只是给 agent 看的，也是给人看的。团队新成员进来，翻一遍skill.json就知道系统能干什么、每个技能需要什么输入、产出什么输出。文档和代码合一，减少沟通成本。

2.3 与 Claude Code 的集成方式

Claude Code 本身是一个命令行工具，它的强项是理解自然语言指令并转化为终端操作。把marketingskills和它集成，核心是让 Claude Code 知道有哪些 skill 可用，以及怎么调用。

我试过两种方式。第一种是通过 MCP（Model Context Protocol）暴露 skill。你可以写一个 MCP server，把每个 skill 注册成一个 tool，Claude Code 通过 MCP 协议发现和调用。这种方式比较规范，适合 skill 数量多、需要跨项目复用的场景。第二种是通过本地脚本直接调用。在项目根目录放一个run-skill.sh，Claude Code 通过执行终端命令来触发 skill。这种方式更轻量，适合快速验证和小规模使用。

我目前用的是第二种，因为配置简单，调试直观。具体做法是在config/agent.json里写一段系统提示，告诉 Claude Code：“当前项目包含以下营销技能，你可以通过执行node skills/<category>/<skill-name>/index.js来调用，参数以 JSON 格式通过 stdin 传入。”然后 Claude Code 在需要的时候就会自己拼命令、传参数、解析输出。

这里有个细节要注意：参数传递格式要统一。我一开始有的 skill 用命令行参数，有的用环境变量，有的用 stdin，结果 Claude Code 经常搞混。后来统一成“所有 skill 都从 stdin 读 JSON，向 stdout 写 JSON”，问题就消失了。统一约定比灵活多样更重要，尤其是在 agent 参与的场景下。

提示：如果你在配置 Claude Code 时遇到“might not be available in your country”之类的提示，那是正常的区域检测逻辑，不影响本地 skill 的执行。skill 本身是本地脚本，只要 Node.js 环境正常就能跑。

3. 核心 skill 实现细节：SEO、CRO、Analytics 三件套

3.1 SEO skill：从页面抓取到关键词密度分析

SEO 类 skill 是整个marketingskills里最基础也最常用的部分。我把它拆成三个独立 skill：extract-page-seo负责抓取和结构化，analyze-keyword-density负责内容分析，check-internal-links负责链接健康度检查。

extract-page-seo的实现逻辑不复杂，但有几个坑要注意。第一，必须设置合理的 User-Agent 和超时。有些站点会屏蔽默认的 Node.js 请求，你需要伪装成正常浏览器。超时我一般设 10 秒，超过就放弃，避免 agent 卡死。第二，要处理重定向。很多 URL 会 301 或 302 跳转，你需要跟随重定向并记录最终 URL。第三，要处理动态渲染页面。如果页面内容是 JS 渲染的，直接抓 HTML 拿不到有效数据，这时候需要上无头浏览器。我一般先用轻量抓取，如果检测到关键字段为空，再降级到无头浏览器模式。

关键词密度分析这个 skill，核心是分词和统计。中文分词我用nodejieba，英文直接用空格和标点切分。统计逻辑是：先提取页面正文文本（去掉导航、页脚、脚本样式），然后计算目标关键词出现次数除以总词数。这里有个经验值：关键词密度在 1% 到 2.5% 之间比较健康，低于 0.5% 可能内容相关性不足，高于 3.5% 可能被判定为堆砌。但这个阈值不是绝对的，长文章可以适当低一些，短页面可以适当高一些。

内链检查 skill 会遍历页面所有<a>标签，区分内链和外链，然后检查内链目标是否返回 200。我一般会输出一个表格，列出所有内链的 URL、锚文本、状态码。如果发现 404 或者 301 链，就标记出来让 agent 决定是否修复。

这三个 skill 组合起来，就能完成一次基础的页面 SEO 审计。Agent 的调用顺序通常是：先extract-page-seo拿到页面结构，再analyze-keyword-density分析内容，最后check-internal-links检查链接。每一步的输出都可以作为下一步的输入，形成流水线。

3.2 CRO skill：漏斗分析与 CTA 变体生成

CRO（转化率优化）类 skill 比 SEO 类更依赖数据，也更依赖对用户行为的理解。我目前实现了两个核心 skill：analyze-funnel和generate-cta-variants。

analyze-funnel的思路是：给定一组漏斗步骤（比如“访问首页 → 进入产品页 → 加入购物车 → 完成支付”），以及每一步的转化数据，计算每一步的流失率，并识别流失最严重的环节。数据来源可以是 GA4 API，也可以是本地 CSV。我一般会输出一个漏斗图表格，加上每个环节的流失率排名。

这里有个计算细节：流失率 = (上一步人数 - 当前步人数) / 上一步人数。比如首页 10000 人，产品页 3000 人，那首页到产品页的流失率就是 70%。这个数字看起来很吓人，但其实是正常的——大部分电商站的首页到产品页转化率都在 20% 到 40% 之间。关键是看相对变化：如果某个环节的流失率突然比历史均值高了 20%，那才是需要关注的问题。

generate-cta-variants这个 skill 我用了比较简单的模板加变量替换策略。给定原始 CTA 文案和页面上下文，生成 3 到 5 个变体。变体维度包括：动作词替换（“立即购买” vs “马上抢购” vs “加入购物车”）、紧迫感添加（“限时优惠” vs “今日特价”）、利益点前置（“省 50%” vs “买一送一”）。每个变体都会附带一个预期提升理由，方便人工审核时判断是否合理。

注意：CTA 变体生成后不要直接上线。我踩过的坑是，agent 生成的某个变体在语法上没问题，但和品牌调性完全不搭，上线后转化率反而降了。建议把生成的变体先放进 A/B 测试队列，跑够统计显著性的样本量再决定是否全量。

CRO skill 的另一个重要能力是页面元素分析。我会让 agent 检查页面是否有明确的价值主张、是否有社会证明（评价、案例、logo）、是否有风险消除元素（退款保证、隐私政策）。这些检查项可以做成一个 checklist skill，输出一个打分表。分数不一定要精确，但能帮人快速定位明显缺失的环节。

3.3 Analytics skill：数据拉取与指标计算

Analytics 类 skill 是连接营销动作和实际效果的桥梁。没有数据反馈，前面的 SEO 和 CRO 都是盲猜。我实现了两个基础 skill：fetch-ga4-metrics和calculate-conversion-rate。

fetch-ga4-metrics通过 GA4 Data API 拉取指定时间范围内的指标数据。配置上需要先在 Google Cloud Console 创建服务账号，下载 JSON 密钥，然后在 GA4 后台把服务账号邮箱添加为查看者。这个流程看起来繁琐，但一次配置好之后就能长期用。我一般把密钥文件放在config/credentials/下，并在.gitignore里排除，避免泄露。

拉取数据时要注意维度组合不要太多。GA4 API 对每个请求的维度数量有限制，而且维度越多，数据采样越严重。我一般只拉核心维度：日期、页面路径、来源渠道、设备类别。指标包括：会话数、用户数、转化数、转化率、平均 engagement time。这些数据足够做大部分分析。

calculate-conversion-rate是一个纯计算 skill，输入分子分母，输出转化率和置信区间。置信区间的计算我用的是 Wald 区间公式：

p ± z * sqrt(p * (1 - p) / n)

其中 p 是转化率，n 是样本量，z 是置信水平对应的 z 值（95% 置信水平对应 1.96）。这个计算的意义在于：当两个变体的转化率差异在置信区间内重叠时，不能轻易判定哪个更好。我见过太多人看到 A 变体 5.1%、B 变体 5.3% 就立刻切到 B，结果样本量只有几百，差异完全在随机波动范围内。

这三个 skill 组合起来，就能形成“拉数据 → 算指标 → 判断显著性”的完整分析链路。Agent 可以定期跑这套流程，生成周报或日报，人只需要看结论和异常项。

4. 实操流程：从零跑通一个营销自动化任务

4.1 环境准备与 Claude Code 配置

先假设你从零开始。第一步是装 Node.js，版本建议 18 以上，因为很多 HTTP 库和新版 API 需要较新的运行时。装完之后验证一下：

node -v npm -v

然后装 Claude Code。如果你用的是 macOS 或 Linux，可以通过 npm 全局安装：

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

Windows 下如果遇到安装问题，可以试试用 WSL2，或者在 PowerShell 里用管理员权限跑。安装完成后，在项目目录下初始化：

claude init

这会生成一个基础的配置文件。然后你需要配置模型接入。Claude Code 默认用 Anthropic 的模型，但如果你需要接入其他模型（比如通过兼容接口），可以在配置里指定 base URL 和 API key。具体配置方式参考官方文档，这里不展开。

接下来创建marketingskills项目结构：

mkdir -p marketingskills/skills/{seo,cro,analytics} mkdir -p marketingskills/config mkdir -p marketingskills/data/snapshots cd marketingskills npm init -y npm install axios cheerio nodejieba

axios用于 HTTP 请求，cheerio用于 HTML 解析，nodejieba用于中文分词。这三个是基础依赖，后面按需加。

然后在config/agent.json里写系统提示：

{ "systemPrompt": "你是一个营销自动化助手。当前项目包含 SEO、CRO、Analytics 三类技能。你可以通过执行 `node skills/<category>/<skill-name>/index.js` 来调用技能，参数以 JSON 格式通过 stdin 传入，输出为 JSON 格式。在执行任何写操作前，先向用户确认。", "skillsDir": "./skills", "dataDir": "./data" }

这个提示告诉 Claude Code 有哪些能力可用，以及调用约定。配置好之后，启动 Claude Code：

claude

如果一切正常，你应该能看到一个交互式界面，可以开始输入指令了。

提示：如果你在 Ubuntu 上配置，可能会遇到权限问题。建议不要用 root 跑，而是创建一个专用用户，把项目放在用户目录下。另外，Node.js 的全局安装路径可能需要加到 PATH 里，具体看你的 shell 配置。

4.2 编写第一个 skill：extract-page-seo

我们从一个最简单的 skill 开始，把流程跑通。在skills/seo/extract-page-seo/下创建两个文件。

skill.json：

{ "name": "extract-page-seo", "description": "抓取指定 URL 的页面，返回 SEO 相关结构化数据", "input": { "type": "object", "properties": { "url": { "type": "string" } }, "required": ["url"] } }

index.js：

const axios = require('axios'); const cheerio = require('cheerio'); async function main() { let input = ''; process.stdin.on('data', chunk => input += chunk); process.stdin.on('end', async () => { const { url } = JSON.parse(input); try { const response = await axios.get(url, { timeout: 10000, headers: { 'User-Agent': 'Mozilla/5.0 (compatible; MarketingSkills/1.0)' } }); const $ = cheerio.load(response.data); const result = { title: $('title').text().trim(), metaDescription: $('meta[name="description"]').attr('content') || '', headings: $('h1, h2, h3').map((i, el) => ({ level: el.tagName, text: $(el).text().trim() })).get(), imageAlts: $('img').map((i, el) => $(el).attr('alt') || '').get(), internalLinks: 0, externalLinks: 0 }; const host = new URL(url).hostname; $('a[href]').each((i, el) => { const href = $(el).attr('href'); if (href.startsWith('http')) { if (href.includes(host)) result.internalLinks++; else result.externalLinks++; } else if (href.startsWith('/')) { result.internalLinks++; } }); process.stdout.write(JSON.stringify(result, null, 2)); } catch (err) { process.stdout.write(JSON.stringify({ error: err.message })); } }); } main();

这个脚本的逻辑很直白：读 stdin 的 JSON，发 HTTP 请求，用 cheerio 解析，输出结构化 JSON。你可以手动测试：

echo '{"url":"https://example.com"}' | node skills/seo/extract-page-seo/index.js

如果输出正常，说明 skill 可用。然后在 Claude Code 里输入：“帮我分析一下 https://example.com 的 SEO 情况”，它应该会自动调用这个 skill 并展示结果。

4.3 串联多个 skill 完成一次完整审计

单个 skill 跑通后，下一步是让 agent 串联多个 skill。比如你输入：“对 https://example.com 做一次完整的 SEO 审计，包括页面结构、关键词密度和内链检查。”

Agent 的推理过程大概是：先调extract-page-seo拿到页面数据，然后从数据里提取正文文本，调analyze-keyword-density分析关键词，同时调check-internal-links检查链接。最后把三个结果汇总成一份报告。

这里的关键是中间数据的传递。extract-page-seo输出的 headings 和正文文本，需要作为analyze-keyword-density的输入。我在实现时会让extract-page-seo额外输出一个bodyText字段，存正文纯文本。这样下一个 skill 直接读这个字段就行，不需要重新抓页面。

analyze-keyword-density的实现：

const nodejieba = require('nodejieba'); async function main() { let input = ''; process.stdin.on('data', chunk => input += chunk); process.stdin.on('end', () => { const { text, keyword } = JSON.parse(input); const words = nodejieba.cut(text); const total = words.length; const count = words.filter(w => w === keyword).length; const density = total > 0 ? (count / total * 100).toFixed(2) : '0.00'; process.stdout.write(JSON.stringify({ keyword, count, totalWords: total, density: parseFloat(density) }, null, 2)); }); } main();

check-internal-links稍微复杂一点，需要并发请求多个 URL 并检查状态码。我用Promise.all加并发限制，避免一次性发太多请求把目标站点打挂。并发数我一般设 5，超时 5 秒。

三个 skill 都跑通后，一次完整审计的耗时大概在 10 到 30 秒之间，取决于页面大小和链接数量。输出是一份 JSON 报告，包含所有检查项和发现的问题。你可以让 agent 把报告格式化成 Markdown 表格，直接贴到文档里。

注意：并发请求一定要加限制。我一开始没加，结果对一个有 200 多个内链的页面做检查时，瞬间发了 200 个请求，直接把目标站点触发了限流，后面所有请求都返回 429。后来改成并发 5、每个请求间隔 200ms，就稳定了。

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

5.1 Skill 调用失败排查速查表

在实际使用中，skill 调用失败是最常见的问题。我整理了一份速查表，覆盖大部分场景：

这份表是我踩坑踩出来的。特别是“输出为空”这一条，我遇到过好几次，最后发现是 agent 传参时用了单引号包裹 JSON，而 shell 把单引号吃掉了。后来统一改成用 heredoc 或者临时文件传参，问题就解决了。

另一个高频问题是模型对 skill 描述的理解偏差。比如你写“分析关键词密度”，模型可能理解成“分析关键词的搜索量”。解决办法是把 skill 描述写得更具体：“给定文本和目标关键词，计算该关键词在文本中的出现次数和密度百分比”。描述越具体，模型匹配越准确。

5.2 数据准确性与 agent 幻觉的应对

Agent 幻觉在营销场景里特别危险，因为它可能编造一个看起来很合理但完全错误的数据。我遇到过 agent 在报告里写“该页面关键词密度为 2.3%，处于健康范围”，但实际上它根本没调用 skill，而是根据页面内容猜的。

应对方法有几个。第一，强制 agent 在输出数据时附带来源。比如要求它写“根据 extract-page-seo 的输出，标题长度为 58 字符”，而不是直接说“标题长度合适”。第二，在系统提示里明确禁止编造数据：“所有数字必须来自 skill 的实际输出，如果 skill 未返回该数据，必须说明‘数据不可用’。”第三，定期抽查。我会随机选几条 agent 的输出，手动跑一遍 skill 对比结果，发现偏差就调整提示词。

还有一个技巧是让 agent 输出中间步骤。比如要求它先列出“我将调用以下 skill：1. extract-page-seo 2. analyze-keyword-density”，然后再执行。这样你能看到它的推理路径，如果路径不对，可以在执行前纠正。

提示：不要完全信任 agent 的结论。我的做法是让 agent 输出原始数据和结论，人只看结论但保留核查原始数据的能力。这样既提高了效率，又保留了纠错空间。

5.3 性能优化与成本控制

当 skill 数量多、调用频繁时，性能和成本会成为问题。我总结了几个优化点。

缓存：对同一 URL 的页面抓取结果缓存 24 小时。很多审计任务会重复抓同一个页面，缓存能省掉大量重复请求。我用文件缓存，按 URL 的 hash 做文件名，存在data/snapshots/下。

批量处理：如果需要分析多个页面，不要一个一个调 skill，而是写一个批量 skill，一次接收 URL 列表，内部并发处理。这样减少了 agent 和 skill 之间的往返次数。

模型调用成本：Claude Code 每次推理都会消耗 token。如果任务简单，可以用更小的模型；如果任务复杂，再用大模型。我一般把 skill 执行和模型推理分开——skill 执行不消耗模型 token，只有 agent 的推理和结果汇总消耗。所以尽量把重活放在 skill 里，让 agent 只做编排和总结。

超时和重试：网络请求一定要设超时，并且对失败请求做有限重试。我一般设 2 次重试，间隔 1 秒。超过就放弃并记录错误，不要让 agent 无限等待。

这些优化不是一开始就要做，而是等到你发现“怎么这么慢”或者“怎么这么贵”的时候再逐步加上。过早优化会增加复杂度，反而拖慢开发进度。

6. 扩展方向：从单点 skill 到营销自动化流水线

跑通基础流程后，marketingskills可以往几个方向扩展。第一个方向是定时任务。用 cron 或者 node-cron 定期跑 SEO 审计、拉取 Analytics 数据、生成周报。Agent 不需要一直在线，只需要在触发时启动、执行、退出。

第二个方向是多站点管理。如果你有多个独立站，可以把站点配置抽出来，每个站点一套 credentials 和 skill 参数。Agent 根据站点 ID 选择对应配置，实现一套 skill 服务多个站点。

第三个方向是与内容管理系统集成。比如把生成的 CTA 变体直接推送到 CMS 的草稿箱，或者把 SEO 建议写成评论挂在对应页面上。这需要额外写集成 skill，但能进一步缩短“分析到执行”的链路。

第四个方向是引入更多数据源。除了 GA4，还可以接入 Search Console、热力图工具、CRM 数据。数据源越多，分析越全面，但也要注意数据质量和隐私合规。我一般只接入自己拥有完全控制权的数据源，避免合规风险。

最后一个方向是skill 的市场化。如果你把 skill 设计得足够通用，可以打包成 npm 包或者 Docker 镜像，分享给团队或社区。我目前把一些通用 skill 抽出来放在独立仓库里，通过 npm link 在多个项目间复用。这样既保持了项目独立性，又避免了重复造轮子。

提示：扩展的时候要克制。我见过太多项目因为功能越加越多，最后变得难以维护。建议每加一个 skill 之前先问：这个 skill 解决的是高频问题还是低频问题？如果一个月用不到一次，可能不值得做成 skill，手动处理更划算。

7. 我个人的一些实操体会

这套东西我断断续续折腾了大半年，最大的体会是：营销自动化的瓶颈不在技术，而在对营销动作的理解。你让 agent 调用 skill 很容易，但你要先想清楚“这个营销动作到底在做什么、输入是什么、输出是什么、怎么判断做得好不好”。想不清楚这些，skill 写得再漂亮也是花架子。

另一个体会是从小处着手。我一开始想做一个“全自动增长引擎”，结果卡在数据对齐上整整两周。后来退回来，只做一个“页面 SEO 审计”的 skill，跑通之后再逐步加 CRO 和 Analytics。每一步都验证过、稳定了，再往下走。这样虽然看起来慢，但实际比大跃进快得多。

还有一点是保留人工审核环节。Agent 可以生成建议，但最终执行最好由人确认。我试过让 agent 直接改页面标题，结果它把一个核心关键词从标题里删了，理由是“标题太长”。虽然它说得有道理，但那个关键词是主要流量来源，删了之后排名直接掉了。从那以后，所有写操作我都加了确认步骤。

最后分享一个小技巧：给每个 skill 写一个“反例”测试。比如extract-page-seo的反例是“传入一个不存在的域名”，看它是否返回清晰的错误信息而不是崩溃。analyze-keyword-density的反例是“传入空文本”，看它是否处理边界情况。这些反例测试能帮你提前发现很多问题，比等到线上出故障再排查高效得多。

这套marketingskills的思路还在演进，我也在持续加新的 skill 和优化现有流程。如果你也在做类似的事情，欢迎交流踩坑经验。这个领域没有标准答案，每个人根据自己的业务场景调整，能跑通、能产出价值，就是好方案。