企业官网建设流程全解析

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

第一次看到marketingskills这个项目名，我的直觉是：这大概率不是一个单纯的营销工具，而是一套围绕 AI Agent 能力扩展的“技能包”集合。把标题拆开看，marketing指向的是营销场景，skills则直接对应了当下 AI 编程助手生态里最热的一个概念——Agent Skills。合在一起，它想做的事情就很清楚了：把营销工作中那些高频、重复、有固定套路的任务，封装成 AI Agent 可以直接调用的技能模块，让 Claude Code、Cursor、Codex 这类工具在营销场景下真正能干活，而不是只会聊天。

这个判断不是凭空来的。最近一段时间，Claude Code 的 Agent Skills 规范逐渐被更多工具接受，Cursor、OpenAI Codex 也在往类似方向靠。所谓 Skill，本质上就是一份结构化的指令文件，通常是一个SKILL.md，里面写清楚这个技能叫什么、什么时候触发、执行步骤是什么、需要哪些工具配合。Agent 在运行时读取这些文件，就能在特定场景下自动加载对应的能力。marketingskills要做的，就是把这套机制落到营销这个垂直领域里。

那它具体能干什么？我理解至少覆盖这几类：内容选题与大纲生成、竞品文案拆解、落地页结构诊断、SEO 关键词聚类、社媒多平台改写、邮件序列编排、广告投放素材批量生成。这些任务的共同点是——有明确的输入输出、有可复用的方法论、有相对固定的质量评判标准。正好符合 Skill 封装的三个前提。

适合谁来参考？三类人最直接受益。第一类是独立开发者或小团队，没有专职营销，想让 AI 帮忙把营销动作跑起来；第二类是营销从业者，想把自己的经验沉淀成可复用的自动化流程；第三类是 AI 工具的重度用户，已经在用 Claude Code 或 Cursor 写代码，想把这套能力延伸到非编码场景。哪怕你只是刚装好 Claude Code 的新手，只要理解了 Skill 的组织方式，也能照着搭出自己的第一套营销技能包。

2. 为什么是 Agent Skills，而不是写一堆提示词

2.1 提示词堆叠的三个死穴

很多人第一反应是：营销任务嘛，写几个提示词不就行了，为什么要搞一套 Skill 体系？我一开始也这么想，直到实际用下来发现提示词方案有三个绕不过去的坑。

第一个坑是上下文漂移。你在一个对话里塞了选题、改写、SEO 三套提示词，聊到第十轮的时候，模型已经开始混淆哪条规则属于哪个任务。尤其是营销场景里经常要“先分析再生成再优化”，多轮下来提示词之间的边界会糊掉。

第二个坑是复用成本高。你写好一套很满意的落地页诊断提示词，下次换个项目想用，得手动复制粘贴，还得重新调整变量。时间一长，你的提示词散落在各种笔记、聊天记录、文档里，根本管不过来。

第三个坑是无法组合。真实的营销工作流往往是“选题 → 大纲 → 初稿 → SEO 优化 → 多平台改写”，每一步都依赖上一步的输出。纯提示词方案里，这个链条要么靠人手动串，要么写一个巨大的提示词把五步全塞进去，结果就是模型顾此失彼。

2.2 Skill 机制带来的结构性改变

Agent Skills 的价值就在于它把“提示词”升级成了“可加载的能力单元”。每个 Skill 是一个独立目录，里面有SKILL.md定义元信息和执行逻辑，还可以带辅助文件——模板、示例、参考数据、脚本。Agent 在运行时根据当前任务判断该加载哪个 Skill，加载完执行，执行完卸载，上下文干净。

这个机制解决了上面三个问题。上下文漂移没了，因为每个 Skill 独立加载；复用成本低了，因为 Skill 就是文件，复制目录即可；组合能力有了，因为你可以让 Agent 依次调用多个 Skill，前一个的输出作为后一个的输入。

更关键的是，Skill 支持渐进式披露。SKILL.md里只放最核心的指令，详细的参考资料放在同目录的其他文件里，Agent 需要时才去读。这对营销场景特别友好——比如一个“品牌语调”Skill，主文件写规则，附带一个tone-examples.md放几十条真实文案样例，Agent 只在需要对齐语调时才加载样例文件，平时不占上下文。

2.3 跨工具兼容的现实考量

marketingskills这类项目还有一个隐含价值：它天然要考虑跨工具兼容。Claude Code 有自己的 Skill 规范，Cursor 通过 rules 和 commands 实现类似效果，Codex 也在演进。如果你把营销能力写成相对通用的 Markdown 结构，再针对不同工具做适配层，就能一套内容多处使用。

我实测下来的做法是：核心逻辑写在SKILL.md里，保持工具无关；然后为 Claude Code 准备.claude/skills/目录结构，为 Cursor 准备.cursor/rules/的映射，为 Codex 准备对应的配置。这样同一套营销技能，换个工具不用重写。

注意：不同工具对 Skill 的触发机制差异很大。Claude Code 更依赖 description 字段的语义匹配，Cursor 的 rules 更偏向文件路径和 glob 匹配。写 description 时要同时兼顾“语义清晰”和“关键词覆盖”，否则在某些工具里可能触发不了。

3. marketingskills 的核心技能拆解与设计思路

3.1 技能颗粒度怎么切

设计一套营销 Skill，最先要决策的是颗粒度。切太细，Agent 要调用七八个 Skill 才能完成一个任务，中间容易断链；切太粗，一个 Skill 塞太多职责，又退回到“巨型提示词”的老路。

我的经验是按“可独立交付的营销产物”来切。一个 Skill 对应一种明确的输出物，比如“一份内容大纲”“一组 SEO 关键词”“一版落地页文案”“一套邮件序列”。这样每个 Skill 的输入输出边界清晰，也方便组合。

按这个原则，marketingskills大致可以拆成这么几类：

这张表不是让你一次全做完，而是给你一个切分参考。实际搭建时，先做你最高频的那两三个，跑顺了再扩。

3.2 一个 Skill 的内部结构长什么样

拿landing-page-copy举例，一个完整的 Skill 目录大概是这样：

landing-page-copy/ ├── SKILL.md ├── frameworks/ │ ├── pas.md │ └── aida.md ├── examples/ │ └── saas-landing.md └── checklist.md

SKILL.md是入口，内容大致分四块：元信息（name、description、触发条件）、执行流程（分步骤）、输出格式（模板）、质量校验（checklist 引用）。frameworks/放不同的文案框架，Agent 根据产品类型选择 PAS 还是 AIDA。examples/放真实案例供参考。checklist.md是自检清单，Agent 生成完文案后逐条核对。

这种结构的妙处在于主文件保持精简。SKILL.md可能只有 150 行，但整个 Skill 的实际知识量是它的好几倍，需要时才展开。这直接对应了前面说的渐进式披露。

3.3 description 字段的写法决定触发率

这是最容易被忽视、但影响最大的细节。Agent 判断要不要加载某个 Skill，主要看description。写得太泛，比如“帮助写营销文案”，会跟其他 Skill 抢触发；写得太窄，又可能该触发时不触发。

我的写法是**“场景 + 动作 + 产物”三段式**。比如：

description: 当用户需要为产品落地页生成文案，或要求优化现有落地页的转化率时使用。适用于 SaaS、电商、课程等需要结构化销售页面的场景。输出包含标题、副标题、痛点、方案、社会证明、CTA 的完整模块。

这段话里，“当用户需要……”定义了触发场景，“适用于……”限定了适用范围，“输出包含……”明确了产物。三个信息缺一不可。我试过只写前两段，结果 Agent 经常在只需要改一个标题的时候也把整个 Skill 加载进来，浪费上下文。

实操心得：description 里最好包含用户可能说的原话关键词。比如用户会说“帮我写个卖货页面”“落地页转化不行”，这些口语化表达要能匹配上。我一般会列 3-5 个同义触发短语。

4. 从零搭建一套营销 Skill 的完整实操

4.1 环境准备与目录规划

不管你用 Claude Code、Cursor 还是 Codex，第一步都是把目录结构定下来。我推荐的项目结构：

marketing-agent/ ├── .claude/ │ └── skills/ │ ├── topic-ideation/ │ ├── outline-builder/ │ └── landing-page-copy/ ├── .cursor/ │ └── rules/ ├── shared/ │ ├── brand-voice.md │ └── audience-profiles.md └── README.md

.claude/skills/放 Claude Code 用的 Skill，.cursor/rules/放 Cursor 的映射，shared/放跨 Skill 共享的品牌语调、受众画像等基础资料。这样组织的好处是：核心知识只维护一份，各工具通过引用或软链接复用。

如果你用的是 Claude Code，安装完成后在项目根目录执行claude进入交互，它会自动识别.claude/skills/下的内容。Cursor 则需要在设置里确认 rules 目录路径。Codex 的配置方式略有不同，通常通过项目级配置文件指定。

4.2 写第一个 Skill：以选题生成为例

topic-ideation是最适合入门的 Skill，因为逻辑简单、验证快。完整SKILL.md如下：

--- name: topic-ideation description: 当用户需要为内容营销生成选题，或要求基于行业、受众、目标产出文章/视频选题列表时使用。适用于博客、公众号、短视频脚本策划。输出为分组选题列表，每组包含选题、目标受众、核心角度、预估搜索意图。 --- # 选题生成技能 ## 执行流程 1. 确认三个输入：行业领域、目标受众、内容目标（拉新/转化/留存） 2. 若用户未提供，主动询问，不要假设 3. 读取 `shared/audience-profiles.md` 获取受众画像 4. 按以下四个维度各生成 3-5 个选题： - 痛点型：受众正在遭遇的具体问题 - 认知型：受众不知道但应该知道的事 - 对比型：A 方案 vs B 方案的决策参考 - 趋势型：行业近期变化带来的新话题 5. 每个选题标注：目标受众、核心角度、搜索意图（信息型/商业型/交易型） ## 输出格式 按维度分组，每组用表格呈现： | 选题 | 目标受众 | 核心角度 | 搜索意图 | |------|---------|---------|---------| ## 质量校验 - 选题是否具体到可以直接开写，而非泛泛而谈 - 是否覆盖了至少三个不同搜索意图 - 是否避免了与受众画像不符的话题

这个 Skill 大概 60 行，但已经能稳定产出可用的选题。关键在于流程里的“不要假设”和“四个维度”，前者防止 Agent 自作主张，后者保证选题的多样性。

4.3 参数与变量的处理技巧

营销 Skill 经常需要接收变量，比如品牌名、产品名、目标关键词。有两种处理方式：一种是在SKILL.md里用占位符，让 Agent 运行时替换；另一种是放在shared/目录的配置文件里，Skill 执行时读取。

我倾向后者，因为变量集中管理，改一处全生效。比如shared/brand-voice.md里写：

# 品牌语调 - 品牌名：{{BRAND_NAME}} - 语调：专业但不端着，允许适度口语化 - 禁用词：赋能、闭环、抓手、颗粒度 - 偏好表达：直接说结果，少用形容词 - 示例句：把“我们提供全方位的解决方案”改成“这件事我们帮你搞定”

Skill 里只需要写“读取 brand-voice.md 并对齐语调”，不用重复定义。这样换品牌时只改一个文件。

4.4 组合多个 Skill 跑通完整工作流

单个 Skill 跑通后，真正的价值在于组合。一个典型的内容生产工作流：

1. topic-ideation产出选题列表
2. 用户选定一个选题
3. outline-builder基于选题生成大纲
4. draft-writer按大纲写初稿
5. seo-optimizer做关键词密度和结构优化
6. social-rewriter改写成各平台版本

在 Claude Code 里，你可以直接说“用 topic-ideation 生成选题，我选第三个，然后走完整流程到 social-rewriter”。Agent 会依次加载对应 Skill。实测下来，六步走完大概 3-5 分钟，产出质量比单次大提示词稳定得多。

注意：组合流程时，每一步的输出要显式保存成文件，比如output/01-topics.md、output/02-outline.md。这样中途某一步不满意，可以只重跑那一步，不用从头来。我踩过的坑就是全在对话里传递，结果第三步不满意，前两步的上下文已经被挤掉了。

5. 跨工具适配：Claude Code、Cursor、Codex 怎么各取所需

5.1 Claude Code 的 Skill 加载机制

Claude Code 对 Skill 的支持最原生。把 Skill 放在.claude/skills/下，启动时它会扫描所有SKILL.md的 description，建立索引。当你的请求语义匹配某个 description 时，它会提示加载或自动加载。

这里有个细节：Claude Code 默认不会一次性加载所有 Skill 的完整内容，只加载 description。只有确定要用某个 Skill 时，才读取完整SKILL.md。这就是渐进式披露在工具层面的实现。所以你的 description 写得越准，加载越精准，上下文越省。

如果你在 VS Code 里用 Claude Code 插件，目录结构是一样的，插件会读取项目根目录的.claude/。Ubuntu 或 Mac 下配置没有本质区别，都是项目级目录优先。

5.2 Cursor 的 rules 映射方案

Cursor 没有 Skill 这个概念，但有 rules 和 commands。我的做法是把每个 Skill 映射成一条 rule，用 glob 或 description 触发。Cursor 的 rules 支持alwaysApply、autoAttached、agentRequested几种模式，营销 Skill 一般用agentRequested，让 Agent 自己判断。

具体操作是在.cursor/rules/下建对应的.mdc文件，内容基本复用SKILL.md，只是把 frontmatter 换成 Cursor 的格式。比如：

--- description: 生成营销选题列表 globs: alwaysApply: false --- （这里放 SKILL.md 的正文内容）

Cursor 的中文设置和界面汉化不影响 rules 的功能，只是显示语言变化。如果你习惯中文回复，可以在 Cursor 设置里把回复语言设为中文，Skill 内容本身不受影响。

5.3 Codex 与其他工具的兼容思路

Codex 的 Skill 机制还在演进，目前更依赖项目级配置和指令文件。思路是一样的：把核心逻辑写成工具无关的 Markdown，然后针对 Codex 做一层薄适配。如果你遇到missing optional dependency @openai/codex-win32-x64这类报错，通常是安装不完整，按提示重新安装对应平台的包即可，跟 Skill 内容无关。

跨工具适配的核心原则是：知识层与工具层分离。知识层是纯 Markdown，写清楚“做什么、怎么做、输出什么”；工具层是各平台的配置文件，只负责“怎么让 Agent 读到知识层”。这样换工具时，知识层不动，只改工具层。

6. 实操中踩过的坑与排查速查表

6.1 Skill 不触发或触发错误

这是最高频的问题。表现是你说“帮我写个落地页”，Agent 却去加载了topic-ideation。原因通常是 description 之间的语义重叠。排查步骤：

1. 把所有 Skill 的 description 列出来，看有没有两个都在描述“写内容”
2. 检查是否缺少明确的场景限定词
3. 在 description 里加入“不适用于……”的反向限定

我遇到过一次，landing-page-copy和social-rewriter都包含“文案”这个词，结果 Agent 经常搞混。后来在social-rewriter的 description 里加了“仅用于将已有长文改写为社媒短内容，不用于从零生成”，问题就解决了。

6.2 输出格式不稳定

Agent 有时输出表格，有时输出列表，有时又变成大段文字。根因是SKILL.md里的输出格式定义不够硬。解决办法是把格式模板写死，并加一句“严格按此格式输出，不要增删字段”。

如果还是不稳定，可以在 Skill 里加一个output-schema.md，用 JSON Schema 或明确的字段说明约束。实测下来，给出具体示例比抽象描述有效得多。

6.3 上下文被撑爆

组合多个 Skill 时，如果每个 Skill 都加载大量参考文件，上下文很快就不够用。对策是严格控制每个 Skill 的“常驻内容”体积。SKILL.md主文件控制在 200 行以内，大块参考资料一律放独立文件，按需加载。

另一个技巧是中间产物落盘。每步输出写文件，下一步只读文件路径，不把全文塞回对话。这样上下文里只保留路径和摘要，能省大量空间。

6.4 常见问题速查表

6.5 几个不写在文档里的经验

第一，先跑通一个再扩。我见过有人一上来就设计十几个 Skill，结果每个都半成品，互相干扰。正确做法是先把最高频的一个 Skill 打磨到稳定，再复制它的结构扩第二个。

第二，description 要定期回看。随着 Skill 增多，早期的 description 可能和新 Skill 冲突。我一般每加三个 Skill 就回头审一遍全部 description。

第三，保留失败案例。在examples/里除了放好案例，也放几个“反例”，标注“这样写不行，因为……”。Agent 看到反例后，避开错误的概率明显提升。

第四，版本管理别偷懒。Skill 是文本文件，直接进 Git。每次调整 description 或流程都提交一次，出问题时能快速回滚。我吃过亏，改了一版 description 导致触发率暴跌，幸好有 Git 才找回来。

7. 把营销经验沉淀成可复用资产

搭marketingskills这件事，表面上是配置几个文件，实质上是把你的营销方法论显性化。你脑子里那些“写落地页要先讲痛点再讲方案”“选题要覆盖不同搜索意图”的隐性经验，一旦写成 Skill，就变成了可复用、可迭代、可传承的资产。

我自己的体会是，写 Skill 的过程反过来逼我把很多模糊的判断想清楚了。以前觉得“文案要打动人”这种话，写进 Skill 时就必须回答：打动谁、在哪个环节打动、用什么结构打动、怎么判断打动了。这些问题的答案，才是真正值钱的东西。

后续可以扩展的方向也不少。比如给 Skill 加上 A/B 测试的变体生成能力，或者接入数据分析，让 Skill 根据历史表现自动调整策略。再比如把多个 Skill 编排成更长的自动化流水线，从选题一路跑到发布。这些都不需要重写底层，只是在现有结构上叠加。

最后分享一个我一直在用的小技巧：给每个 Skill 建一个changelog.md，记录每次调整的原因和效果。比如“2024-06 把 description 里的‘文案’改成‘销售页面文案’，触发准确率从 60% 提到 90%”。这些记录攒起来，就是你自己的 Skill 调优手册，比任何通用文档都管用。