企业官网建设流程全解析

1. 从零搭建一套可复用的营销技能库：marketingskills 项目拆解

第一次看到 marketingskills 这个标题，我脑子里蹦出来的不是某个具体工具，而是一类很实在的需求：把营销工作中那些反复用到的能力——关键词研究、竞品拆解、落地页文案、结构化数据标记、外链机会挖掘——从“每次现想”变成“随时可调用的技能模块”。这个项目本质上就是干这件事的：它是一套面向 AI 编程助手（尤其是 Claude Code 这类支持 Agent Skills 规范的终端工具）的营销技能集合，把 SEO、内容营销、增长实验等场景拆成一个个独立的 skill 文件，让 AI 在需要的时候按需加载、按规范执行。

说白了，marketingskills 解决的是“AI 懂代码但不懂营销套路”这个断层。你让一个通用大模型去写落地页，它给你的是四平八稳的模板文；你让它去做关键词聚类，它可能连搜索意图分类都搞不清楚。而 marketingskills 通过结构化的技能描述、输入输出约定、执行步骤和检查清单，把营销老手的经验固化下来，让 AI 每次执行都像有一个资深营销顾问在旁边盯着。这套东西适合谁？独立站站长、做谷歌 SEO 的外贸从业者、内容营销负责人，以及那些已经在用 Claude Code 或类似 AI agent 工具、想把营销流程自动化的技术型营销人。

我之所以对这个方向感兴趣，是因为过去半年我一直在折腾 Claude Code 的本地化使用——从 Ubuntu 下的安装配置，到 VS Code 插件的接入，再到通过第三方 API 切换不同模型。过程中最大的感受是：工具本身很强，但如果没有领域技能包，它就是一个“什么都会一点、什么都不精”的通用助手。marketingskills 这类项目的价值，恰恰在于给通用 agent 装上垂直领域的“操作手册”。下面我就按自己的理解，把这套东西的设计思路、核心细节、实操流程和踩坑经验完整拆一遍。

2. 整体设计与思路拆解：为什么是技能包而不是提示词合集

2.1 从“一次性提示词”到“可复用技能”的转变

大多数人用 AI 做营销，习惯是打开对话框，敲一段提示词，拿到结果，复制走人。下次遇到类似任务，再把提示词改一改重新发。这种做法在单次任务上没问题，但一旦任务变复杂、步骤变多、需要多轮迭代，就会暴露三个致命问题：第一，提示词越写越长，模型注意力被稀释，后面说的它记不住；第二，每次都要重新描述背景，效率极低；第三，执行标准不统一，今天写的落地页和上周写的风格完全两样。

marketingskills 走的是另一条路：把每个营销能力封装成一个独立的 skill，每个 skill 有明确的名称、描述、触发条件、执行步骤和输出格式。这跟 Agent Skills 规范的设计哲学是一致的——技能是“可被 agent 发现和调用的能力单元”，而不是一段塞进上下文的文本。当 AI 判断当前任务需要做关键词研究时，它会主动加载对应的 skill，按照里面定义的流程一步步执行，而不是靠用户每次手动喂提示词。

这个转变的意义在于：营销经验从“人脑里的隐性知识”变成了“文件里的显性流程”。你可以把公司里最懂 SEO 的那个人的方法论写成 skill，然后让团队里每个人通过 AI 调用它。新人不需要学三年才能写出合格的 meta description，AI 按 skill 执行就能达到 80 分水平。

2.2 技能粒度的取舍：为什么不做成一个大而全的营销助手

设计这类项目时，最容易犯的错误是贪大求全。我见过不少人试图做一个“营销全能 agent”，把 SEO、SEM、社媒、邮件营销全塞进一个提示词里，结果就是每个方向都浅尝辄止。marketingskills 的选择是拆成细粒度技能，我推测它的目录结构大概是这样的：

marketingskills/ ├── keyword-research/ │ ├── SKILL.md │ └── references/ ├── serp-analysis/ │ ├── SKILL.md │ └── templates/ ├── landing-page-copy/ │ ├── SKILL.md │ └── examples/ ├── faq-schema/ │ ├── SKILL.md │ └── snippets/ └── competitor-audit/ ├── SKILL.md └── checklists/

每个 skill 目录下有一个核心的 SKILL.md，定义这个技能的元信息（名称、描述、何时使用）和执行逻辑，旁边可以挂参考资料、模板、代码片段。这种结构的优势很明显：AI 在加载时只读取当前任务相关的 skill，不会把无关内容塞进上下文，既省 token 又提高准确率。

粒度怎么定？我的经验是：一个 skill 对应一个“可独立交付的营销产出”。比如“关键词研究”是一个 skill，因为它最终输出一份关键词列表和聚类结果；“FAQ 结构化数据生成”是另一个 skill，因为它输出的是可以直接贴进网页的 JSON-LD 代码。如果你把这两个合并，AI 在执行时就会混淆“研究阶段”和“输出阶段”的边界。

2.3 与 Claude Code 等工具的集成逻辑

marketingskills 这类项目要发挥作用，离不开宿主工具的支持。目前最典型的宿主就是 Claude Code——一个跑在终端里的 AI 编程助手，支持通过 Agent Skills 规范加载外部技能。Claude Code 的工作方式是：你在项目目录下运行它，它会扫描可用的 skills，根据你的自然语言指令判断该调用哪个技能，然后执行。

这里有个关键设计点：skill 的触发描述必须写得足够精准。如果描述太宽泛，比如“用于营销相关工作”，AI 在任何营销任务上都会加载它，导致上下文污染；如果描述太窄，比如“用于生成 FAQ 页面的 JSON-LD 标记”，那 AI 可能在你问“怎么给产品页加结构化数据”时想不到调用它。好的描述应该是“做什么 + 什么时候用 + 不适用于什么场景”三件套。

我实测下来，Claude Code 对 skill 的识别准确率跟描述质量强相关。同样的技能内容，描述写得清楚，调用准确率能到九成以上；描述含糊，可能一半的任务都匹配不上。这一点在后面讲实操时会展开说。

3. 核心细节解析与实操要点：一个 skill 文件到底该写什么

3.1 SKILL.md 的结构：元信息、触发条件、执行流程

一个合格的 skill 文件，我理解应该包含四个部分。第一部分是元信息，用 YAML frontmatter 写清楚 name、description、version、author 这些字段。description 是最关键的，它决定了 AI 什么时候会想起你。第二部分是触发条件，明确列出“当用户提到 X、Y、Z 时使用本技能”，以及“当任务涉及 A、B 时不要使用本技能”。第三部分是执行流程，把营销任务拆成有序步骤，每步说明输入、操作、输出。第四部分是输出规范，定义最终产出的格式、字段、示例。

拿“FAQ 结构化数据生成”这个 skill 举例，它的执行流程大概是这样：

1. 读取用户提供的页面内容或问题列表
2. 判断哪些内容适合做成 FAQ（标准：用户真实会问、有明确答案、与页面主题相关）
3. 为每个问题生成简洁答案（控制在 40-60 字，便于语音搜索抓取）
4. 按照 schema.org 的 FAQPage 规范生成 JSON-LD
5. 校验 JSON 语法和必填字段
6. 输出可直接嵌入 HTML 的 script 标签

每一步都要写清楚判断标准和注意事项。比如第 2 步要说明“不要为了凑数把陈述句改成问句”，第 3 步要提醒“答案里不要堆关键词，谷歌的 FAQ 富媒体结果更看重答案的直接性”。

3.2 触发描述的写法：让 AI 在对的时候想起你

触发描述写得好不好，直接决定 skill 的可用性。我总结了一个模板：

当用户需要 [具体任务] 时使用本技能。典型触发词包括 [词1]、[词2]、[词3]。本技能适用于 [场景A] 和 [场景B]。不适用于 [场景C]，那种情况应该使用 [其他技能]。

以关键词研究 skill 为例，触发描述可以写成：“当用户需要为网站或内容页面寻找目标关键词、分析搜索意图、进行关键词聚类时使用。典型触发词包括‘关键词’、‘搜索量’、‘长尾词’、‘搜索意图’。适用于新页面选题、现有页面优化、内容缺口分析。不适用于纯技术 SEO 审计，那种情况应使用 technical-seo 技能。”

这样写的好处是，AI 在匹配时既有正向信号（该用什么词触发），也有负向信号（什么情况别用）。实测下来，带负向信号的描述能减少三成左右的误调用。

3.3 输出格式的约束：让结果可直接使用

营销人最烦的就是 AI 给一堆“看起来有用但没法直接用”的东西。skill 设计时必须把输出格式卡死。比如落地页文案 skill，输出应该是一个结构化的 Markdown 表格，包含区块名称、文案内容、字数、优化说明四列。再比如竞品审计 skill，输出应该是一份带优先级标记的问题清单，每个问题有严重程度、影响范围、修复建议。

我习惯在 skill 里放一个“输出示例”，让 AI 照着格式填。这比单纯用文字描述格式有效得多。因为模型对示例的模仿能力远强于对抽象规则的理解能力。你给它一个填好的表格，它下次就会按同样的列和粒度输出。

注意：输出格式不要定得太死。留一两个可选字段，让 AI 在遇到特殊情况时能补充说明。完全固定的格式会导致信息丢失。

4. 实操过程与核心环节实现：从安装到跑通第一个技能

4.1 环境准备：Claude Code 的安装与配置

要跑 marketingskills，前提是你有一个支持 Agent Skills 的宿主环境。目前最主流的选择是 Claude Code。安装方式根据操作系统不同有所差异。在 Ubuntu 或 macOS 下，通常通过 npm 全局安装：

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

安装完成后，在项目目录下运行claude命令即可启动。首次使用需要完成账号认证，按照终端提示操作即可。如果你在 VS Code 里工作，也可以安装 Claude Code 的 VS Code 插件，在编辑器内直接调用。

这里有个实际会遇到的问题：部分地区可能提示服务不可用。遇到这种情况，我的建议是检查网络环境是否符合服务支持范围，或者考虑使用支持第三方 API 的替代方案。市面上有一些工具可以让你把 Claude Code 接到其他模型服务上，比如通过 cc switch 这类工具接入 DeepSeek、Qwen、GLM 等模型。具体做法是配置环境变量指向兼容的 API 端点，然后在启动时指定模型。这样即使官方服务不可用，你依然能跑通 skill 的加载和执行流程。

4.2 技能目录的放置与加载验证

Claude Code 加载 skills 的方式通常是扫描特定目录。根据 Agent Skills 规范，技能一般放在项目的.claude/skills/目录下，或者用户主目录的全局技能目录里。把 marketingskills 的各个技能文件夹复制进去后，重启 Claude Code，它应该能自动发现这些技能。

验证是否加载成功的方法很简单：在对话里输入“你有哪些可用的技能”，或者直接问“你能帮我做关键词研究吗”。如果 skill 加载正常，AI 会告诉你它可以使用 keyword-research 技能，并询问你具体要研究什么主题。如果它没反应，检查目录结构是否正确、SKILL.md 的 frontmatter 格式是否合法。

我踩过的一个坑是：SKILL.md 的 YAML frontmatter 里，description 字段如果包含冒号，必须用引号包起来，否则解析会出错。比如description: "关键词研究：寻找和分析目标关键词"这样写才对，不引号的话 YAML 解析器会把冒号后面的内容当成新字段。

4.3 跑通第一个技能：以 FAQ 结构化数据生成为例

假设你要给一个产品页面加 FAQ 结构化数据。操作流程是这样的：

第一步，在 Claude Code 里输入：“帮我为这个产品页面生成 FAQ 结构化数据”，然后把页面内容粘贴进去。AI 会识别到 faq-schema 技能，加载对应的 SKILL.md。

第二步，AI 按照 skill 里定义的流程，先从页面内容里提取候选问题。它会判断哪些内容适合做成 FAQ，比如“这个产品支持退货吗”、“保修期多长”、“怎么联系客服”这类用户真实关心的问题。

第三步，AI 为每个问题生成答案。这里 skill 里会约束答案长度和风格，比如“答案控制在 50 字以内，直接回答问题，不要绕弯子”。

第四步，AI 生成 JSON-LD 代码。格式大概是这样：

{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "这个产品支持退货吗？", "acceptedAnswer": { "@type": "Answer", "text": "支持。自收到商品之日起 30 天内，商品未使用且包装完好，可申请无理由退货。" } } ] }

第五步，AI 会提醒你把这个 script 标签放到页面的<head>或<body>里，并建议用谷歌的富媒体结果测试工具验证一下。

整个流程跑下来，从输入到拿到可用代码，大概两三分钟。比手动写快得多，而且格式不会出错。

4.4 参数与判断标准的量化：让 AI 执行有据可依

skill 里最值钱的部分，是那些量化的判断标准。比如关键词研究 skill 里，我会定义：

• 搜索量低于 100/月 的关键词，除非转化意图极强，否则不纳入主攻列表
• 关键词难度（KD）高于 60 的，标记为“长期目标”，不放在新页面选题里
• 搜索意图分为四类：信息型、导航型、商业调查型、交易型，每类对应不同的内容策略

这些数字不是拍脑袋来的，而是根据实际项目经验总结的。写进 skill 后，AI 每次执行都会按这个标准筛选，输出结果的一致性大幅提升。你不需要每次跟它解释“什么样的关键词值得做”，它自己就知道。

提示：量化标准要留出调整空间。不同行业、不同网站权重的阈值不一样。可以在 skill 里写“默认阈值如下，如用户提供行业或网站权重信息，按以下规则调整……”，这样既保证默认可用，又支持个性化。

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

5.1 技能不触发或触发错误怎么办

这是最常见的问题。表现是：你明明在问关键词相关的问题，AI 却没用 keyword-research 技能，或者它用了错误的技能。排查思路分三步：

第一，检查 description 是否包含用户可能用的词。如果你问“帮我找找选题”，而 description 里只写了“关键词研究”，AI 可能匹配不上。解决办法是在 description 里补充同义词和口语化表达。

第二，检查是否有多个技能竞争同一个触发场景。比如 keyword-research 和 content-strategy 都可能被“选题”触发。这时候需要在 description 里明确边界，比如“当任务聚焦于关键词本身时使用本技能；当任务涉及整体内容规划时使用 content-strategy”。

第三，检查 skill 文件是否真的被加载了。有时候目录层级放错了，或者文件名大小写不对，都会导致加载失败。Claude Code 通常会在启动时打印加载的技能列表，留意一下终端输出。

5.2 输出格式不符合预期怎么调

AI 没按你定义的格式输出，通常是因为格式描述不够具体。我的经验是：与其用文字描述格式，不如直接给一个填好的示例。比如你要一个表格，就在 skill 里放一个 Markdown 表格示例，里面填上假数据。AI 看到示例后，模仿的准确率远高于看文字说明。

另一个技巧是加一句“如果信息不足，用‘待补充’占位，不要留空”。这样 AI 不会因为缺数据就跳过某个字段，导致格式错乱。

5.3 多技能协作时的上下文管理

复杂营销任务往往需要多个技能接力。比如先做关键词研究，再做 SERP 分析，最后写落地页文案。这时候容易出现上下文过长、AI 忘记前面结论的问题。

我的做法是在每个 skill 的输出里加一个“交接摘要”字段，用三五句话总结本步骤的核心结论，供下一个技能使用。比如关键词研究 skill 输出时，除了完整的关键词列表，还生成一段摘要：“本次研究确定主攻关键词 5 个，长尾词 20 个，搜索意图以商业调查型为主，建议优先创建对比类内容。”下一个技能加载时，优先读这段摘要，而不是重新解析整个列表。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑：skill 文件写得太长。一开始我恨不得把十年经验全塞进去，结果 AI 加载后反而抓不住重点。后来我强制自己每个 skill 的 SKILL.md 不超过 500 行，核心流程控制在 10 步以内，细节放到 references 子目录里按需读取。

第二个坑：忽略了 skill 的版本管理。营销策略会变，skill 内容也要更新。我现在的做法是在 frontmatter 里加 version 字段，每次修改都递增，并在文件末尾加一个 changelog。这样团队协作时能清楚知道当前用的是哪个版本。

第三个坑：没有做技能之间的依赖声明。有些技能依赖另一些技能的产出，比如落地页文案 skill 依赖关键词研究 skill 的输出。如果不声明依赖，AI 可能在缺少关键词数据的情况下硬写文案，质量很差。解决办法是在 skill 开头写一句“使用本技能前，请确认已完成关键词研究，或用户已提供目标关键词列表”。

6. 技能库的扩展与长期维护思路

6.1 从单点技能到技能网络

当技能数量超过十个，就需要考虑它们之间的关系了。我的做法是建一个skills-index.md文件，列出所有技能的名称、用途、依赖关系和典型使用顺序。这个索引文件不直接参与执行，但可以作为 AI 的参考，帮助它在复杂任务中规划技能调用顺序。

比如一个完整的独立站新页面创建流程，可能涉及：keyword-research → serp-analysis → content-outline → landing-page-copy → faq-schema → internal-link-suggestion。在索引文件里把这个链路写清楚，AI 在执行时就能按顺序调用，而不是东一榔头西一棒子。

6.2 根据实际项目反馈迭代技能内容

技能库不是写完就完了。每次实际项目跑完，我都会花十分钟复盘：哪个技能的输出直接用了，哪个技能的输出需要大改，哪个技能根本没被调用。需要大改的技能，说明它的执行流程或输出格式有问题，回去改 SKILL.md。没被调用的技能，要么是触发描述有问题，要么是这个技能本身就不该存在。

我个人的习惯是每个月做一次技能库清理。把三个月内从未被调用的技能归档，把高频使用的技能优化描述和示例。保持技能库精简，比堆一堆用不上的技能更有价值。

6.3 团队协作中的技能共享

如果是团队使用，技能库最好放在 Git 仓库里管理。每个人都可以提交新的技能或修改现有技能，通过 pull request 审核。审核标准很简单：新技能是否有明确的触发场景、是否有可执行的步骤、是否有格式化的输出示例。三条都满足就合并。

另外建议给每个技能指定一个 owner，负责该技能的准确性和时效性。营销环境变化快，谷歌的算法更新、结构化数据规范的调整，都需要及时反映到技能内容里。没有 owner 的技能，很容易变成没人维护的僵尸文件。

6.4 关于模型切换的兼容性考虑

前面提到过，Claude Code 可以通过第三方 API 接入其他模型。这时候要注意：不同模型对 skill 格式的解析能力有差异。Claude 系列对 Agent Skills 规范的支持最完整，其他模型可能需要调整 skill 的写法，比如把 YAML frontmatter 改成纯文本描述，或者简化执行步骤的嵌套层级。

我的建议是：核心技能保持规范格式，同时准备一个“兼容版”的简化描述，放在单独的文件里。切换模型时，根据目标模型的能力选择加载哪个版本。这样既不影响在 Claude Code 上的体验，也能在备用模型上跑通基本流程。

这套 marketingskills 的思路，说到底就是把营销人的经验变成 AI 能理解、能执行、能复用的结构化知识。工具会变，模型会换，但“把专业能力封装成可调用单元”这个方向，我觉得会越来越重要。毕竟 AI 再强，也需要有人告诉它“在营销这个领域，什么叫做得好”。