企业官网建设流程全解析

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

第一次看到marketingskills这个项目名，我的直觉是：这大概率不是一个传统的营销工具库，而是一套面向 AI Agent 的"技能包"。事实也确实如此——它本质上是一组遵循Agent Skills spec规范编写的技能定义集合，专门服务于 Claude Code 这类具备工具调用能力的 AI 编程代理，把营销领域里那些高频、重复、有固定套路的工作，封装成 Agent 可以直接调用的"技能"。

为什么这件事值得单独拿出来讲？因为大多数人用 Claude Code 的方式还停留在"我提问、它回答"的对话层面，而 Agent Skills 的价值在于把"提问"变成"调用"——你不再需要每次把 SEO 检查清单、结构化数据模板、内容审核规则重新描述一遍，而是让 Agent 在需要的时候自动加载对应的技能。这中间的差别，类似于你每次做菜都要现查菜谱，和厨房墙上直接贴好了标准作业流程。

marketingskills瞄准的场景非常具体：独立站运营、谷歌 SEO、内容营销、FAQPage 结构化数据、关键词布局这些活儿。这些工作的共同特点是——规则明确、重复度高、但细节极其琐碎。比如 FAQPage 结构化数据，字段就那么几个，但@type、mainEntity、acceptedAnswer的嵌套关系错一层，搜索引擎就识别不了。人做十遍会烦，做一百遍会错，而这恰恰是 Agent Skills 最擅长的领域。

这篇文章适合三类人看：一是已经在用 Claude Code 但只会基础对话的开发者；二是做独立站、需要批量处理 SEO 事务的运营；三是对 Agent Skills spec 感兴趣、想自己写技能包的技术人。我会从技能包的结构讲起，一路讲到怎么把它接进你的工作流，中间穿插我自己踩过的坑。

2. Agent Skills spec 的骨架：一个技能包到底由什么组成

2.1 技能不是提示词，是带元数据的可发现单元

很多人第一次接触 Agent Skills，会把它理解成"一段比较长的提示词"。这个理解偏差会导致后面所有的设计都跑偏。技能和提示词最本质的区别在于：技能是可被发现的、有边界的、带触发条件的。

在 Agent Skills spec 里，一个技能通常以目录形式存在，核心是一个SKILL.md文件，头部用 YAML frontmatter 声明元数据，正文才是具体的指令内容。元数据里最关键的两个字段是name和description——前者是技能的唯一标识，后者是 Agent 判断"当前任务要不要加载这个技能"的依据。

--- name: faqpage-structured-data description: 为独立站页面生成符合规范的 FAQPage 结构化数据，适用于产品页、帮助中心、博客问答区。当用户提到 FAQ、结构化数据、富媒体摘要、schema 标记时使用。 ---

注意description的写法：它不是给人看的简介，而是给 Agent 做语义匹配的"触发语料"。所以里面要自然包含用户可能说出的关键词——"FAQ""结构化数据""富媒体摘要""schema"，这些词决定了技能能不能被正确唤起。我见过太多人把 description 写成"这是一个用于生成 FAQ 结构化数据的技能"，结果 Agent 在用户说"帮我加个 schema 标记"的时候完全没反应，因为描述里没有"schema"这个词。

2.2 渐进式披露：为什么技能要分层加载

Agent Skills spec 里有一个我认为最聪明的设计——渐进式披露（progressive disclosure）。它的意思是：技能内容不是一次性全部塞进上下文，而是分三层按需加载。

第一层是元数据（name + description），永远常驻，体量极小，让 Agent 知道"有这么个技能存在"。第二层是SKILL.md的正文，只有当 Agent 判断需要用到这个技能时才加载。第三层是技能目录下的附加资源——参考文档、模板文件、脚本，只有在正文指令明确要求时才进一步读取。

这个设计解决了一个非常现实的问题：上下文窗口是稀缺资源。如果你有二十个营销技能，每个正文两千字，全量加载就是四万字，还没开始干活上下文就满了。渐进式披露让常驻成本降到几百字，真正用到的技能才展开，用完就释放。

提示：写技能时，正文里不要把所有细节都铺开。把"什么时候用、核心步骤是什么"放在SKILL.md，把"完整字段对照表、边界案例、历史踩坑记录"放到同目录的reference.md里，正文用一句话指向它。这样既保证 Agent 需要时能查到，又不占用默认上下文。

2.3 技能目录的典型结构

一个规范的营销技能包，目录结构大致是这样：

marketingskills/ ├── faqpage-structured-data/ │ ├── SKILL.md │ ├── reference.md │ └── templates/ │ └── faqpage.json ├── seo-content-audit/ │ ├── SKILL.md │ └── checklist.md ├── keyword-clustering/ │ ├── SKILL.md │ └── scripts/ │ └── cluster.py └── meta-description-writer/ └── SKILL.md

每个技能一个目录，互不干扰。SKILL.md是入口，reference.md放深度资料，templates/放可复用的模板，scripts/放需要执行的脚本。这种结构的价值在于可维护性——你要改 FAQPage 的字段规则，只动faqpage-structured-data/这一个目录，不会牵连其他技能。

3. 把营销工作拆成技能：哪些活值得封装，哪些不值得

3.1 判断标准：高频、有规则、易出错

不是所有营销工作都适合做成技能。我总结了一个简单的三问判断法：

按这个标准，marketingskills里最值得封装的几类活是：FAQPage 结构化数据生成、Meta Description 批量撰写、SEO 内容审计、关键词聚类、内链建议。这几类的共同点是——规则清晰、重复度高、细节容易错。

反过来，像"品牌定位""年度营销策略"这种高度依赖业务理解和创意判断的活，封装成技能反而会限制 Agent 的发挥。技能应该处理"确定性工作"，把人的精力释放到"不确定性工作"上。

3.2 FAQPage 结构化数据：一个典型的"规则明确但易错"场景

拿 FAQPage 举例。它的 JSON-LD 结构其实不复杂：

{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "独立站谷歌 SEO 需要多久见效？", "acceptedAnswer": { "@type": "Answer", "text": "通常新站需要 3 到 6 个月才能看到稳定排名，具体取决于竞争度和内容质量。" } } ] }

但实际写的时候，坑非常多。mainEntity必须是数组，每个元素是Question类型；acceptedAnswer里必须是Answer类型，text字段不能为空；问题文本要和页面上可见的 FAQ 内容一致，否则会被判定为作弊。这些规则写进技能后，Agent 每次生成都会自动校验，比人肉检查靠谱得多。

我在技能正文里加了一条硬性约束：生成后必须逐条核对问题文本与页面可见文本的一致性。这条约束来自一次真实教训——有个页面结构化数据里的问题和页面上显示的问题差了一个标点，结果富媒体摘要一直不显示，排查了两天才发现。

3.3 关键词聚类：需要脚本配合的技能

有些营销技能光靠指令不够，需要跑脚本。关键词聚类就是典型。你给 Agent 一堆关键词，让它按搜索意图分组，纯靠语言模型判断会有偏差，尤其是关键词量大（几百上千个）的时候。

我的做法是在技能目录下放一个cluster.py，用简单的文本相似度做初筛，把结果交给 Agent 做语义归类和命名。技能正文里写清楚调用方式：

python scripts/cluster.py --input keywords.txt --output clusters.json --threshold 0.75

threshold这个参数控制聚类粒度，0.75 是我实测下来比较平衡的值——太低会把不相关的词并到一起，太高则分得太碎。这个数值不是拍脑袋定的，是拿几百个真实关键词跑出来的经验值。

注意：脚本类技能一定要在正文里说明"脚本输出是初稿，需要 Agent 二次判断"。否则 Agent 可能直接把脚本结果当最终答案，把明显不合理的聚类也照单全收。

4. 接入 Claude Code 的实操路径：从安装到技能生效

4.1 环境准备中最容易被忽略的一步

Claude Code 的安装本身不复杂，但有一个环节经常被跳过——确认技能目录的加载路径。Claude Code 默认会从特定位置读取技能，如果你把marketingskills放在别的地方，Agent 是发现不了的。

我的建议是：先跑一次claude进入交互模式，用/skills之类的命令（具体命令随版本变化，以官方文档为准）确认当前已加载的技能列表。如果列表是空的，说明路径没配对。这时候不要急着改配置，先确认你的 Claude Code 版本是否支持 Skills 功能——早期版本是没有这个能力的。

另一个容易忽略的点是文件权限。技能目录下的脚本需要可执行权限，否则 Agent 调用时会报错。在 Linux 或 macOS 上：

chmod +x marketingskills/*/scripts/*.py

这个命令我建议直接写进部署脚本，省得每次手动改。

4.2 技能生效的验证方法

技能配好之后，怎么确认它真的生效了？不要靠"感觉"，要用可复现的测试。

我的验证流程是三步：

1. 触发测试：输入一句包含技能关键词的话，比如"帮我给这个产品页加 FAQ 结构化数据"，看 Agent 是否加载了对应技能。如果没加载，回去改description。
2. 输出测试：给一个具体的页面内容，看生成的 JSON-LD 是否符合规范。重点检查嵌套层级和必填字段。
3. 边界测试：给一个"没有 FAQ 内容"的页面，看 Agent 是否会拒绝生成，而不是硬编造问题。

第三步最容易被忽略，但恰恰最重要。一个合格的技能应该知道什么时候不该用。如果 Agent 对着一个没有任何问答内容的页面硬生成 FAQPage，那这个技能就是有害的。

4.3 本地模型接入时的技能兼容性

有些团队出于成本或数据考虑，会用本地模型驱动 Claude Code。这时候要注意：不是所有模型都能正确处理 Agent Skills。技能机制依赖模型对工具调用和结构化指令的理解能力，能力弱的模型可能加载了技能但执行不到位。

我实测下来的经验是：本地模型跑技能时，把SKILL.md的指令写得更"笨"一点——步骤拆得更细，少用"酌情""视情况"这类模糊表述，多用"第一步做 X，第二步做 Y"的硬指令。这样即使模型推理能力一般，也能按部就班执行。

另外，本地模型的上下文窗口通常比云端小，渐进式披露的价值就更大了。技能正文要尽量精简，把细节推到reference.md，避免一次性占满窗口。

5. 写一个能用的营销技能：以 Meta Description 批量生成为例

5.1 先想清楚输入输出，再动笔写指令

写技能最容易犯的错是"上来就写指令"。正确的顺序是：先定义清楚这个技能的输入是什么、输出是什么、边界在哪。

以 Meta Description 生成为例：

• 输入：页面标题、页面核心内容摘要、目标关键词、字数限制（通常 150-160 字符）
• 输出：符合字数要求、包含目标关键词、有行动号召的 meta description
• 边界：不编造页面没有的内容；关键词不堆砌；不生成超过字数限制的版本

把这三点想清楚，SKILL.md的正文就水到渠成了。

5.2 指令要包含"反例"，而不只是"正例"

大多数人写技能只写"应该怎么做"，但真正让技能稳定的是"不要怎么做"。我在 Meta Description 技能里专门加了一段反例说明：

不要生成以下类型的描述： - 纯关键词堆砌："SEO, 独立站, 谷歌优化, 排名提升" - 空洞承诺："最好的服务，值得信赖" - 超过 160 字符的版本 - 与页面实际内容不符的描述

反例的价值在于划定负面空间。语言模型在没有明确禁止的情况下，很容易滑向"看起来像那么回事但实际没用"的输出。把反例写清楚，等于给 Agent 装了一道护栏。

5.3 用模板降低输出波动

批量生成类技能，输出格式的稳定性比内容质量还重要。如果每次生成的格式都不一样，后续处理会很痛苦。解决办法是在技能目录下放一个模板文件，正文里要求 Agent 严格按模板输出。

## 输出格式 每条描述按以下格式输出，不要添加额外说明： 页面标题 | Meta Description | 字符数

这个简单的表格格式，让输出可以直接复制进 Excel 做后续处理。字符数这一列是刻意加的——让 Agent 自己数一遍，比事后人工核对高效得多。

6. 技能包维护中的真实坑：我踩过的几个

6.1 description 写得太"文雅"，技能唤不起来

前面提过 description 要包含关键词，但具体多"直白"才够？我的经验是：把用户可能说的原话直接写进去。不要写"用于优化搜索引擎表现"，要写"当用户提到 SEO、排名、搜索优化、谷歌收录时使用"。

我有个技能一开始 description 写的是"协助内容营销人员提升内容质量"，结果用户说"帮我审一下这篇文章的 SEO"时完全没触发。改成"当用户提到内容审计、SEO 检查、文章优化、关键词密度时使用"之后，触发率立刻上来了。

6.2 技能之间职责重叠，Agent 不知道该用哪个

当你技能多了之后，会出现"两个技能都能处理当前任务"的情况。比如"SEO 内容审计"和"内容质量检查"如果有重叠，Agent 可能随机选一个，导致输出不稳定。

解决办法是在 description 里明确划清边界。比如 SEO 审计技能写"专注于关键词布局、标题标签、结构化数据"，内容质量技能写"专注于可读性、逻辑连贯性、事实准确性"。边界清晰了，Agent 的选择就稳定了。

6.3 技能更新后没有版本管理，改坏了回不去

技能包是要持续迭代的。今天加一条规则，明天改一个字段，改着改着就乱了。我的做法是用 Git 管理技能包，每次改动都提交，commit message 写清楚改了什么、为什么改。

feat(faqpage): 增加问题文本一致性校验规则 fix(meta-desc): 修正字符数统计包含空格的问题

这样出问题能快速回滚，也能追溯某条规则是什么时候、为什么加进去的。技能包不是一次性写完就扔那儿的，它更像一份活的文档，需要持续维护。

6.4 忽略技能的"失败模式"

每个技能都应该有明确的失败处理方式。比如 FAQPage 技能遇到"页面没有问答内容"时，应该输出"当前页面无 FAQ 内容，不建议生成结构化数据"，而不是硬编。这个失败模式要写进技能正文，否则 Agent 会倾向于"完成任务"而不是"正确完成任务"。

我在技能里加了一段：

如果输入内容中不包含明确的问答对，停止生成并提示用户： "未检测到问答内容，FAQPage 结构化数据需要页面上有真实可见的问答。"

这条规则救过我好几次，避免了生成无效结构化数据被搜索引擎判定为作弊。

7. 从单点技能到技能体系：下一步可以怎么走

单个技能解决单点问题，但真正的效率提升来自技能之间的协作。比如一个完整的独立站页面优化流程，可能涉及：关键词聚类 → 内容生成 → Meta Description 撰写 → FAQPage 结构化数据 → 内链建议。如果这五个技能能串起来，Agent 就能处理"优化这个页面"这样的高层指令，而不是你一步步手动调用。

实现协作的关键是技能之间的输入输出要能对接。关键词聚类的输出格式，要能被内容生成技能直接读取；内容生成的输出，要能被 Meta Description 技能消费。这要求你在设计每个技能时，不仅考虑它自己，还要考虑它在整个流程里的位置。

我目前的做法是定义一个统一的中间格式，所有技能都围绕这个格式读写。这样新增技能时，只要它遵循这个格式，就能无缝接入现有流程。这套东西还在打磨，但方向是明确的——技能包的价值不在于单个技能多强，而在于它们能不能组合成一个可复用的工作流。

最后分享一个我自己的习惯：每写完一个技能，我会故意用"最笨的方式"测一遍——把技能描述念给一个不了解背景的同事听，问他"你觉得这个技能是干嘛的、什么时候会用"。如果他说不清楚，说明 description 还没写到位。这个土办法比任何自动化测试都管用。