企业官网建设流程全解析

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

第一次看到marketingskills这个名字，我的直觉是：这大概率是一个把营销领域里那些高频、重复、有固定套路的活儿，封装成 AI Agent 可以直接调用的"技能包"。事实也确实如此。它不是一个 SaaS 产品，也不是一个营销自动化平台，而是一套面向Claude Code这类 AI 编程代理的Agent Skills规范实现——用结构化的目录、说明文件和脚本，把"做 SEO 审计""写落地页文案""生成 FAQ 结构化数据""分析关键词"这类任务，变成 AI 可以稳定复现的工作流。

这件事的价值在哪？我举个自己踩过的坑。早两年我用大模型做 SEO 内容，每次都要在对话里重新解释一遍"标题要控制在多少字符""meta description 怎么写""FAQ schema 的字段有哪些"。模型每次给的格式都不一样，有时候 JSON-LD 里少个@context，有时候acceptedAnswer写成了answer。你没法把它接进流水线，因为输出不稳定。Agent Skills 这套东西的核心思路，就是把这些"隐性知识"从你的脑子里、从每次的对话里，搬到文件系统里，变成模型每次都能读到的显式规范。

所以marketingskills适合谁？三类人最该关注：一是做独立站、需要持续产出 SEO 内容的运营；二是想把营销流程自动化的开发者；三是已经在用 Claude Code 或类似 AI Agent 工具、但觉得"每次都要重复交代背景"很烦的从业者。它解决的不是"AI 会不会写文案"的问题，而是"AI 能不能按你的标准、稳定地、批量地写文案"的问题。这两者之间差着一整个工程化的距离。

下面我会从仓库结构、技能设计逻辑、和 Claude Code 的配合方式、SEO 场景的落地细节，以及我自己实测中遇到的坑，一层层拆开讲。你不需要是程序员，但需要有一点"把任务拆成步骤"的思维习惯。

2. Agent Skills 规范下，一个"技能"到底长什么样

2.1 为什么是文件夹，而不是一段提示词

很多人第一反应是：不就是提示词吗，我写个 system prompt 不就行了？我一开始也这么想，直到我把一个 3000 字的 SEO 提示词塞进对话，发现模型在第 5 轮之后就开始"遗忘"细节。提示词是易失的，它活在上下文窗口里，会被后续对话稀释。而 Agent Skills 的做法是把技能落成磁盘上的文件夹，模型在需要的时候主动去读。这个区别很关键：前者是"你喂给它"，后者是"它自己去拿"。

一个符合 Agent Skills 规范的技能，通常长这样：

marketingskills/ seo-audit/ SKILL.md scripts/ check_meta.py references/ schema-faq.md landing-page-copy/ SKILL.md templates/ hero-section.md

核心是那个SKILL.md。它一般包含三部分：元信息（技能叫什么、什么时候该用）、操作指令（具体怎么做）、资源引用（需要哪些脚本或参考文件）。模型读到这个文件，就知道"哦，遇到 SEO 审计的活儿，我该走这套流程"。

2.2 SKILL.md 里的元信息为什么决定成败

我见过太多人把 SKILL.md 写成一篇教程，结果模型根本不知道什么时候该调用它。元信息里的description字段，本质上是给模型看的"触发条件"。写得含糊，比如"用于营销相关工作"，模型就懵了——写文案算不算？发邮件算不算？写得精准，比如"当用户需要对一个网页进行 SEO 审计，检查 title、meta description、heading 结构和结构化数据时使用"，模型就能准确命中。

这里有个我实测出来的经验：description 里要包含"触发词"和"排除词"。比如 SEO 审计这个技能，触发词是"SEO 审计""页面优化""meta 检查"，排除词可以写"不适用于关键词研究，那属于另一个技能"。这样能大幅降低技能之间的误触发。我在一个项目里同时放了 6 个营销技能，没写排除词的时候，模型经常把"写 FAQ"的活儿派给"写落地页"的技能，加了排除词之后准确率肉眼可见地提升。

2.3 脚本和参考文件的分工逻辑

scripts/目录放的是确定性任务。什么叫确定性？就是"输入 A 必然得到 B"的活儿。比如检查一个 HTML 文件里有没有 canonical 标签、统计 title 的字符数、验证 JSON-LD 是否合法。这些用 Python 脚本做，比让模型"心算"靠谱一万倍。模型擅长的是判断和生成，不擅长精确计算和格式校验，把这两类活儿分开，是整个技能设计的精髓。

references/目录放的是知识性内容。比如 FAQ 结构化数据的字段规范、不同搜索引擎对 meta description 长度的偏好、Schema.org 的常用类型清单。这些内容不需要模型"执行"，只需要它"查阅"。把它们单独放文件里，而不是塞进 SKILL.md 正文，好处是 SKILL.md 保持精简，模型读起来不费劲，需要细节时再去读参考文件。

提示：SKILL.md 正文建议控制在 500 行以内。超过这个长度，模型读取时容易抓不住重点。把细节外移到 references，是保持技能可维护的关键。

3. 把营销任务翻译成技能：拆解的颗粒度怎么定

3.1 颗粒度太粗和太细都会翻车

这是我在实际搭建营销技能库时纠结最久的问题。一个"SEO 内容生产"技能，听起来很完整，但它其实包含了关键词研究、大纲生成、正文撰写、meta 优化、结构化数据、内链规划至少六个子任务。如果全塞进一个技能，SKILL.md 会变成一本手册，模型执行时容易顾此失彼。反过来，如果拆成"写 title""写 meta""写 H1"这种粒度，技能数量爆炸，模型在调度时会陷入选择困难。

我的经验法则是：一个技能对应一个"可独立交付的产物"。SEO 审计的产物是一份审计报告，那它就是一个技能。落地页文案的产物是一整套页面文案，那它是另一个技能。FAQ 结构化数据的产物是一段 JSON-LD，那它单独成一个技能。判断标准很简单——如果这个任务的输出能直接交给下一个人（或下一个环节）用，它就是一个合格的技能边界。

3.2 用"输入-处理-输出"三段式定义技能

我习惯用这个框架来设计每个技能，写进 SKILL.md 的正文：

这个表格看起来简单，但它逼你把模糊的"帮我优化一下 SEO"变成可执行的流程。我见过的最大的坑，就是技能里只写了"检查页面的 SEO 问题"，没写检查哪些项、按什么标准、输出什么格式。结果模型每次检查的维度都不一样，有时候查了图片 alt，有时候忘了查。

3.3 技能之间的依赖关系要显式声明

营销任务很少是孤立的。关键词研究的结果要喂给内容撰写，内容撰写的结果要喂给结构化数据生成。如果技能之间没有显式的依赖声明，模型就不知道"先做哪个、后做哪个"。我的做法是在 SKILL.md 里加一段"前置条件"和"后续技能"的说明。比如 FAQ 结构化数据技能的前置条件是"已有 FAQ 问答内容"，后续技能是"页面部署检查"。这样模型在调度时就有了拓扑顺序，不会出现"还没写内容就先生成 schema"的荒唐情况。

4. 和 Claude Code 配合：技能是怎么被"调用"起来的

4.1 Claude Code 读取技能的机制

Claude Code 这类工具的工作方式是：它在项目目录里扫描，发现符合规范的技能文件夹，读取 SKILL.md 的元信息，建立一个"技能索引"。当你提出一个需求，它先匹配索引，找到最合适的技能，然后读取该技能的完整指令和资源，再执行。这个过程是按需加载的——不是一上来把所有技能都读进上下文，而是用到哪个读哪个。这也是为什么技能可以有很多个，但不会撑爆上下文窗口。

理解这一点很重要，因为它决定了你的技能库该怎么组织。如果你把所有技能都堆在一个大文件里，就失去了按需加载的优势。正确的做法是每个技能独立成目录，元信息写清楚，让索引能准确匹配。

4.2 本地模型接入时的注意事项

热词里提到用 LM Studio 跑本地模型、通过第三方 API 接入其他模型，这块我实测过。核心结论是：技能规范是通用的，但模型能力决定了技能能跑多复杂。Agent Skills 这套东西本质上是"给模型看的说明书"，说明书本身不挑模型，但一个需要多步推理、调用脚本、读取多个参考文件的复杂技能，小参数量的本地模型可能执行到一半就"跑偏"了。

我的建议是分档：简单的格式校验、模板填充类技能，本地小模型完全够用；涉及多步判断、需要综合多个参考文件的技能，还是用能力更强的模型。另外，本地模型对 SKILL.md 里指令的遵循度，往往不如大模型稳定，所以给本地模型用的技能，指令要写得更"死"——少用"酌情""视情况而定"这种模糊表述，多用"必须""如果 X 则 Y"这种确定性语言。

4.3 在 VS Code 里调试技能的实用姿势

我大部分时间是在 VS Code 里调试这些技能的。几个实测好用的习惯：第一，把技能目录放在工作区根目录下，这样 Claude Code 扫描时不会漏掉；第二，改完 SKILL.md 后，新开一个对话测试，因为旧对话里模型可能还记着旧版本的指令；第三，用简单的测试用例先跑通流程，比如给一个只有 title 和 meta 的极简 HTML，看技能能不能正确识别问题，再上真实页面。

注意：技能文件改动后，如果发现模型行为没变化，八成是缓存或旧上下文的问题。新开对话是最省事的排查手段，别在旧对话里反复追问"你为什么没按新规则来"。

5. SEO 场景深挖：FAQ 结构化数据这个技能该怎么写

5.1 为什么 FAQ schema 值得单独做成一个技能

热词里"谷歌 SEO 的 FAQPage 结构化数据"出现频率很高，说明这是很多人的痛点。FAQPage 结构化数据的坑在于：它有一套严格的字段规范，@type必须是FAQPage，mainEntity是个数组，每个元素是Question，里面又有acceptedAnswer，acceptedAnswer里还有@type: Answer和text。少一层、错一个字段名，搜索引擎就不认。这种"格式严格、内容灵活"的任务，正是技能化的最佳场景——格式部分用脚本校验，内容部分让模型生成。

5.2 技能里的校验脚本怎么写

我在技能里放了一个 Python 脚本，专门做 JSON-LD 的合法性校验。核心逻辑是：解析 JSON、检查必需的@context和@type、递归验证mainEntity数组里每个 Question 的结构、检查acceptedAnswer.text是否为空。这个脚本不负责"内容好不好"，只负责"格式对不对"。模型生成完 JSON-LD 后，调用脚本跑一遍，不通过就让它改。这个"生成-校验-修正"的闭环，是保证输出质量的关键。

import json def validate_faq_schema(data): errors = [] if data.get("@context") != "https://schema.org": errors.append("@context 必须是 https://schema.org") if data.get("@type") != "FAQPage": errors.append("@type 必须是 FAQPage") entities = data.get("mainEntity", []) if not isinstance(entities, list) or not entities: errors.append("mainEntity 必须是非空数组") for i, q in enumerate(entities): if q.get("@type") != "Question": errors.append(f"第{i}项 @type 必须是 Question") if not q.get("name"): errors.append(f"第{i}项缺少 name 字段") ans = q.get("acceptedAnswer", {}) if ans.get("@type") != "Answer": errors.append(f"第{i}项 acceptedAnswer 的 @type 必须是 Answer") if not ans.get("text"): errors.append(f"第{i}项 acceptedAnswer 缺少 text") return errors

这段代码不长，但它把最容易出错的几个点全兜住了。我实测下来，加了校验脚本之后，FAQ schema 的一次通过率从大概六成提到了九成以上。

5.3 内容生成部分的分寸把握

格式交给脚本，内容交给模型，但内容也不是随便生成。我在 SKILL.md 里明确写了几条约束：FAQ 的问题必须是用户真实会搜的问句，答案控制在 40 到 60 字，答案里要自然包含目标关键词但不要堆砌，每个答案要能独立成立（不依赖上下文）。这几条约束来自我对搜索引擎偏好的观察——太长的答案在富媒体展示时会被截断，太短的又显得信息量不足。

还有一个容易被忽略的点：FAQ 内容要和页面正文一致。我见过有人为了做 schema 单独编了一套问答，和页面正文对不上，这种"结构化数据和可见内容不一致"是明确违反规范的，轻则不展示，重则被判定为作弊。所以技能里要加一条指令：生成 FAQ 前先读取页面正文，确保问答内容源于正文。

6. 实测中踩过的坑和排查链路

6.1 技能不触发：从索引到描述的逐层排查

最让人抓狂的问题是"我明明写了技能，模型就是不用"。我的排查链路是这样的：第一步，确认技能目录结构对不对，SKILL.md 是不是在正确的位置，文件名大小写有没有问题（有些系统大小写敏感）；第二步，看元信息里的 description 是不是太模糊，模型匹配不上；第三步，看是不是有另一个技能的 description 更"抢眼"，导致误匹配；第四步，新开对话排除上下文干扰。这四步走下来，九成的"不触发"问题都能定位。

我印象最深的一次，是技能死活不触发，查了半天发现是 SKILL.md 的元信息用了 YAML 格式，但我缩进用了 Tab 而不是空格，解析直接失败了。这种低级错误在排查时最容易被忽略，因为文件"看起来"是对的。

6.2 技能触发了但执行跑偏：指令歧义的识别

另一个高频问题是技能被调用了，但执行结果不对。这通常是 SKILL.md 里的指令有歧义。比如我写过一句"检查页面的标题"，模型理解成检查 H1，而我本意是检查<title>标签。后来我改成"检查 HTML<head>中的<title>标签内容"，歧义就消失了。指令里凡是可能有两种理解的词，都要用具体的技术名词替换。这个教训我吃了不止一次。

6.3 脚本调用失败：路径和环境问题

技能里的脚本调用失败，八成是路径问题。模型执行脚本时，工作目录可能和你预期的不一样。我的做法是在 SKILL.md 里明确写脚本的相对路径，并且在脚本开头用os.path.dirname(__file__)来定位资源文件，而不是依赖当前工作目录。另外，脚本依赖的第三方库要在技能文档里写清楚，别让模型去猜。我有个技能用了beautifulsoup4解析 HTML，没在文档里写，换台机器跑就报ModuleNotFoundError，排查了半天。

7. 把技能库当成产品来维护的几个习惯

7.1 版本管理和变更记录

技能库一旦超过五个技能，就需要版本管理了。我用 Git 管理整个marketingskills目录，每次改 SKILL.md 都写清楚改了什么、为什么改。这不是形式主义——当你发现某个技能突然不好用了，能快速定位是哪次改动引入的问题。我还会在技能目录里放一个CHANGELOG.md，记录这个技能的演进，尤其是那些"踩坑后修正"的条目，下次遇到类似问题能直接翻记录。

7.2 用真实任务做回归测试

技能改完之后，别只看它"能不能跑"，要拿真实任务测。我维护了一组测试用例：一个结构完整的页面、一个缺 meta 的页面、一个 schema 写错的页面。每次改动技能，都拿这组用例跑一遍，看输出有没有退化。这个习惯帮我避免了好几次"修了一个 bug 引入两个新 bug"的情况。回归测试不需要多复杂，几个代表性的输入加预期输出就够了。

7.3 技能文档要写给"未来的自己"看

最后说个心态问题。写 SKILL.md 的时候，别想着"模型能看懂就行"，要想着"三个月后的我还能不能看懂"。模型是执行者，但维护者是你。指令写得清楚，不仅模型执行得准，你回头改的时候也省事。我现在的习惯是，每个技能开头写一段"这个技能解决什么问题、不解决什么问题"，中间写清楚步骤和判断标准，结尾写"已知限制"。这三段下来，技能的可维护性会好很多。

营销这件事，本质上是一堆"有套路但需要判断"的任务的集合。Agent Skills 的价值，就是把这堆任务里"套路"的部分固化下来，让 AI 稳定执行，把人的精力留给真正需要判断的部分。marketingskills这个方向，我觉得才刚刚开始，后面值得深挖的东西还有很多，比如技能之间的编排、多技能协作完成一个完整营销活动、技能效果的量化评估。这些我还在摸索，有新的心得再聊。