企业官网建设流程全解析

1. 从"marketingskills"这个标题说起：一个被低估的AI Agent技能库

第一次看到"marketingskills"这个词，我脑子里蹦出来的不是"营销技巧"这种泛泛的概念，而是一个很具体的东西——它大概率是一个围绕Claude Code和AI agents构建的技能包（Skills）集合，专门服务于营销场景。为什么这么判断？因为最近半年，Agent Skills spec 这套规范在开发者圈子里讨论度非常高，而 Claude Code 作为目前最成熟的终端级 AI 编程代理之一，它的 Skills 机制允许你把一套可复用的工作流封装成"技能"，让 agent 在特定场景下自动调用。

那 marketingskills 到底解决什么问题？说白了，它把营销工作中那些重复性高、但又需要一定专业判断的任务——比如 SEO 内容优化、FAQ 结构化数据生成、落地页文案批量产出、竞品关键词分析——封装成 agent 可以直接执行的技能模块。你不需要每次都从头写 prompt，也不需要手动整理一堆上下文，agent 会根据任务类型自动匹配对应的 skill。

这篇文章适合谁看？三类人：一是已经在用 Claude Code 但还没玩转 Skills 机制的开发者；二是做独立站、做谷歌 SEO、需要批量处理内容营销任务的人；三是想理解 Agent Skills spec 到底怎么落地到具体业务场景的技术负责人。不管你之前有没有接触过 Claude Code，我都会从安装配置讲到技能设计，再到实际跑通一个营销技能的全流程。

我自己的背景是做了七八年技术营销，从最早的脚本自动化到后来的 GPT 工作流，再到现在的 agent 编排，踩过的坑不算少。marketingskills 这个方向我是认真研究过一段时间的，下面把我知道的、试过的、以及踩过的坑都摊开讲。

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

2.1 为什么需要一套"技能规范"

在 Agent Skills spec 出现之前，大家给 AI agent 加能力的方式很原始——要么把所有指令塞进一个巨大的 system prompt，要么写一堆工具函数让 agent 去调。前者的问题是上下文爆炸，一个 prompt 塞几千字，模型注意力被稀释，执行质量直线下降；后者的问题是工具和业务逻辑耦合太紧，换个场景就得重写。

Agent Skills spec 的思路不一样。它把"技能"定义成一个自包含的单元：有明确的触发条件、有独立的指令文件、有可选的辅助资源（脚本、模板、参考文档）。Agent 在运行时根据当前任务判断该加载哪个 skill，只把相关的指令注入上下文。这就像给一个员工发了一本员工手册，但手册是分章节的，遇到什么问题翻哪一章，而不是让他把整本书背下来。

提示：Skills 的核心价值在于"按需加载"。一个设计良好的 skill 不应该超过 500 行指令，超过这个量级说明你该拆分了。

2.2 Claude Code 里的 Skills 是怎么工作的

Claude Code 对 Skills 的支持体现在它的项目级配置里。你可以在项目根目录下建一个.claude/skills/目录，每个子目录就是一个 skill，里面通常包含一个SKILL.md作为主指令文件，还可以带scripts/、templates/、references/等辅助目录。

当你在 Claude Code 里发起一个任务时，它会先扫描可用的 skills 列表（只读每个 skill 的元信息，比如名称和一句话描述），然后根据你的任务描述判断是否需要加载某个 skill 的完整内容。这个判断过程本身也是一次模型调用，所以 skill 的描述写得准不准，直接决定了它会不会被正确触发。

我实测下来，skill 的触发准确率和三个因素强相关：描述里的关键词覆盖度、任务描述和 skill 描述的语义距离、以及当前上下文里已经加载了多少其他 skill。第三个因素经常被忽略——如果你同时装了二十个 skill，模型的选择困难症就犯了，触发率反而下降。

2.3 marketingskills 的定位与边界

回到 marketingskills 本身。从命名来看，它是一个面向营销领域的 skill 集合，而不是单个 skill。这意味着它内部应该包含多个子技能，比如：

• SEO 内容优化技能：给定一篇草稿和目标关键词，输出优化建议
• FAQ 结构化数据生成技能：根据页面内容自动生成符合 schema.org 规范的 FAQPage 标记
• 关键词聚类技能：把一堆搜索词按意图和主题分组
• 落地页文案技能：根据产品信息生成多版本文案

这些技能的共同特点是：输入输出格式相对固定、依赖一定的领域知识、但不需要实时外部数据。这正好是 Skills 机制最擅长的场景——把领域知识固化下来，让 agent 每次执行时不用重新"学习"。

边界也很清楚：marketingskills 不负责数据采集（那是爬虫或 API 的事），不负责发布（那是 CMS 的事），它专注在"内容加工"这个环节。理解这个边界很重要，不然你会指望它做它做不到的事。

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

3.1 安装 Claude Code 的几种方式与选择逻辑

Claude Code 目前有几种安装途径，不同系统下的体验差异挺大。我把常见的几种列出来，顺便说说各自适合什么人。

我个人的建议是：如果你本来就写代码，直接 npm 装；如果你主要用 VS Code 写东西，装插件版；如果你完全不想碰命令行，用桌面版。三条路都能到同一个地方，别在选路上纠结太久。

macOS 和 Ubuntu 下的 npm 安装命令基本一致：

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

装完之后跑claude --version验证一下。如果提示找不到命令，大概率是 npm 全局路径没加到 PATH 里，检查一下npm config get prefix的输出，把对应的 bin 目录加进去。

Windows 用户要注意一个坑：32 位系统是不支持的，会直接报兼容性错误。现在还在用 32 位 Windows 的机器基本是十年前的老设备了，如果遇到"与64位版本不兼容"之类的提示，先确认系统架构。

3.2 VS Code 插件配置的关键细节

VS Code 里装 Claude Code 插件之后，有几个配置项值得单独说。第一个是模型选择——插件默认走官方订阅，但如果你有自己的 API 渠道，可以在设置里切换。第二个是工作目录，插件会以你当前打开的文件夹作为项目根目录，.claude/skills/也要放在这个根目录下才会被识别。

有个常见问题：装完插件后提示"your organization has disabled claude subscription access"，这通常是账号权限层面的限制，不是插件本身的问题。遇到这种情况，要么换一个有权限的账号，要么配置第三方 API 接入。

3.3 接入本地模型或其他模型服务

Claude Code 的一个灵活之处是它不绑定特定模型后端。你可以通过配置让它调用本地跑的模型（比如用 LM Studio 起的服务），也可以接入其他兼容 OpenAI 接口的模型服务。

配置方式通常是在项目或全局配置里指定 base URL 和 API key。以接入本地 LM Studio 为例，先在 LM Studio 里启动一个兼容 OpenAI 格式的服务（默认端口 1234），然后在 Claude Code 的配置里把 base URL 指向http://localhost:1234/v1。

注意：本地小模型跑 agent 任务的效果和云端大模型差距明显，尤其是需要多步推理和工具调用的场景。本地模型更适合做简单的文本处理类 skill，复杂的编排任务还是建议用能力更强的模型。

如果你用的是第三方 API 聚合服务，配置逻辑类似，关键是确认接口格式兼容。有些服务虽然号称兼容 OpenAI，但 function calling 的实现有差异，会导致 skill 调用失败。这个只能实测，没有捷径。

4. marketingskills 的技能设计：从需求到可执行模块

4.1 一个营销 skill 应该包含哪些部分

设计一个 marketingskills 里的技能，我习惯按这个结构来组织：

.claude/skills/seo-content-optimizer/ ├── SKILL.md # 主指令，定义触发条件和执行流程 ├── templates/ │ └── output-format.md # 输出格式模板 └── references/ └── seo-checklist.md # SEO 检查清单参考

SKILL.md是最核心的，它需要回答三个问题：什么时候用这个技能（触发条件）、用的时候按什么步骤做（执行流程）、做完输出成什么样（输出规范）。

触发条件的写法有讲究。不要写"当用户需要 SEO 优化时"，太模糊了。要写"当用户提供一段文本并提到关键词优化、排名提升、SEO 检查等意图时"。把具体的触发词列出来，模型的判断准确率会高很多。

4.2 SEO 内容优化技能的具体实现

拿 SEO 内容优化这个技能举例，它的执行流程我设计成四步：

第一步，解析输入。提取用户提供的正文、目标关键词、以及可选的竞品参考。如果用户没给关键词，先从正文里推断核心主题。

第二步，关键词密度与分布分析。统计目标关键词及其变体在标题、首段、各小标题、正文、结尾的出现位置和频次。这里有个经验值：主关键词密度控制在 1% 到 2% 之间比较安全，超过 3% 就有堆砌嫌疑。

第三步，结构优化建议。检查 H1/H2/H3 的层级是否合理，小标题里是否自然包含了关键词变体，段落长度是否适合移动端阅读（建议每段不超过 150 字）。

第四步，输出优化后的版本和修改说明。修改说明很重要，让用户知道每处改动的原因，而不是直接给一个改好的版本让人摸不着头脑。

这个流程写进 SKILL.md 之后，每次调用都会按这个逻辑走，输出质量就稳定了。这就是 skill 相比裸 prompt 的优势——它把"怎么做"固化下来了。

4.3 FAQPage 结构化数据生成技能

FAQ 结构化数据是谷歌 SEO 里一个高频需求，但很多人搞不清楚它的规则。FAQPage schema 的本质是告诉搜索引擎"这个页面包含一组问答对"，从而有机会在搜索结果里展示富摘要。

生成这个技能的关键在于两点：一是正确识别页面里哪些内容适合做成 FAQ，二是输出符合 schema.org 规范的 JSON-LD。

识别逻辑我一般这样设计：扫描正文里以问句形式出现的段落（以问号结尾、或者以"如何""什么""为什么"开头的句子），把紧随其后的段落作为答案。如果答案超过 300 字，截取前两句作为摘要，因为富摘要展示的字数有限。

JSON-LD 的输出格式必须严格：

{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "问题文本", "acceptedAnswer": { "@type": "Answer", "text": "答案文本" } } ] }

注意：谷歌对 FAQ 富摘要的展示有严格的内容政策，答案必须是页面上真实存在的内容，不能为了拿富摘要而编造问答。另外，同一个页面不要重复标记多个 FAQPage，一个页面一个就够了。

4.4 关键词聚类技能的设计思路

关键词聚类是内容策略的基础工作。你从关键词工具里导出几百个词，人工分组要花大半天，用 skill 来做就快很多。

我的设计思路是让 agent 按"搜索意图"和"主题相关性"两个维度聚类。搜索意图分四类：信息型（想了解）、导航型（找特定网站）、商业型（比较产品）、交易型（准备购买）。主题相关性则看词与词之间的语义重叠度。

执行流程上，先让 agent 对每个词标注意图类型，然后按主题分组，最后给每组起一个能概括的主题名。输出格式用表格最直观：

这个技能的价值在于把非结构化的关键词列表变成了可执行的内容规划。

5. 实操全流程：跑通一个完整的营销技能

5.1 项目初始化与目录结构

假设你要从零搭一个 marketingskills 项目，第一步是建目录结构。我习惯这样组织：

my-marketing-agent/ ├── .claude/ │ └── skills/ │ ├── seo-optimizer/ │ ├── faq-generator/ │ └── keyword-cluster/ ├── content/ │ ├── drafts/ │ └── published/ └── CLAUDE.md

CLAUDE.md是项目级指令文件，Claude Code 启动时会自动读取。你可以在里面写项目背景、写作规范、常用术语表，这样所有 skill 共享这些上下文，不用每个 skill 里重复写。

5.2 编写第一个 SKILL.md

以 seo-optimizer 为例，SKILL.md 的内容大概长这样：

--- name: seo-content-optimizer description: 当用户提供文章草稿并希望进行SEO优化、关键词密度检查、标题结构改进时使用此技能 --- # SEO 内容优化技能 ## 触发条件 用户提供了正文内容，并提到以下任一意图：SEO优化、关键词优化、排名提升、内容检查。 ## 执行步骤 1. 提取正文、目标关键词（如未提供则从正文推断） 2. 分析关键词在标题、首段、小标题、正文、结尾的分布 3. 检查标题层级结构（H1唯一，H2/H3不跳级） 4. 输出优化建议和修改后的版本 ## 输出格式 - 优化前 vs 优化后对照 - 每处修改附原因说明 - 关键词密度统计表

frontmatter 里的 description 是触发判断的依据，一定要写清楚"什么时候用"，而不是"这个技能是什么"。

5.3 实际运行与效果验证

写完 skill 之后，在 Claude Code 里发起一个任务测试。比如把一篇草稿贴进去，说"帮我优化这篇关于独立站谷歌SEO的文章"。

观察几个点：skill 有没有被正确触发（看它有没有按你定义的步骤走）、输出格式是否符合预期、关键词分析是否准确。如果没触发，先检查 description 的措辞，把用户可能说的词都加进去。

我实测下来，第一次写 skill 触发率能到 70% 就不错了，通常要迭代两三轮。迭代的方法很简单：把没触发的任务描述收集起来，看它们和你的 description 差在哪里，然后补充关键词。

5.4 多技能协同的场景

单个 skill 跑通之后，可以试试多技能协同。比如一个完整的营销内容生产流程：先用 keyword-cluster 做关键词分组，再用 seo-optimizer 优化草稿，最后用 faq-generator 生成结构化数据。

多技能协同的关键是让每个 skill 的输出格式能被下一个 skill 直接消费。比如 keyword-cluster 输出的表格，seo-optimizer 要能读懂里面的关键词列。这需要在设计时就考虑数据流转，而不是各写各的。

提示：多技能场景下，建议在 CLAUDE.md 里定义一套通用的数据格式约定，比如关键词统一用逗号分隔、输出统一用 Markdown 表格。这样技能之间对接会顺畅很多。

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

6.1 技能不触发怎么办

这是最高频的问题。排查顺序我一般这样走：

先看 description 写得够不够具体。如果只写"SEO相关任务"，模型很难判断。改成"当用户提供文章并希望优化搜索排名时"就明确多了。

再看是不是装了太多 skill。超过 15 个之后触发准确率会明显下降，建议按项目拆分，不同项目装不同的 skill 集合。

最后看任务描述本身。如果用户说"帮我看看这篇文章"，没有任何营销相关词汇，模型确实没理由触发 SEO 技能。这种情况下要么让用户说得更具体，要么在 CLAUDE.md 里加一句"本项目的所有内容任务默认走 SEO 优化流程"。

6.2 输出格式不稳定的处理

有时候 skill 第一次跑输出很规范，第二次就放飞了。这通常是因为 SKILL.md 里的输出格式描述不够刚性。解决办法是给一个完整的输出示例，让模型照着抄格式。

另一个技巧是在 SKILL.md 里明确写"不要做 X"。比如"不要在输出里添加额外的解释段落""不要改变原文的段落顺序"。负面指令有时候比正面指令更有效。

6.3 模型选择对技能效果的影响

同一个 skill，换不同模型跑，效果差异可能很大。我做过对比：复杂的关键词聚类任务，能力强的模型分组更合理；简单的格式转换任务，小模型也能胜任，而且速度快、成本低。

所以我的策略是分级使用：需要推理和判断的 skill 用强模型，纯格式处理的 skill 用轻量模型。Claude Code 支持在配置里切换，你可以根据任务类型灵活调整。

6.4 常见问题速查表

6.5 几个我踩过的坑

第一个坑是 skill 命名太随意。一开始我用skill1、skill2这种名字，后来自己都忘了哪个是哪个。命名要见名知意，用seo-optimizer而不是optimizer。

第二个坑是把太多逻辑塞进一个 skill。我最早写过一个"全能营销技能"，结果触发条件写得含糊，执行步骤有十几步，模型跑到一半就乱了。后来拆成四个独立 skill，每个只做一件事，稳定性大幅提升。

第三个坑是忽略了 CLAUDE.md 的作用。项目级的共享上下文能省掉大量重复描述，我一开始每个 skill 里都重复写"本项目是做独立站SEO的"，后来统一挪到 CLAUDE.md，skill 文件清爽了很多。

7. 技能库的扩展与长期维护

7.1 什么时候该新增一个技能

判断标准很简单：如果某个任务你重复做了三次以上，而且每次的流程基本一致，就该把它固化成 skill 了。反过来，如果任务每次都不一样，或者需要大量人工判断，那就不适合做成 skill，老老实实手动做。

新增技能的另一个信号是：你发现自己在不同项目里反复复制同一段 prompt。这段 prompt 就是 skill 的雏形。

7.2 技能版本管理

Skill 也是代码，需要版本管理。我建议把.claude/skills/目录纳入 git 管理，每次修改 SKILL.md 都提交一次，commit message 写清楚改了什么、为什么改。

这样做的好处是，当某个 skill 改完之后效果变差了，你能快速回滚到上一个版本。我吃过这个亏——有一次优化了一个 skill 的措辞，结果触发率反而降了，还好有 git 记录，五分钟就回滚了。

7.3 团队协作中的技能共享

如果是团队使用，skill 库可以做成共享仓库，每个人 clone 下来放到自己的项目里。但要注意，不同人的使用习惯不同，对同一个 skill 的期望也不一样。我的做法是核心 skill 统一维护，个性化需求通过 CLAUDE.md 里的项目级配置来覆盖。

另外，团队里应该有一个"技能评审"机制。新 skill 上线前，至少两个人测试过，确认触发条件和输出格式都符合预期。这能避免一个人写的 skill 在别人那里完全跑不通。

7.4 后续可以扩展的方向

marketingskills 这个方向往下走，我觉得有几个值得探索的点。一是接入实时数据，比如让 skill 能调用关键词工具的 API 获取最新搜索量；二是增加 A/B 测试文案生成能力，一次输出多个版本文案供选择；三是和内容管理系统打通，优化完直接发布，省掉复制粘贴的环节。

不过这些都是锦上添花，核心还是把基础的几个 skill 打磨稳定。技能库的价值不在于数量多，而在于每个都可靠、可复用。我见过有人装了五十个 skill，结果常用的就三个，剩下的全是摆设。与其铺量，不如把三五个核心技能做到闭眼可用。

最后分享一个我自己的习惯：每隔一段时间，我会把最近一个月实际调用过的 skill 记录翻出来看一遍，哪些触发频繁、哪些从没触发过、哪些触发了但输出需要大量手动修改。从没触发的考虑删掉或重写，需要大量修改的说明设计有问题。这个复盘习惯让我的技能库一直保持精简和高效。