企业官网建设流程全解析

1. 从“marketingskills”说起：一个被低估的营销技能工程化思路

第一次看到marketingskills这个词，我脑子里蹦出来的不是某个具体工具，而是一种组织方式——把营销这件事拆成一项项可复用、可组合、可被 AI 调用的“技能单元”。这跟过去我们做营销的方式有本质区别。以前做营销，靠的是人脑里的经验、Excel 里的模板、收藏夹里的一堆链接，换个项目就得从头再来一遍。而marketingskills这个思路，是把营销能力沉淀成结构化的技能包，让 AI agent 能够按需加载、按场景调用。

我之所以对这个方向特别感兴趣，是因为它踩中了两个正在交汇的趋势。一个是 AI agent 的能力边界在快速扩张，尤其是以 Claude Code 为代表的命令行智能体工具，已经能直接读写文件、执行终端命令、调用外部 API；另一个是营销工作本身高度碎片化，SEO、内容、投放、数据分析、竞品监控，每一项都有大量重复劳动。把这两件事接起来，就是marketingskills真正要解决的问题：让营销人用自然语言指挥 AI 完成那些原本需要切换五六个工具才能搞定的活。

这篇文章适合谁看？如果你是一个独立站运营者，每天在 Google Search Console、Ahrefs、内容后台之间来回切换，那这套思路能帮你省掉大量机械操作。如果你是一个技术背景的营销人，已经在用 Claude Code 或者类似的 AI agent 工具，那你可以直接照着本文的框架搭建自己的技能库。如果你只是听说过 Agent Skills spec 但不知道从哪下手，那本文会从目录结构、技能定义、调用逻辑到实际案例，一步步拆给你看。

需要提前说明的是，marketingskills目前并不是一个官方标准化的产品，它更像是一种基于 Agent Skills spec 的实践模式。我下面讲的内容，一部分来自公开的规范文档，一部分来自我自己在独立站 SEO 和内容营销场景中的实际搭建经验。哪些是标准、哪些是我的补充，我会在文中明确标出来。

2. 核心概念拆解：Agent Skills spec 到底规定了什么

2.1 技能单元的基本结构

Agent Skills spec 的核心思想很朴素：一个技能就是一个文件夹，文件夹里至少有一个SKILL.md文件，用 YAML frontmatter 声明元信息，用 Markdown 正文描述这个技能要做什么、怎么做。这个设计的好处是，它不绑定任何特定的 AI 平台，Claude Code 能读，其他支持该规范的 agent 工具也能读。

一个典型的技能目录长这样：

marketingskills/ ├── seo-audit/ │ ├── SKILL.md │ └── references/ │ └── checklist.md ├── content-brief/ │ ├── SKILL.md │ └── templates/ │ └── brief-template.md ├── keyword-cluster/ │ └── SKILL.md └── faq-schema/ ├── SKILL.md └── examples/ └── sample.json

SKILL.md里的 frontmatter 通常包含name、description两个必填字段。description特别关键，因为 agent 是靠它来判断“当前任务该不该调用这个技能”的。我见过太多人把 description 写成“这是一个 SEO 技能”，结果 agent 根本不知道什么时候该用它。正确的写法应该描述触发场景，比如“当用户需要对一个页面进行 SEO 审计、检查标题标签、meta 描述、heading 结构、内链和外链配置时使用”。

2.2 为什么用 Markdown 而不是代码

很多人第一反应是：技能为什么不写成 Python 函数或者 JSON schema？我的理解是，Markdown 的优势在于它同时对人友好、对模型友好。人可以直接读、直接改，不需要懂编程；模型在解析时也能自然理解步骤之间的逻辑关系。而且 Markdown 天然支持嵌套结构、代码块、表格，表达力足够覆盖大多数营销场景。

当然，如果技能里需要执行确定性计算，比如算关键词密度、算 ROI，那还是得配合脚本。Agent Skills spec 允许在技能目录里放scripts/文件夹，agent 在执行时可以调用这些脚本。我的做法是：判断逻辑用 Markdown 写，精确计算用脚本兜底。

2.3 技能之间的组合与编排

单个技能能做的事有限，marketingskills真正的威力在于组合。比如一个完整的“独立站新页面上线”流程，可能涉及：关键词调研技能 → 内容大纲生成技能 → FAQ 结构化数据生成技能 → 页面 SEO 审计技能。Agent 会根据任务描述自动判断调用顺序，也可以由用户在 prompt 里显式指定。

这里有个容易踩的坑：技能之间的输入输出格式如果不统一，组合起来就会很别扭。我的经验是，在技能库里约定一套通用的中间数据格式，比如关键词列表统一用[{keyword, volume, difficulty, intent}]这样的结构，内容大纲统一用{h1, sections: [{h2, points}]}。这样技能 A 的输出可以直接喂给技能 B，不需要人工转换。

3. 环境搭建：从零把 Claude Code 跑起来

3.1 安装 Claude Code 的几种方式

Claude Code 目前有几种使用形态：命令行版本、VS Code 插件版本、桌面版。我主要用命令行版本，因为它在处理文件批量操作时最顺手。安装方式根据系统不同有差异。

macOS 和 Linux 下，官方推荐的方式是通过 npm 全局安装：

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

安装完成后，在项目目录下直接运行claude就能启动。Windows 用户需要注意，早期版本对 64 位 Windows 的兼容性有过一些问题，如果你遇到“与 64 位版本的 Windows 不兼容”的提示，优先检查 Node.js 版本是否过旧，建议用 Node 18 以上。Ubuntu 下如果遇到权限问题，不要用sudo npm install -g，而是配置 npm 的全局目录到用户目录下，避免后续文件权限混乱。

VS Code 用户可以直接在扩展市场搜索 Claude Code 插件安装。插件版的优势是能直接在编辑器里看到 agent 的文件修改 diff，审查起来更直观。我自己的习惯是：探索性任务用命令行，需要精细审查代码或配置改动用 VS Code 插件。

3.2 模型接入的几种选择

Claude Code 默认走官方模型，但很多人会遇到账号注册、订阅权限、地区可用性之类的限制。这时候可以考虑接入第三方模型。常见的做法是通过兼容层把 Claude Code 指向其他模型服务，比如 DeepSeek、Qwen、GLM 等。具体配置方式通常是在环境变量里指定 API base URL 和 API key，或者在 Claude Code 的配置文件里设置模型映射。

这里我要提醒一句：不同模型对 Agent Skills spec 的支持程度不一样。有些模型能很好地遵循 Markdown 里的步骤指令，有些则容易跳步或者自作主张。我的实测经验是，技能描述写得越具体、步骤拆得越细，模型之间的表现差异就越小。如果你的技能里大量依赖“模型自己判断”，那换模型后效果波动会比较大。

3.3 项目目录的初始化

搭marketingskills之前，先建一个干净的项目目录。我的习惯是：

mkdir my-marketing-agent && cd my-marketing-agent mkdir -p skills references output

skills/放所有技能单元，references/放共享的参考资料（比如行业术语表、品牌调性文档），output/放 agent 生成的结果。然后在项目根目录放一个CLAUDE.md，用来告诉 agent 这个项目的背景信息，比如“这是一个面向北美市场的独立站，主营户外装备，目标关键词集中在 hiking gear 和 camping essentials”。

CLAUDE.md这个文件很多人忽略，但它对 agent 的表现影响很大。它相当于给 agent 的“入职培训”，让它知道自己在什么场景下工作。我试过同一个技能，在有CLAUDE.md和没有的情况下，输出质量差距明显。

4. 搭建第一个营销技能：以 FAQ 结构化数据为例

4.1 为什么选 FAQ Schema 作为入门技能

FAQ 结构化数据是独立站 SEO 里性价比很高的一个点。它能让你的页面在搜索结果里展示额外的问答折叠区域，提升点击率。而且它的规则相对明确，适合作为第一个技能来练手。Google 对 FAQPage 结构化数据有明确的格式要求，用 JSON-LD 写在页面里，包含@type: FAQPage和一组Question/Answer对。

但要注意，Google 在 2023 年之后收紧了 FAQ 富结果的展示范围，现在主要对权威站点和特定类型的页面展示。所以做这个技能的目的不只是“拿富结果”，更是让页面结构更清晰、语义更完整，这对长尾关键词的排名有间接帮助。

4.2 技能文件的编写

在skills/faq-schema/SKILL.md里，我是这样写的：

--- name: faq-schema description: 当用户需要为某个页面生成 FAQ 结构化数据（FAQPage JSON-LD），或需要根据页面内容提取常见问题并生成符合 Google 规范的 JSON-LD 代码时使用。适用于独立站产品页、教程页、服务页。 --- # FAQ Schema 生成技能 ## 执行步骤 1. 读取用户指定的页面内容文件，或从对话中提取页面主题。 2. 识别页面中适合做 FAQ 的信息点，优先选择： - 用户高频疑问（价格、配送、退换、使用方法） - 页面中已有但表述分散的信息 - 与目标关键词相关的长尾问题 3. 每个问题生成简洁答案，答案控制在 40-60 字，直接回答问题，不堆砌关键词。 4. 按以下 JSON-LD 格式输出： ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "问题文本", "acceptedAnswer": { "@type": "Answer", "text": "答案文本" } } ] }

5. 将结果写入output/faq-schema-{页面标识}.json。

注意事项

• 问题数量控制在 3-8 个，太少没意义，太多稀释权重。
• 答案里不要出现“点击这里”“了解更多”这类无信息量的引导语。
• 如果页面本身已经有 FAQ 区块，优先复用已有问答，不要另起炉灶。

这个技能写完后，我在 Claude Code 里输入“帮我给 output/product-page-hiking-boots.md 生成 FAQ schema”，agent 就会自动读取文件、提取问题、生成 JSON-LD 并写入输出目录。整个过程不需要我手动复制粘贴。 ### 4.3 参数与细节的调优 上面这个技能看起来简单，但有几个参数我调了好几轮才满意。第一个是问题数量。一开始我设的是 5-10 个，结果 agent 经常硬凑问题，生成一些用户根本不会问的内容。后来改成 3-8 个，并且明确“优先选择用户高频疑问”，质量明显提升。 第二个是答案长度。40-60 字这个区间是我测试下来比较合适的。太短显得敷衍，太长在搜索结果里会被截断。而且这个长度也符合语音搜索的播报习惯。 第三个是输出格式。我一开始让 agent 直接输出 JSON，结果它有时候会在 JSON 外面包一层解释文字，导致文件不能直接用。后来我在技能里明确“只输出 JSON，不要任何额外说明”，并且指定写入文件而不是打印到对话里，问题就解决了。 ## 5. 技能库的扩展：从单点技能到营销工作流 ### 5.1 关键词聚类技能的设计 FAQ schema 只是单点技能。真正让 `marketingskills` 发挥价值的是把多个技能串成工作流。我第二个搭的技能是关键词聚类。它的输入是一批关键词（通常从 Search Console 或关键词工具导出），输出是分好组的关键词簇，每组对应一个内容主题。 这个技能的难点在于聚类逻辑。纯靠模型判断，结果不稳定；纯靠规则（比如按词根分组），又太死板。我的做法是混合：先用规则做初步分组（相同词根、相同修饰词归为一组），再让模型对每组做语义合并和主题命名。技能文件里我会写清楚这个两步逻辑，并且给出一个示例输入输出，让模型有参照。 ### 5.2 内容大纲生成技能 关键词聚类之后，自然就是内容大纲生成。这个技能的输入是一个关键词簇，输出是一个页面大纲，包含 H1、H2、每个 H2 下的要点、建议的内链锚文本。我在技能里内置了一个大纲模板，要求每个 H2 必须对应一个搜索意图，并且标注这个意图是信息型、导航型还是交易型。 这里有个经验：大纲生成技能最好和关键词聚类技能共享同一套意图分类标准。否则聚类时说这个词是信息型，大纲生成时又变成交易型，整个工作流就乱了。我在 `references/` 里放了一个 `intent-taxonomy.md`，两个技能都引用它，保证一致性。 ### 5.3 SEO 审计技能 页面写完后，需要审计。SEO 审计技能做的事情包括：检查 title 长度和关键词位置、检查 meta description、检查 H1 唯一性、检查 H2 层级、检查图片 alt、检查内链数量和外链配置、检查页面加载相关的静态指标（如果 agent 能读到构建产物的话）。 这个技能我写得比较细，因为审计项多，而且每项的判断标准不一样。比如 title 长度，我设的是 50-60 字符，超过就警告；meta description 设的是 140-160 字符。这些数字不是拍脑袋来的，是参考了搜索结果页的展示宽度和常见最佳实践。技能里我会把每个审计项的标准、检查方法、输出格式都写清楚。 ### 5.4 工作流的编排方式 四个技能搭好后，我在项目根目录的 `CLAUDE.md` 里写了一段工作流说明： ```markdown ## 标准内容生产流程 1. 用户提供关键词列表 → 调用 keyword-cluster 技能 2. 选定一个关键词簇 → 调用 content-brief 技能生成大纲 3. 根据大纲撰写内容 → 调用 faq-schema 技能生成结构化数据 4. 内容完成后 → 调用 seo-audit 技能进行审计 5. 审计通过后输出到 output/ 目录

这样 agent 就知道整个流程的先后顺序，我在对话里只需要说“走一遍标准流程，关键词列表在 input/keywords.csv”，它就会自动按顺序调用技能。当然，实际执行时我建议还是分步确认，不要一次性全自动跑完，因为中间环节的输出质量需要人工把关。

6. 实操中踩过的坑与排查技巧

6.1 技能不被调用怎么办

最常见的问题是：技能写好了，但 agent 不调用它。原因通常是 description 写得不够“场景化”。Agent 判断是否调用某个技能，靠的是把当前任务和技能的 description 做匹配。如果你的 description 是“SEO 相关技能”，那 agent 只有在任务里明确出现“SEO”这个词时才可能调用。但如果用户说的是“帮我看看这个页面有没有问题”，agent 就不知道要用这个技能。

解决办法是把 description 写成“当用户需要……时使用”的句式，把触发场景列全。比如 SEO 审计技能的 description 我会写成：“当用户需要检查页面 SEO 配置、审计 title/meta/heading/内链/图片 alt、或需要一份页面优化建议清单时使用。”

6.2 输出格式不稳定的处理

模型输出格式漂移是另一个高频问题。同样的技能，有时候输出纯 JSON，有时候在 JSON 外面加一段“好的，以下是生成结果”。我的应对策略有三层：第一，在技能里用代码块明确输出格式，并且加一句“只输出代码块内容，不要任何额外文字”；第二，在技能里给出一个完整的输入输出示例，让模型有样学样；第三，如果还是不稳定，就在技能目录里放一个校验脚本，agent 生成后自动跑脚本检查格式，不合格就重新生成。

6.3 多技能协同时的上下文丢失

当工作流涉及多个技能时，容易出现上下文丢失。比如关键词聚类技能输出了一个簇，内容大纲技能却不知道这个簇的主题是什么。这是因为 agent 在不同技能之间切换时，可能没有把上一个技能的完整输出传递下去。

我的做法是在技能里明确声明输入依赖。比如内容大纲技能的 SKILL.md 开头就写：“本技能需要输入一个关键词簇，格式为{topic, keywords: [], intent}。如果用户没有提供，先询问或调用 keyword-cluster 技能。”这样 agent 就知道缺输入时该去哪里找。

6.4 常见问题速查表

6.5 几个我踩过的具体坑

第一个坑是技能命名。我一开始用中文命名技能文件夹，比如关键词聚类/，结果在某些系统上路径处理出问题。后来统一改成英文小写加连字符，比如keyword-cluster/，就再没出过问题。

第二个坑是技能粒度。我一开始把“内容生产”写成一个巨大的技能，包含调研、大纲、撰写、审计所有步骤。结果这个技能太长，模型执行到后面就忘了前面的要求。后来拆成四个独立技能，每个只做一件事，执行质量明显提升。技能拆分的标准我总结为：如果一个技能的步骤超过 7 步，或者涉及超过 3 个不同的输出类型，就应该考虑拆分。

第三个坑是参考资料的管理。我一开始把参考文档直接写在 SKILL.md 里，导致文件很长。后来改成放在references/子目录，SKILL.md 里只写“参考 references/xxx.md”，模型需要时会自己去读。这样技能文件保持简洁，参考资料也能被多个技能共享。

7. 技能库的维护与迭代

7.1 版本管理

marketingskills技能库是需要持续迭代的。我建议用 Git 管理整个项目目录，每次修改技能后提交一次，commit message 写清楚改了什么、为什么改。这样当某个技能效果变差时，可以快速回滚到之前的版本。

技能文件里我还会加一个version字段，虽然 Agent Skills spec 没有强制要求，但自己维护一个版本号有助于追踪。比如version: 1.2，配合 Git 的 commit 记录，能清楚看到每个技能的演进过程。

7.2 效果评估

怎么判断一个技能好不好用？我的评估维度有三个：触发准确率（该调用时是否调用）、输出合格率（生成结果是否直接可用）、执行耗时。前两个靠人工抽查，第三个可以在技能里加时间戳来记录。

我一般会攒一批测试用例，比如 10 个不同的页面内容，跑一遍 FAQ schema 技能，看有多少个输出不需要修改就能用。合格率低于 70% 的技能，就需要回去改 description 或步骤描述。

7.3 技能库的扩展方向

marketingskills可以扩展的方向很多。除了我上面提到的四个技能，还可以加：竞品分析技能（抓取竞品页面结构并对比）、外链机会挖掘技能（根据内容主题找相关站点）、社媒文案生成技能（把长内容拆成短帖）、邮件营销序列技能（生成 welcome sequence）。

每加一个技能，都要考虑它和现有技能的衔接。我的原则是：新技能的输入格式必须兼容现有技能的输出格式，否则就要先改现有技能。这样整个技能库才能保持一致性，不会越加越乱。

8. 关于模型选择和成本控制的几点经验

8.1 不同模型在营销技能上的表现差异

我用过几个不同的模型来跑这套技能库，感受比较明显。在遵循 Markdown 步骤指令方面，能力强的模型确实更稳，尤其是涉及多步逻辑判断时，不容易跳步。但在一些纯文本生成任务上，比如写 FAQ 答案，中等能力的模型也能做得不错，成本却低很多。

我的策略是分层使用：需要复杂判断的技能（比如关键词聚类、SEO 审计）用能力强的模型；纯生成类技能（比如 FAQ 答案、社媒文案）用成本低的模型。Claude Code 支持在配置里切换模型，我通常会在跑不同技能时手动切换，或者在工作流里标注每个步骤建议使用的模型档次。

8.2 Token 消耗的优化

营销技能库跑起来后，token 消耗是个实际问题。一个完整的内容生产流程，从关键词聚类到 SEO 审计，可能消耗几万到十几万 token。优化方向有几个：第一，参考资料按需加载，不要一次性全塞进上下文；第二，技能输出写入文件而不是留在对话里，减少上下文累积；第三，长文档分段处理，不要一次性让模型读完整篇内容。

我实测下来，把输出写入文件这一项就能省下 30% 左右的 token，因为对话上下文不会越滚越长。另外，CLAUDE.md里的项目背景信息也要精简，只保留最关键的品牌调性、目标市场、内容规范，不要把整个品牌手册都塞进去。

8.3 本地模型的可能性

有些场景下，用本地模型跑营销技能是可行的，比如批量生成 FAQ 答案、批量改写 meta description。这些任务对模型推理能力要求不高，本地模型完全能胜任，而且没有 token 成本。但涉及多步判断的技能，比如 SEO 审计里的优先级排序，本地模型的表现还是差一些。

我的建议是：把技能按“判断密集型”和“生成密集型”分类，前者用云端强模型，后者可以尝试本地模型。Claude Code 支持配置本地模型服务，具体配置方式参考官方文档里的模型接入章节。

9. 一个完整的实操案例：从关键词到上线页面

9.1 输入准备

假设我要为独立站生产一个关于“hiking boots for wide feet”的页面。我先把从关键词工具导出的相关词整理成 CSV：

keyword,volume,difficulty,intent hiking boots for wide feet,2400,35,informational wide hiking boots mens,880,28,transactional best hiking boots wide toe box,1200,32,informational wide fit hiking boots womens,720,30,transactional hiking boots wide width,1600,38,informational

9.2 执行关键词聚类

在 Claude Code 里输入：“读取 input/keywords.csv，调用 keyword-cluster 技能进行聚类。”Agent 会输出类似这样的结果：

{ "topic": "wide fit hiking boots", "keywords": ["hiking boots for wide feet", "wide hiking boots mens", "best hiking boots wide toe box", "wide fit hiking boots womens", "hiking boots wide width"], "intent": "informational + transactional", "suggested_page_type": "buying guide" }

9.3 生成内容大纲

接着输入：“基于上面的聚类结果，调用 content-brief 技能生成大纲。”Agent 输出：

# H1: The Complete Guide to Wide Fit Hiking Boots ## H2: Why Standard Hiking Boots Don't Fit Wide Feet - 脚型差异说明 - 标准鞋楦的问题 - 意图：信息型 ## H2: How to Measure Your Feet for Wide Hiking Boots - 测量步骤 - 尺码对照 - 意图：信息型 ## H2: Top Wide Fit Hiking Boots for Men - 产品推荐 - 意图：交易型 ## H2: Top Wide Fit Hiking Boots for Women - 产品推荐 - 意图：交易型 ## H2: FAQ - 常见问题 - 意图：信息型

9.4 生成 FAQ Schema

根据大纲里的 FAQ 部分，调用 faq-schema 技能，生成 JSON-LD 并写入output/faq-wide-hiking-boots.json。

9.5 SEO 审计

最后调用 seo-audit 技能，检查生成的大纲和 FAQ 是否符合 SEO 规范。审计输出会列出所有检查项和通过情况，不通过的项会给出修改建议。

整个流程跑下来，从关键词到可执行的内容方案，大概 15-20 分钟。如果手动做，光是关键词聚类和大纲构思就得花一两个小时。这就是marketingskills的价值所在：不是替代营销人的判断，而是把机械劳动压缩掉，让人把时间花在策略和创意上。

10. 关于技能库安全与合规的几点提醒

搭marketingskills的时候，有几个安全边界要注意。第一，技能里不要写任何涉及敏感话题的内容生成指令，营销内容本身要符合公序良俗。第二，如果技能涉及抓取外部数据，要确保目标站点的 robots.txt 允许，并且控制抓取频率。第三，技能生成的 JSON-LD 结构化数据要符合搜索引擎的规范，不要试图用结构化数据标记来误导搜索结果。

另外，技能库里的参考资料如果包含用户数据或商业机密，要注意存储安全。我的做法是references/目录里的敏感文件不提交到 Git，用.gitignore排除，只在本地保留。

11. 后续可以怎么扩展这套技能库

marketingskills搭到后面，我发现它不只是一个工具集合，更像是一个营销知识管理系统。每当我总结出一个新的营销方法论，就把它写成一个技能，下次遇到类似场景直接调用。时间长了，这个技能库就成了我自己的营销经验外脑。

扩展方向上，我接下来想尝试的是：把技能库和定时任务结合起来，比如每天早上自动跑一次竞品页面监控，发现变化就生成报告；把技能库和飞书之类的协作工具打通，让 agent 生成的报告直接推送到团队频道；把技能库里的判断逻辑做成可配置的参数，不同项目用不同的参数集，而不需要改技能文件本身。

这些扩展的前提是技能库本身结构清晰、格式统一。如果前期技能写得随意，后期扩展就会很痛苦。所以我的建议是：一开始就定好目录规范、命名规范、输入输出格式规范，哪怕多花点时间，后面会省很多事。

我个人在实际操作中的体会是，marketingskills这套东西最大的价值不在于自动化本身，而在于它强迫你把营销经验显性化。以前很多判断是“凭感觉”，现在必须写成明确的步骤和标准，这个过程本身就是对营销能力的梳理和提升。而且写出来的技能可以被复用、被迭代、被分享，这比藏在个人脑子里的经验有价值得多。