企业官网建设流程全解析

最近我们在货拉拉营销广告链路里铺了一批大模型能力，从广告文案生成、图片素材制作到投放后的反馈分析都有参与。这篇文章把我在这个项目里踩过的坑、验证过的方案、以及最终跑通的技术路径整理出来。如果你正在做营销中台、广告智能投放，或者团队刚准备把大模型接进业务，可以拿这份实践当参考。我会尽量把关键决策背后的原因讲清楚，而不是只贴一堆参数。

货拉拉的广告场景覆盖司机端和用户端两个方向。司机端要讲收入、接单效率、平台规则，用户端要讲便宜、准时、拉货省心。两者语气完全不同，投放渠道更是分散在信息流、搜索、短视频、线下物料等多处。以前靠运营手工写文案、设计师逐张出图，效率低，而且很难在不同渠道快速做A/B测试。大模型进来以后，我们重点解决三件事：用生成模型批量产出多版本创意，用多模态能力把文案和配图一次性生成，再用模型对投放效果进行归因和迭代。

1. 项目背景：营销广告场景为什么值得用大模型

1.1 业务痛点与需求解析

货拉拉本身是做同城货运的，营销团队的日常工作里有大量重复且需要快速响应的内容生产。比如大促期间，一天要产出上百条不同渠道的广告语，还要配合优惠券策略、车型活动、区域差异化运营。以前的做法是运营写几版文案，设计出几张图，投放同学拿去开计划，跑出来以后再人工看数据。这种流程的问题很明显：生产速度跟不上投放消耗，创意同质化严重，很难针对不同人群做个性化表达。

我们拆解以后发现，广告内容生产其实是一个典型的生成任务：输入的是商品利益点、目标人群、渠道规则、品牌语调，输出的是文案、图片、视频脚本。大模型天然适合做这件事，尤其生成式语言模型和多模态模型，本质上就是把“输入约束”转化为“输出内容”。但难点在于，怎么让模型输出符合货拉拉的品牌调性，而不是看起来像通用AI写出来的那种“重磅上线”“重磅福利”。

另一个痛点是经验沉淀。老运营脑子里有一套“什么人群吃什么文案”的打法，比如对搬家用户强调“不用跟车，便宜透明”，对企业客户强调“运力稳定、可开发票”。这些经验散落在表格和微信聊天记录里，很难系统化。我们后来用RAG把过往优秀文案、品牌规范、广告法禁用词列表全部做成知识库，让大模型每次生成前先检索再组织语言，效果比裸用模型稳定很多。

1.2 大模型能切入的营销环节

从项目梳理来看，大模型在营销广告里至少有四个可落地切入点。

第一个是广告文案批量生成。这里不只是简单的“写一句话”，而是要支持多个维度组合生成：渠道（朋友圈、抖音、搜索）、人群（新用户、沉默用户、高频司机）、业务线（搬家、拉货、企业版）。每个组合需要不同的利益点和语气。我们用了一套基于提示词编排的生成管线，把维度拆成参数，再交给模型。

第二个是图片和视频素材生成。用多模态大模型做场景图、背景图、甚至动态视频脚本，能极大节省设计工时。尤其货拉拉的素材经常涉及货车、搬运、小区、仓库这类实体场景，模型生成后还需要跟真实产品图、司机形象结合，所以我们采用的是“文生图+图生图+人工精修”的混合流程。

第三个是投放入口的人群策略。大模型可以从历史投放数据里学习人群特征，输出投放建议。这个严格来说不算是内容生成，但它是广告系统的一部分。我们让模型基于广告文案自动打标签，再结合后端人群包数据，帮助投放平台更精准地圈选受众。

第四个是效果反馈分析。以往看投放报表需要人工写总结，现在让大模型读数据，自动生成归因摘要、异常波动提醒和下一步优化建议。这个环节投入产出比最高，因为不需要太多生成控制，只需要让模型理解表格和指标含义。

2. 技术选型与整体方案设计

2.1 模型选型：开源底座加微调的取舍

项目一开始我们就讨论过，用闭源API还是开源模型。广告内容属于业务敏感数据，而且我们需要频繁调整生成风格，频繁调用API的成本和延迟都是问题。最后决定以开源大模型为底座，在私有化环境部署，关键场景做微调，非核心场景直接走提示词。

底座选型上，我们主要对比了Qwen、Llama、DeepSeek、ChatGLM这几个系列。实际跑下来，Qwen系列对中文广告语的理解和生成稳定性最好，尤其是处理短文本、口语化表达、品牌词这些场景。Llama中文能力稍微弱一些，需要额外做中文词表扩充，成本高。所以我们主力用了Qwen2.5系列的7B和14B两个版本，轻量任务用7B，复杂文案和多轮改写用14B。

这里有个重要经验：模型不是越大越好。我们的广告文案生成任务属于短文本生成，7B模型在微调以后已经能输出不错的效果，14B虽然质量更高，但推理延迟和显存占用都上了一个量级。后来我们做了分层策略，简单模板化文案直接走7B，复杂创意文案走14B，实测下来整体成本降低了一半，可接受的延迟控制在500毫秒以内。

2.2 系统工程架构：从生成到投放的闭环

整体架构不是简单调API，而是一个完整的内部服务。我简单说一下分层。

最底层是模型推理层，用vLLM部署Qwen模型，支持流式输出和并发请求。vLLM的PagedAttention机制对显存利用率提升非常明显，我们单卡A100能同时服务几十个请求，吞吐量比之前用过的一种简单方案高了两倍多。模型部署我们做了两个容器，一个跑7B，一个跑14B，通过服务路由自动分流。

中间层是业务逻辑层，包含提示词模板管理、知识库检索、敏感词过滤、结果缓存。这里最重要的是提示词模板管理。我们不是把提示词硬编码在代码里，而是做成可配置的JSON，每个场景对应一个模板，模板里可以引用知识库检索结果和业务参数。这样运营同学可以自己调整语气词、利益点顺序，不需要每次改代码。

上层是业务接入层，对接公司内部的广告投放中台、素材管理系统和实验平台。投放计划创建的时候，系统自动调用生成服务，生成完文案和图片以后，推送到人工审核后台。审核通过以后进入A/B测试池。等投放数据回来以后，再自动反馈给效果分析模块。整个链路形成了一个闭环，而大模型是其中一个核心组件。

3. 核心实操：从数据处理到模型微调与部署

3.1 广告文案生成系统的搭建

文案生成是我们第一个上线的能力。上线初期，我们直接用通用的提示词，让模型扮演“货拉拉营销文案专家”，结果生成的文案很多是套话，比如“一站式搬家服务，省心省力”。这个问题不在于模型差，而在于提示词里没有足够的约束。

后来我们重新设计了提示词结构，分成五个部分：角色设定、业务背景、生成要求、参考示例、负面约束。角色设定告诉模型它是什么，业务背景说明货拉拉的品牌定位，生成要求里有字数范围、必须包含的关键词、目标人群，参考示例给它看几组真实优秀文案，负面约束明说不能出现哪些夸张词和禁用词。

一个典型的提示词模板长这样：

{ "role": "你是一位熟悉同城货运行业的资深广告文案编辑", "background": "货拉拉为用户提供面包车、小货车等运输服务，核心卖点是便宜、准时、透明计价", "task": "针对搬家用户，生成一条30字以内的朋友圈广告文案", "constraints": "必须包含'搬家'，体现价格优势，语气轻松，不使用'最'、'第一'等极限词", "examples": "参考：今天搬家没被坑，比打车还便宜，货拉拉师傅准时到楼下" }

这套模板上线后，文案合格率从30%提升到了70%。但依然有部分输出太死板，所以后来我们加入了知识库检索。把历史投放表现最好的1000条文案按场景拆开，生成时先找到最相似的五条作为参考示例放进提示词里。这个做法本质上是RAG，虽然看起来简单，但对文案自然度的提升非常明显。

为了进一步提高效果，我们还做了微调。微调数据来自两部分：一是历史库里的优质文案，二是运营人工修正过的生成结果。我们按渠道和业务线分别整理了几千条数据，使用LoRA方式微调Qwen2.5-7B。LoRA的优势是训练参数少，我们只用了两张A100，跑了大概三小时就完成了一个领域的微调，模型文件才几百MB。微调以后，风格稳定性好了很多，不再频繁出现“共同富裕”“阖家欢乐”这类的通用祝福词。

3.2 多模态素材生成与广告审核

图片素材这块，我们最初想直接用文生图模型生成整张海报，后来发现可控性太差。比如模型生成的货车经常贴地飞行，车身上的字也是乱写的，直接投放会砸招牌。我们的方案是把文生图用于背景合成，比如生成“上海某小区门口搬家场景”，再让后端合成引擎把真实货拉拉车辆和品牌标识贴进去。

这里用到的多模态大模型既包括图像生成模型，也包括图像理解模型。生成场景图之后，会用图像理解模型做一轮自动审核，检测有没有车牌号、人脸、违规标语。注意，广告素材涉及真实人物和车辆，合规要求很高，自动审核+人工复核的流程必须保留，不能为了效率完全依赖模型判断。

另外我们还训练了一个小模型做品牌一致性打分。输入生成图片，输出一个0到1的分数，低于阈值的图片直接退回重新生成。这种打分模型的训练数据来自历史素材库，人工标注过“是/否符合品牌规范”，效果比单纯用提示词约束图片生成模型可靠得多。

3.3 大模型微调实战与部署优化

微调这块我多说一点技术细节。我们用的底座是Qwen2.5-7B-Instruct，微调框架是LLaMA-Factory。数据格式统一成对话式，历史文案作为人类回答，前面拼接一个系统提示词描述场景和约束。训练轮数控制在三到四个epoch，学习率设置在2e-4左右，LoRA rank设16，alpha设32。经验是轮数太多容易过拟合，导致输出全是训练集里的句子。

训练完成后，我们把LoRA权重合并到基础模型，导出成HuggingFace格式，再用vLLM部署。合并后的模型大小和基础模型差不多，但显存占用还要考虑上下文长度。广告文案任务上下文比较短，我们控制在2048 token以内，这样7B模型用一张A10也跑得动，性价比很高。

部署的时候有两个优化点。一个是动态批处理，vLLM默认支持连续批处理，但需要把max_num_seqs调大，否则并发一高就会排队。我们把max_num_seqs从32调到64，吞吐量提升明显。另一个是preemption策略，长上下文请求偶尔触发显存不足，我们把gpu_memory_utilization调成0.9，并且启用swap空间，牺牲一点速度换稳定性。

3.4 提示词工程与上下文管理

提示词工程在这类业务里比想象中重要得多。很多人觉得大模型能力强，随便写几个词就行，实践下来不是这样。广告文案对措辞极其敏感，差一个字可能就会触碰广告法禁用词，或者语气跟品牌不符。

我们做了几层提示词优化。第一层是词汇级限制，把禁用词列表挂在每个请求后面，让模型在生成前先“过一遍脑子”。第二层是句式偏好，通过示例指导模型使用“越短越有力”的句式。第三层是上下文管理，RAG检索到的内容会放在知识块里，并明确告诉模型哪些是必须使用的卖点，哪些是可以忽略的背景。

再说说流式输出。营销后台的体验要求看到生成过程，所以接口是SSE流式。但流式输出有一个麻烦，就是敏感词过滤没法逐字判断。我们的做法是前端展示流式内容，最终生成结束以后后台再跑一遍完整过滤，如果命中禁用词，整条文案标记为待人工修改，而不是直接丢弃。这样既保证交互体验，也不让风险内容漏出去。

4. 踩坑实录与问题排查

4.1 内容质量与效果波动问题

第一个典型的坑是模型输出效果不稳定。同样的提示词，早上生成和下午生成的文案措辞会有差异，哪怕温度参数设成0也一样。这个问题的根源在于采样随机性和后端工程的并发状态。我们最终把生成结果的候选数设成三个，由评分模型选一个最优输出，同时配置了固定随机种子。虽然不能保证100%一致，但线上可接受。

第二个坑是过度优化。我们曾经把温度调得很低，让输出更加稳定，结果文案变得干巴巴，全是模板句。后来调整为温度0.7，top_p 0.9，既保留一定的多样性，又不至于跑偏。这个参数我们测了很多组，最终定下来，不同任务可能不一样，但大方向是这样。

第三个坑是数据回流。一开始我们只做生成，不做反馈闭环，模型根本不知道哪条文案最后转化率高。后来我们在生成结果里带上了生成时的参数和业务ID，投放结束以后把点击率、转化率回写到文案条目上。每个月用这些带效果标签的数据重新微调一次，模型才真正越用越准。

4.2 推理性能与成本控制

性能方面，最大的坑是并发突刺。大促期间广告系统会一次性预生成几百条文案，导致推理服务瞬间被打满。我们做了三层防护：一是整体批量任务走异步队列，不是同步请求；二是模型服务单独限流，超过阈值直接报错，让上游重试；三是主动缓存，如果同一个业务参数组合已经有生成结果，就直接从缓存里返回，不再调用模型。

成本方面，建议不要把大模型用在所有生成任务上。我们做了一个很简单的判断逻辑：纯模板套路的文案，用规则引擎加随机词汇组合就能生成，成本几乎是零；只有需要创意表达、风格把控、语义泛化的任务才走大模型。这个判断逻辑上线后，大模型调用量下降了40%，但文案整体质量没有明显下降。

GPU成本也要细算。我们最初租了好多卡，后来发现大部分时间利用率不到10%。现在改成动态扩缩容，非高峰时段只保留两个节点，高峰时段自动扩到八个节点。这个在Kubernetes里配一下HPA就行。注意要用模型自身的吞吐指标来做扩缩容依据，不要只看CPU，因为大模型推理瓶颈在显存和计算，CPU高不代表卡忙。

4.3 数据安全与广告合规

广告营销直接对外，内容合规是底线。我们总结了几条硬规矩。

第一，所有生成内容必须经过机审和人审两道关。机审用规则匹配和大模型判别结合，规则负责禁用词、商标词、极限词，大模型负责捕捉语义风险，比如文案里虽然没有禁用词，但整体暗示“必赚”“保底”。第二，素材里涉及真实人物、地址、车牌要打码或替换，不能直接用真实场景照进广告。第三，用户数据不能直接拼进提示词，比如不能用“李先生的手机号是138xxxx”这种内容作为生成上下文，否则会造成隐私泄露。我们的做法是把用户信息脱敏成占位符，比如“用户A所在城市是上海”，模型只感知到业务变量，不需要知道真实个人信息。

在合规这块，我们专门整理了一个动态更新的禁用词库，除了广告法明确禁止的“最”“第一”“国家级”以及相关变体，还包括货拉拉业务里不适合出现的金融暗示词。词库放在配置中心里，每次生成前自动拉取，不写死在模型权重里，这样改动词库不需要重新部署模型，非常灵活。

5. 后续扩展可能性

这套体系跑通以后，我们发现它其实不止能用在广告内容生产上。货拉拉还有大量面向司机的运营通知、App端弹窗文案、甚至客服话术，本质上都是同一类生成任务，只要把知识库替换成对应业务域的内容，微调一下语法风格，就能快速复制。

我个人在实际操作中的体会是，大模型在营销广告落地的关键不是模型本身多强，而是业务上下文够不够厚。你给模型多少好数据、多少清晰的约束，它就还给多少靠谱的输出。盲目上大带宽、大算力，不如先把提示词和知识库做扎实。后面如果继续做，我计划把多轮改写能力加进去，让模型能根据历史投放数据自动优化一句差评文案，而不是每次都从零生成。