企业官网建设流程全解析

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

第一次看到"marketingskills"这个标题，我脑子里冒出来的第一个念头是：这大概率不是一个单纯的营销理论合集，而是一套把营销动作拆成可执行技能单元的东西。结合后面跟着的一串热词——Claude Code、AI agents、SEO、CRO——基本可以判断，这个项目的核心是把营销能力（尤其是独立站场景下的SEO和转化率优化）封装成AI agent可以调用的"技能包"，让Claude Code这类命令行AI工具在跑任务时，能直接调用结构化的营销方法论，而不是每次从零开始瞎猜。

说白了，传统做独立站SEO和CRO，你得自己翻文档、查竞品、写brief、盯数据，中间大量重复劳动。而"marketingskills"想干的事，是把这些重复动作沉淀成一个个skill文件，AI agent读到之后就知道"遇到列表页SEO该怎么处理""遇到落地页转化率低该从哪几个维度排查"。这跟单纯丢一个prompt给AI完全是两码事——prompt是一次性的，skill是可复用、可版本管理、可组合的。

这篇文章适合谁看？三类人：一是正在用Claude Code做自动化工作流的开发者，想知道怎么把营销逻辑接进去；二是做独立站、需要系统化SEO和CRO但不想每次都手动重复的运营；三是对AI agents感兴趣、想理解"技能封装"这个思路的技术人。我会从项目结构、技能设计逻辑、Claude Code的接入方式、SEO和CRO两个核心技能域的拆解、以及实际跑起来会踩的坑这几个角度，把这件事讲透。

需要先说明一点：下面涉及的具体文件结构、配置方式，是基于这类AI agent技能项目的常见实践做的合理推演，不是对某个特定仓库的逐行复刻。你在实际使用时，以自己拿到的代码为准，但思路是通用的。

2. 为什么营销能力需要被"技能化"，而不是继续堆prompt

2.1 一次性prompt的三个致命伤

大部分人用AI做营销辅助，停留在"打开对话框，输入一段话，拿结果"的阶段。这个模式在单次任务上没问题，但一旦你要做的是持续性的独立站运营，问题立刻暴露。

第一个问题是不可复用。你今天写了一段很长的prompt让AI帮你分析某个列表页的SEO问题，明天换一个页面，你得重新写一遍，而且写出来的质量全看你当天状态。第二个问题是不可组合。SEO分析、关键词研究、内链规划、转化率诊断，这些动作之间是有依赖关系的，但prompt之间是孤立的，AI没法自动把上一个任务的输出喂给下一个任务。第三个问题是不可版本管理。你调好了一版prompt，效果不错，过两周想改进，改完之后发现还不如上一版，但你根本不知道上一版长什么样。

技能化解决的正是这三个问题。一个skill本质上是一个带元数据的结构化文件，里面写清楚了：这个技能叫什么、什么时候触发、需要什么输入、执行什么步骤、输出什么格式。它像是一个函数，而不是一段散文。

2.2 skill和prompt的本质区别

我用一个类比来说明。prompt像是你临时给一个外包同事发微信说"帮我看看这个页面SEO有啥问题"；skill像是你写了一份标准作业程序（SOP）放进公司知识库，任何人任何时候调用，都能按同样的标准执行。

具体到文件层面，一个典型的marketing skill通常包含这几块：

• name：技能标识，比如seo-list-page-audit
• description：什么场景下该用这个技能，这是AI agent做技能路由的关键依据
• inputs：需要哪些参数，比如页面URL、目标关键词、竞品URL
• steps：分步骤的执行逻辑，每一步该检查什么、判断标准是什么
• output_format：输出结构，是表格、清单还是报告
• references：相关的补充资料或子技能

这套结构的好处是，AI agent在接到任务时，会先匹配description，找到最合适的skill，然后按steps执行。整个过程是可追溯、可调试的。你发现某一步输出不对，直接改那一步就行，不用重写整个prompt。

2.3 为什么偏偏是Claude Code来承载

热词里Claude Code出现频率极高，这不是偶然。Claude Code是一个跑在终端里的AI编程助手，它能直接读写文件、执行命令、访问项目目录。这意味着marketing skills放在项目里，Claude Code可以像调用代码库一样调用它们。

对比一下：如果你用网页版AI对话，skill文件得手动复制粘贴进去；用Claude Code，skill就在项目目录里，agent自己会去读。这个差别在单次任务上不明显，但在需要连续执行几十个营销任务的场景下，效率差距是数量级的。

而且Claude Code支持通过配置文件定义agent的行为边界，你可以把marketing skills目录挂进去，让agent在需要营销分析时自动加载对应技能。这就把"营销能力"变成了项目基础设施的一部分，而不是外挂。

3. marketing skills的目录结构与技能分类逻辑

3.1 一个可落地的目录组织方式

假设你拿到或者要自己搭一套marketing skills，目录结构大概率长这样：

marketing-skills/ ├── skills/ │ ├── seo/ │ │ ├── list-page-audit.md │ │ ├── keyword-clustering.md │ │ ├── internal-link-planning.md │ │ └── meta-tag-optimization.md │ ├── cro/ │ │ ├── landing-page-diagnosis.md │ │ ├── ab-test-design.md │ │ └── funnel-dropoff-analysis.md │ └── content/ │ ├── brief-generation.md │ └── content-gap-analysis.md ├── agents/ │ └── marketing-agent.md ├── config/ │ └── skills-manifest.json └── README.md

这个结构的关键在于按域分层。seo、cro、content是三个独立的技能域，每个域下面再按具体任务拆分。为什么这么分？因为不同域的触发条件、输入输出差异很大，混在一起会让agent的路由逻辑变复杂。

skills-manifest.json是索引文件，里面登记了所有技能的name、description和路径。agent启动时先读这个manifest，建立技能索引，接到任务后再按需加载具体技能文件。这样做的好处是启动快，不用一次性把所有技能内容都塞进上下文。

3.2 技能粒度怎么把握

这是实操中最容易做错的地方。技能拆得太粗，一个skill管一大堆事，agent执行时容易跑偏；拆得太细，技能数量爆炸，路由准确率下降。

我的经验是，一个skill对应一个明确的、可独立验证的输出。比如"列表页SEO审计"是一个skill，因为它有明确输入（页面URL）和明确输出（问题清单+修复建议）。但"整个网站SEO优化"就不该是一个skill，它太宽泛，应该拆成列表页审计、详情页审计、内链规划、站点结构分析等多个skill。

判断粒度是否合适，有个简单测试：你能不能给这个skill写一个明确的验收标准？能写出来，粒度就对了；写不出来，说明还是太粗。

3.3 description字段为什么是重中之重

在skill文件里，description不是给人看的简介，而是给agent做路由决策的核心依据。它必须回答两个问题：什么情况下用这个技能，以及这个技能能产出什么。

对比两种写法：

差的写法：description: 用于SEO分析

好的写法：description: 当需要对电商独立站的分类列表页进行SEO健康度检查时使用。输入页面URL和目标关键词，输出标题标签、H1、分页处理、canonical配置、内链结构五个维度的问题清单及优先级排序。

后者明确说了触发场景（分类列表页SEO检查）、输入（URL+关键词）、输出（五维度问题清单）。agent拿到任务描述后，能精准匹配。这个字段写得好不好，直接决定整个技能库的可用性。

4. 把Claude Code接进来：环境准备与技能加载

4.1 安装与基础配置的常见路径

Claude Code的安装方式根据操作系统不同有差异。macOS和Linux下通常通过包管理器或者官方提供的安装脚本完成，Windows下则需要注意终端环境的兼容性——很多人卡在这一步，是因为默认的PowerShell对某些命令的支持和bash不一致。

安装完成后，第一件事是确认版本和登录状态。热词里有人问"claude code可以不登录用其他模型吗"，这个问题的本质是：Claude Code默认绑定官方模型服务，如果你想接第三方模型（比如通过兼容接口接入其他模型），需要在配置层面做适配。具体能不能接、怎么接，取决于你用的版本和官方是否开放了自定义endpoint。我的建议是先用官方默认配置跑通，确认整个链路没问题，再去折腾模型替换，否则出问题你分不清是环境问题还是模型问题。

配置层面，核心是让Claude Code知道去哪里找你的marketing skills。通常有两种方式：一是把skills目录放在项目根目录下，agent默认会扫描；二是在配置文件里显式指定skills路径。前者简单，后者灵活。如果你有多个项目共用一套skills，用后者更合适。

4.2 技能加载的两种模式

全量加载是把所有skill的description一次性读进上下文，agent随时可以调用任何一个。优点是路由快，缺点是技能多了之后上下文占用大，而且可能干扰agent的判断。

按需加载是先只读manifest，agent根据当前任务判断需要哪个域的技能，再去加载具体文件。优点是上下文干净，缺点是多一次判断步骤，偶尔会判断错。

实操中我倾向于混合模式：把高频使用的核心技能（比如列表页审计、落地页诊断）全量加载，长尾技能按需加载。这个平衡点需要根据你的实际任务分布来调，没有标准答案。

4.3 验证技能是否被正确加载

配置完之后，别急着跑真实任务，先做个冒烟测试。给agent一个简单的指令，比如"帮我检查一下这个列表页的SEO问题"，然后观察它的行为：它有没有去读对应的skill文件？读的是不是正确的那个？执行步骤是否符合skill里定义的流程？

如果agent没读skill就开始瞎答，说明description没匹配上，或者manifest路径配错了。如果读错了skill，说明两个技能的description边界模糊，需要重新划分。这个调试过程很枯燥，但省不得，因为技能库一旦规模上去，路由错误会越来越难排查。

5. SEO技能域拆解：从列表页审计到关键词聚类

5.1 列表页SEO审计技能的具体设计

列表页SEO是独立站的一个高频痛点。热词里"discuz 列表页seo设置"能上榜，说明这类需求很普遍。一个列表页审计skill，我建议覆盖这几个检查维度：

这个表格本身就是skill里steps部分的骨架。agent执行时，会逐项检查，然后按优先级输出问题清单。优先级怎么定？我的经验是：影响收录的（canonical、分页）排最高，影响点击的（标题、H1）次之，影响权重传递的（内链）再次。

5.2 关键词聚类技能为什么难做

关键词聚类听起来简单——把意思相近的词归到一起嘛。但实操中难点在于"相近"的判定标准。纯靠字面相似度会出错，比如"独立站SEO"和"独立站SEO工具"字面很像，但搜索意图完全不同，前者是学习需求，后者是工具需求，不该聚在一起。

一个好的聚类skill，应该引导agent从搜索意图出发，而不是从字面出发。具体步骤可以是：先按词根分组，再对每组内的词做意图判断（信息型、导航型、交易型），最后按意图重新聚合。这个过程需要agent有一定的语义理解能力，所以skill里要写清楚判断规则，不能只丢一句"把相似的词聚在一起"。

5.3 内链规划技能的输入输出设计

内链规划是个典型的"输入简单、输出复杂"的任务。输入可能就是一个页面URL列表，输出却是一张完整的内链关系图加锚文本建议。

这个skill的设计要点是约束条件要写死。比如：每个页面至少被3个其他页面链接、锚文本不能完全重复、优先从高权重页面链接到需要提升的页面。这些约束如果不写进skill，agent会给出看起来很合理但实际没法用的方案。

我踩过的一个坑是：早期没写锚文本多样性约束，agent给所有内链都用了同一个锚文本，结果等于没做内链优化。后来在skill里加了"同一目标页面的入站锚文本至少3种不同表述"这条规则，输出质量立刻上来了。

6. CRO技能域拆解：落地页诊断与漏斗分析

6.1 落地页诊断技能的检查框架

CRO（转化率优化）和SEO的逻辑完全不同。SEO关注的是"能不能被找到"，CRO关注的是"找到之后会不会转化"。落地页诊断skill的核心是建立一个可复用的检查框架。

我常用的框架是分三层：清晰度、说服力、行动门槛。

清晰度层检查：用户3秒内能不能看懂这个页面是干什么的？价值主张是否在首屏？标题是否具体而非空泛？

说服力层检查：有没有社会证明（评价、案例、数据）？有没有处理常见异议？信任信号（安全标识、退款政策）是否可见？

行动门槛层检查：CTA按钮是否醒目？表单字段是否过多？有没有降低决策压力的元素（免费试用、无理由退款）？

这个框架写进skill后，agent会按层检查，每层给出具体问题和改进建议。比让agent自由发挥要稳定得多。

6.2 漏斗流失分析技能的数据依赖

漏斗分析skill有个前提：你得有数据。没有数据的漏斗分析就是猜。所以这个skill的输入必须包含各环节的转化数据，agent才能定位流失最严重的环节。

skill的设计逻辑是：先算各环节转化率，找出低于基准值的环节，再针对该环节调用对应的诊断子技能。比如发现"加购到结算"环节流失严重，就触发结算页诊断；发现"落地页到产品页"流失严重，就触发落地页诊断。

这种技能间的调用关系，是marketing skills比单个prompt强大的关键。它形成了一个技能网络，而不是一堆孤立工具。

6.3 A/B测试设计技能的边界

A/B测试设计skill容易越界。它应该做的是：根据当前页面问题，提出测试假设、设计变量、计算所需样本量、定义成功指标。它不该做的是：直接告诉你"把按钮改成红色就能提升20%转化"——这种断言没有数据支撑，是耍流氓。

所以这个skill的output_format要明确写成"测试方案"，包含假设、变量、样本量、指标、预期方向，而不是"结论"。这个边界不划清楚，agent会给出过度自信的建议，误导决策。

7. 实际跑起来会遇到的坑与排查思路

7.1 技能路由错误：agent用错了技能

这是最常见的问题。表现是agent执行任务时，调用的skill和任务不匹配。根因通常是两个技能的description有重叠。

排查方法：把出问题的任务描述和两个技能的description并排看，找出重叠的关键词，然后修改其中一个的description，加入区分性描述。比如"列表页审计"和"详情页审计"如果description都只写了"页面SEO检查"，agent就会混。改成"分类/列表类页面的SEO检查"和"产品/文章详情页的SEO检查"就清楚了。

7.2 上下文溢出：技能太多导致agent"失忆"

当技能库规模上去之后，全量加载会让上下文爆掉，agent开始遗忘前面的指令。表现是执行到一半突然跑偏，或者重复执行已经做过的步骤。

解决方案是前面提到的按需加载，加上定期清理不再使用的技能。我一般会每季度review一次技能库，把三个月没被调用过的技能归档。技能库不是越多越好，精简比堆砌重要。

7.3 输出格式不稳定：同样的技能每次输出结构不一样

这个问题通常出在output_format定义不够严格。如果你只写"输出问题清单"，agent每次的清单格式都可能不同。要稳定，就得把格式写死，比如"输出Markdown表格，列为：问题、严重程度、修复建议、优先级"。

还有一个技巧是在skill里给一个输出示例。agent看到示例后，格式稳定性会大幅提升。这个示例不用很长，一个简化版的样例就够了。

7.4 模型替换后的行为漂移

如果你把Claude Code背后的模型换成了其他模型，技能的表现可能会变。不同模型对同一段skill指令的理解和执行有差异。这时候不要急着改skill，先跑几个标准测试用例，看差异出在哪里。如果只是格式差异，调output_format；如果是逻辑差异，才需要动steps。

我的建议是：技能库和模型要配套测试。换模型之前，先准备好一组回归测试用例，换完之后跑一遍，确认核心技能的行为没有退化。

8. 关于技能库维护的一点个人体会

搭一套marketing skills，前期投入最大的是设计阶段，但真正决定它能不能长期用的是维护阶段。我见过太多人兴冲冲搭了一堆技能，用了两周就荒废了，原因是技能和实际任务脱节——设计的时候想得很好，实际用起来发现输入对不上、输出用不了。

避免这个问题的方法只有一个：从真实任务倒推技能。不要先想"我应该有哪些技能"，而是先记录你过去一个月实际做了哪些营销任务，然后把重复度最高的那几个任务技能化。这样搭出来的技能库，每一个都是被真实需求验证过的，不会沦为摆设。

另外，技能文件要当代码一样管理。用Git做版本控制，每次修改写清楚改了什么、为什么改。这样当某个技能效果变差时，你能快速定位是哪次修改导致的。这个习惯在技能数量少的时候看不出价值，一旦超过二十个技能，没有版本管理基本没法维护。

最后说一个容易被忽略的点：技能库需要定期做"压力测试"。挑一个复杂任务，看agent能不能正确组合多个技能完成它。如果组合过程中频繁出错，说明技能之间的接口定义有问题，需要重新设计输入输出格式。这个测试比单个技能测试更能暴露系统性问题。