企业官网建设流程全解析

前阵子不少人问我，货拉拉这种做同城货运的平台，怎么也想起来要用大模型做营销广告了。说实话，一开始我们内部也有这个疑问。广告业务本身有一套成熟的规则和工具，模板文案、兴趣标签、人群定向用了很多年，突然上个"大模型"，到底解决什么问题？会不会只是追热点？后来真正把这个项目从0到1推上线，我才想明白一个道理：货拉拉广告场景的核心问题，从来不是"缺流量"或"缺工具"，而是创意供给跟不上投放规模，人群理解粗糙到只能靠关键词去猜。这两个问题刚好是大模型的强项。

这篇文章我会按一条完整的落地链路来写：先讲讲我们为什么判断这个场景值得上大模型，再拆技术架构和几个核心模块的实战细节，包括提示词设计、微调、流式输出、效果实验、成本与安全，最后聊一些不太会写进汇报材料里的经验教训。内容尽量说人话，适合正在做"大模型+营销"方向，或者想搞清楚广告场景怎么落地的朋友参考。

1. 为什么是货拉拉：把广告场景的"脏活累活"先摊开看

1.1 货运用户的决策链路，和电商冲动消费完全不一样

货拉拉的平台服务包括同城货运、跨城货运、搬家、企业物流等，用户找车的行为有一个非常明显的特点：决策短、目标明确、场景碎片化。比如一个用户搬家，他可能今天下午就要用车，在意的是"有没有大面额优惠、司机多久能到、能不能搬运大件"；一个批发市场的商户要发货，他在意的是"能不能马上接单、车型对不对、费用怎么算"。这和电商场景里"逛着逛着就买了"完全不同，广告文案必须直击当时的即时需求。

这就带来一个麻烦：同一套文案模板，放在深圳搬家场景和杭州商户发货场景，效果差距很大。用户刷到一条"同城货运低至X元"的广告，搬家用户关心的是"有没有人帮忙搬"，商户关心的是"能不能装下这批货"。货拉拉本身覆盖的城市多、业务线多，加上司机端招募、企业版、搬家、跑腿等不同业务都有投放需求，创意要做的细分组合非常多。

1.2 营销团队最真实的四类痛点

项目立项之前，我们花了两周时间把营销广告相关的同事全部聊了一遍，把痛点归纳成四类：

• 创意供给瓶颈：每个城市、每条业务线、每类人群都需要对应文案和素材。运营同学手动写，一天最多出几十条，还要做A/B测试，经常是"测试还没做完，活动已经下线了"。素材制作更慢，一张banner从需求提出到设计返稿，通常要一到两天。
• 人群圈选靠规则：原有的标签体系里面，"搬家意向人群"基本靠用户搜索过"搬家""拉货"这类关键词来圈，但用户真实表达往往是"周末要从宝安搬到南山，东西有点多"，这种自然语言描述传递的意图，规则标签根本覆盖不了。
• 投放策略调优滞后：广告出价和人群预算的调整依赖运营的经验判断，数据反馈快则几小时慢则一天，等发现某个组合效果差再手动调整，预算已经花了不少。
• 复盘分析太占人力：每轮投放结束后，团队需要人工看报表，分析哪个渠道、哪类素材、哪个人群效果最好。数据量大、维度多，运营同学大部分时间花在"从数据里找结论"而不是"做决策"。

这四类痛点出来之后，结论其实很清晰：不是每一条都要用大模型解决，优先级应该是创意生成和人群意图理解，这两个是纯文本/语义问题，大模型最擅长；投放调优和复盘分析作为配套能力，可以逐步建设。这样就避免了"给所有问题都套上大模型"的伪需求陷阱。

2. 技术架构：大模型在营销链路里的三个落位点

2.1 整体思路：不是做一个"聊天机器人"，而是把大模型嵌进生产链路

我们最终搭建的架构，不是很多人想象中那种"运营同学打开一个对话框，让大模型帮写文案"的单点工具，而是把大模型拆成三个服务模块，分别落在创意生产、人群理解、投放复盘三个环节上。

第一个模块叫"创意大脑"，负责广告文案生成、素材文案改写、落地页标题生成。它在离线批量任务和在线实时生成两种模式下工作：离线场景下，每天凌晨批量生成第二天的广告文案候选池；在线场景下，当某个用户命中实时营销事件，系统在几百毫秒内动态生成个性化文案。

第二个模块叫"人群理解中枢"，负责把用户产生的非结构化文本，比如搜索词、浏览记录、订单备注，转换成结构化的投放标签。这个模块需要私有化部署，因为它涉及用户行为数据，不能随便走外部接口。

第三个模块叫"复盘助手"，负责把历史投放数据沉淀成语义向量，存进向量数据库。运营同学用自然语言提问，比如"上个月深圳搬家业务的广告哪类素材转化最好"，系统通过向量检索加部分结构化查询，返回结论和建议。

2.2 模型选型的分层策略

选型的时候我们定了两条原则：第一，在线链路尽量私有化部署，因为latency和数据安全都不允许每次都调用外部API；第二，离线批量任务可以用性能更强的模型，甚至允许少量使用云端API，因为不涉及实时交互。

具体选型上，文案生成走的是偏中大规模的开源模型（这里不写具体型号，免得被当软广），量化后部署在带GPU的集群上；标签抽取和意图理解用稍小一号的模型，尤其是在线请求量大的场景，小模型速度快，效果也够用；复盘助手因为要处理长文本和复杂查询，对语义理解要求高，用的模型能力更强，但处理的是离线和异步任务，慢一点也可以接受。

这套分层方案实施之后，我们最大的感受是：不要试图用一个模型解决所有问题。大模型的能力边界差异很大，在广告场景里，效果和速度往往要做一个清晰的取舍。

2.3 统一模型网关：所有广告业务方都走同一个入口

三个模块不是零散地接给下游系统，而是统一封装成一个"模型网关"服务。网关对外提供API，内部做了路由、权限、限流、缓存、降级。广告投放系统、消息推送系统、运营平台都只需要对接网关，不需要关心模型部署在哪、用什么框架。

网关层的价值我们在上线第二周就体会到了。某一天在线生成接口的调用量突然涨了三倍，如果每个业务方直连模型，即时模型扛得住，也会因为互相争抢资源导致响应变慢。有了网关，我们可以在网关层把非核心任务的调用降级为返回缓存结果，优先保障在线个性化文案的响应速度。广告系统这种高并发业务，流量治理比模型本身效果更能决定生死。

3. 文案生成的实战细节：提示词架构、知识注入与效果约束

3.1 结构化提示词：让大模型从"会写"到"写得对"

很多团队刚开始做文案生成，都会遇到一个现象：模型写出来的文案语句通顺，但完全不能用。不是语法不对，而是不落地——它不知道货拉拉的品牌调性，不知道广告法有哪些极限词不能碰，不知道不同城市的用户关注点完全不同。

我们的解法是设计一套结构化的提示词模板，把文案生成任务拆解成固定字段。以搬家业务为例，最基本的模板长这样：

你是一位熟悉同城货运行业的资深广告文案专家。请根据以下结构化信息生成一条推广文案： 业务线：搬家 目标城市：深圳 目标人群：25-35岁，近期需跨区搬家的上班族 核心卖点：新用户首单立减、司机最快5分钟接单、可搬运大件家具 投放渠道：App消息推送 文案字数：30字以内 风格要求：口语化、有紧迫感、避免夸张承诺 合规要求：不得出现"最便宜""第一名""100%准时"等绝对化用语，价格信息必须使用"低至""起"等表述 输出格式：直接输出一条文案，不要解释。

这套模板看起来简单，但调参过程里我们踩过一个坑：字段越多，模型越容易在某个字段上忽略指令，尤其是"字数限制"和"合规要求"。后来我们加了几个技巧：一是把最重要的约束放在system prompt里，并且用负面清单的方式写清楚"不得出现……"；二是把历史上验证过效果好的文案作为few-shot示例拼在prompt里，让模型模仿语感；三是设置输出格式约束，要求模型只输出最终文案，不要带解释，减少解析成本。

3.2 从Prompt到微调：什么场景值得投入LoRA

Prompt调优能覆盖80%的通用场景，但总有那么一些细分场景，怎么调都差口气。比如货拉拉的企业版业务，目标客户是B端商户，文案需要更专业、更强调物流效率，而通用模型的默认语感偏C端。又比如司机端招募广告，目标人群是货拉拉司机，文案要突出"收入稳定""平台单量充足"，但大模型生成的文字经常显得太"画饼"，缺乏真实感。

这些场景的共同点是：有大量历史优质文案沉淀，但分布和通用语料差异大。我们为此规划了LoRA微调。数据来自过去两年运营实际投放中点击率和转化率较高的历史文案，清洗后大概攒了几万条，每条包含业务线、城市、目标人群、文案正文。微调时只更新LoRA适配器，基座模型权重冻结，单卡即可完成训练。

微调完成后再用同样提示词跑一遍测试集，明显感觉到输出更贴业务调性了。但我也想提醒：微调不是越多越好，做之前先确认Prompt确实调不动了。LoRA微调会引入模型版本管理、数据回流、效果回归等一系列问题，小团队贸然上微调，很容易陷入"调完一个场景，另一个场景效果又掉了"的循环。

3.3 让大模型自动"审稿"：合规不靠自觉，靠流水线

广告文案有一个硬约束：合规审查。货拉拉的广告涉及价格、服务范围、时效承诺，出问题就是虚假宣传；另外广告法对绝对化用语查得很严。大模型生成内容天然有幻觉属性，所以我们从一开始就明确：不管模型生成能力多强，审核环节不能省，但可以用模型加速审核。

我们做的第一层是规则审核，内置一份敏感词、极限词、竞品词词典，命中即拦截；第二层是模型审核，把生成的文案丢给一个小模型做文本分类，判断是否存在违规风险；第三层是人工抽检，按一定比例抽看。三层下来，违规文案才被真正拦截的概率已经非常低，运营审核的人力从逐条看变成了看异常告警。

这个流程上线后，我们甚至反哺了生成环节：把规则审核结果作为负样本回填到生成模型里，让模型在生成阶段就主动避开违规表达。比如它知道"最低价"不能用，会自动换成"特惠价""起步价低至"这类合规表述。这比靠审查机制被动拦截要省事得多。

4. 实时性这件大事：广告系统接入大模型的延迟治理

4.1 同步调用的痛：一次文案生成拖垮整个投放编排

广告场景对延迟的要求，比很多人想象中苛刻。比如用户触发了一个营销弹窗，从触发到展示留给我们的时间往往只有500毫秒。而大模型生成一句文案，即便是量化部署的小模型，首token返回也要几百毫秒，全量生成一个短句通常要两三秒。如果走同步调用，投放系统会被拖垮。

我们最初上线时有一个业务场景就是同步等待模型返回，结果接口超时率一度高达20%。监控图表拉出来后，我们做了个决定：在线强时效场景，永远不直接同步调大模型，除非你已经做好了缓存和降级方案。

4.2 流式输出落地：SSE协议下的任务分发与结果聚合

对于某些"在线但不要求秒回"的场景，比如运营后台的实时文案生成、部分Web端编辑器的辅助写作，我们引入了SSE流式输出。这个技术本身不复杂，核心就是通过HTTP长连接把大模型生成的token一个个推给前端，前端逐字渲染，用户体感是"模型在边想边写"，比转圈等待舒服很多。

但广告投放系统跟编辑器不一样，它需要拿到完整文案后才能做合规审核、拼装落地页URL、走投放编排。所以我们在架构上做了个折中：首包优先策略——模型先输出一个符合基本要求的短句作为"种子文案"，马上返回给投放系统去跑流程；后续输出的备选文案再通过异步回调写入候选池，供下一轮使用。这样既保住了时效，又把大模型的生产力全部用上了。

还有一点容易踩坑：SSE连接是长连接，在广告这种高并发场景下，如果不做连接管理，大量半开连接会占满服务端资源。我们的做法是给SSE请求设置超时时间，并在网关层做并发限制，超过阈值的请求直接走缓存或降级路径。

4.3 模型网关层：缓存、降级与并发控制

延迟治理的另一半是流量治理。广告业务的流量峰值非常集中，比如大促活动一开闸，瞬间可能有几十万次营销触达请求。模型再快也扛不住这种突发流量，必须在网关层做文章。

我们设计了三级缓存：第一级是短文案缓存，命中率大概在20%到30%，因为同一个城市、同一个业务线、同一个活动期的组合经常重复；第二级是语义相似缓存，把用户请求转成向量后做最近邻检索，相似的请求可以复用近似结果；第三级才是真正调用模型。降级策略也预设了几档：模型超时自动返回规则模板文案、模型过载自动切换小模型、小模型也扛不住就返回固定的兜底文案。

上线运行一段时间后，我们统计过一个数据：加上缓存和降级，最终走到模型推理的请求只占全部请求的一小半，而整体p95延迟从近3秒压到了700毫秒以内。这个结果不是靠优化模型推理速度得来的，是靠架构设计曲线救国。

5. 从生成到投放：匹配模型的优化与实验设计

5.1 用大模型做用户需求意图抽取，替代纯规则标签

文案生成得再好，如果推送给了错误的人群，效果照样很差。这一步我们做了"人群理解中枢"模块，核心任务是把用户的自然语言表达转化成广告系统能用的结构化标签。

举个真实例子。以前用户搜索"明天搬家到福田"，规则系统只能识别出"搬家"这个关键词，然后给他打"搬家意向"标签。大模型的做法是：把这句话联合用户的浏览序列和订单历史一起编码，输出一个结构化的意图向量，包含"搬家场景+跨城/同城+是否有大件+时间紧迫度+价格敏感度"等维度。相比关键词标签，这个向量能在语义层面捕捉到"虽然用户没直接说搬家，但他在连续搜索纸箱、家电回收、小区停车管理费"这类隐性强意图。

落地时我们特别注意了隐私问题。用户的行为文本进了模型，但无论训练还是推理，都不能掺入手机号、真实姓名、具体门牌号。我们专门做了脱敏处理，把所有个人标识符替换成掩码后再进入模型服务。这一步在合规上很重要，我们把它写进了上线检查清单。

5.2 A/B测试怎么切割流量才能看出效果

模型和策略上线后，最难回答的是"到底有没有用"。广告场景里指标太多：CTR、CVR、ROI、拉新成本、留存率，而且不同渠道之间的流量质量差异很大。如果A/B测试切分不干净，很容易得出错误结论。

我们的做法是：以"用户设备号+广告活动"为最小单元做分层划分，保证同一个用户在一段时间内只会看到同一套策略的内容；对照组和实验组的流量比例动态调整，初期实验组占10%，跑出明显正向结果后再逐步放量到50%；同时设置一个"刹车机制"——如果实验组的核心指标连续三天显著差于对照组，系统自动缩量。

这里我想重点提一个容易忽略的指标：后续自然转化率。大模型生成的内容如果过于同质化，短期CTR可能不差，但用户看多了会产生审美疲劳，后续自然打开率和转化率反而下降。所以A/B测试不能只看投放期的转化，还要观察测试窗口结束之后一段时间的自然行为，否则你的"收益"可能是在透支用户注意力。

5.3 我们遇到的冷启动与效果回落问题

新品上市或新城市开城时，没有任何历史投放数据，人群标签和文案都无从下手。我们的临时方案是：用大模型生成一批"地域化种子文案"，结合地理围栏圈定目标区域，小预算快跑，同时人工审核每一批文案质量，跑出正向样本后再逐步放量。

更麻烦的是效果回落。有一段时间我们发现自己非常满意：实验组CTR比对照组高了大约10%，于是全量上线。结果上线第二周，CTR优势缩水到3%左右。复盘下来，原因是模型生成的文案高度雷同——同一个活动期，系统反复推送句式相近的内容，用户的新鲜感下降得很快。后来我们在生成环节加入了多样性控制：调整采样温度、设置多套提示词路径、限制同一个文案模板的使用频次，才把回落问题压住。这条经验后来写进了团队的操作手册：大模型批量生产能力很强大，但同质化风险也与生俱来，必须从生成源头控制多样性。

6. 成本与安全：上线一段时间后不得不管的事

6.1 单次生成成本预算：从GPU占用到token消耗

大模型不是免费的，广告业务本身就对成本敏感。我们很早就算过一笔账：一个文案生成任务，带上完整的提示词和few-shot示例，输入输出加在一起大概消耗多少token；按部署的GPU集群折旧和电力成本折算，单次生成的边际成本是多少。再乘以每天的调用量，一个月下来就是一笔不小的数字。

省钱的办法其实不复杂，总结下来是三条：

• 减少重复输入：把固定不动的system prompt和常量的few-shot拉出来做前缀缓存，避免每次请求都重复计算。
• 分层使用模型：80%的简单请求用小模型完成，只有复杂长文案才上大模型。小模型不够的情况再升级。
• 错峰执行：线下批量生成任务全部放到凌晨低峰期跑，在线高优先级任务才占白天的GPU资源。

这三条做完，整体成本大概降了30%到40%，效果没有明显衰减。

6.2 内容安全与隐私红线：广告场景比想象中敏感

营销广告的内容安全，比很多内部工具更严格，因为它直接暴露给海量用户。哪怕是模型生成的一个价格数字，如果跟实际活动不一致，都可能引发客诉甚至合规问题。我们的做法是引入"事实核对"环节：生成文案里出现的所有服务承诺、价格区间、时效说明，都必须从活动配置中心实时拉取真实参数来填充，模型只负责写"表述方式"，不负责编造数字。

隐私方面前面提到过，用户文本要脱敏。除此之外还要注意日志安全：模型请求日志里不能明文记录用户ID对应的详细行为序列。我们最初的日志系统会把整个请求体打出来，里面包含用户搜索词，后来统一改成了脱敏摘要，只有标签结果，不保留原文。这件事做的时候多花了一点时间，但心里踏实很多。

6.3 降本：小模型先过滤、大模型做精修的分层思路

最后说一个我们验证过的降本组合拳：用生成式小模型做初稿，用评估模型做打分，必要时才调用大模型精修。

这个思路跟很多人默认的"所有内容都要让大模型生成"不太一样。实际执行中，我们把文案生成任务拆成两段：第一段用一个量化的7B级别模型基于规则模板生成初稿，速度极快、成本极低；第二段用一个分类模型评估初稿质量，如果评分超过阈值，就直接采用；只有评分不达标或属于重点业务线的文案，才送到更大规模的模型做重写和润色。运行下来，真正走到大模型精修的请求只占三分之一左右，而整体文案合格率没有明显下降。

这套方案的启发是：大模型不应该被当成所有文本任务的默认选择，它应该是那个在关键节点把质量兜住的角色。能用规则解决的就用规则，能用小模型解决的就用小模型，大模型的价值应该放在"复杂难题"上，而不是流水线的每一环。

7. 最后说说团队协作和踩过的路

如果让我总结这个项目里最重要的经验，我不会说是模型选型、提示词调优或者微调技术，而是人的协作方式。第一次做这个项目时，我们团队满脑子都是"用大模型替代运营"，结果把运营同学搞得很紧张，配合度很差。后来换了一种思路：大模型先承担"生成量大、重复度高"的初稿工作，运营从写文案的人变成审文案和定方向的人，他们的工作量变化不大，但成就感完全不同。

还有个很务实的建议：上线节奏别太急，先让一个业务线跑通，再横向推广。我们最开始只做了深圳搬家业务的文案生成，跑了两个月，把提示词、审核流程、效果评估都打磨顺了，才逐步推到其他城市和业务线。如果一上来就铺所有场景，团队根本忙不过来，出了问题也分不清是模型的问题还是流程的问题。

最后分享一个小技巧：大模型生成内容的线上效果，不一定看单次CTR有多高，更要看文案与offer的匹配度。模型负责把话说得好听，但"说得对不对"取决于你在提示词里给的事实信息是否真实。把活动配置和运营知识库接进生成环节，比堆任何花哨的技巧都管用。这个思路，对我们这种做交易撮合的平台来说，比单纯追求模型能力上限更值得投入。