企业官网建设流程全解析

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

第一次看到marketingskills这个项目名，我的直觉是：这不是一个单纯的工具库，而更像是一套"能力封装"。它把营销场景里那些重复、琐碎、但又必须做扎实的动作——SEO 诊断、转化率优化（CRO）、数据埋点分析、内容分发——打包成一组可被 AI agent 调用的技能模块。换句话说，它试图回答一个很现实的问题：当 AI 已经能写文案、能读数据、能跑脚本的时候，营销人到底该怎么把这些能力"接"到自己的日常流程里，而不是每次从零开始写提示词。

这个项目的核心价值，不在于它提供了多少条提示词，而在于它把"营销动作"抽象成了"技能（skill）"这一层。技能和提示词的区别，就像菜谱和食材的区别：食材谁都能买，但菜谱决定了你什么时候放盐、火候多大、什么时候起锅。marketingskills想做的，就是给 AI agent 一套营销领域的"菜谱"，让它在面对"帮我看看这个落地页为什么转化低"这类问题时，知道先查什么、再查什么、最后怎么给结论。

适合读这篇内容的人，我大致分三类。第一类是独立站运营者，尤其是做谷歌 SEO 和付费流量的，手里有站点、有数据，但缺一套系统化的诊断方法；第二类是增长/营销方向的从业者，想借助 AI agent 把重复劳动自动化，比如批量生成 meta 描述、批量检查内链结构；第三类是对 AI agent 落地感兴趣的开发者，想看看"技能"这种抽象在真实业务里长什么样。不管你是哪一类，这篇内容都会从"为什么这样设计"讲到"具体怎么跑起来"，尽量让你看完能直接上手。

需要提前说明的是，marketingskills本身是一个偏概念和框架的项目，它依赖 AI agent 的运行环境（比如 Claude Code 这类能在本地执行命令、读写文件的 agent 工具）来发挥价值。所以我会花不少篇幅讲清楚"技能是怎么被 agent 调用的"，以及在这个过程中容易踩的坑。这些坑我在实际配置和调试时都遇到过，有些还挺隐蔽，后面会逐个拆开讲。

2. 为什么营销场景特别适合"技能化"封装

2.1 营销动作的三个特征：高频、可枚举、有明确产出

营销工作有个很尴尬的特点：它既需要创意，又充满了大量机械重复。写一篇深度文章需要灵感，但检查 200 个页面的 title 标签是否重复、是否超过 60 字符，这纯粹是体力活。marketingskills的切入点就在这里——把那些"高频、可枚举、有明确产出"的动作抽出来，做成技能。

我拿 SEO 举例。一个完整的 SEO 审计，拆开来看无非是这几件事：抓取站点结构、检查 robots 和 sitemap、分析 title/description 的覆盖率和重复率、检查 H 标签层级、看内链分布、评估页面加载相关的技术指标、对比关键词排名。这些动作每一个都有明确的输入（一个 URL 或一份页面列表）和明确的输出（一份问题清单）。这种"输入输出清晰"的特性，正是技能化封装的最佳土壤。

反过来，像"帮我策划一个品牌 campaign"这种任务，输入模糊、输出开放，就不适合做成固定技能，更适合让 agent 自由发挥。理解这个边界很重要，否则你会试图把什么都塞进技能里，最后发现技能又臭又长，还不如直接对话。

2.2 技能和提示词的本质区别：可复用、可组合、可版本管理

很多人会把技能理解成"高级提示词"，这个理解只对了一半。提示词是一次性的，你这次写了一段让 AI 分析落地页的话，下次换个页面还得重写。技能不一样，它是一份带参数的、可复用的"操作说明书"。

我自己的体会是，技能至少带来三个好处。第一是一致性：同一个技能每次执行，检查项和判断标准都一样，不会因为今天心情好多查两项、明天赶时间少查两项。第二是可组合：一个"落地页诊断"技能可以调用"标题检查""CTA 分析""表单字段审查"三个子技能，像搭积木一样。第三是可版本管理：技能是文件，可以放进 Git，改了什么、为什么改，都有记录。这在团队协作里太重要了——你不想每次换个人接手，诊断标准就全变了。

提示：判断一个动作该不该做成技能，我的标准是"这个动作我一个月内会不会重复做三次以上"。会，就值得封装；不会，直接对话更省事。

2.3 从"人找工具"到"agent 调技能"的范式转变

传统工作流是"人找工具"：我要做 SEO 审计，打开 Screaming Frog；我要看转化，打开 GA；我要查排名，打开 Search Console。工具之间数据不通，人成了搬运工。

marketingskills代表的是一种转变：agent 成为调度中心，技能成为它的"手"。你告诉 agent"帮我审计 example.com 的 SEO 状况"，agent 自己去调用抓取技能、分析技能、报告生成技能，最后给你一份整合结论。人从"操作工具"变成"定义目标"。

这个转变听起来很美，但落地时有前提：agent 必须能访问数据源。这就是为什么这类项目通常和 Claude Code 这种"能在本地执行终端命令、读写文件"的 agent 绑定——因为只有能跑命令，agent 才能真正去抓页面、跑脚本、读日志。纯聊天式的 AI 做不到这一点，它只能基于你粘贴给它的内容分析。

3. 把 marketingskills 跑起来：环境准备里那些没人告诉你的细节

3.1 agent 运行环境的选择：为什么本地执行能力是硬门槛

前面说了，技能要真正干活，agent 得有"手"。这个"手"就是本地执行能力。市面上能提供这种能力的 agent 工具不多，Claude Code 是其中比较有代表性的一个——它能在你的终端里执行命令、读写项目文件、调用外部脚本。marketingskills这类项目通常就是围绕它设计的。

这里有个常见误区：很多人以为装个桌面版客户端就够了。实际上，桌面版和命令行版的能力边界不一样。命令行版（CLI）通常对本地文件系统和终端命令的访问更直接，适合跑需要读写文件、执行脚本的技能；桌面版更偏向交互体验，适合日常对话和轻量任务。如果你要跑的是"批量抓取站点并生成报告"这种重活，CLI 是更稳的选择。

安装环节本身不复杂，但有几个细节容易卡住人。第一是运行环境，Node.js 版本建议用 LTS（长期支持版），太新的版本有时候会和某些依赖冲突。第二是权限，agent 要执行终端命令，你得确保它在你授权的目录下有读写权限，否则技能跑到一半报"permission denied"，排查起来很费劲。第三是网络环境，抓取外部站点、调用 API 都需要稳定的网络，这个不用多说。

3.2 技能目录的组织方式：一个清晰的目录结构能省你一半时间

marketingskills这类项目，技能通常以文件形式存在。我建议的目录组织方式是这样的：

marketingskills/ ├── seo/ │ ├── audit-site.md # 站点级 SEO 审计技能 │ ├── check-meta.md # meta 标签检查技能 │ └── internal-links.md # 内链结构分析技能 ├── cro/ │ ├── landing-page-review.md # 落地页转化诊断 │ └── form-analysis.md # 表单字段与流失分析 ├── analytics/ │ ├── traffic-report.md # 流量报告生成 │ └── funnel-analysis.md # 漏斗分析 └── shared/ ├── fetch-page.md # 通用页面抓取技能 └── report-format.md # 统一报告格式规范

这个结构的好处是"按业务域分层"。SEO、CRO、analytics 各自独立，共享的底层能力（抓取、报告格式）放在 shared 里。当你要新增一个技能时，先想清楚它属于哪个域，再决定放哪。我见过有人把所有技能平铺在一个目录里，几十个文件堆在一起，找起来眼花缭乱，改起来还容易误伤。

注意：技能文件命名尽量用"动词+名词"的形式，比如check-meta、audit-site，一眼能看出这个技能干什么。别用skill1、test这种名字，过两周你自己都不记得是啥。

3.3 让 agent 认识你的技能：注册与索引机制

技能文件写好了，agent 怎么知道它们存在？这就涉及注册机制。不同 agent 工具的做法不一样，但核心逻辑类似：要么在配置文件里显式声明技能路径，要么让 agent 扫描指定目录自动索引。

我倾向于显式声明，因为可控。自动扫描虽然省事，但技能一多，agent 每次启动都要扫一遍，慢不说，还可能把你不想要的临时文件也索引进去。显式声明的话，你清楚知道哪些技能是"激活"状态，调试时也容易定位问题。

注册完之后，建议做个"冒烟测试"：随便挑一个技能，让 agent 执行一次，看它能不能正确找到技能文件、理解技能意图、按预期产出。这一步别省，我见过太多人技能写得很漂亮，结果 agent 根本找不到文件，白忙活。

4. SEO 技能模块的拆解：从站点审计到 meta 优化的完整链路

4.1 站点级审计技能：抓取、解析、问题归类

站点级 SEO 审计是marketingskills里最重的一个技能，也是最能体现"技能化"价值的。它的完整链路是这样的：先抓取站点（通常从 sitemap 或首页出发，递归抓内链），把页面存下来；然后解析每个页面的关键元素（title、description、H 标签、图片 alt、内链、外链）；最后按问题类型归类，生成报告。

抓取环节有个坑：递归深度和并发数要控制好。深度太浅，抓不全；太深，容易陷入无限循环（尤其是那些带参数的 URL）。并发数太高，目标站点可能把你当攻击，直接封 IP。我的经验是，并发控制在 5 到 10 之间，递归深度限制在 3 到 4 层，同时设置一个"最大抓取页数"上限，比如 500 页，防止小站点抓出几万页的意外情况。

解析环节的关键是"标准化"。不同站点的 HTML 结构千差万别，但 SEO 关注的核心元素是固定的。技能里要定义清楚：title 取<title>标签内容，description 取<meta name="description">，H1 取第一个<h1>，等等。遇到缺失的元素，标记为"缺失"而不是报错跳过，因为"缺失"本身就是个问题。

问题归类我习惯分四档：致命（比如整站 noindex、robots.txt 屏蔽了所有爬虫）、严重（大量重复 title、关键页面缺失 H1）、一般（description 过长或过短、图片缺 alt）、建议（内链可以更丰富、URL 结构可以更语义化）。分档的好处是，报告出来之后，运营者知道先修哪个。

4.2 meta 标签批量检查：重复率、长度、关键词覆盖

meta 标签检查是个典型的"看起来简单、做起来琐碎"的活。一个 500 页的站点，人工检查 title 和 description 得花大半天，还容易漏。做成技能之后，几分钟出结果。

检查维度我一般设这几个。重复率：完全相同的 title 有多少组，高度相似的（比如只差一个词）有多少组。长度：title 建议 50 到 60 字符，description 建议 120 到 158 字符，超出会被搜索引擎截断。关键词覆盖：目标关键词有没有出现在 title 和 description 里，出现的位置靠不靠前。

这里有个细节值得说：长度计算要按"字符数"还是"像素宽度"？严格来说，搜索引擎是按像素宽度截断的，中文字符和英文字符宽度不同。但实操中，按字符数估算已经够用，除非你做的是多语言站点，中英混排，那最好按像素宽度算。技能里可以内置一个简单的宽度估算函数，中文按 2 个单位、英文按 1 个单位累加。

提示：批量检查出来的重复 title，不要急着全改。先看这些页面是不是"分页"或"筛选"产生的，这类页面有时候用相同 title 是合理的，强行差异化反而可能引入新问题。

4.3 内链结构分析：孤岛页面与权重流动

内链是 SEO 里最容易被忽视、但影响很大的部分。搜索引擎靠链接爬行和理解页面关系，内链结构乱了，权重流动就不畅，有些页面可能永远不被收录。

内链分析技能主要看三件事。第一是孤岛页面：没有任何内链指向的页面。这类页面搜索引擎很难发现，除非在 sitemap 里。第二是链接深度：从首页出发，点几次能到目标页面。深度超过 4 层的页面，抓取优先级会下降。第三是锚文本分布：指向同一个页面的内链，锚文本是不是太单一，或者太泛（比如全是"点击这里"）。

我做过一个站点，首页内链指向的全是导航栏那几个页面，几百篇内容页只能靠 sitemap 被发现，收录率一直上不去。后来在相关文章模块里加了内链，两个月后收录率从 60% 涨到 90% 多。这个案例说明，内链分析不能只看"有没有链接"，还要看"链接放的位置合不合理"。

5. CRO 与 analytics 技能：让数据真正指导决策

5.1 落地页转化诊断：从首屏到表单的逐层排查

CRO（转化率优化）技能的核心是"逐层排查"。一个落地页的转化路径，大致是：用户到达 → 看首屏 → 往下滚动 → 找到 CTA → 点击 → 填表单 → 提交。每一层都有流失，技能要做的就是定位流失最严重的那一层。

首屏排查看什么？看价值主张是否清晰（用户 3 秒内能不能明白你是干嘛的）、看主 CTA 是否可见（不用滚动就能看到）、看视觉焦点是否被无关元素抢走。往下滚动看什么？看内容节奏（是不是一大段文字没有分隔）、看信任元素（评价、案例、资质有没有）、看 CTA 是否重复出现。

表单是流失重灾区。字段越多，流失越高，这是常识。但具体到你的业务，哪个字段最劝退？技能可以结合 analytics 数据回答：如果表单有"公司规模"这个字段，而放弃填写的人里 70% 都停在这一步，那这个字段就值得重新考虑。

5.2 流量与漏斗分析技能：把 GA 数据翻译成行动项

analytics 技能的价值在于"翻译"。GA 里一堆数字，跳出率、会话时长、转化率，运营者看得懂数字，但看不懂"所以呢"。技能要做的是把数字翻译成行动项。

比如，某个渠道的跳出率 85%，远高于站点平均的 55%。技能不应该只报告这个数字，而应该进一步分析：这个渠道来的用户，落地页是哪个？落地页内容和渠道广告的承诺一致吗？如果广告说"免费试用"，落地页却要"预约演示"，那跳出率高就说得通了。这种"数字 → 原因 → 行动"的链路，才是 analytics 技能该产出的东西。

漏斗分析同理。用户从"访问"到"加购"到"下单"，每一步的转化率是多少，哪一步掉得最狠。掉得最狠的那一步，就是优化优先级最高的地方。技能可以自动算出每一步的转化率，并和行业基准对比，给出"正常/偏低/严重偏低"的判断。

5.3 报告生成技能：统一格式，让结论可执行

前面所有技能产出的都是"原始发现"，报告生成技能负责把它们整合成一份人能读、能执行的文档。格式统一很重要，我习惯用这个结构：

这个结构的好处是"分层阅读"。老板只看执行摘要，执行的人看问题清单和行动优先级，需要深挖的看数据附录。一份报告满足三种读者，比写三份报告高效得多。

6. 实操中踩过的坑与排查思路

6.1 技能被 agent 忽略：从文件格式到触发词的排查链路

我遇到最多的问题，是技能写好了，agent 却不调用。排查这个问题的链路，我总结成四步。

第一步，确认文件被索引了。让 agent 列出它当前能看到的技能，如果列表里没有你的技能，那就是注册或路径问题。第二步，确认文件格式正确。技能文件通常有固定的头部格式（比如 YAML front matter），少个冒号、缩进错了，agent 就解析不了。第三步，确认触发词匹配。技能里一般会写"什么时候用这个技能"，如果你的提问和触发词对不上，agent 就不会调用。第四步，确认技能描述清晰。描述太模糊，agent 判断不了该不该用。

这四步里，第三步最隐蔽。我写过一个"检查页面加载速度"的技能，触发词写的是"性能分析"，结果我提问时说"看看这个页面快不快"，agent 就没触发。后来把触发词改得更口语化，问题就解决了。

6.2 抓取被限流或封禁：并发、频率与 User-Agent 的处理

抓取外部站点时被限流，几乎是必然的。目标站点的防护策略各不相同，有的看频率，有的看并发，有的看 User-Agent。

我的处理原则是"先慢后快"。第一次抓一个新站点，并发设 1，每次请求间隔 1 到 2 秒，先抓 10 个页面看看反应。如果顺利，再逐步提高并发、缩短间隔。如果遇到 429（请求过多）或 403（禁止访问），立刻降速，并检查 User-Agent 是不是被识别成了爬虫。

User-Agent 这块有个细节：不要伪装成搜索引擎的爬虫（比如 Googlebot），这既不道德，也可能触发更严格的验证。老老实实用一个正常的浏览器 UA，配合合理的抓取频率，大多数站点不会为难你。

注意：抓取前先看目标站点的 robots.txt，这是基本礼仪，也是避免法律风险的必要步骤。robots.txt 里 Disallow 的路径，别碰。

6.3 分析结果"看起来对但没用"：如何让技能产出可执行结论

这是最让人沮丧的坑：技能跑通了，报告生成了，数据都对，但看完不知道要干嘛。问题出在技能的设计上——它只做了"描述"，没做"判断"。

举个例子。技能报告"这个页面有 3 个 H1 标签"。这是描述。但"3 个 H1 会导致搜索引擎困惑，建议保留 1 个，其余降级为 H2"——这才是判断加建议。技能里必须内置"判断规则"，否则产出的就是一堆数字，不是洞察。

我的做法是，每个检查项都配一条"判断逻辑"。比如 title 长度，规则是：小于 30 字符标记"过短"，30 到 60 标记"正常"，大于 60 标记"过长"。有了规则，技能才能自动给出结论，而不是把原始数据甩给你。

6.4 技能之间的依赖与冲突：组合调用时的顺序问题

当技能开始组合调用时，顺序就变得重要了。比如"站点审计"技能内部会调用"抓取"技能和"meta 检查"技能。如果抓取还没完成，meta 检查就没数据可查。

处理依赖关系，我建议在技能里显式声明"前置条件"。比如 meta 检查技能开头写清楚："本技能需要一份页面列表作为输入，如果输入为空，先调用抓取技能。"这样 agent 在组合调用时，就知道该先做什么。

冲突则更微妙。两个技能可能对同一份数据给出不同建议。比如一个技能说"title 越短越好"，另一个说"title 要包含完整关键词，可以长一点"。这种冲突要在技能设计阶段就协调好，统一判断标准，否则 agent 会无所适从。

7. 我对这套东西的真实看法

用了一段时间marketingskills这类技能化方案，我最大的感受是：它把营销工作里"可标准化的部分"和"需要人判断的部分"分开了。标准化的部分交给技能，跑得快、不出错、可复用；需要判断的部分留给人，比如"这个品牌调性该用什么语气""这个转化目标合不合理"。

这个分工挺健康的。以前营销人大量时间耗在重复劳动上，现在可以把精力挪到真正需要思考的地方。但也要清醒：技能不是万能的。它擅长"检查"和"归纳"，不擅长"创造"和"权衡"。指望它替你做战略决策，那是不现实的。

另外，技能是需要维护的。搜索引擎的规则在变，用户的行为在变，技能的判断标准也得跟着更新。我建议每隔一两个月，回头看看技能里的规则还准不准，有没有新的检查项该加进去。把技能当成一份"活的文档"，而不是写完就扔的脚本。

最后分享一个小技巧：刚开始别贪多，先做两三个技能，跑顺了再扩展。我见过有人一上来就规划了二十个技能，结果每个都半成品，用起来处处是坑。技能这东西，质量比数量重要得多。一个打磨到位的"站点审计"技能，价值超过十个粗糙的半成品。