企业官网建设流程全解析

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

第一次看到"marketingskills"这个词，我脑子里冒出来的第一个念头是：这大概率不是一个单纯的营销课程或者资料合集，而更像是一套"技能包"——把营销工作中那些高频、重复、有固定套路的动作，拆解成可以被工具调用、被流程复用的模块。结合热搜词里反复出现的 Claude Code、AI agents、SEO、CRO 这几个词，基本可以判断，这个项目想做的事情是：用 AI agent 的方式，把营销技能工程化。

为什么这么说？因为传统做营销，尤其是做独立站和谷歌 SEO 的人，日常干的活儿其实高度碎片化：写落地页文案、做关键词调研、优化 FAQ 结构化数据、跑 A/B 测试、分析转化漏斗、写邮件序列、做竞品拆解……每一件事单独看都不难，但堆在一起就是无底洞。一个运营一天能高质量产出的东西是有上限的，而这个上限往往卡在"重复劳动"上，不是卡在"创意"上。

marketingskills 这个思路的价值就在于，它把这些重复劳动抽象成了"技能"（skills），然后交给 AI agent 去执行。你可以把它理解成给 AI 装了一本《营销操作手册》，手册里写清楚了每一步该怎么做、输入是什么、输出是什么、什么情况下该走哪个分支。这样 AI 就不再是那个只会聊天、写点泛泛文案的玩具，而是一个能真正接手具体营销任务的执行者。

这篇文章适合谁看？三类人。第一类是做独立站、做谷歌 SEO 的运营和站长，你们最需要把重复工作自动化；第二类是正在折腾 Claude Code、想搞清楚 AI agent 到底怎么落地到具体业务的人；第三类是对 CRO（转化率优化）感兴趣、想把数据驱动落到实处的从业者。不管你是刚入门还是已经做过几个项目，只要你想让 AI 真正帮你干活而不是帮倒忙，这篇内容都值得往下看。

需要提前说明的是，下面涉及的具体配置、目录结构、提示词写法，一部分来自公开的通用实践，一部分是我自己在类似项目里踩出来的经验。凡是原文没有明确给出的细节，我都会标注清楚这是"基于常见实践的合理补全"，你可以根据自己的实际情况调整。

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

2.1 为什么是"技能"而不是"提示词模板"

很多人做 AI 营销工具的第一反应是攒一堆提示词模板，什么"爆款文案生成器""SEO 标题优化器"，存到 Notion 里，用的时候复制粘贴。这个做法在早期能用，但很快就会崩，原因有三个。

第一，提示词模板是静态的。你写死了一个"生成产品描述"的模板，但真实场景里，产品描述要分品类、分受众、分渠道，一个模板根本覆盖不了。第二，模板之间不联动。你做完关键词调研，结果要手动复制到文案生成那一步，中间全靠人肉搬运。第三，模板没有判断能力。它不知道当前这个页面是该优化标题还是该改 CTA，只能等你告诉它。

"技能"这个概念不一样。一个技能本质上是一个带输入输出契约、带执行逻辑、带边界条件的功能单元。它知道自己什么时候被调用、需要什么参数、产出什么结果、失败了怎么办。这跟软件工程里的"函数"是一个道理。当你把营销工作拆成一个个技能，AI agent 就能像调用函数一样把它们串起来，形成完整的工作流。

举个具体例子。在 marketingskills 的语境下，"关键词调研"不是一个提示词，而是一个技能：输入是种子词和竞品域名，输出是分好组的关键词列表加上搜索意图标注，执行逻辑是先抓竞品页面、再提取词、再聚类、再打意图标签。这个技能可以被"内容规划"技能调用，也可以被"落地页优化"技能调用，复用性一下就上来了。

2.2 一个营销技能应该包含哪几个部分

根据我在实际项目里的经验，一个能用的营销技能，至少要包含五个部分，缺一个都会在真实使用中出问题。

• 触发条件：什么情况下该用这个技能。比如"当用户提供一个落地页 URL 且要求提升转化率时"。
• 输入契约：需要哪些参数，哪些必填哪些可选。比如关键词调研技能，种子词必填，竞品域名可选，目标地区可选。
• 执行步骤：具体分几步做，每步用什么工具或数据源。这一步是技能的核心。
• 输出格式：产出什么结构的数据。是 Markdown 表格、JSON、还是直接可粘贴的 HTML。
• 边界与失败处理：什么情况下这个技能不适用，失败了返回什么。比如竞品页面抓不到时，是报错还是降级用公开数据。

这五个部分里，最容易被忽略的是边界与失败处理。我见过太多人写的技能，happy path 跑得飞起，一遇到异常就胡言乱语。比如让 AI 分析一个打不开的页面，它不会说"我打不开"，而是会编一段看起来很像那么回事的分析。这在营销场景里是致命的，因为你会基于假数据做决策。

2.3 技能之间怎么组合成工作流

单个技能价值有限，真正的威力在于组合。marketingskills 这类项目的典型工作流是这样的：

1. 调研阶段：关键词调研技能 + 竞品拆解技能，产出机会点清单。
2. 规划阶段：内容规划技能，把机会点转成内容日历和页面结构。
3. 生产阶段：文案生成技能 + 结构化数据技能，产出页面内容和 FAQ schema。
4. 优化阶段：CRO 分析技能 + A/B 测试设计技能，基于数据迭代。

这个链条里，每一步的输出都是下一步的输入，中间不需要人肉搬运。这才是"技能包"相对于"提示词模板"的本质区别。你可以把它想象成一条流水线，而不是一堆散落的工具。

提示：设计工作流时，一定要让每一步的输出格式对下一步友好。我踩过的坑是，调研阶段输出的是给人看的漂亮报告，结果规划阶段根本没法解析，只能手动重录一遍。后来改成"人看的报告 + 机器读的 JSON"双输出，问题才解决。

3. 用 Claude Code 承载 marketingskills：环境搭建与技能目录设计

3.1 为什么选 Claude Code 而不是普通对话界面

热搜词里 Claude Code 出现频率极高，这不是偶然。普通对话界面适合"一问一答"，但 marketingskills 这种项目需要的是能读写文件、能执行命令、能多轮自主推进的环境。Claude Code 恰好满足这三点：它能直接操作你本地的项目目录，能跑脚本抓数据，能在你给一个目标后自己拆解步骤往下做。

打个比方，普通对话界面像是一个只能跟你聊天的顾问，Claude Code 像是一个能进你办公室、打开你电脑、帮你把活干完的同事。做营销技能包，你需要的是后者。

安装和配置这块，网上教程已经很多，我不重复造轮子，只讲几个跟 marketingskills 项目强相关的点。第一，项目目录要独立。不要把你的技能包散落在各个地方，建一个专门的目录，比如~/projects/marketingskills，所有技能、数据、产出都放里面。第二，用 Git 管理。技能是会迭代的，今天写的关键词调研逻辑，下周可能就要改，没有版本控制你会疯。第三，配置文件单独放。API key、数据源地址这些敏感信息，放.env或者单独的 config 文件，别硬编码在技能里。

3.2 技能目录应该怎么组织

这是我实际用下来比较顺手的一种结构，你可以参考：

marketingskills/ ├── skills/ # 所有技能定义 │ ├── keyword-research/ │ │ ├── SKILL.md # 技能说明与执行逻辑 │ │ ├── input.schema # 输入契约 │ │ └── examples/ # 示例输入输出 │ ├── competitor-audit/ │ ├── content-planning/ │ ├── faq-schema/ │ └── cro-analysis/ ├── workflows/ # 组合好的工作流 │ ├── new-site-launch.md │ └── landing-page-optimize.md ├── data/ # 中间数据和产出 │ ├── raw/ │ └── processed/ ├── config/ │ └── sources.yaml # 数据源配置 └── README.md

这个结构的关键在于技能、工作流、数据三层分离。技能是能力，工作流是编排，数据是结果。分开之后，你想换一个数据源，只改 config；想调整执行顺序，只改 workflow；想升级某个技能，只动 skills 下对应的目录。互不干扰。

3.3 SKILL.md 里到底该写什么

SKILL.md 是整个技能包的核心文件，它决定了 AI 能不能正确执行这个技能。我见过两种极端写法：一种是写得太简略，就一句话"帮我做关键词调研"，AI 只能瞎猜；另一种是写得太啰嗦，把营销学教材抄了一遍，AI 抓不住重点。

我的经验是，SKILL.md 应该像一份给聪明但不懂你业务的实习生看的操作手册。它需要包含：

• 技能目标：一句话说清楚这个技能产出什么。
• 适用场景：什么情况下用，什么情况下不用。
• 执行步骤：分步骤写，每步说清楚做什么、用什么、产出什么。
• 输出规范：格式、字段、示例。
• 注意事项：容易出错的地方、边界条件。

举个 FAQ 结构化数据技能的例子，SKILL.md 里应该写清楚：输入是页面主题和目标关键词，输出是符合规范的 FAQPage JSON-LD，步骤是先基于关键词生成 5-8 个真实用户会问的问题，再为每个问题写 40-60 字的答案，最后组装成 schema 格式。注意事项里要写明：问题必须是真实搜索意图，不能自问自答式硬凑；答案不能是营销话术，要直接回答问题。

注意：SKILL.md 里的执行步骤，尽量用"动词开头 + 明确对象"的写法，比如"提取竞品页面的 H2 标题"，而不是"分析竞品页面结构"。前者 AI 知道具体做什么，后者太模糊。

4. SEO 与 CRO 技能的具体实现：从关键词到结构化数据

4.1 关键词调研技能：别只盯着搜索量

关键词调研是 SEO 的起点，但大多数人做关键词调研的方式是错的。他们打开关键词工具，按搜索量排序，挑几个大的就开始写。结果写出来的内容竞争不过大站，流量上不去。

在 marketingskills 的框架下，关键词调研技能应该输出的是带意图标注和竞争度评估的机会清单，而不是一个按搜索量排的列表。具体来说，每个关键词至少要标注四个维度：

这个技能的执行逻辑，我建议分四步：第一步，用种子词和竞品域名扩展出候选词；第二步，对每个词抓取首页结果，分析域名权重和内容类型；第三步，用规则或模型给每个词打意图标签；第四步，按"商业价值高 + 竞争度低 + 有内容缺口"排序输出。

这里有个实操心得：别迷信搜索量。我做过一个项目，一个月搜索量只有 200 的长尾词，因为意图极其精准，转化率是主词的 8 倍。如果只看搜索量，这个词根本进不了你的视野。所以在技能设计里，一定要把"商业价值"和"意图精准度"的权重调高。

4.2 FAQ 结构化数据技能：热搜词里那个问题的答案

热搜词里有一条"谷歌seo的 faqpage 结构化数据是怎么回事"，说明很多人对这个东西有疑问。我在这里把它讲透，顺便说清楚它在 marketingskills 里怎么实现。

FAQPage 结构化数据，本质上是告诉搜索引擎："这个页面上有一组问答，请把它们理解成 FAQ。"它的价值在于，符合条件的页面在搜索结果里可能展示成可展开的问答列表，占据更多视觉空间，点击率通常会有提升。

但这里有几个坑，我必须说清楚。第一，不是所有页面都适合加 FAQ schema。谷歌的规范是，FAQ 内容必须是页面上真实可见的，不能只写在 schema 里而用户看不到。第二，问题必须是真实用户会问的，不能为了凑 schema 硬编问题。第三，答案要直接回答问题，不要绕圈子做营销。

在 marketingskills 里，FAQ schema 技能的执行逻辑是这样的：输入页面主题和目标关键词，第一步从"人们还问"和相关搜索里提取真实问题，第二步对每个问题生成简洁答案，第三步组装成 JSON-LD 格式，第四步校验格式是否符合规范。

{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "独立站谷歌 SEO 多久能见效？", "acceptedAnswer": { "@type": "Answer", "text": "通常新站需要 3-6 个月才能看到稳定自然流量，具体取决于内容质量、外链建设和竞争程度。" } } ] }

这个技能的关键在于问题来源要真实。我一般会让技能从三个地方抓：谷歌的"人们还问"、竞品页面的 FAQ 区、以及站内搜索日志。这三个来源的问题，才是用户真正关心的。

4.3 CRO 分析技能：把转化率当成一个可拆解的系统

CRO（转化率优化）是 marketingskills 里技术含量最高的部分，因为它涉及数据分析和实验设计。很多人做 CRO 的方式是"拍脑袋改按钮颜色"，这不叫 CRO，这叫碰运气。

真正的 CRO 技能，应该把转化率拆解成一个漏斗，然后逐层分析。一个典型的落地页漏斗是这样的：曝光 → 首屏停留 → 滚动深度 → CTA 点击 → 表单开始填写 → 表单提交。每一层都有流失，每一层的流失原因不同。

CRO 分析技能的执行逻辑：第一步，拉取各层的数据；第二步，找出流失最严重的环节；第三步，基于常见优化模式提出假设；第四步，设计 A/B 测试验证假设。

这里有个经验：优先优化漏斗上游。很多人一上来就改 CTA 文案，但如果用户根本没滚动到 CTA 位置，改文案有什么用？先解决首屏吸引力和滚动深度的问题，再往下游走。

4.4 内容规划技能：把机会点变成可执行的日历

关键词调研产出的是一堆机会点，内容规划技能要做的是把这些机会点变成一张可执行的内容日历。这个技能看起来简单，实际上很容易做砸。

砸的原因通常是：只考虑了"写什么"，没考虑"谁来写、什么时候写、写完怎么推"。一个能用的内容规划技能，输出应该包含：内容主题、目标关键词、内容形式、优先级、预计工时、发布渠道、内链规划。

我自己的做法是，让这个技能按"主题集群"来组织内容，而不是按单篇来排。比如围绕"独立站 SEO"这个主题，规划一篇 pillar 页面加五篇 cluster 文章，互相内链。这样做的原因是，搜索引擎更认可主题权威性，一堆散篇不如一个结构化的集群。

5. 让技能真正跑起来：编排、调试与常见故障

5.1 工作流编排：串行、并行与条件分支

技能写好了，怎么串起来是个问题。最简单的是串行：A 做完做 B，B 做完做 C。但真实工作流往往更复杂。

比如"新站上线"这个工作流，关键词调研和竞品拆解是可以并行的，两者都完成后才进入内容规划。内容规划完成后，文案生成和 FAQ schema 又可以并行。这种并行能大幅缩短整体时间。

还有条件分支。比如 CRO 分析技能跑完后，如果发现是首屏问题，走"首屏优化"分支；如果是表单问题，走"表单优化"分支。这个判断逻辑要写在工作流里，而不是让 AI 每次临时决定。

我的建议是，工作流用 Markdown 写清楚，每一步标注：依赖哪些前置步骤、可以并行还是必须串行、什么条件下走哪个分支。这样 AI 执行时有据可依，你排查问题时也有据可查。

5.2 调试技能：怎么知道是技能写错了还是模型不行

技能跑出来的结果不对，很多人第一反应是"模型不行"。但根据我的经验，八成是技能写得有问题，模型只是执行者。

排查顺序应该是这样的：第一，看输入对不对。很多时候是上游技能输出的数据格式不对，导致下游技能拿到垃圾。第二，看步骤清不清晰。如果 SKILL.md 里某一步写得模糊，AI 就会自由发挥。第三，看输出规范有没有明确。没规定格式，AI 就按自己喜好来。第四，才是考虑换模型或者调参数。

我一般会在技能里加一个"自检"步骤，让 AI 在输出前先检查自己的结果是否符合规范。这个自检步骤能拦下大部分低级错误。

5.3 几个高频故障和它们的根因

下面这几个问题，是我在实际使用中遇到频率最高的，列出来给你省点时间。

提示：遇到"执行到一半停了"的情况，不要急着怪模型。先看看是不是你的技能步骤太长，一次要处理的信息超出了上下文窗口。拆步骤是最有效的解法。

5.4 关于本地模型和第三方接入的一点经验

热搜词里有很多关于接入本地模型、第三方 API 的讨论。我的看法是：做 marketingskills 这类项目，模型能力直接决定产出质量。营销内容需要理解语境、把握语气、做判断，这些对模型能力要求不低。

本地模型的好处是数据不出本地、成本可控，但目前在复杂营销任务上的表现，跟头部模型还有差距。我的建议是分场景用：简单的格式转换、数据清洗，本地模型够用；需要判断和创意的环节，用能力更强的模型。至于具体怎么接入，不同环境的配置方式不一样，核心是搞清楚你的调用链路，把模型当成一个可替换的组件来设计，这样换模型时不用重写技能。

6. 我踩过的坑和几条实在的建议

6.1 别一上来就追求全自动

我刚开始做这套东西的时候，野心很大，想让 AI 从关键词调研一路自动做到内容发布。结果就是每个环节都做得半吊子，最后产出质量惨不忍睹。

后来我调整了策略：先做半自动，人机协作，跑顺了再逐步自动化。具体来说，先让 AI 做调研和初稿，人来审核和定稿。等某个环节的产出稳定了，再把它接入全自动流程。这样每一步都可控，出问题也能快速定位。

这个思路在营销场景里尤其重要，因为营销内容直接面向用户，质量不过关会伤品牌。宁可慢一点，也别让 AI 的垃圾内容上线。

6.2 数据源要留后手

做 SEO 和 CRO，数据源是命脉。但任何单一数据源都可能出问题：接口变了、限流了、页面改版了。我踩过的坑是，整个技能依赖一个数据源，结果那个源一挂，整条工作流全瘫。

现在的做法是，每个关键数据源都配一个备用方案。主源抓不到，自动降级到备用源。备用源也没有，就明确报错，而不是让 AI 编数据。这一点在技能设计时就要考虑进去，别等出事了再补。

6.3 技能要定期复盘和迭代

营销环境变化很快，去年有效的关键词策略，今年可能就失效了。所以技能不是写完就完事，要定期复盘。

我的习惯是每个月看一次各技能的产出质量，重点看三个指标：产出被采纳的比例、人工修改的幅度、以及最终的业务效果。如果某个技能产出老是要大改，说明技能本身该升级了。如果某个技能产出稳定但业务效果一般，说明可能选错了优化方向。

6.4 关于"独立站谷歌 SEO"这件事的几句实话

热搜词里"什么是独立站谷歌seo"出现多次，说明很多新手在入门。我借这个机会说几句实在的。

独立站做谷歌 SEO，核心不是技术，是内容能不能解决用户的真实问题。技术层面的东西，结构化数据、页面速度、内链，这些都是加分项，但前提是你的内容本身有价值。我见过太多站，技术优化做得漂漂亮亮，内容却是拼凑的，排名上不去。

marketingskills 这类工具能帮你提高效率，但它替代不了你对用户的理解。工具负责把重复劳动干掉，你负责想清楚"用户到底要什么"。这个分工搞清楚了，工具才真正有用。

6.5 最后分享一个提高技能产出质量的小技巧

在 SKILL.md 里加一段"反例"。也就是明确告诉 AI："以下这些是错误示范，不要这样输出。"比如做 FAQ schema 技能时，我会写："不要生成'我们的产品很好'这类自夸式答案，要生成直接回答用户疑问的答案。"

这个反例机制的效果出乎意料地好。因为 AI 对"不要做什么"的敏感度，有时候比"要做什么"还高。你给它一个具体的错误示范，它就能避开那个坑。这个技巧成本极低，但收益很明显，建议你在每个技能里都试试。