企业官网建设流程全解析

做了大半年 AI 代理营销，我发现最折磨人的不是模型不够聪明，而是经验根本留不住。团队里攒了一堆 Prompt，可换个产品、换个场景就全失去参考价值；后来我们决定不再给 Agent 堆 Prompt，而是直接给它建一座营销技能库。所谓营销技能库，就是把营销场景中反复出现、验证过有效的能力，封装成标准化、可调用、可复用的功能单元。这个决定，让整个项目组的工作方式彻底改变了。这篇就把我搭 Marketingskills 项目时摸出来的技术路径、架构设计和实战经验摊开讲一遍，适合正在做 AI 营销落地的技术团队，也适合被“Prompt 越来越长但效果越来越飘”困扰的业务同学参考。

1. 为什么要给 AI 代理建“技能库”，而不是继续调 Prompt

1.1 从零散 Prompt 到可复用资产

很多团队接触 AI 营销，都会经历三个阶段。第一阶段是把 AI 当成问答盒子，问一句答一句，图个新鲜。第二阶段是有人开始用长 Prompt 批量生成内容，一条活动文案能写出三千字的提示词。第三阶段最崩溃——Prompt 模板多到没人维护，换个产品线、换个渠道，原先那套直接失效，所有人又开始从头写了。

我们团队盘过一遍历史记录，高峰期超过三成的 Prompt 都在重复描述同一类场景，比如“用正式语气写一条促销通知”“根据用户画像生成一句话卖点”，看着不同，内核几乎是一样的。这就是典型的重复造轮子：营销场景本质上不是一个问答问题，而是一个多步骤任务问题。比如“帮我写一篇官微推文”，背后是选题确认、素材检索、语气判断、合规检查、渠道格式适配等一系列动作。传统 Prompt 把所有这些逻辑全塞进一段文字里，模型一边理解一边推理，既慢又不稳定。

所以后来我们换了个思路，借鉴代码工程里的“函数封装”理念：把某个稳定可靠的流程封装起来，对外只暴露输入和输出。调 Prompt 是让模型每次“即兴发挥”，技能库则是让模型每次执行同一套被验证过的流程。前者靠运气，后者靠体系。

1.2 “技能”与“工具”的本质区别

这里必须先纠正一个容易混淆的概念：技能不等于工具，更不等于 API 调用。

工具层负责的是“把消息发出去”“把数据查出来”这种原子动作；技能层则要回答“该不该发、发给谁、用什么话术发、发了之后怎么评估”。举个例子，发送一条促销推送，工具层只负责调用消息接口。技能层要处理的是：判断当前人群是否合适接收、提炼产品卖点、生成文案、选择头图、检查价格表达是否合规、如果预估打开率低就自动修改重试。这些不是 API 能提供的，它们是营销经验本身。

用一个生活化的类比：工具层好比厨房里的锅碗瓢盆，技能是餐厅的标准化菜谱和火候经验。锅再高级，没有菜谱和手艺，也做不出稳定味道。我们一开始把大量精力花在接 API 上，后来才发现真正值钱的是把业务经验沉淀成技能，工具接入只是地基。

2. 技能库的整体架构：场景、技能、工具三层怎么拆

2.1 场景层：营销任务的入口

在设计 Marketingskills 时，我们把技能库拆成了三层：场景层、技能层、工具层。最上面是场景层，它面向业务，解决“用户想干什么”的问题。

营销需求五花八门，但归类下来就那几类：内容生产、受众洞察、投放执行、数据复盘、线索运营。每个大类再往下细分。场景层的作用是任务映射：业务同事说“帮我对这次活动做个复盘”，场景层把这个需求翻译成“数据回收→指标对比→归因→报告生成→汇报调整”的执行链路，然后交给技能层。

这里有个教训：场景分类切忌太细。我们第一版分了 45 个场景，结果一半没人用，Agent 选场景时还经常犹豫。后来砍到 12 个高频场景，覆盖了大约 80% 的日常任务，选错率明显下降。技能库的入口要尽量简单，复杂度应该藏在内部，而不是扔给使用者。

2.2 技能层：能力原子与编排模板

技能层是整个项目的核心资产。我们先做了一步“能力原子化”：把业务需求拆成最小可复用的能力单元。比如生成标题、提炼关键词、判断内容合规、选择投放时段、生成报告摘要，每个原子技能只负责一件事。然后再把原子技能拼成工作流模板。

举一个实际案例。新品推广的自动执行模板是“受众洞察→内容生成→合规审核→渠道发布→数据回收”五个节点，每个节点挂对应的原子技能。这样设计最大的好处是，可以替换单点技能而不重写整条链路。比如把“内容生成”升级成“内容生成并带 A/B 版本”，模板其他部分不需要动。技能层就像乐高积木，原子技能是标准件，工作流模板是拼装图纸。

2.3 工具层：异构 API 的统一网关

技能要落地必须调外部系统。我们把邮件、广告平台、CRM、数据仓库等系统统一接入一个工具网关，对外提供标准接口协议。工程上必须解决三件事：

• 统一的鉴权和租户隔离，避免不同技能之间越权访问数据。
• 统一的限流和熔断，防止某个技能调用异常拖垮外部系统。
• Mock 环境支持，让技能在无外部依赖的情况下也能跑通测试。

我当时的体会是，千万别小看工具层。技能库的稳定性天花板不在模型，而在网关。某个外部平台升级了 API 版本，如果网关适配没跟上，所有依赖这个接口的技能会同时失效。这种情况我们至少碰上过两次，每次都是半夜被叫起来处理。

3. 技能描述与执行引擎：让代理“看得懂、调得动、准得狠”

3.1 技能描述文件的 Schema 设计

Agent 能选对技能，前提是技能描述足够清楚。我们为每个技能维护一份 JSON 描述文件，结构大致长这样：

{ "skill_id": "content_wechat_generator_v2", "name": "微信公众号推文生成", "description": "根据产品卖点、受众画像和活动目标，生成一篇符合品牌语气的微信公众号推文。适用于新品发布、活动预告、节日问候。", "input_schema": { "product_name": "string", "target_audience": "string", "campaign_goal": "string", "tone": "enum[sophisticated, friendly, professional]" }, "output_schema": { "title": "string", "content": "string", "suggest_cover": "string", "compliance_status": "string" }, "required_permissions": ["crm:read_audience", "content:suggest_cover"], "quality_metrics": { "readability_min": 60, "compliance_required": true }, "fallback_policy": "如果合规校验未通过，返回修改建议并停止发送" }

这里面每一行都有用意。description 字段写清楚适用场景和反例，防止 Agent 选错技能；input_schema 和 output_schema 把参数边界定死，执行时不会出现参数漏传、类型错乱；required_permissions 是权限声明，网关运行时强制校验；fallback_policy 告诉 Agent 出问题时的处理方向。

我们做过一次对比实验：描述里只有一句话的技能，被误选率高达 22%；补全 schema、适用场景和反例之后，误选率降到 3% 以下。这个数据说明，技能描述不是写给人看的文档，而是模型决策的关键上下文。写得越细，Agent 判断越准。

3.2 意图路由与动态编排策略

技能库里的技能一多，Agent 必须决定“这次任务该用哪几个技能”。我们的方案是用语义检索做意图路由：事先把技能描述向量化存进向量库，Agent 接到任务后先做语义检索，选出 Top-K 个候选技能，再交给模型做最终选择。这样既节省 token，又能减少模型在几百个技能里乱翻的噪音。

但选对技能只是第一步，真正执行时还要动态编排。我们的执行引擎允许 Agent 在节点之间做判断和回退。比如发现“受众洞察”的结果异常，样本量过低，就不再往“内容生成”走，而是先触发数据修复技能，把数据质量问题解决掉再继续。营销链路充满不确定性，死板的流水线效果很差，带判断回退机制的编排才实用。

3.3 执行过程中的超时、降级与重试

营销场景对时效要求差异极大。投放素材生成可能是秒级要求，日报分析则可以容忍分钟级。所以每个技能必须单独配置超时和重试策略。我们常用的故障处理策略如下表：

特别说一下“合规拦截”这一行。很多人把拦截当成失败，其实对营销来说，被拦下来本身就是保护。技能库设计里要把“被拦截之后怎么办”想清楚，而不是让 Agent 偷偷绕过去。我们的方案是：技能返回明确修改建议，由业务人员确认后再重跑，绝不让它自行绕过审核逻辑。

4. 营销技能从需求到上线的完整流转链路

4.1 需求拆解与技能立项

技能不是凭空设计出来的，是从业务需求里长出来的。但营销需求的原始表达通常很模糊，比如业务同事说“文案要高级一点”，什么是高级？是极简用词还是多写修辞？是强调权威感还是亲切感？我们在需求拆解阶段必须做两件事：翻出过去几个月的人工案例；把业务表述翻译成可量化的评估标准。

比如“高级一点”最终被拆成“减少感叹号使用”“避免网络流行语”“多采用短句和名词短语”。只有把需求变成可验证的评估标准，技能才有验收依据。我们内部立过一条规矩：技能立项文档里必须写清楚“通过标准”，写不出来的技能不开发。

4.2 技能开发与测试：功能、风格、合规三类测试集

技能在语义上像功能，本质上是一个“带推理能力的程序”。所以测试也要分三层：

• 功能测试：技能能否完成既定动作，参数映射是否正确，工具调用是否成功。
• 风格测试：生成内容是否贴合品牌语气，是否有明显的“AI 腔”。
• 合规测试：是否触碰业务禁忌、敏感表达、价格法规边界。

我们内部规定，技能上线前要同时通过三关：功能通过率不低于 90%，风格通过率不低于 80%，合规正确拦截率达到 100%。其中合规是硬底线，没有商量余地。

这里有一个真实教训：某技能在灰度阶段写出了“限时抢购”加具体两小时期限的文案，但业务规则不允许这样表达。当时测试集里没有覆盖这个场景，漏掉了，差点上线。后来我们把促销时限规则细化进合规测试集，并建立正反例对照库，这类问题基本消失了。

4.3 灰度发布与效果回收

技能全量上线之前，我们会先选一个低风险、低价值的渠道做灰度。灰度期间收集三类数据：功能成功率、效果指标、人工干预率。效果指标具体看场景，内容生成看点击率，投放技能看转化率和成本，线索运营看留资率和响应速度。

灰度数据不达标，技能就不能上。比如“标题生成”技能第一次灰度，点击率比人工写的低 12%，我们就没放量，而是回头调整了样本库和描述规则，跑第二轮灰度才通过。这里有一个技术团队很容易掉进去的坑：只看调用成功率和响应速度，忽略了业务效果指标。结果就是技能库看起来跑得很顺，业务增长却一点没体现。

5. 技能库的最大隐患：质量、合规与品牌一致性

5.1 品牌语气一致性问题的根源

技能库用久了，会发现一个让人头疼的问题：AI 生成的内容看起来能用，但总觉得不像自己团队写的。品牌语气本质上是一种隐性知识，模型的预训练语料里什么风格都有，仅靠 Prompt 描述很难稳定复现某个品牌独有的语气。

我们的解法是把品牌语气拆成“正样本 + 反样本 + 表达规则”的三元组。比如某零售品牌的语气是“专业但不冷冰冰”，正样本库里收录那些“用通俗名词解释概念，而不是堆学术术语”的合格文案；反样本库里记录“过于亲密的网络用语”“权威命令式语气”等不合格表达。技能执行时自动检索这些样本做 few-shot 参考，而不是每次让模型从零理解品牌是什么样。实测下来，这种做法的稳定性比直接改 Prompt 高得多。

5.2 人审与机器评审双轨机制

营销内容直接面向用户，全自动发布的风险太大了。我们搭了机器初审加人工抽审的双轨机制。机器先跑一轮：可读性评分、敏感词检测、事实一致性抽查；人工再抽：普通场景抽检 5%，高影响场景比如核心用户推送、站内信、大促主视觉文案，抽检比例提到 100%。

这里要强调一个认知：人审不是技能库的敌人，而是技能迭代的数据来源。每次人审的修改意见，我们都结构化整理成规则，回填到技能的知识库里。比如人工把“优惠力度很大”改成了“立减 30 元起”，这个修改信息就进入技能库，下次生成时优先采用具体数字表达。人审越审，技能越准，这才是一个正向循环。

5.3 负面清单与敏感词审计机制

技能库真正的“质检老师”是踩坑记录。我们维护着一张持续更新的负面清单：哪些词不能用，哪些句式容易引发用户投诉，哪些价格表达不被允许。这张清单由运营、法务、客服团队定期同步，动态进库。

同时，每个技能都带着完整审计日志：谁改过、为什么改、灰度数据如何、有没有回滚记录。很多团队不做审计日志，三个月后技能库就变成一个没人敢动的黑匣子。我们吃过这个亏——某次排查线上问题，翻遍历史版本，根本不知道是哪个改动引入了 bug。自那以后，审计日志就成了技能库的强制配置，没有日志的技能不允许上线。

6. 落地踩坑记录：我在部署技能库时遇到的几个真问题

6.1 技能响应过慢，广告投放等不起

我们的内容生成技能第一次上线，就栽在速度上。调用一次平均 3 秒，p95 冲到 6 秒。投放团队遇到热点事件，根本等不起这个速度，直接跑回人工。后来做了三件事优化：预热高频素材缓存；把“一步生成”拆成“轻量模型出初稿 + 大模型润色”，初稿 100 毫秒出，润色异步进行；把生成要求从“一次十个版本”改成“一次一个最优版本”。优化后 p95 从 6 秒压到 1.8 秒，投放团队才真正愿意用。

这件事暴露的本质问题是：技术团队自测只看平均响应时间，业务真正在意的是尾部延迟。技能库的性能优化，目标不是把平均值做得好看，而是把最慢的那 5% 压下来。

6.2 数据权限和内容审核的边界

技能库调用数据这件事，比想象中敏感得多。一开始我们让 Agent 在描述里自由声明要访问的数据，结果出现了越权风险——某个技能声明要读全量 CRM 数据，实际只用其中一个字段。后来改成“技能权限清单”机制：每个技能上架前，由数据负责人审批它的数据访问对象和操作范围，网关运行时强制校验。

权限这里省不了事。营销 Agent 看起来只是发发消息，但它能接触到的数据包括用户标签、订单记录、联系方式，敏感级别很高。我们后来加了敏感字段脱敏中间层，即使技能参数写错了，也只能拿到脱敏后的数据，从根源上堵住越权漏洞。

6.3 版本耦合问题：技能库与模型版本如何同步

模型升级对技能库的影响，比大多数人预想的大。换上新模型后，一批技能的风格测试通过率明显下降——新模型写得更“放飞自我”，不那么贴合品牌语气。原因很简单，技能是在特定模型版本上调教出来的，换模型等于换了底层的“性子”。

我们的对策是建立“模型亲和版本矩阵”，记录每个技能验证过的模型版本。升级模型之前必须做全量回归测试；同时加了一键回退机制，某技能表现异常时，不用改任何技能代码，直接把整条链路的“技能版本 + 模型版本”回退到上一个稳定组合。营销场景一旦出现内容投放事故，处理窗口可能只有几分钟，这个回退能力是保命的。

6.4 效果不佳时先别改代码：警惕“技能库退化”

技能库越用越差，是件反直觉的事。但这是真实存在的“技能库退化”现象。根源在于技能库在膨胀：当库里有两百多个技能、大量技能职责重叠时，Agent 开始出现“选择犹豫”，同类技能反复换来换去，输出越发不稳定。

我们定了一个技能淘汰机制，按三个维度打分：30 天调用次数、人工干预率、效果指标变化。调用少、干预多、效果没有提升的技能，进入观察期；连续两个周期没有改善，直接下架。维护技能库的人要敢于删技能，因为营销技能有生命周期和时效性，一年前好用的促销话术，今年可能已经完全不合规了。与其留着一个行为不明的技能持续制造噪音，不如果断清掉。

如果再让我重做一遍 Marketingskills，我会从最核心的高频场景开始，先用十个技能把闭环跑通，再逐步扩展规模。最后分享一个容易忽略的小技巧：技能库的效果指标，不要只看生成速度和调用成功率，一定要绑定业务指标，否则团队很容易自我感觉良好。营销技能库是一个长期工程，真正的门槛不在模型选型，而在于能否持续把一线业务经验，转成可验证、可复用、敢下线的资产。