企业官网建设流程全解析

1. 从"marketingskills"这个标题说起：它到底想解决什么问题

第一次看到"marketingskills"这个词，我脑子里冒出来的不是某个具体工具，而是一类很实际的需求：把营销这件事拆成一项项可复用的技能，然后让 AI 去执行。过去两年我一直在折腾各种 AI 编程助手和自动化流程，接触最多的场景之一，就是帮做独立站、做内容、做增长的朋友把重复性的营销动作交给 AI 去跑。这个标题背后真正指向的，是一套"营销技能库"的思路——把 SEO、CRO、内容生产、关键词研究这些动作，封装成 AI agent 能理解、能调用的技能模块。

为什么这个方向值得单独拿出来讲？因为绝大多数人用 AI 做营销，还停留在"打开对话框，问一句，复制一段"的阶段。这种方式的问题非常明显：每次都要重新描述背景，输出质量忽高忽低，没法沉淀，也没法批量执行。而"marketingskills"这类思路的核心价值，是把营销工作流标准化、模块化，让 AI 每次都能在固定的框架里干活。它适合的人群很明确：独立站运营者、做 SEO 的自由职业者、内容团队里负责增长的人，以及任何想把营销动作自动化、但又不想写一大堆代码的人。

我自己的判断是，这个标题背后其实藏着三层东西。第一层是技能定义——一项营销技能到底包含哪些输入、哪些步骤、哪些输出。第二层是执行载体——用什么来跑这些技能，比如 Claude Code 这类能在终端里直接执行命令、读写文件的 AI agent。第三层是落地场景——SEO 的 FAQ 结构化数据、CRO 的落地页优化、独立站的关键词布局，这些都是具体能见效的地方。接下来我会把这三层拆开讲，重点放在"怎么定义技能""怎么让 agent 跑起来""怎么在真实项目里验证效果"。

需要先说明一点：下面涉及的工具配置和操作步骤，一部分来自我自己的实测，一部分是基于这类 AI agent 工具的常见实践做的合理补充。不同版本、不同系统环境下细节会有差异，你在复现的时候以自己环境的实际表现为准。

2. 把营销动作拆成"技能"：marketingskills 的底层设计逻辑

2.1 为什么"技能化"比"提示词化"更适合营销场景

很多人会问：我直接写一段提示词不就行了吗，为什么要搞成"技能"？这个问题我踩过坑。早期我也是把一堆提示词存在笔记里，用的时候复制粘贴。用了几个月之后发现两个致命问题：一是提示词越写越长，最后变成一篇小作文，AI 反而抓不住重点；二是同一个任务，今天跑和下周跑，结果结构完全不一样，没法做对比，也没法沉淀经验。

"技能"和"提示词"最大的区别在于结构化和可复用性。一项技能应该包含固定的几个部分：触发条件（什么时候用这个技能）、输入要求（需要提供什么信息）、执行步骤（按什么顺序做什么）、输出格式（结果长什么样）、校验标准（怎么判断做得好不好）。这五个部分定下来之后，无论谁来跑、什么时候跑，产出的骨架都是一致的。对营销工作来说，这一点特别重要，因为营销的很多动作是需要反复迭代的——你今天优化了一版落地页文案，下周要根据数据再改一版，如果两次的评估维度都不一样，你根本没法判断改动到底有没有效果。

我举个具体的例子。假设我们要定义一项"独立站产品页 SEO 审计"技能。提示词化的做法可能是："帮我看看这个产品页的 SEO 有没有问题。"而技能化的做法是：输入要求是产品页 URL 加目标关键词；执行步骤是先检查 title 和 meta description 的长度与关键词覆盖，再检查 H1/H2 结构，再检查图片 alt 属性，再检查内链和外链，最后检查结构化数据；输出格式是一张表格，列出问题项、严重程度、修改建议；校验标准是每个问题项都要能对应到具体的 SEO 最佳实践。你看，后者跑出来的东西，是可以直接拿去改页面的，前者往往只能得到一堆泛泛而谈。

2.2 一项合格营销技能应该包含的五个字段

基于我自己的实践，我把营销技能拆成五个字段来定义，这套结构在多个项目里验证过，比较稳。

• 技能名称与触发词：名称要短，触发词要具体。比如"faq-schema-gen"这种，一看就知道是生成 FAQ 结构化数据的。
• 输入契约：明确需要哪些输入，哪些是必填，哪些是可选。必填项缺失时，技能应该主动追问，而不是瞎猜。
• 执行步骤：按顺序列出每一步做什么。步骤要细到"打开哪个文件""检查哪个字段"这个粒度。
• 输出模板：给出一个固定的输出结构，比如 Markdown 表格、JSON、或者一段带小标题的文本。
• 质量校验清单：列出几条硬性标准，跑完之后逐条对照。

这五个字段里，最容易被忽略的是输入契约和质量校验清单。大多数人只写执行步骤，结果 AI 拿到不完整的输入就开始编，输出看着挺像那么回事，实际全是错的。而质量校验清单是保证输出稳定的关键，它相当于给 AI 一个自检的钩子。

2.3 技能库的组织方式：按"营销漏斗"还是按"交付物"

技能多了之后，怎么组织是个问题。我试过两种方式。一种是按营销漏斗分：认知层、考虑层、转化层、留存层。另一种是按交付物分：页面类、内容类、数据类、广告类。实测下来，按交付物分更适合 AI agent 场景。原因是 AI 执行任务时，它关心的是"我要产出一个什么东西"，而不是"这个动作属于漏斗哪一层"。按交付物分，技能之间的依赖关系也更清晰——比如"关键词研究"产出关键词列表，"内容大纲生成"消费这个列表，"页面文案生成"再消费大纲，形成一条清晰的流水线。

我现在的做法是建一个目录结构，每个技能一个文件夹，里面放一个技能定义文件（Markdown 或 YAML 都行），再加一个示例输入和示例输出。这样无论是人看还是 AI 读，都很清楚。下面是一个简化的目录示意：

marketingskills/ seo/ keyword-research/ skill.md example-input.md example-output.md faq-schema-gen/ skill.md example-input.md example-output.md cro/ landing-page-audit/ skill.md example-input.md example-output.md content/ outline-gen/ skill.md example-input.md example-output.md

这个结构的好处是，当你用 Claude Code 这类工具时，可以直接让它读取某个技能文件夹，然后按技能定义去执行。技能定义文件本身也是 Markdown，AI 读起来毫无障碍。

3. 让 AI agent 真正跑起来：Claude Code 在营销技能库里的角色

3.1 为什么选 Claude Code 这类终端型 agent 而不是纯对话工具

纯对话工具做营销，最大的短板是它碰不到你的文件系统。你让它改一个页面的 meta description，它只能给你一段文字，你还得自己复制到文件里。而 Claude Code 这类能在终端里执行命令、读写文件的 agent，可以直接打开你的项目文件，改完保存，甚至跑一个脚本验证结果。这个差别在批量任务上会被放大很多倍。

我拿一个真实场景说明。假设你有一个独立站，有 50 个产品页需要做 SEO 审计。纯对话工具的做法是：你把每个页面的内容复制进去，问一遍，得到建议，再手动改。50 个页面就是 50 轮对话加 50 次手动操作。而用终端型 agent 的做法是：写一个技能定义，让它遍历指定目录下的所有 HTML 文件，逐个审计，把结果汇总成一张表，然后按优先级批量修改。整个过程你只需要在关键节点确认一下。这就是"技能库 + agent"组合的威力。

Claude Code 的安装和配置，不同系统略有差异。macOS 和 Ubuntu 下一般通过包管理器或者官方提供的安装方式来做，Windows 下要注意 64 位兼容性问题，有些版本在特定 Windows 环境下会报不兼容。安装完之后，通常需要在 VS Code 里配置插件，或者直接在终端里调用。如果你所在的环境访问受限，也可以考虑接入第三方 API 或者本地模型，比如通过一些模型切换工具接入 DeepSeek、Qwen、GLM 这类模型。这里我不展开具体配置命令，因为版本更新很快，你以官方文档为准，重点是把"agent 能读写文件、能执行命令"这个能力跑通。

3.2 技能定义文件怎么写才能让 agent 准确执行

这是整个流程里最考验功力的地方。技能定义写得好，agent 执行得就准；写得含糊，agent 就开始自由发挥。我的经验是，技能定义要遵循"步骤可执行、判断有依据、输出有模板"三个原则。

先说步骤可执行。不要写"优化页面 SEO"这种话，要写"读取 index.html，找到 title 标签，检查字符数是否在 50 到 60 之间，如果超出则给出缩短建议"。每一步都要对应一个具体动作，agent 才知道该调用什么工具。

再说判断有依据。凡是涉及"好/不好""合格/不合格"的判断，都要给出明确标准。比如"meta description 长度在 120 到 158 字符之间为合格"，而不是"meta description 要合理"。AI 对模糊标准的理解每次都不一样，只有量化标准才能保证一致性。

最后说输出有模板。给一个具体的输出示例，比描述十句都管用。我通常会在技能定义里直接放一个 Markdown 表格模板，agent 照着填就行。

下面是一个"FAQ 结构化数据生成"技能的简化定义示例，你可以参考这个结构：

# 技能：faq-schema-gen ## 触发条件 当需要为页面生成 FAQ 结构化数据时使用。 ## 输入 - 页面主题（必填） - 目标关键词（必填） - 已有 FAQ 内容（可选，如有则基于此生成） ## 执行步骤 1. 读取输入的主题和关键词 2. 生成 5 到 8 个用户最可能搜索的问题 3. 每个问题配一段 40 到 80 字的回答 4. 按 schema.org 的 FAQPage 格式输出 JSON-LD 5. 校验 JSON 语法是否正确 ## 输出模板 （此处放 JSON-LD 模板） ## 质量校验 - 问题必须覆盖目标关键词的变体 - 回答不能超过 80 字 - JSON-LD 必须通过语法校验

这个定义里，每一步都是可执行的，判断标准是量化的，输出有模板，校验有清单。agent 拿到这样的定义，执行准确率会高很多。

3.3 本地模型与第三方 API 的取舍：什么场景用什么

不是所有场景都需要用最强的模型。我自己的做法是分层：需要深度推理和复杂判断的任务用强模型，格式转换和批量处理用本地模型或轻量 API。比如关键词聚类、内容大纲生成这种需要理解语义的任务，用强模型效果明显更好；而把一批数据从 CSV 转成 JSON、批量替换页面里的某个字段，这种任务用本地模型就够了，还省成本。

接入本地模型一般通过 LM Studio 这类工具起一个本地服务，然后让 agent 指向这个服务。第三方 API 的话，通过模型切换工具可以接入 DeepSeek、Qwen、GLM 等。这里要注意的是，不同模型对工具调用的支持程度不一样，有些模型在 agent 场景下表现不稳定，会漏掉步骤或者不按格式输出。我的建议是，技能库先在一个模型上跑通，确认流程没问题，再考虑换模型或者做混合调度。

4. SEO 与 CRO 场景下的技能落地：从 FAQ 结构化数据到落地页审计

4.1 FAQ 结构化数据为什么值得单独做成一项技能

"谷歌 SEO 的 FAQ page 结构化数据是怎么回事"这个问题，我在不同场合被问过很多次。简单说，FAQPage 结构化数据是一种告诉搜索引擎"这个页面包含问答内容"的标记方式，它有机会让搜索结果里直接展示你的问答，增加曝光面积。对独立站来说，这是一个性价比很高的优化点，因为它的实现成本不高，但带来的展示效果提升比较直观。

但为什么值得做成一项技能？因为手工做这件事非常繁琐且容易出错。你需要为每个页面想问题、写回答、拼 JSON-LD、校验语法、嵌入页面。一个页面还好，几十个页面就是灾难。而这项技能一旦定义好，agent 可以批量处理：读取页面内容，生成问题，写回答，输出 JSON-LD，校验，嵌入。整个过程标准化，出错率大幅下降。

我在实操中总结的几个要点：问题要贴近真实搜索意图，不要自己造一些没人搜的问题；回答要简洁，控制在 80 字以内，太长了搜索引擎可能不展示；JSON-LD 的语法一定要校验，一个逗号错了整段就失效；同一个页面不要堆太多 FAQ，5 到 8 个比较合适，太多反而显得刻意。

4.2 独立站 SEO 审计技能：检查项与优先级怎么定

独立站 SEO 审计是另一项高频技能。我把它拆成几个检查维度，每个维度下再列具体检查项，然后给每项定优先级。下面这张表是我常用的审计框架：

这张表的价值在于，它把"审计"这个模糊的动作变成了可执行的清单。agent 拿到这张表，可以逐项检查，逐项打分，最后输出一份带优先级的报告。你拿到报告之后，先改高优先级的，再改中优先级的，节奏很清楚。

这里有个经验：不要一次性让 agent 改所有问题。我试过让它一口气改完一个页面的所有 SEO 问题，结果它改着改着就乱了，有些改动还互相冲突。后来我改成按优先级分批改，每批改完确认一下，稳定性好很多。这个道理其实和人做事情一样，一次专注一件事，比同时处理一堆事靠谱。

4.3 CRO 落地页审计：把"转化率优化"拆成可执行动作

CRO 比 SEO 更抽象，因为转化率受很多因素影响，很难说某一个改动就一定能提升转化。但抽象不代表不能技能化。我的做法是把 CRO 审计拆成几个可观察的维度：首屏信息清晰度、行动号召按钮、信任元素、表单复杂度、移动端体验。每个维度下再列具体检查项。

比如首屏信息清晰度，检查项包括：主标题是否在 3 秒内说清价值主张、副标题是否补充了具体信息、首屏是否有明确的下一步动作。行动号召按钮的检查项包括：按钮文案是否具体（"免费试用"比"提交"好）、按钮颜色是否与背景有足够对比、按钮位置是否在视线自然落点。

这些检查项看起来简单，但真正逐条对照的时候，你会发现很多页面都有问题。我见过不少独立站，首屏放了一张很大的氛围图，主标题写得很文艺，但用户看完根本不知道这个产品是干嘛的。这种问题，人眼扫过去容易忽略，但按清单逐条检查就藏不住。

CRO 技能的输出，我建议用"问题 + 影响 + 建议"的三段式。问题描述清楚哪里不对，影响说明这个问题可能怎么影响转化，建议给出具体的修改方案。这样运营拿到报告，不用再猜"那我到底该怎么改"。

5. 实操中踩过的坑与稳定性经验

5.1 技能定义写太"聪明"反而容易翻车

我一开始写技能定义，总想写得面面俱到，把各种边界情况都考虑进去。结果发现，定义越长，agent 执行越不稳定。后来我悟了：技能定义要像给新人的操作手册，而不是像给专家的设计文档。新人手册的特点是步骤明确、判断标准清晰、不需要太多背景知识就能执行。设计文档的特点是充满权衡和取舍，需要读者有足够的背景才能理解。

举个例子。我早期写过一个"内容大纲生成"技能，里面写了一大段关于"如何判断内容角度是否有差异化"的说明。结果 agent 每次执行到这一步就开始纠结，输出的大纲结构五花八门。后来我把这段删了，改成"生成 3 个不同角度的大纲，每个角度用一句话说明差异点"，输出立刻稳定了。这个教训是：把判断留给规则，把选择留给人。agent 负责按规则生成选项，人来决定用哪个。

5.2 批量任务一定要做"小样本验证"

这是我最想强调的一条经验。无论技能定义写得多好，在批量执行之前，一定要先拿 2 到 3 个样本跑一遍，确认输出符合预期，再放开批量。我踩过的坑是：有一次定义了一个批量修改 meta description 的技能，直接跑了 80 个页面，跑完一看，有十几个页面的描述被改得莫名其妙，因为那些页面的内容结构比较特殊，技能定义没覆盖到。结果只能回滚重来，浪费了大半天。

小样本验证的成本很低，但能避免的损失很大。我的做法是，技能定义写完后，先手动挑 3 个有代表性的样本（一个标准的、一个边缘的、一个特殊的），跑一遍，检查输出。三个都过了，再批量。这个习惯养成之后，翻车率下降了很多。

5.3 输出格式校验：别让一个逗号毁掉整批结果

结构化数据、JSON 输出、配置文件这类东西，对格式极其敏感。一个逗号、一个引号错了，整段就失效。agent 生成这类内容时，偶尔会犯低级错误。所以我在技能定义里都会加一步"格式校验"，让 agent 生成完之后自己检查一遍语法。如果环境里有校验工具，比如 JSON 校验器，直接调用工具校验更可靠。

另外，输出最好带一个"校验结果"字段，明确写"通过"或"不通过"。这样你批量跑完之后，扫一眼就知道哪些需要人工介入。我现在的习惯是，任何涉及结构化输出的技能，输出里都必须有一个校验状态字段，没有这个字段的技能定义我都不放心用。

5.4 模型切换时的兼容性检查清单

如果你用多个模型跑同一套技能库，切换模型时一定要做兼容性检查。不同模型对指令的遵循程度、对输出格式的坚持程度、对工具调用的支持程度都不一样。我整理了一个简单的检查清单，每次换模型时过一遍：

• 技能定义里的步骤，新模型是否都能正确执行
• 输出格式是否和原来一致
• 遇到模糊输入时，新模型是追问还是瞎猜
• 工具调用是否正常，有没有漏调用或重复调用
• 长任务执行到后半段时，是否还能保持稳定

这个清单看起来简单，但能帮你快速判断一个新模型适不适合你的技能库。我试过几个模型，有的在短任务上表现很好，一到长任务就开始丢步骤；有的格式坚持得很好，但推理能力弱，判断类任务做不好。没有哪个模型是万能的，关键是找到适合你具体任务的组合。

6. 技能库的扩展方向与个人实践体会

技能库建起来之后，扩展方向其实很多。我目前在做的一个方向是技能之间的串联。单个技能解决单点问题，但营销工作往往是链式的：关键词研究产出关键词，内容大纲消费关键词，页面文案消费大纲，SEO 审计检查文案，CRO 审计再检查页面。如果把这些技能串成一条流水线，agent 就能端到端地跑完一个完整流程。这个方向我还在摸索，目前的难点在于技能之间的数据格式要统一，不然串起来会断。

另一个方向是技能的效果追踪。技能跑完不是终点，效果怎么样才是关键。比如 FAQ 结构化数据加上去之后，搜索结果的展示有没有变化；落地页按 CRO 建议改完之后，转化率有没有提升。把这些效果数据回填到技能库里，就能形成"执行-反馈-优化"的闭环。这一步需要一些数据埋点和统计工具配合，我目前是用简单的表格手动记录，后面考虑做成自动化的。

最后分享一个我自己的体会。做这套东西最大的收获，不是省了多少时间，而是把营销经验显性化了。以前很多判断是靠感觉，说不清楚为什么。现在要把判断写成技能定义里的规则，就必须逼自己想清楚"我到底依据什么做这个判断"。这个过程本身，比技能库跑起来更有价值。你会发现自己以前很多"经验"，其实是模糊的直觉，经不起推敲。把它们一条条写清楚，才是真正的沉淀。

如果你也想开始做自己的营销技能库，我的建议是从一个最小的技能开始，别贪多。挑一个你每周都要重复做的动作，把它拆成步骤，写成定义，跑通，再跑稳。一个技能跑顺了，再复制这个模式做第二个。技能库是长出来的，不是设计出来的。