企业官网建设流程全解析

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

第一次看到“marketingskills”这个标题，我脑子里蹦出来的不是某个具体工具，而是一类很典型的需求：把营销这件事拆成可复用、可组合、可被 AI 调用的“技能单元”。这个词本身很朴素，但它背后指向的东西一点都不朴素——它试图回答一个困扰很多团队的老问题：营销经验到底能不能被结构化沉淀下来，而不是永远散落在几个老员工的脑子里和一堆命名混乱的文件夹里。

我接触过不少做增长、做投放、做内容的朋友，大家共同的痛点是：一个活动跑完，复盘文档写了，SOP 也存了，但下次换个渠道、换个产品线，这套东西几乎没法直接复用。原因很简单，过去的“营销资产”大多是非结构化的——一篇复盘文章、一个 Excel 表、一段聊天记录。AI 时代来了之后，大家第一反应是“让 AI 帮我写文案、做投放计划”，但很快发现，如果你只是把需求丢给一个通用模型，它给你的东西永远是“正确的废话”。真正能拉开差距的，是你有没有把营销能力拆成一个个边界清晰、输入输出明确的技能模块，然后让 AI 按需调用。

“marketingskills”这个标题，我理解它想做的就是这样一件事：定义一套营销领域的技能规范，让这些技能可以被 AI agent 识别、调用、组合。它和最近很火的 Agent Skills spec、Claude Code 这些概念是同一脉络的。Claude Code 这类工具的出现，让“用自然语言驱动终端、驱动文件系统、驱动一整套工作流”变成了现实，而 marketingskills 要做的，是把营销这个垂直领域的技能，按照 agent 能理解的格式封装起来。

所以这篇文章适合谁看？如果你是做增长的、做内容的、做投放的，或者你是那个被老板要求“研究一下 AI 怎么落地到营销”的人，那这篇内容会对你有用。如果你只是想了解 Claude Code 怎么安装、怎么配置，网上教程已经很多了，我这里不会重复那些。我要聊的是更上游的东西：怎么把营销能力变成 AI 能用的技能，以及这套东西在实际操作中会踩哪些坑。

2. 核心思路拆解：为什么是“技能”而不是“提示词”

2.1 提示词的天花板在哪里

过去两年，大家用 AI 做营销基本停留在“提示词工程”阶段。你写一个很长的 prompt，告诉模型你是谁、你要什么、输出格式是什么。这套方法在单次任务上有效，但一旦任务变复杂，问题就暴露了。

我举个实际例子。假设你要让 AI 帮你做一次新品上市的整合营销方案。你用提示词的方式，可能会写：“你是一个资深营销专家，请为某新品制定上市方案，包括目标人群、核心卖点、渠道策略、内容日历、预算分配……”模型会给你一份看起来很像样的方案。但你仔细看，里面的目标人群是泛泛的“18-35岁都市白领”，核心卖点是“高品质、高性价比”，渠道策略是“小红书+抖音+微信”。这些东西放在任何一个产品上都成立，也就意味着放在任何一个产品上都没用。

问题出在哪？出在提示词是一个“一次性”的东西。它没有记忆，没有工具，没有对具体数据的访问能力，也没有办法把一个大任务拆成多个可验证的小任务。你让它做方案，它就凭训练数据里的“平均营销知识”给你编一份。它不知道你的产品实际转化数据，不知道你上个季度在某个渠道的 ROI 是多少，也不知道你的供应链能不能支撑某个促销力度。

2.2 技能化改造的三个关键动作

marketingskills 这类思路的核心，是把“写提示词”变成“定义技能”。这两者的区别，我用一个类比来说明。提示词就像你临时给一个外包写了一份 brief，他做完这一单就走了。技能就像你给一个长期合作的员工写了一份岗位说明书，里面写清楚了他的职责边界、他需要哪些工具、他的输入从哪来、输出给谁、什么情况下该找谁协作。下次有类似任务，你不需要重新写 brief，直接调用这个“岗位”就行。

具体来说，技能化改造要做三个关键动作。

第一个动作是边界定义。一个营销技能必须说清楚它“做什么”和“不做什么”。比如“竞品分析”这个技能，它的边界可能是：输入一个竞品名称和三个核心维度，输出一份结构化的对比表。它不负责做策略建议，那是另一个技能的事。边界清晰的好处是，AI 在调用时不会越界，也不会因为任务太模糊而胡编。

第二个动作是输入输出契约。这是很多做营销的人容易忽略的。你要明确定义：这个技能需要什么格式的输入？是 JSON 还是自然语言？需要哪些必填字段？输出又是什么格式？是 Markdown 表格还是结构化数据？我见过太多团队，技能定义写得像散文，AI 调用时全靠猜，结果就是输出质量极不稳定。

第三个动作是工具与数据绑定。一个营销技能如果只能靠模型“脑补”，那它的价值有限。真正有用的技能，应该能调用外部工具或数据源。比如“关键词挖掘”技能，它应该能调用搜索指数接口、能读取你已有的关键词库、能把结果写入指定文件。Claude Code 这类工具之所以重要，就是因为它给了 agent 执行终端命令、读写文件的能力，让技能不再只是“说”，而是能“做”。

2.3 为什么现在这个时间点值得做

有人可能会问，这套东西是不是太早了？我的判断是，现在恰恰是窗口期。原因有两个。

一是 agent 基础设施在快速成熟。Claude Code 这类工具已经把“自然语言驱动终端”这件事做得相当可用，Agent Skills spec 也在推动技能描述的标准化。这意味着你定义好的技能，未来迁移到不同 agent 平台的成本会越来越低。

二是营销领域的 AI 应用还停留在很浅的层面。大部分团队还在用 AI 写文案、做图，真正把 AI 嵌入到营销工作流里的很少。谁先把自己的营销能力技能化，谁就能在效率上拉开差距。这个差距不是 10%，可能是 3 到 5 倍。因为技能可以被组合、被复用、被并行调用，而人工流程只能线性推进。

3. 核心细节解析：一个营销技能应该长什么样

3.1 技能描述文件的结构

按照目前 Agent Skills spec 的常见实践，一个技能通常用一个描述文件来定义。这个文件的核心字段包括：技能名称、技能描述、触发条件、输入参数、执行步骤、输出格式、依赖工具。我用一个“小红书种草文案生成”技能来举例说明。

技能名称要足够具体，不要叫“内容生成”，要叫“小红书种草文案生成”。描述要写清楚这个技能解决什么问题，比如“根据产品卖点和目标人群，生成符合小红书平台调性的种草文案，包含标题、正文、话题标签”。触发条件写什么情况下该调用这个技能，比如“当用户需要为某个产品生成小红书推广内容时”。

输入参数要定义清楚每个字段的类型和是否必填。比如产品名称（字符串，必填）、核心卖点（字符串数组，必填）、目标人群（字符串，必填）、参考风格（字符串，可选）、禁忌词（字符串数组，可选）。执行步骤要写成有序列表，每一步做什么、用什么工具、产出什么中间结果。输出格式要明确，比如输出一个 Markdown 代码块，里面包含标题、正文、标签三个部分。

这里有个经验：执行步骤不要写得太粗，也不要写得太细。太粗了 AI 自由发挥空间太大，输出不稳定；太细了又变成了硬编码，失去了 AI 的灵活性。我的做法是，把步骤拆到“一个步骤对应一个明确的动作”这个粒度。比如“分析目标人群的语言习惯”是一个步骤，“根据语言习惯调整文案语气”是另一个步骤。这样既给了 AI 判断空间，又保证了流程可控。

3.2 输入输出的契约设计

输入输出契约是技能能不能被稳定调用的关键。我见过太多技能定义，输入写的是“用户提供产品信息”，这种描述等于没写。AI 不知道产品信息具体包含什么，也不知道格式是什么，结果就是每次调用都要重新问一遍，或者干脆瞎猜。

正确的做法是用类似 JSON Schema 的方式把输入结构定死。比如：

{ "product_name": "string, required", "selling_points": ["string", "string"], "target_audience": "string", "tone": "string, optional, default: 亲切自然", "forbidden_words": ["string"] }

输出也一样。不要写“输出一段文案”，要写清楚输出的结构。比如输出一个对象，包含title、body、hashtags三个字段，hashtags是一个字符串数组，每个标签以 # 开头。这样下游技能或者人工审核时，就能直接按结构解析，不需要再做一次自然语言理解。

注意：输入输出契约一旦定下来，就不要轻易改。因为下游可能有很多技能依赖这个契约。如果确实要改，要做好版本管理，比如xiaohongshu_copy_v1和xiaohongshu_copy_v2并存一段时间。

3.3 工具绑定与权限控制

一个营销技能如果只能“动嘴”，价值有限。真正有用的技能要能“动手”。在 Claude Code 这类环境里，技能可以调用终端命令、读写文件、访问 API。这就带来了两个问题：一是工具怎么选，二是权限怎么控。

工具选择的原则是：能用简单工具就不用复杂工具，能用本地就不用远程。比如读取一个 CSV 文件，用cat或head就够了，不需要专门写一个 Python 脚本。调用一个 HTTP 接口，用curl就够了，不需要引入一个 HTTP 客户端库。工具越简单，出问题的概率越低，调试也越容易。

权限控制是很多人会忽略的。一个营销技能如果需要读取你的客户数据，那它就应该被限制只能读取指定目录下的文件，不能访问整个文件系统。如果需要调用外部 API，那 API key 应该通过环境变量注入，而不是硬编码在技能描述里。这些安全实践在个人使用时可能觉得麻烦，但一旦团队协作，就是必须的。

我自己的做法是，给每个技能定义一个“权限清单”，写清楚它能访问哪些目录、能调用哪些命令、能访问哪些网络端点。然后在 agent 配置里做对应的限制。这样即使某个技能被恶意利用，影响范围也可控。

4. 实操过程：从零搭建一个营销技能库

4.1 环境准备与工具选型

先说环境。如果你用的是 Claude Code，安装和配置的教程网上很多，我这里只提几个和技能开发相关的点。第一，确保你的工作目录结构清晰。我建议的目录结构是这样的：

marketing-skills/ skills/ xiaohongshu-copy/ SKILL.md examples/ competitor-analysis/ SKILL.md examples/ keyword-research/ SKILL.md examples/ shared/ data/ templates/ config/ permissions.json

每个技能一个目录，目录名用短横线连接的小写英文。SKILL.md是技能描述文件，examples/放几个输入输出示例，方便调试和给 AI 做 few-shot 参考。shared/放公共数据和模板，config/放权限配置。

工具选型上，我建议至少准备这几样：一个文本编辑器（VS Code 就行）、一个终端、一个版本控制工具（Git）。如果你要调用外部 API，还需要一个能管理环境变量的方式，比如.env文件配合dotenv。这些工具都很基础，不需要额外学习成本。

4.2 编写第一个技能：竞品分析

我拿“竞品分析”这个技能来完整走一遍流程。为什么选它？因为它是一个典型的“输入明确、输出结构化、需要调用外部数据”的营销技能，能覆盖大部分技能开发中会遇到的问题。

第一步，定义技能边界。这个技能做什么：给定一个竞品名称和三个分析维度，输出一份结构化的竞品分析报告。不做什么：不做策略建议，不做预算分配，不做创意生成。边界写清楚，后面调用时就不会跑偏。

第二步，定义输入。输入参数包括：竞品名称（必填）、分析维度（必填，从预设列表中选择，比如“产品功能”“定价策略”“渠道布局”“内容策略”）、输出语言（可选，默认中文）、详细程度（可选，默认“标准”）。

第三步，定义执行步骤。我把它拆成五步：

1. 确认竞品名称和分析维度，如果维度不在预设列表中，提示用户重新选择。
2. 调用搜索工具，获取竞品在指定维度上的公开信息。这里要指定搜索关键词模板，比如“{竞品名称} {维度} 分析”。
3. 对搜索结果做去重和筛选，保留最近 12 个月内的信息。
4. 按照预设的报告模板，把信息填入对应章节。
5. 输出 Markdown 格式的报告，并在末尾附上信息来源链接。

第四步，定义输出格式。输出一个 Markdown 文档，包含标题、概述、各维度分析、总结、信息来源五个部分。每个维度分析下面要有“现状描述”“关键发现”“数据支撑”三个子项。

第五步，绑定工具。这个技能需要调用搜索工具和文件写入工具。搜索工具可以用现成的搜索 API，文件写入用标准的文件操作命令。

写完之后，用几个真实的竞品跑一遍，看看输出质量。我实测下来，最容易出问题的地方是第三步的“去重和筛选”。因为搜索结果里会有大量重复内容和过时信息，如果筛选逻辑写得太粗，报告里就会混入很多噪音。我的做法是在技能描述里明确写清楚筛选规则，比如“优先保留来自官方渠道、权威媒体、最近 6 个月内的信息；同一信息源只保留一条”。

4.3 技能组合与工作流编排

单个技能有用，但真正威力大的是技能组合。比如你可以把“竞品分析”“关键词挖掘”“内容日历生成”三个技能串起来，形成一个“新品上市内容策略”工作流。

编排工作流的关键是定义清楚技能之间的数据传递。比如“竞品分析”的输出里包含“竞品核心卖点”，这个字段可以直接作为“关键词挖掘”的输入之一。“关键词挖掘”的输出里包含“高价值关键词列表”，这个又可以作为“内容日历生成”的输入。

这里有个坑：不要假设上游技能的输出格式永远不变。我建议在技能之间加一层“适配器”，把上游输出转换成下游需要的格式。这层适配器可以是一个简单的脚本，也可以是一段自然语言指令。加这一层的好处是，当上游技能升级时，只需要改适配器，不需要改下游技能。

工作流编排还有一个实践是“并行调用”。比如“竞品分析”和“关键词挖掘”之间没有依赖关系，可以并行跑，节省时间。在 Claude Code 里，你可以用后台任务的方式并行执行多个技能。但要注意，并行任务如果都要写同一个文件，会有冲突。我的做法是让每个技能写自己的临时文件，最后再合并。

4.4 调试与迭代

技能开发不是一次性的，需要反复调试。我常用的调试方法是“最小输入测试”。先用最简单的输入跑一遍，看看技能能不能正常执行。比如竞品分析技能，先用一个你非常熟悉的竞品，输入一个维度，看看输出是否符合预期。如果这一步就有问题，那说明技能描述里有歧义。

最小输入测试通过后，再逐步增加复杂度。增加输入维度、增加数据量、增加边界情况。每增加一项，都记录下输出质量的变化。我一般会维护一个“测试用例表”，里面记录每个用例的输入、预期输出、实际输出、是否通过。这个表在技能迭代时非常有用，能快速发现回归问题。

迭代的节奏我建议是“小步快跑”。不要憋一个大版本，每次改一两个点，跑一遍测试，确认没问题就提交。这样出问题时容易定位，也不会因为改动太大而引入一堆新问题。

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

5.1 技能调用不触发怎么办

这是最常见的问题。你定义了一个技能，但 AI 在该用的时候没用。原因通常有三个。

一是触发条件写得太窄。比如你写“当用户明确说‘请使用竞品分析技能’时触发”，那用户说“帮我看看这个竞品”就不会触发。我的建议是触发条件要写“意图”而不是“关键词”。比如“当用户表达出需要了解竞品信息的意图时触发”。

二是技能描述和用户输入之间的语义距离太远。比如用户说“帮我做一下市场调研”，你的技能叫“竞品分析”，AI 可能觉得这两个不是一回事。解决办法是在技能描述里加上同义词和相关场景，比如“竞品分析，也称为竞争对手研究、市场对标分析”。

三是技能太多，AI 选择困难。当你有几十个技能时，AI 可能会在多个相似技能之间犹豫。这时候需要做技能分组，或者给每个技能加一个“优先级”字段，让 AI 在冲突时知道该选哪个。

5.2 输出格式不稳定的排查思路

输出格式不稳定是另一个高频问题。同样的输入，有时候输出 Markdown 表格，有时候输出纯文本列表。排查思路是这样的。

先检查技能描述里的输出格式定义是否足够具体。如果你写的是“输出一个表格”，那 AI 可能用 Markdown 表格，也可能用 CSV，还可能用自然语言描述一个表格。要写就写死，比如“输出一个 Markdown 表格，表头为：维度、竞品表现、我方表现、差距分析”。

如果格式定义已经足够具体但输出还是不稳定，那可能是模型的问题。不同模型对格式指令的遵循程度不一样。我的经验是，对于格式要求严格的技能，在技能描述里加一个“输出示例”会很有帮助。给 AI 一个具体的输出样例，它模仿的准确率会高很多。

还有一个技巧是“后处理校验”。在技能执行完输出之后，加一步校验，检查输出是否符合格式要求。如果不符合，就让 AI 重新生成，或者用脚本做格式转换。这一步会增加一点时间，但能大幅提升稳定性。

5.3 数据源访问失败的应对

营销技能经常需要访问外部数据源，比如搜索 API、社交媒体 API、内部数据库。这些访问失败是常态，要有应对方案。

首先是超时和重试。在技能描述里明确写清楚超时时间和重试次数。比如“调用搜索 API 时，超时时间设为 10 秒，失败后重试 2 次，每次间隔 2 秒”。不要小看这个，很多技能失败就是因为没有重试机制，一次网络抖动就挂了。

其次是降级方案。如果主数据源访问失败，要有备选方案。比如搜索 API 挂了，可以降级到用本地缓存的数据，或者提示用户手动提供信息。降级方案要在技能描述里写清楚，让 AI 知道什么情况下该降级、怎么降级。

最后是错误记录。每次数据源访问失败，都要记录下失败原因、时间、输入参数。这些记录在排查问题时非常有用。我一般会让技能把错误信息写到一个统一的日志文件里，方便后续分析。

5.4 常见问题速查表

提示：这张表建议放在你的技能库根目录下，每次遇到新问题就补充一行。积累下来就是你自己的排查手册。

6. 技能库的维护与扩展：一些实操心得

6.1 版本管理与变更记录

技能库一旦开始被多人使用，版本管理就变得很重要。我的做法是每个技能目录下放一个CHANGELOG.md，记录每次变更的内容、原因、影响范围。变更记录不用写得很正式，但要写清楚“改了什么”和“为什么改”。

比如：“2024-06-15，将竞品分析技能的搜索时间范围从 6 个月改为 12 个月。原因：6 个月内的信息太少，导致报告内容单薄。影响：执行时间增加约 20%，但输出质量明显提升。”

这种记录看起来琐碎，但当三个月后有人问“为什么这个技能要跑这么久”时，你翻一下变更记录就能回答。没有变更记录，你就只能靠回忆，而回忆往往不靠谱。

6.2 技能复用与抽象

随着技能数量增加，你会发现很多技能之间有重复的逻辑。比如“小红书文案生成”和“抖音文案生成”可能共享 80% 的逻辑，只是平台调性和格式要求不同。这时候就要做抽象。

抽象的方法是把公共逻辑抽成一个“基础技能”，然后平台特定的技能去调用这个基础技能。比如抽一个“短文案生成基础技能”，负责处理产品信息、卖点提取、语气调整这些通用逻辑。然后“小红书文案生成”和“抖音文案生成”分别在这个基础上加平台特定的格式和调性要求。

抽象的好处是维护成本大幅降低。改一个公共逻辑，所有依赖它的技能都受益。但抽象也要适度，不要为了抽象而抽象。我的经验是，当两个技能有超过 60% 的重复逻辑时，才考虑抽象。低于这个比例，抽象带来的复杂度可能超过收益。

6.3 团队协作中的技能共享

如果是团队使用，技能库的共享机制要设计好。我见过两种模式，各有优劣。

一种是“中央仓库”模式。所有技能放在一个 Git 仓库里，大家通过 Pull Request 提交新技能或修改。这种模式的好处是统一管理，质量可控。坏处是流程较重，小改动也要走 PR。

另一种是“个人仓库+注册中心”模式。每个人维护自己的技能仓库，然后在一个注册中心里登记自己的技能。这种模式灵活，但容易出现技能重复和质量参差不齐。

我自己的做法是混合模式：核心技能放中央仓库，严格管理；实验性技能放个人仓库，通过注册中心共享。等实验性技能成熟了，再迁移到中央仓库。这样既保证了核心技能的稳定性，又给了创新空间。

6.4 技能效果的度量

最后聊一个容易被忽略的点：怎么衡量一个技能到底有没有用。我的做法是给每个技能定义两到三个度量指标。

对于内容生成类技能，指标可以是“人工修改率”和“生成速度”。人工修改率越低，说明技能输出质量越高。生成速度则影响使用体验。

对于分析类技能，指标可以是“信息准确率”和“覆盖度”。信息准确率需要人工抽查，覆盖度可以通过对比人工分析的结果来评估。

对于流程类技能，指标可以是“执行成功率”和“耗时”。执行成功率低于 90% 的技能，就需要重点排查。

这些指标不需要很精确，但要有。没有度量，你就不知道技能是在进步还是在退步。我一般会每个月跑一次度量，把结果记录在技能目录下的METRICS.md里。时间长了，就能看出哪些技能值得继续投入，哪些应该淘汰。

我个人在实际操作中的体会是，做 marketingskills 这件事，最大的障碍不是技术，而是愿不愿意把营销经验“拆开”。很多人做营销久了，习惯了一套模糊的、靠感觉的判断方式，让他把每个判断拆成明确的输入输出，他会觉得别扭。但恰恰是这种拆解，才是 AI 能帮上忙的前提。你拆得越清楚，AI 干得越漂亮。这个道理，和带团队是一样的。