企业官网建设流程全解析

1. 这个项目到底在解决什么问题

第一次看到“把 50 多种营销 Skill 装进 AI Agent”这个标题，我脑子里冒出来的第一个念头是：终于有人把营销人日常那些碎得不能再碎的活儿，做成了一套可以复用的能力包。做过营销的都知道，写文案、做竞品分析、拆解爆款、生成投放素材、整理用户画像、写落地页、做 SEO 关键词表、给私域写话术、给活动写脚本……这些事单拎出来都不算难，但架不住它多、它杂、它天天重复。以前我们的做法是打开一个对话框，把需求敲进去，等模型吐出来，不满意再改，改完再复制到另一个工具里。整个过程里，人其实是在给 AI 打杂。

这个开源项目的思路很直接：既然 AI Agent 已经能调用工具、能读文件、能按步骤执行任务，那为什么不把营销里那些高频、标准化的动作，直接封装成 Agent 可以调用的 Skill？所谓 Skill，你可以理解成一份写给 AI 看的“岗位说明书 + 操作手册”。它告诉 Agent 在什么场景下该做什么、按什么顺序做、输出成什么格式、注意哪些坑。50 多种 Skill 堆在一起，就相当于给一个通用 AI Agent 装上了一整套营销部门的技能树。

它解决的核心问题有三个。第一是一致性，同一个任务今天做和明天做，输出质量不能靠运气，Skill 把流程固定下来，结果就稳。第二是可组合，一个营销任务往往不是单一动作，比如“给新品做一轮上市传播”，里面包含受众分析、卖点提炼、渠道选择、内容排期、素材生成，Skill 可以像积木一样拼起来。第三是降低门槛，新手不需要懂提示词工程，只要选对 Skill，按它的输入要求填内容，就能拿到接近老手的产出。

适合谁看？如果你是营销从业者，想把自己的经验沉淀成可复用的资产，这套东西值得研究。如果你是 AI Agent 的开发者或重度用户，正在用 Claude Code、Codex、Cursor、Windsurf 这类工具做自动化，那这套 Skill 的组织方式能给你很多启发。哪怕你只是刚接触 AI Agent，想找一个练手项目，从“营销 Skill 库”切入也比从零搭一个通用 Agent 要实在得多，因为场景明确、反馈快、容易看到效果。

2. 核心设计思路拆解

2.1 为什么是 Skill，而不是一个大而全的提示词

很多人第一反应是：我写一个超长的系统提示词，把营销的所有要求都塞进去不就行了？我试过，不行。提示词越长，模型的注意力越容易被稀释，前面说的规则到后面就忘了，而且不同任务之间会互相干扰。比如你让同一个提示词既写严肃的 B 端白皮书，又写活泼的社交媒体段子，模型会精神分裂。

Skill 的做法是把能力切碎。每个 Skill 只负责一类任务，有自己的触发条件、输入规范、执行步骤和输出模板。Agent 在接到任务时，先判断该调用哪个 Skill，再按那个 Skill 的规则执行。这就像公司里不会让一个人同时干文案、设计、投放、数据分析，而是分岗位，每个岗位有自己的 SOP。切碎之后，每个 Skill 的提示词可以写得很精炼，模型执行时的专注度也高。

从工程角度看，Skill 通常是一个结构化的文件，可能是 Markdown、YAML 或者 JSON，里面包含几个关键字段：名称、描述、适用场景、输入参数、执行指令、输出格式、示例。Agent 框架读取这些文件后，就能把它们注册成可调用的工具。这种设计的好处是可维护，改一个 Skill 不影响其他 Skill；可扩展，新增能力就是加一个文件；可测试，每个 Skill 可以单独跑用例验证。

2.2 50 多种 Skill 是怎么分类的

我拿到这类项目时，习惯先看它的分类逻辑，因为分类方式直接反映了作者对营销工作的理解。一个合理的营销 Skill 库，通常会覆盖以下几个层面。

策略层：市场调研、竞品分析、受众画像、定位梳理、卖点提炼、传播策略。这些 Skill 的输出是方向性的，不直接产生最终物料，但决定了后面所有动作的准头。

内容层：文案撰写、标题生成、脚本创作、邮件撰写、落地页文案、产品描述、广告语。这是数量最多的一类，因为内容生产的频次最高。

渠道层：SEO 关键词、社交媒体排期、社群话术、KOL 筛选、投放素材适配。不同渠道的规则不一样，Skill 需要内置渠道特性。

分析层：数据解读、A/B 测试方案、用户反馈归类、转化漏斗诊断。这类 Skill 往往需要 Agent 能读表格或调用分析工具。

运营层：活动策划、用户分层、召回话术、会员体系设计、私域 SOP。

这五层不是孤立的，实际任务里经常跨层调用。比如做一次新品推广，Agent 可能先调“竞品分析”Skill，再调“卖点提炼”，然后调“内容日历”，最后调“社交媒体文案”。Skill 之间的衔接靠的是统一的输入输出约定，比如都用结构化的 JSON 传递中间结果，这样上一个 Skill 的输出能直接喂给下一个。

2.3 和 Claude Code、Codex、Cursor 这些工具怎么配合

热词里出现了 Claude Code、Codex、Cursor、Windsurf，说明大家关心的是这套 Skill 能不能在自己常用的工具里跑起来。答案是能，但方式不太一样。

Claude Code 和 Codex 这类偏命令行、偏 Agent 原生的工具，通常支持读取本地文件作为上下文。你可以把 Skill 库放在项目目录里，Agent 在执行任务时按需读取对应的 Skill 文件。这种方式最灵活，因为 Skill 就是普通文件，版本管理、团队共享都很方便。

Cursor 和 Windsurf 这类 AI 编程助手，本质上是编辑器里嵌了模型。它们对“Skill”的支持方式更多是通过规则文件、自定义指令或者项目级配置。你可以把营销 Skill 写成项目里的规则文档，让助手在生成内容时参考。虽然不如原生 Agent 那么自动化，但对于“边写边用”的场景已经够用。

这里有个关键点：Skill 的格式最好保持通用，不要绑死某一个平台。用 Markdown 写主体，用 YAML 写元数据，这样换工具时迁移成本最低。我见过一些项目把 Skill 写成了某个平台专属的格式，结果想换工具时全部重写，很痛苦。

3. 核心细节解析与实操要点

3.1 一个 Skill 文件应该包含哪些字段

我拆过不少类似的 Skill 库，一个能真正跑起来的 Skill，字段设计比想象中讲究。下面是我总结的一套比较实用的结构。

name: competitor-analysis display_name: 竞品分析 description: 对指定竞品进行结构化分析，输出对比表格和差异化建议 trigger: 当用户需要分析竞品、做市场对比、找差异化定位时调用 inputs: - name: competitor_list type: array required: true description: 竞品名称列表，至少 2 个 - name: our_product type: string required: true description: 我方产品名称和核心信息 - name: dimensions type: array required: false default: [定位, 目标用户, 核心功能, 价格, 渠道, 传播话术] description: 对比维度 outputs: - type: markdown description: 包含对比表格、各自优劣势、差异化机会点 steps: - 逐个收集竞品公开信息 - 按维度填充对比表格 - 识别每个竞品的强项和弱项 - 结合我方产品找出可切入的差异化角度 - 输出建议并标注信息可信度 constraints: - 不编造未经验证的数据 - 信息缺失时明确标注“待补充” - 对比表格不超过 8 列，避免过宽

这套字段里，trigger和constraints是最容易被忽略但最重要的。trigger决定了 Agent 什么时候该用这个 Skill，写得太窄会漏调用，写得太宽会误调用。constraints是防翻车的护栏，营销内容最怕 AI 一本正经地胡说，把“不编造数据”写进约束里，能挡掉很多问题。

3.2 输入设计：为什么不能让用户随便填

新手做 Skill 常犯的错是输入设计太随意，比如只写一个“请输入你的需求”。这样 Agent 拿到的东西千奇百怪，输出自然不稳定。好的输入设计要引导用户提供结构化信息。

以“受众画像”Skill 为例，如果只让用户说“帮我分析目标用户”，模型只能泛泛而谈。但如果输入字段设计成：产品类别、价格区间、已知用户特征、使用场景、竞品用户重叠情况，模型就能基于这些锚点做有依据的推断。输入字段本身就是一种提示，它告诉模型“从这些角度去想”。

另一个技巧是给默认值。很多用户不知道自己该提供什么，默认值能兜底。比如对比维度默认给一组常用的，用户不填就用默认，填了就覆盖。这样既降低了使用门槛，又保留了灵活性。

3.3 输出格式的约束技巧

营销 Skill 的输出最怕两种：一种是长篇大论没有重点，另一种是格式混乱没法直接用。解决办法是在 Skill 里把输出格式写死。

我一般会要求输出包含三个部分：结论先行、支撑细节、可执行建议。结论先行是给决策者看的，支撑细节是给执行者看的，可执行建议是给下一步动作看的。格式上用 Markdown 的标题、表格、列表来组织，这样复制到文档或邮件里不会乱。

对于需要程序化处理的输出，比如生成关键词表、内容排期表，我会要求输出 JSON 或 CSV。这里有个细节：要在 Skill 里给出字段定义和示例，否则模型输出的 JSON 键名可能每次都不一样，下游没法解析。

提示：输出格式的约束不要只写在文字描述里，最好给一个完整的示例输出。模型对示例的遵循度远高于对抽象描述的理解。

3.4 Skill 之间的依赖和编排

单个 Skill 好用，但真正的价值在组合。50 多个 Skill 如果只是散落着，用户得自己记住哪个先哪个后，体验就差了。好的项目会提供编排层，比如用工作流文件把多个 Skill 串起来。

一个典型的营销工作流可能是：市场调研 → 竞品分析 → 受众画像 → 卖点提炼 → 内容策略 → 文案生成 → 渠道适配。每个环节的输出作为下一个环节的输入。编排文件里要定义清楚数据怎么传递、哪些环节可以并行、出错时怎么回退。

我自己的经验是，编排不要做太深。超过 5 个环节的工作流，中间任何一步出问题都很难排查。更好的做法是把大流程拆成几个小工作流，每个小工作流 3 到 4 个 Skill，这样既灵活又好调试。

4. 实操过程与核心环节实现

4.1 环境准备：把 Skill 库跑起来

假设你用的是支持 Agent 的工具，第一步是把 Skill 库放到项目里。通常的做法是建一个skills/目录，每个 Skill 一个文件，再加一个index.yaml作为总索引。

mkdir marketing-agent cd marketing-agent mkdir skills # 把下载的 Skill 文件放进 skills 目录 # 创建索引文件 touch skills/index.yaml

索引文件的作用是让 Agent 快速知道有哪些 Skill 可用，不用每次都扫描整个目录。索引里至少包含名称、描述、文件路径。

skills: - name: competitor-analysis file: skills/competitor-analysis.yaml description: 竞品分析 - name: audience-persona file: skills/audience-persona.yaml description: 受众画像 - name: copywriting file: skills/copywriting.yaml description: 文案撰写

然后在 Agent 的配置里指向这个索引。不同工具的配置方式不一样，但核心都是告诉 Agent“去这里找 Skill”。

4.2 跑通第一个 Skill：以竞品分析为例

选竞品分析作为第一个跑通的 Skill，是因为它的输入输出都很明确，容易验证。操作步骤大致如下。

第一步，准备输入。假设你要分析三款笔记类应用，整理成结构化数据。

{ "competitor_list": ["应用A", "应用B", "应用C"], "our_product": "我们的笔记应用，主打极简和本地优先", "dimensions": ["定位", "目标用户", "核心功能", "价格", "渠道", "传播话术"] }

第二步，触发 Agent 调用 Skill。在对话框里输入类似“用竞品分析 Skill 分析这三个竞品”，Agent 应该能识别并加载对应的 Skill 文件。

第三步，检查输出。一个合格的输出应该包含对比表格、每个竞品的优劣势、以及针对我方产品的差异化建议。如果输出里出现了编造的数据，说明约束没生效，需要回去检查 Skill 里的constraints字段。

第四步，迭代。第一次跑出来的结果通常不会完美，可能是维度不够贴切，可能是建议太泛。把这些问题记下来，回到 Skill 文件里调整。比如发现“传播话术”这个维度模型总是分析得很浅，可以在 Skill 的步骤里加一句“传播话术维度需要引用竞品实际使用的广告语或社交媒体文案”。

4.3 参数选择：Skill 的粒度怎么定

这是实操中最纠结的问题。粒度太粗，一个 Skill 干太多事，提示词会很长，效果下降；粒度太细，Skill 数量爆炸，编排复杂。

我的判断标准是：一个 Skill 对应一个明确的交付物。比如“写一条朋友圈文案”是一个交付物，“写一套社交媒体内容”就不是，后者应该拆成“内容策略”“文案生成”“排期”三个 Skill。交付物明确，输入输出就容易定义，测试也有标准。

另一个标准是复用频率。高频动作值得单独成 Skill，低频的可以合并。比如“标题生成”几乎每个内容任务都要用，单独成 Skill 很合理；“年报撰写”一年一次，可以和其他长文写作合并。

50 多个 Skill 听起来多，但如果分类清晰、命名规范，管理起来并不难。关键是索引要做好，让 Agent 和用户都能快速找到需要的那个。

4.4 让 Skill 输出更稳定的三个技巧

第一个技巧是在 Skill 里内置检查清单。比如文案类 Skill，可以在步骤最后加一步“自查：是否包含行动号召？是否避免了绝对化用语？是否符合品牌调性？”模型在生成后会按清单过一遍，质量明显提升。

第二个技巧是给正反示例。与其说“不要写得太官方”，不如给一个官方腔的反例和一个自然腔的正例。模型对示例的模仿能力很强，两个例子一摆，风格就稳了。

第三个技巧是限制输出长度。营销内容不是越长越好，很多场景需要精炼。在 Skill 里写明“正文不超过 300 字”“标题不超过 20 字”，能逼着模型做取舍，反而出精品。

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

5.1 Agent 不调用 Skill 怎么办

这是最常见的问题。你明明把 Skill 放好了，Agent 却当没看见，自己瞎答。原因通常有三个。

一是索引没被正确加载。检查 Agent 的配置里有没有指向index.yaml，路径对不对。有些工具需要重启才生效，改完配置记得重启。

二是 Skill 的trigger写得太窄。比如只写了“当用户明确说‘竞品分析’时调用”，但用户实际说的是“帮我看看这几个产品有啥不一样”，就匹配不上。解决办法是把trigger写得更贴近自然语言，多列几种可能的说法。

三是 Skill 的描述不够清晰。Agent 判断是否调用某个 Skill，主要看描述。如果描述写得很抽象，Agent 就不知道这个 Skill 能干什么。描述要具体，最好包含“输入什么、输出什么、解决什么问题”。

5.2 输出质量忽高忽低

同一个 Skill，有时候输出很好，有时候很水。这种波动通常来自输入的差异。用户填的输入越具体，输出越稳；输入越模糊，模型越容易自由发挥。

排查方法是固定输入跑多次，看波动是否来自模型本身。如果固定输入下输出稳定，那就是输入设计的问题，需要在 Skill 里加更多引导和默认值。如果固定输入下还是波动，可能是 Skill 的步骤写得太笼统，需要把每一步拆得更细。

还有一个隐藏原因是上下文长度。如果 Agent 在调用这个 Skill 之前已经积累了大量对话，模型的注意力会被分散。解决办法是在 Skill 里明确要求“忽略之前的无关上下文，只基于本次输入执行”。

5.3 多个 Skill 冲突或重复调用

当 Skill 数量多了，Agent 可能在一个任务里反复调用相似的 Skill，或者两个 Skill 都想处理同一个请求。这会造成输出冗余甚至矛盾。

解决思路是给 Skill 加优先级和互斥标记。比如“深度竞品分析”和“快速竞品扫描”是两个 Skill，前者用于正式报告，后者用于快速了解。在索引里标注优先级，Agent 在冲突时选优先级高的。互斥标记则告诉 Agent“用了这个就别用那个”。

另一个办法是合并。如果两个 Skill 的输入输出高度重叠，只是详细程度不同，不如合并成一个 Skill，用参数控制深度。Skill 数量不是越多越好，清晰比数量重要。

5.4 常见问题速查表

5.5 我踩过的几个坑

第一个坑是Skill 写得太长。刚开始我觉得写得越详细越好，一个 Skill 文件写了上千字，结果模型执行时反而抓不住重点。后来我把每个 Skill 控制在 300 到 500 字，只保留最关键的步骤和约束，效果反而更好。Skill 是操作手册，不是百科全书。

第二个坑是忽略版本管理。Skill 改来改去，改到最后不知道哪版好用。后来我把 Skill 库放进 Git，每次调整都提交，出问题能回滚，也能看到演进过程。团队协作时，谁改了什么一目了然。

第三个坑是没有测试用例。每个 Skill 应该配几个标准输入和期望输出，改完 Skill 跑一遍测试，确认没退化。我现在的做法是每个 Skill 配三个用例：正常输入、边界输入、异常输入。跑一遍只要几分钟，但能挡掉大部分低级错误。

第四个坑是过度依赖单一模型。不同模型对同一个 Skill 的执行效果不一样。有的模型擅长遵循格式，有的模型擅长创意发挥。如果 Skill 库要跨模型使用，约束要写得更明确，不能假设模型会“懂事”。

6. 这套 Skill 库还能怎么扩展

跑通基础功能之后，我建议从两个方向扩展。一个是垂直深化，针对你所在的行业加专属 Skill。比如做电商的，可以加“商品详情页优化”“评价分析”“大促节奏规划”；做教育的，可以加“课程卖点提炼”“家长沟通话术”“试听课转化脚本”。通用 Skill 解决 80% 的问题，垂直 Skill 解决剩下 20% 但最值钱的部分。

另一个是数据打通。现在的 Skill 大多基于用户手动输入的信息，如果能接上真实数据源，比如把网站分析数据、社交媒体互动数据、CRM 里的用户数据喂给 Skill，输出的针对性和可信度会大幅提升。这需要一些工程工作，但方向是明确的。

还有一个容易被忽略的扩展点是反馈闭环。每次 Skill 输出后，让用户打个分或者标一下哪里好哪里不好，这些反馈积累起来，可以用来优化 Skill 的提示词。我试过用简单的表格记录每次输出的评分和问题，积累几十条之后，就能看出哪个 Skill 的哪个环节最常出问题，改起来有的放矢。

我个人在实际操作中的体会是，Skill 库的价值不在于数量，而在于有没有形成闭环。50 个 Skill 如果各自为战，用起来还是很累；但如果它们能按工作流串起来，输入输出能顺畅传递，那才真正把营销工作流装进了 Agent。刚开始不用追求大而全，选三五个最高频的场景，把 Skill 打磨到稳定可用，再逐步扩展，这条路走起来更踏实。