企业官网建设流程全解析

最近在复盘一个挺有意思的项目——Marketingskills，简单来说，是一套给 AI 代理（也就是常说的 Agent）用的营销技能库。当时接到这个项目时，"技能库"这个概念让我琢磨了很久：它到底和传统的知识库有什么区别？为什么营销场景需要单独为 Agent 建一套技能库？又该如何设计才能让 AI 代理真正"学会"做营销，而不是只会调一堆 API 接口？整个项目从构思到落地跑通，前后花了几周时间，踩了不少坑，也沉淀了一些实打实的经验。这篇文章就把这套技能库的构建思路、核心设计、具体实现和避坑记录完整拆开来讲，希望能给正在做 AI 营销自动化、或者想给 Agent 建能力域的同行一些参考。

这套方案适合谁？如果你已经在用大模型做内容生成、用户洞察或者广告投放优化，正苦恼于"AI 输出不稳定、没法形成标准作业流程"，那这套技能库的思路会很对路子。如果你刚开始接触 AI 代理，还没想清楚怎么把营销方法论塞进模型里，我的建议是先别急着建库，先把这篇文章里的架构图和设计逻辑看明白，再动手会顺很多。

1. 整体设计与思路拆解

1.1 为什么营销场景需要"技能库"，而不是提示词模板或知识库

很多团队第一次搭建营销 AI 时，第一反应是"我多写几套提示词模板不就行了？"当时我们也是这个思路，但做了一段时间后发现问题很明显：提示词模板只是把任务描述得更清楚，模型依然不知道"什么时候该用什么方法、按什么流程推进、产出物要满足什么标准"。比如你告诉模型"写一篇小红书种草文案"，它确实能写，但写出来的东西能不能贴合品牌调性、有没有按 AIDA 模型安排结构、是否避开了合规禁区，这些它统统不管，因为提示词里根本没这些约束。

知识库是另一个常见选择。把营销案例、行业报告、产品手册全部塞进向量数据库，让 Agent 检索后生成内容。但知识库解决的是"知道什么"的问题，解决不了"该怎么做"的问题。知识库本质上是一个静态参考资料，营销是一个需要判断、编排、执行、复盘的动态过程。举个例子，知识库里存了 100 篇爆款文案，Agent 能搜出来，但它不知道先分析用户画像还是先确认产品卖点，不知道内容产出后要经过哪些审核环节，更不知道投放效果数据回来之后该怎么反哺下一轮内容生产。

技能库的思路恰好补上了这一环。它的核心是把"营销能力"拆解成一个个可以执行、复用、组合的技能单元，每个技能都有明确的触发条件、执行步骤、输入输出规范和质检标准。从本质上看，技能库是给 Agent 写的一份操作手册，告诉它"在什么情况下用什么招数，每个招数怎么拆解成动作，每个动作的产出物长什么样算合格"。这套设计直接解决了我前面提到的两个痛点：流程标准化和输出可控性。

1.2 技能库整体架构：从技能定义到执行反馈

那 Marketingskills 项目的架构到底长什么样？我把它拆成四个层次：技能层、编排层、执行层、评估层。

技能层是整个技能库的地基。每个技能是一个自包含的模块，里面定义了技能的名称、功能描述、适用场景、触发条件、输入参数、执行步骤和输出格式。这一层的粒度很重要，拆得太粗，一个技能里塞了十几步操作，Agent 跑起来既笨重又费 Token；拆得太细，技能数量爆炸，Agent 在决策选择时反而会纠结。我们最终把粒度控制在一个技能对应一个完整但独立的营销动作，比如"生成短视频脚本""分析竞品卖点""制定投放预算分配建议"，每个技能内部的步骤控制在 3 到 8 个。

编排层负责把多个技能串成一条完整的工作流。营销活动本身是一个多环节的链条，调研用户需求、产出内容、选渠道、投放、回收数据，每个环节对应一到多个技能。编排层的设计思路是让 Agent 根据目标任务动态选择技能组合，而不是提前写死流程。比如做一次新品推广，Agent 可以根据当前阶段选择"用户调研技能 + 卖点提炼技能 + 内容生产技能"，如果投放渠道是抖音，就追加"短视频脚本技能"，如果是公众号，就换成"长图文写作技能"。

执行层解决的是"技能怎么被真正跑起来"的问题。每个技能内部是带状态的步骤序列，Agent 按顺序执行，每完成一步就更新上下文，直到产出最终结果。这里有一个关键的工程设计：技能步骤之间要允许数据流转。比如"卖点提炼技能"输出的结构化卖点列表，要能被"短视频脚本技能"直接引用，而不是重新生成一遍，否则既浪费 Token，又容易上下文漂移。

评估层是很多技术方案最容易漏掉的部分。技能库的价值是让 Agent 的营销产出越来越稳定，那怎么衡量是否稳定？就需要对每次技能执行的效果做评估，把结果反馈回技能定义的优化。我们会为每个技能配置评估维度，比如内容技能看信息准确性、创意度、品牌一致性，投放技能看转化率、成本效率。评估既可以是规则打分，也可以让模型当裁判，还可以引入人工抽查，关键在于形成闭环，这一点我会在后面的实操章节细讲。

这四个层级放在一起，才构成一个完整的技能库体系。单独把技能定义写得再漂亮，没有编排和执行机制，就是一摞文档；没有评估反馈，就是一锤子买卖，永远在同一个地方踩坑。

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

2.1 技能 Schema 设计：让 AI 代理能读懂并正确调用

技能层的数据结构是整个项目最核心的设计决策。最初我们用了很随意的 JSON 结构，只有一个 name 和 description，结果 Agent 经常选错技能或者不知道怎么填参数。后来重构成一套完整的技能 Schema，才把这个局面扭转过来。

一个标准技能的字段结构大致如下：

这里最容易被忽略的是 description 和 trigger_conditions。很多技术团队把 description 写得特别学术，比如"该技能旨在辅助营销人员进行深度市场分析，通过收集并处理多维度数据，为决策提供支持"。这句话 Agent 看了等于没看。我们的写法应该更接近操作指令："当用户需要了解竞品策略时，使用本技能。输入为竞品名称，输出包括竞品的定位、核心卖点、内容渠道分布。"从实际表现看，描述写得越具体，Agent 的技能命中率越高。

input_params 的设计也要尽量结构化。不用让 Agent 凭感觉传一段长文本，而是拆成明确的字段，比如 product_name、target_group、channel，每个字段加解释，如"target_group：目标人群的描述，如 25-35 岁一线城市女性白领"。这样既方便 Agent 理解，也让后续的步骤执行有据可依。

2.2 营销方法论如何转化为技能步骤

技能库最考验"方法论转译"能力的地方，就是把抽象的营销理论变成 Agent 可执行的步骤。举个例子，内容营销里最经典的 AIDA 模型——注意、兴趣、欲望、行动，教科书里就是四行字：吸引注意、激发兴趣、唤起欲望、促使行动。但要变成技能步骤，你得把每个阶段细化成具体的操作指令。

我在项目里把 AIDA 模型做了一个技能化改造，大致长这样：

第 1 步 parsenotice：分析产品信息，提炼出最反差或最具冲击力的卖点事实，作为标题和开头的素材；第 2 步 buildinterest：围绕卖点设计一个具体生活场景，让目标用户产生代入感，输出场景描述；第 3 步 triggerdesire：列出至少 3 个购买理由，包括功能价值和情感价值，并说明目标用户对哪些卖点敏感；第 4 步 guideaction：设计明确的转化指令，比如"点击下方链接购买""扫码领取优惠券"，并配上紧迫感话术。

这个转化过程的关键，是不让 Agent 自由发挥，而是每一步都强制输出结构化字段。这样模型既保留了创意的灵活性，又不会跑偏。从实际生成效果看，按 AIDA 结构化的文案，转化率数据确实比自由发挥的文案更稳定，因为用户注意力路径是被设计出来的。

类似的，4P 理论也可以转成技能步骤：product 步骤要求输出产品的核心卖点和差异化特征；price 步骤要求结合成本、竞品价格和用户价格敏感度给出建议区间；place 步骤要求列出渠道偏好和触达路径；promotion 步骤要求设计推广节奏和活动形式。这些方法论在营销教科书里是概念，在技能库里变成了可执行的流水线，这是项目落地过程中最有价值的一环。

2.3 技能编排与多技能协作机制

单技能跑通并不能解决真实营销场景，因为一个完整任务往往会横跨多个技能。设计编排层时，我们自己内部讨论了几个候选方案，最后还是回到了"让 Agent 编排 + 技能库兜底"的模式。

具体来说，Agent 收到一个目标后，先把目标拆解成一系列子任务，然后从技能库里匹配每个子任务对应的技能，最后按依赖顺序执行。这里有一个反向依赖的问题需要处理：如果先做内容生成再做用户画像分析，那内容就是无源之水。因此编排时，技能之间需要声明依赖关系，比如"内容生成技能依赖用户画像技能的输出""投放建议技能依赖预算信息和竞品分析结果"。

我梳理了营销活动最常见的技能依赖链：用户画像分析技能 → 卖点提炼技能 → 内容生产技能 → 分发渠道匹配技能 → 回收数据分析技能。这条链几乎覆盖了大部分非实时营销任务。也遇到过反向情况，比如一个老客户的持续运营场景，没有明确的用户画像更新需求，Agent 可以从卖点开始走，不强制走完整链条。

多技能协作还有一个容易被忽略的问题：技能之间的上下文一致性。如果卖点提炼技能说"该产品主打便携性"，结果内容生成技能写出来的是"该产品功能强大"，用户一看就懵了。因此我们在设计上让每个技能的产出物都回写到共享上下文池，供后续技能读取。用简单话讲，技能库里必须有一个"公共记忆"，而不是让每个技能各做各的。

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

3.1 定义一个技能描述并注册到技能库

讲完设计，就直接进入实现环节。我在这个项目里主要用 Python 写了一套轻量级技能框架。核心部分是一个技能基类和注册器。先看技能定义的代码骨架：

from typing import Dict, List, Any import json class BaseSkill: """技能基类：所有营销技能的公共抽象""" skill_name = "" description = "" input_params = {} steps = [] output_format = {} def __init__(self, context_manager=None): self.context_manager = context_manager def validate_params(self, params: Dict[str, Any]) -> Dict[str, Any]: """校验输入参数是否有缺失""" missing = [k for k in self.input_params if k not in params] if missing: raise ValueError(f"缺少必要参数: {missing}") return params def run(self, params: Dict[str, Any]) -> Dict[str, Any]: raise NotImplementedError("技能子类必须实现 run 方法")

实际落地时，每个技能都是一个继承 BaseSkill 的类，run 方法里按 steps 顺序调用不同的模型能力或外部工具。比如内容生成技能里，pos-generation 这一步调大模型 API，scoring 这一步调规则函数。每一步的结果都写进一个 step_results 字典，最后包成统一的输出结构。

注册器比较简单，就是一个技能名到技能类实例的映射：

class SkillRegistry: def __init__(self): self._skills = {} def register(self, skill: BaseSkill): self._skills[skill.skill_name] = skill def get_skill(self, skill_name: str) -> BaseSkill: if skill_name not in self._skills: raise KeyError(f"技能 {skill_name} 未注册") return self._skills[skill_name] def list_skills(self) -> List[str]: return list(self._skills.keys())

写这块时最容易犯的错误，是把所有技能塞到一个模块里。技能数量一多，维护成本暴增。我后来按营销场景拆成多个子模块：内容生产类、用户研究类、投放优化类、数据分析类，每个子模块独立注册自己的技能。Agent 决策时，先按场景定位到子模块，再在更小的技能集合里做选择，命中率明显更高。

3.2 一个内容营销技能从 0 到 1 的实现示例

拿项目里一个典型技能——"电商产品种草文案生成"——来演示完整实现过程。先定义技能 Schema：

class ProductContentSkill(BaseSkill): skill_name = "product_seeding_copy" description = ( "当用户提供产品名称、目标人群和渠道信息，要求生成种草类文案时使用。" "本技能输出包含标题、正文三段落、关键词建议和转化行动引导。" ) input_params = { "product_name": {"type": "str", "required": True, "desc": "产品名称"}, "target_group": {"type": "str", "required": True, "desc": "目标人群描述"}, "channel": {"type": "str", "required": True, "desc": "内容渠道，如小红书/抖音/公众号"}, "product_highlights": {"type": "list", "required": False, "desc": "核心卖点清单"} } steps = [ {"step_name": "parse_intention", "desc": "理解用户任务目标，判断文案风格与调性"}, {"step_name": "extract_selling_points", "desc": "从产品信息中提取核心卖点，按重要性排序"}, {"step_name": "write_headline", "desc": "生成 3 个候选标题，要求包含数字或对比反差"}, {"step_name": "generate_body", "desc": "按 AIDA 模型生成正文内容"}, {"step_name": "review_quality", "desc": "对照质量检查规则自评并修正"} ] output_format = { "headline": "str", "body": "str", "keywords": "list", "cta": "str" }

schema 定义好后写执行逻辑。大致的 run 方法是这样的：

def run(self, params): self.validate_params(params) # 第 1 步：解析任务意图 intention = self.parse_intention(params) # 第 2 步：提取卖点 selling_points = self.extract_points( params.get("product_name"), params.get("product_highlights", []) ) # 第 3 步：生成标题 headlines = self.write_headlines(params, selling_points) # 第 4 步：生成正文 body = self.generate_body(params, selling_points, headlines[0]) # 第 5 步：质量自检 review_result = self.review_quality(body, params) if review_result["needs_revision"]: body = self.revise_body(body, review_result["suggestions"]) return { "headline": headlines, "body": body, "keywords": self.generate_keywords(selling_points), "cta": self.make_cta(params["channel"]) }

有一个特别值得说的小设计：write_headlines 这一步，不是只让模型输出一个标题，而是强制输出 3 个候选标题，再用一个简单规则函数筛掉明显不合格的候选——比如长度超过 25 个字的、包含敏感词的、与品牌调性严重不符的。这个"候选 + 规则筛选"的思路，比让模型一步到位要稳得多，因为模型第一步生成的标题往往偏平淡，有候选池再做一轮挑选，胜率会高不少。

generate_body 这一步也有讲究。我们不是让模型写完整篇，而是让模型先给出正文大纲，再把大纲拆成段落逐一生成。这样做的好处是生成的正文结构更稳定，不容易出现前后矛盾或逻辑断裂。每个段落生成时，会把上一段的内容摘要注入到上下文里，确保段落间衔接连贯。

3.3 Agent 如何选择技能并填充参数

技能库建好之后，真正考验的是 Agent 能不能在收到营销任务时正确选择和调用技能。我测试了很多种做法，最终稳定下来的是"用模型做调度 + 用结构化输出约束"。

调度时，Agent 不需要自己写执行代码，而是以 JSON 形式输出"调用意图"。每次收到用户消息，Agent 会思考这个任务需要什么结果，然后从技能库里匹配最合适的技能，并填充好输入参数。比如用户说"帮我写一篇新品润肤霜的种草文，发到小红书上，面向 20 岁左右的偏干皮女生"。Agent 会输出类似结构：

{ "intent": "call_skill", "skill_name": "product_seeding_copy", "params": { "product_name": "某品牌润肤霜", "target_group": "20-25岁干性皮肤女性", "channel": "小红书", "product_highlights": ["长效保湿", "不粘腻", "性价比高"] } }

这个 JSON 直接传给技能注册器，执行后把结果返回给 Agent，Agent 再包裹一层自然语言回复给用户。整套链路里，技术含量最高的其实不在调模型，而在把技能描述写得足够精准，让 Agent 一次就能选对技能、填对参数。如果技能描述模糊，Agent 就会频繁调用错误技能，或反复追问用户补充信息，体验会非常糟糕。

模型调度时还有一个细小但很实用的点：限定技能列表范围。几百个技能让 Agent 一次性选择，效果一般都不好。项目里我做了技能分组，先让 Agent 判断任务属于哪个二级场景，比如"内容生产""竞品分析""投放优化"。拿到场景后再只在场景内的 5 到 8 个技能里做精确选择。这样两次决策都很简单，准确率比一次性从大列表里选要高得多。

3.4 技能执行数据的回流与技能迭代机制

有了技能库，一个项目跑起来之后，很多人就以为大功告成了，但这恰恰是新一轮工作的起点。技能的产出质量会直接影响营销效果，而营销效果数据需要回到技能定义里，触发技能迭代。

我在这套系统里设计了一个轻量的数据回流模块。每次技能执行完成后，除了返回给用户的结果，还会记录一份执行日志，包括：技能名称、参数快照、输出结果、用户反馈或后续行为数据。这些日志会定期聚合分析，结合人工评估样本，生成技能改进建议。举例来说，某内容生成技能的文案点击率连续一周低于平均水平，就能定位到是哪一类标题结构拖了后腿。是"数字型标题"太多导致审美疲劳，还是"悬念型标题"与产品卖点不匹配？定位到具体问题后，再去调整技能里的步骤描述或质量检查规则。

回流机制要跑起来，有一个关键前提：技能产出的结果必须是结构化、可追踪的。如果 Agent 输出的是一大段自由文本，后面很难做数据归因。这也是我在前面的 Schema 设计里如此强调 output_format 的原因。运营数据回来时，才能精准地匹配到是第几步出了问题。有一次我们发现某短视频脚本技能生成的视频平均播放完成率偏低，排查下来是脚本里的"前 3 秒钩子"步骤没有强制执行。hooks 字段在输出格式里是可选，结果模型经常偷懒不写。我们把它改成必填项，并加了一条步骤级检查规则后，完成率数据明显回升。这个例子让我意识到，技能库不是一个静态字典，而是一套需要持续调优的决策引擎。

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

4.1 技能描述写得像论文，代理频繁选错技能

这是项目初期最头疼的问题。刚开始写技能描述时，我们的团队参照了很多学术资料，把描述写得又长又严谨。比如一个竞品分析技能，描述是"该技能基于市场竞争理论框架，通过对竞品品牌的多维度扫描与数据分析，输出竞品策略全景视图，为后续营销决策提供参考依据"。听起来很专业，实测效果很差：Agent 几乎不触发这个技能，就算触发了，也不太确定该传什么参数。

后来把描述改成大白话，效果立竿见影："当用户想了解对手怎么做营销时使用。输入竞品名称或网址。输出包括：竞品主推的卖点、主要的宣传渠道、近期内容方向、潜在的差异化机会。"这段描述改完后，Agent 的命中率提升了一大截。一个有用的自查方法是，把技能描述给一个完全不懂项目的新人看，如果他能不假思索地说出"什么时候用、传什么、返回什么"，这个描述才算合格。

4.2 技能步骤过于复杂，Token 开销失控

第二个高频坑是步骤细节越加越多，尤其是加了大量"思考提示词"之后，每次技能执行消耗的 Token 量大幅上升。比如一个简单的标题生成技能，里面塞了 6 步，每步都让模型先分析、再展开、再总结，结果生成 3 个标题烧掉了几千 Token。这对线上场景是不可接受的。

我的解决思路是把步骤分成两个等级：必要步骤和增强步骤。必要步骤保证技能最小可用，去除所有花架子；增强步骤只有在大模型判断当前情况需要时才触发。比如标题生成技能，必要步骤是"解析产品卖点"和"生成标题候选"，增强步骤才是"根据渠道风格微调"。大多数情况下，跑必要步骤就够了，Token 开销能减掉一半以上。另外一个降低消耗的实用技巧是，步骤之间的中间输出尽量用压缩格式，比如用要点列表而不是完整句子，模型下游步骤读起来更省 Token。

4.3 技能评估信号缺失，迭代无从下手

技能库上线之后，如果缺少有效的评估信号，就不知道改哪里、改完有没有用。这是最隐蔽也最致命的问题。很多团队把技能库当成一次性开发任务，做完技能就丢给运营，结果运营反馈"内容还是不稳定"，但没人能定位到具体环节。

我们用的办法是三层评估组合。第一层是规则检查：技能执行后自动校验输出是否包含必填字段、长度是否符合渠道要求、有没有触发敏感词库。第二层是模型作为评估者：每次技能执行后，用一个专门的评估提示词，让大模型对输出结果打分，比如按信息完整度、逻辑连贯性、品牌一致性三个维度打分，并输出修正建议。第三层是人工抽样复核：每天对实际执行的技能结果进行随机抽样，由运营同学打分并备注问题。这三层评估结果汇到一张表里，每周做一次归因分析，定位哪类技能、哪个步骤的失败率最高，然后针对性修改技能定义。

三层评估里面，规则检查的成本几乎为零，但价值很大。比如内容生成技能里，如果输出里缺少明确的产品名称，那这篇内容无论写得多么精彩，都是不合格的营销素材。模型评估者能捕捉语义层面的问题，但不完全可靠，人工复核虽然是成本最高的一环，却能在模型评估失效时兜底。三者各有适用场景，缺一不可。

排查技能库问题，可以对照下面这个速查表：

4.4 多技能协作时的冲突与优先级处理

当技能数量多了之后，Agent 可能会遇到"同一个任务能匹配多个技能"的情况。比如用户问"帮我把这个产品推给老客户"，触发的候选技能至少有"老客召回文案技能""会员运营活动技能""定向优惠推荐技能"。如果让 Agent 自己选，它经常会选错，因为它只知道几个技能的简介，不一定能分清各自的使用边界。

我们后来给每个技能增加了优先级字段，比如 level 1 代表该技能是首选，level 2 需要在特定条件下才使用，level 3 是兜底方案。同时，在技能流程里预埋了下一级技能的推荐指引，让编排层能按"当前技能完成 → 推荐后续技能"的方式推进。例如，老客召回文案生成完成后，推荐"优惠券配置技能"和"触达效果回收技能"。这样把一部分编排逻辑下沉到技能层，Agent 的决策压力会小很多。

还有一个很实际的问题：两个技能产出内容互相矛盾。最典型的场景是"数据分析技能"说某个渠道效费比偏低，建议减少预算投入；"内容运营技能"却认为该渠道的内容潜力巨大，建议加大投入。遇到这种冲突，单靠技术手段很难完全消除，我的做法是在编排层加一个调和器，把两个技能产出同时展示出来并标注"建议人工审核"。营销决策本身就有主观判断成分，不必强行用模型做裁决，承认系统边界反而能避免很多无意义的模型调优。

回看整个 Marketingskills 项目的落地过程，我最大的感受是：技能库的技术骨架不是最难的，难的是把营销经验以结构化、可执行、可评估的方式"翻译"给模型。这个过程需要既懂营销方法又有工程落地能力的人反复打磨，甚至要经历好几轮上线、反馈、再调整的循环，技能库才能从一个理论框架变成真正能提效的生产工具。另外一个小技巧是，建技能库时别贪多求全，先选一两个最高频、ROI 最明显的营销场景跑通闭环，验证了评估和迭代机制有效之后，再大规模扩充技能列表，省时省力得多。希望这篇拆解能帮你在搭自己这套体系时少走些弯路。