企业官网建设流程全解析

1. 项目缘起与核心定位

第一次看到 Marketingskills 这个项目名的时候，我脑子里蹦出来的第一个念头是：终于有人把营销这件事拆成可复用的技能模块了。过去两年我一直在折腾 AI 代理相关的落地项目，从客服机器人到内容生成助手，踩过最大的坑不是模型能力不够，而是代理不知道在什么场景下该调用什么能力。你给它一个"帮我写个推广文案"的指令，它要么给你一段四平八稳的废话，要么直接跑偏去写产品说明书。问题的根子在于，我们把营销当成一个整体任务丢给模型，而没有把它拆解成一个个边界清晰、输入输出明确的技能单元。

Marketingskills 这个项目要解决的就是这个问题。它本质上是一个面向 AI 代理的营销技能库，把营销工作中那些高频、可标准化、有明确交付物的环节，抽象成一个个独立的技能模块，每个模块定义清楚触发条件、输入参数、执行逻辑和输出格式。代理在运行时根据用户意图匹配对应技能，按需调用，而不是靠一个大模型硬扛所有任务。这套思路跟我之前做自动化工作流时的"原子能力"设计理念是一脉相承的，只不过这次把原子能力换成了营销领域的专业技能。

这个项目适合谁来参考？我梳理了三类人。第一类是正在做 AI 代理产品化的开发者，尤其是那些发现通用代理在垂直场景下表现不稳定的团队，技能库的思路能帮你把不确定性收敛到可控范围。第二类是营销团队里负责工具建设的人，你可能不写代码，但你需要理解技能库的组织逻辑，才能把团队的经验沉淀成可复用的资产。第三类是对 AI 应用感兴趣的产品经理，这个项目提供了一个很好的样本，展示了如何把领域知识结构化成机器可调用的形式。

核心关键词我提炼几个：技能抽象、代理调度、营销场景拆解、输入输出契约、可复用资产。这几个词贯穿整个项目的设计始终，后面每个章节我都会围绕它们展开。先给个整体判断：这个项目的价值不在于技术有多深，而在于它把"营销"这个模糊的大概念，用工程化的方式切成了可管理的小块，这个思路本身就值得借鉴，哪怕你不做营销领域的代理。

2. 技能库的整体架构与设计思路

2.1 为什么选择"技能"而不是"工具"或"插件"

这里有个设计决策值得掰开说。市面上很多代理框架用的是"工具调用"（tool calling）或者"插件"（plugin）的概念，为什么这个项目偏偏选了"技能"这个词？我琢磨了一下，发现这不是文字游戏，而是三种不同的抽象层级。

工具是能力视角的，比如"搜索""计算""读写文件"，它描述的是代理能做什么动作。插件是集成视角的，强调外部服务的接入，比如"接入某内容平台""接入某数据分析服务"。而技能是任务视角的，它描述的是"完成一件有业务意义的事"，比如"生成一份产品卖点清单""把长文改写成三条社媒短文案"。

这个区别很关键。工具和插件解决的是"能不能做"的问题，技能解决的是"做得对不对、全不全"的问题。一个营销技能内部可能调用了搜索工具、文本生成工具、格式化工具，但对上层代理来说，它只需要知道"我要执行这个技能，给它这些输入，拿到符合规范的输出"。这种封装带来的好处是，代理的调度逻辑可以保持简单，复杂度被下沉到技能内部。

我实测下来的感受是，当代理需要处理的任务超过二十种时，纯工具调用的方式会让调度变得极其混乱，模型经常选错工具或者组合错顺序。而技能库因为每个技能对应一个完整的业务闭环，匹配准确率明显更高。这背后的逻辑其实很朴素：任务粒度越接近人的认知单元，模型的理解成本越低。

2.2 技能库的分层结构

项目把技能库分成了三层，我按自己的理解重新梳理一下。

最底层是原子技能层，这些技能只做一件事，输入输出都很窄。比如"提取产品核心卖点""识别目标人群画像""生成标题候选"。这一层的技能数量最多，但每个都很轻，执行快，容易测试。

中间层是组合技能层，它把多个原子技能按固定流程串起来。比如"生成完整推广文案"这个组合技能，内部会依次调用卖点提取、人群匹配、语气调整、结构生成几个原子技能。这一层是给代理直接调用的主力，因为它对应的是用户能感知到的完整任务。

最上层是策略技能层，这一层比较特殊，它不直接产出内容，而是决定"在什么情况下用哪个组合技能"。比如"根据渠道特性选择文案风格"这个策略技能，它会根据输入里的渠道参数，决定是走"短平快"路线还是"深度种草"路线，然后路由到对应的组合技能。

这个分层设计的好处是复用和隔离。原子技能被多个组合技能共享，改一处就能影响所有上层；策略技能的变化不会污染内容生成逻辑。我在自己的项目里也用过类似的分层，最大的体会是：分层不是为了好看，而是为了在需求变化时，你能快速定位到该改哪一层，而不是牵一发动全身。

2.3 技能描述文件的结构

每个技能在项目里都是一个独立的描述文件，我把它拆成几个核心字段来看。

• 技能标识：唯一名称，代理靠这个来引用技能。
• 触发意图：用自然语言描述"用户在什么情况下该用这个技能"，这是给代理做匹配用的。
• 输入契约：明确列出需要哪些参数，每个参数的类型、是否必填、示例值。
• 执行逻辑：技能内部的处理步骤，可以是调用模型，也可以是调用其他技能。
• 输出契约：规定输出的结构，比如是纯文本、JSON 还是带标记的富文本。
• 质量校验：输出前需要满足的检查条件，比如字数范围、关键词覆盖、禁用词过滤。

我特别想强调输入输出契约这一块。很多团队做技能库失败，就是因为契约定义得太模糊，代理传进来的参数五花八门，技能内部要做大量防御性判断，最后代码里全是 if-else。把契约写死，看起来是限制了灵活性，实际上是换来了可预测性。代理知道该传什么，技能知道该收什么，出问题时能快速定位是调用方传错了还是技能内部处理错了。

提示：契约字段建议用结构化格式（如 JSON Schema）来定义，而不是纯文字描述。结构化定义可以被程序自动校验，也能直接生成给模型看的提示词，一举两得。

3. 核心技能模块的拆解与实现要点

3.1 卖点提取技能的实现细节

卖点提取是营销技能库里最基础也最关键的原子技能。它的任务是从一段产品描述里，抽出可以被用于推广的核心卖点。听起来简单，但实际做起来坑不少。

我看了项目里的实现思路，它没有直接让模型"提取卖点"，而是分了三步走。第一步是信息清洗，把产品描述里的技术参数、内部术语、无关背景先过滤掉，只保留面向用户的价值信息。第二步是价值归类，把清洗后的信息按"功能价值""情感价值""社交价值"三个维度分类。第三步才是卖点生成，针对每个维度生成一句用户能听懂的话。

为什么要这么绕？因为直接提取的话，模型很容易把"采用某某工艺"这种内部视角的表述当成卖点，但用户根本不关心工艺，用户关心的是"这个东西能帮我省多少时间"。三步走的方式强制模型先做视角转换，从"我们做了什么"转到"用户得到什么"。

实操中我建议在输入契约里加一个目标人群参数，哪怕是可选的。因为同一个产品对不同人群的卖点排序完全不同。给职场人的卖点是"效率提升"，给宝妈的卖点可能是"省心省力"。如果技能不接收这个参数，生成的卖点就会很泛，谁看了都觉得跟自己关系不大。

输出格式上，项目用的是带权重的列表，每个卖点附带一个 0 到 1 的置信度分数。这个设计很实用，代理在后续组合时可以优先用高分卖点，低分的作为备选。我自己的经验是，置信度分数不要直接展示给用户，但一定要在技能间传递，它是下游决策的重要依据。

3.2 人群画像匹配技能的关键参数

人群画像匹配这个技能，负责把产品卖点和目标人群对应起来。它的输入是卖点列表和人群描述，输出是"哪些卖点适合哪些人群"的匹配矩阵。

这里有个参数设计我觉得很巧妙，叫人群颗粒度。它控制画像的精细程度，取值可以是"宽泛""中等""精细"三档。宽泛档只区分大类别，比如"年轻女性""中年男性"；精细档会细化到具体场景，比如"一线城市通勤时间超过一小时的职场新人"。颗粒度越细，匹配越准，但生成成本越高，而且过细的画像可能导致覆盖人群太少。

项目里给的经验值是：做内容种草用精细档，做品牌曝光用宽泛档，做效果广告用中等档。这个对应关系背后的逻辑是，种草需要精准击中特定人群的痛点，曝光需要覆盖足够广的人群，效果广告要在精准和规模之间找平衡。这个经验值不是拍脑袋来的，是大量投放数据反推出来的，我觉得很有参考价值。

匹配矩阵的输出格式也值得说一下。它不是一个简单的对应关系，而是一个二维表，行是卖点，列是人群，交叉点是匹配度分数。代理拿到这个矩阵后，可以选择"为每个人群生成一套文案"，也可以选择"找出匹配度最高的卖点人群组合重点打"。这种灵活性是靠输出结构的设计换来的，如果只输出一个平铺的列表，下游就没法做这种选择。

3.3 文案生成技能的结构化输出

文案生成是组合技能，内部会调用前面两个原子技能。它的输出不是一段纯文本，而是结构化的文案包，包含标题候选、正文、行动号召、话题标签几个部分。

我特别欣赏它对标题候选的处理。它一次生成五到八个标题，每个标题标注风格类型（比如"疑问式""数字式""对比式"）和适用渠道（比如"适合信息流""适合搜索""适合社群"）。这样代理在投放时可以根据渠道特性直接筛选，不用再跑一次模型判断。

正文部分用的是分段标记的方式，每段前面标注这段的功能，比如"痛点引入""解决方案""信任背书""行动号召"。这种标记对后续的自动化排版和 A/B 测试非常友好。你可以只替换"痛点引入"这一段，其他保持不变，快速测试不同痛点的效果。如果输出是一整块文本，做这种局部替换就得靠人工切分，效率差很多。

行动号召部分有个细节，项目要求必须包含明确的下一步动作和低门槛的理由。比如"点击下方链接领取试用装"就比"欢迎了解我们的产品"要好，因为前者告诉用户具体做什么，后者只是礼貌性收尾。这个要求在技能的质量校验里是硬性条件，不满足会触发重新生成。

注意：结构化输出虽然好用，但会增加模型的输出长度，进而增加成本和延迟。我的建议是只在组合技能层做结构化，原子技能层保持轻量。如果每个原子技能都输出一大堆结构，组合起来会非常臃肿。

3.4 渠道适配技能的路由逻辑

渠道适配是策略技能层的典型代表。它不生成内容，而是根据渠道参数，决定用哪套内容策略。

项目里支持的渠道类型包括信息流、搜索、社群、短视频脚本、邮件等。每个渠道在技能库里对应一组内容偏好参数，比如信息流偏好短句和强钩子，搜索偏好关键词密度和问题解答结构，社群偏好口语化和互动引导。

路由逻辑是这样的：代理传入渠道类型和基础内容，渠道适配技能先查该渠道的偏好参数，然后判断基础内容是否符合，不符合就调用对应的改写技能进行调整。比如基础内容是长段落，而目标是信息流，就会触发"长句拆短"和"前置钩子"两个改写动作。

这个设计的好处是渠道知识被集中管理。当某个渠道的算法偏好发生变化时，只需要更新这个渠道的偏好参数，所有走这个渠道的内容都会自动调整，不用去改每个生成技能。我在做多平台内容分发时深有体会，渠道规则变化是常态，如果规则散落在各个技能里，维护成本会高到让人放弃。

4. 代理调度与技能匹配的实操机制

4.1 意图识别与技能召回

代理拿到用户请求后，第一步是识别意图，然后从技能库里召回候选技能。项目用的是两阶段召回：先用关键词和向量相似度做粗筛，召回十个左右的候选；再用一个小模型对候选做精排，选出最匹配的两到三个。

粗筛阶段的关键是触发意图的描述质量。如果触发意图写得太窄，比如只写"生成产品文案"，那用户说"帮我写个推广语"就可能召回不到。项目里的做法是每个技能配五到十条同义触发句，覆盖不同的表达方式。这些触发句不是随便写的，是从真实用户请求里聚类出来的高频表达。

精排阶段用的是场景匹配度打分，考虑的因素包括：请求里是否包含技能必需的输入参数、请求的紧急程度、历史调用成功率等。这个打分模型不需要很大，项目里用的是轻量级的分类模型，推理速度快，够用就行。

我自己的经验是，召回阶段宁可多召回一些，也不要漏掉。因为精排的成本远低于漏召回导致的失败。但召回太多也会增加精排负担，十个左右是个比较平衡的数字。

4.2 技能执行的参数填充

召回并选定技能后，代理需要把用户请求里的信息填充到技能的输入契约里。这一步最容易出问题，因为用户请求往往信息不全。

项目的处理方式是参数分级：必填参数缺失时，代理会主动向用户追问；可选参数缺失时，用技能定义的默认值填充。追问的话术也有讲究，不能一次问一堆，而是按重要性逐个问，每次只问一个。

举个例子，用户说"帮我写个文案"，代理识别到文案生成技能需要"产品信息"和"目标人群"两个必填参数，就会先问"请问是哪个产品的文案"，拿到后再问"主要想吸引哪类人群"。这种逐个追问的方式，用户完成率明显高于一次性列出所有缺失项。

参数填充还有个细节是类型转换。用户说的"年轻人"要转成技能能理解的人群标签，"这周内"要转成具体日期范围。项目里维护了一个轻量的映射表来处理常见转换，复杂的转换则调用专门的解析技能。这个映射表是逐步积累的，一开始不用追求全覆盖，遇到一个补一个就行。

4.3 多技能串联的执行顺序

当一个任务需要多个技能协作时，执行顺序就变得重要。项目用的是依赖图的方式，每个技能声明自己依赖哪些技能的输出，调度器根据依赖关系拓扑排序，决定执行顺序。

比如"生成完整推广方案"这个任务，依赖图是这样的：卖点提取和人群匹配可以并行，因为它们互不依赖；文案生成依赖前两者的输出，必须等它们完成；渠道适配依赖文案生成，排在最后。调度器识别出这个结构后，会先并行跑前两个，再串行跑后两个，整体耗时比全部串行少很多。

这里有个坑我要提醒：并行执行的技能如果有共享状态，要特别小心。比如两个技能同时往同一个上下文里写数据，可能互相覆盖。项目的做法是每个技能的输出写到独立的命名空间，下游技能按命名空间读取，避免冲突。这个设计在技能数量少的时候看不出价值，一旦超过十个技能，没有命名空间隔离会乱成一锅粥。

4.4 输出校验与失败重试

技能执行完不代表任务结束，还要过质量校验这一关。项目里的校验分两类：格式校验检查输出是否符合契约定义的结构，内容校验检查是否满足业务规则，比如禁用词过滤、字数范围、关键信息覆盖。

校验不通过时，不是简单重试，而是带反馈重试。系统会把校验失败的原因作为额外输入，重新调用技能。比如输出里缺少行动号召，重试时就会在提示里强调"必须包含明确的行动号召"。这种带反馈的重试，成功率比盲目重试高得多。

重试次数项目里设的是两次，两次还不过就降级处理，要么返回部分结果并标注问题，要么转人工。这个阈值是根据成本和质量平衡定的，重试太多次成本受不了，一次不重试质量又没保障。我实测下来两次是个比较合理的值，大部分问题第一次重试就能解决。

5. 常见问题排查与避坑经验

5.1 技能匹配不准的排查思路

技能匹配不准是最常见的问题，表现是代理选了不合适的技能，或者该选的时候没选。排查我一般按这个顺序走。

先看触发意图描述是否覆盖了用户的实际表达。把匹配失败的请求收集起来，跟技能的触发句对比，看是不是表达方式差异太大。如果是，补充触发句就行。这个工作要持续做，因为用户的表达方式会不断变化。

再看精排模型的打分是否合理。把候选技能的打分打出来，看是不是某个不相关的技能分数异常高。如果是，检查这个技能的训练样本是不是有偏差，或者它的触发意图写得太宽泛，把别人的活也揽过来了。

最后看参数填充是否失败。有时候技能选对了，但必填参数没填上，导致执行失败被误判为匹配问题。这种情况要在日志里区分开，不然会误导排查方向。

5.2 输出质量波动的稳定化手段

同一个技能，同样的输入，两次输出质量差很多，这是模型应用的固有问题。项目里用了几个手段来稳定质量。

温度参数调低是最直接的，生成类技能的温度一般设在 0.3 到 0.5 之间，既保留一定多样性，又不至于太飘。但温度太低会导致输出千篇一律，所以项目里对不同技能设了不同的温度，创意类的高一点，规范类的低一点。

少样本示例是另一个有效手段。每个技能配三到五个输入输出示例，放在提示词里。示例的质量很关键，要选那种"典型但不平庸"的，太普通的示例模型学不到东西，太特殊的示例又会把模型带偏。

输出后处理兜底。比如统一标点符号、修正明显的语法错误、补全缺失的结构字段。这些处理不依赖模型，是确定性的规则，能消除一部分波动。我自己的项目里，后处理规则积累了上百条，虽然每条都很简单，但合起来对稳定性的提升非常明显。

5.3 技能库膨胀后的管理策略

技能库用久了会膨胀，从十几个变成几十个甚至上百个。这时候管理就成了问题：重复的技能、过时的技能、很少用的技能混在一起，召回效率下降。

项目里的做法是定期做技能审计，按调用频率和成功率给技能打分，低分技能进入观察期，观察期内还没起色就下线。下线不是删除，而是归档，需要时可以恢复。

技能合并也很重要。经常发现两个技能有八成逻辑重叠，只是输入输出略有差异。这种情况应该合并成一个技能，用参数来区分差异，而不是维护两份代码。合并的判断标准是：如果两个技能的差异可以用一个枚举参数表达，就该合并；如果需要改内部逻辑，就保持独立。

版本管理不能少。技能更新时保留旧版本，新版本先小流量跑，确认没问题再全量。这个跟软件发布是一个道理，但很多做技能库的团队会忽略，直接改线上技能，出问题回滚都来不及。

5.4 常见问题速查表

这张表是我根据项目里的问题记录整理的，实际排查时按现象对号入座，能省不少时间。但要注意，同一个现象可能有多个原因，表里列的是最常见的那几个，遇到复杂情况还是要结合日志具体分析。

6. 技能库的扩展与个人实践体会

6.1 从营销扩展到其他领域的思路

这套技能库的架构其实不限于营销。我试着把它往其他领域套了一下，发现只要满足"任务可拆解、交付物明确、有重复性"这三个条件，都能用类似的思路来做。

比如做技术文档写作，可以拆出"API 说明生成""示例代码生成""变更日志整理"等技能。做数据分析，可以拆出"数据清洗""指标计算""图表描述"等技能。核心逻辑是一样的：把领域知识结构化成技能，让代理按需调用。

扩展时要注意的是领域特有的约束。营销领域重创意和合规，技术文档重准确和一致，数据分析重可复现。这些约束要体现在技能的质量校验里，不能照搬营销技能的那套规则。我见过有人直接把营销技能库改个名字就用到技术领域，结果生成的内容全是营销腔，完全不能用。

6.2 技能库与知识库的配合

技能库解决"怎么做"，知识库解决"用什么做"。两者配合才能发挥最大价值。

项目里的做法是技能在执行时，按需从知识库检索相关信息。比如卖点提取技能会从产品知识库里拉取产品参数，人群匹配技能会从用户画像知识库里拉取人群标签。知识库的内容更新后，技能不用改，下次执行自动用新数据。

这个配合的关键是检索接口要统一。如果每个技能都用不同的方式查知识库，维护起来会很痛苦。项目里定义了一个统一的检索接口，技能只需要说明"我要查什么类型的信息"，具体怎么查由接口层处理。这样知识库换存储方案时，技能完全无感知。

6.3 我踩过的几个坑

说几个我自己做类似项目时踩过的坑，给准备动手的人提个醒。

第一个坑是技能粒度太细。一开始我觉得拆得越细越灵活，结果拆出了上百个技能，代理调度时召回和精排的压力巨大，而且很多技能只被调用过一两次，维护成本远高于收益。后来我调整了策略，只把高频且边界清晰的任务拆成独立技能，低频的合并到组合技能里。

第二个坑是忽视技能的测试。技能不像普通函数，输入输出有确定性，它的输出是概率性的，测试起来麻烦。我一开始偷懒没做系统测试，结果上线后各种边界情况暴露出来。后来补了一套测试框架，每个技能配一组标准输入和期望输出的关键特征，每次更新跑一遍，问题少了很多。

第三个坑是契约定义太理想化。设计契约时想得很完美，实际调用时发现用户根本提供不了那么多参数。后来我把契约分成"核心参数"和"增强参数"，核心参数必填但尽量少，增强参数可选，有则更好，无则用默认。这样既保证了基本可用，又保留了优化空间。

6.4 后续可以尝试的扩展方向

如果让我在这个项目基础上继续做，我会往几个方向尝试。

技能的自学习。现在技能的触发意图和参数映射是人工维护的，能不能让系统从调用日志里自动学习？比如发现某个技能经常在特定表达下被调用，就自动把这种表达加入触发句。这个方向技术上可行，但要小心自动学习引入的噪声，需要有人工审核环节。

技能的 A/B 测试。同一个技能可以有两个版本，一个用旧提示词，一个用新提示词，流量对半分，看哪个效果好。这个在内容生成类技能上特别有用，因为"好"的标准比较主观，靠人工判断不如靠数据。

跨技能的知识共享。现在技能之间的知识是隔离的，卖点提取技能学到的产品知识，文案生成技能用不上。能不能建一个共享的知识层，让技能在执行过程中积累的知识被其他技能复用？这个如果做成，整个技能库的智能化程度会提升一个台阶。

最后分享一个我在实践中总结的小技巧：技能库的文档要写给两类人看。一类是开发者，他们关心契约、依赖、执行逻辑；另一类是运营人员，他们关心这个技能能干什么、怎么触发、输出长什么样。项目里的文档目前偏开发者视角，如果能补一份运营视角的说明，推广起来会顺利很多。毕竟技能库的价值最终要靠用起来才能体现，而用的人里，运营往往比开发多。