企业官网建设流程全解析

1. 为什么货运平台的广告场景需要大模型介入：这是一道典型的“长尾创意题”

入行做营销系统的人大概都有同感：货运平台的广告投放和普通电商有很大区别。货拉拉业务覆盖货运、搬家、企业物流等多种场景，司机端和货主端是两个完全不同的用户群体。司机在意的是“接单量”“补贴”“提现速度”，货主在意的是“车型够不够”“司机靠不靠谱”“价格透明不透明”。这两类人群的决策链路、话语体系、时间场景完全不同，如果沿用电商那种“一套模板打天下”的思路，投放素材很快就会疲劳。

我们刚开始做“大模型在货拉拉营销广告的应用实践”这个项目时，面临的第一道坎不是模型效果，而是需求梳理。营销侧的同学们列了几十条需求：短信文案、Push推送、落地页标题、App弹窗、广告主创意、线下物料文案……每一条都要求“看起来不像机器生成的”“有一定新鲜感”“符合平台调性”。我数了一下，仅短信文案这一个场景，每个月就有上千条配置需求，靠人工写文案根本跑不过来。

这就是典型的“长尾创意”问题：单条文案的量不大，但胜在量大、类目杂、更新频率高。传统的做法是做模板加变量替换，比如“{优惠券}限时领取，{城市}用户专享”。但模板文案的点击率会随着曝光次数增加快速衰减，而且同一个模板在司机端和货主端的表达方式完全不同。我们需要一种能力，让系统可以根据不同人群、不同活动规则、不同触达渠道，自动产出“有差异但不出格”的创意内容。大模型恰好擅长这件事。

选型的时候我们没有一上来就追最新、最大的模型。内部对比过几款开源基座模型，比如Qwen2.5系列、DeepSeek系列、GLM系列，也对比过商用API。结论是：**对于广告文案这种“小语义、高格式”任务，7B到14B量级的开源模型已经够用，最关键的其实是后侧的提示词工程和数据回流。**商用API的效果确实更好，但高频调用下成本不可控，而且广告文案一旦涉及运营策略，数据安全要求很高。我们最终走的是“开源模型为主、商用API为辅”的混合路线。

这个项目最终要解决的核心问题有三个：第一，把人工写文案的流程从“纯手工”变成“人工审核+大模型生成”；第二，让不同渠道、不同用户的触达内容具备个性化差异；第三，把效果数据回流到模型侧，形成持续优化的闭环。下面我从架构、生成实现、个性化、踩坑经验、效果复盘几个维度，把我们这一路走过来的实际经验写出来。

2. 从0到1的整体架构设计：模型推理、知识库召回和流式输出的分工

很多团队做大模型应用，上来就先调prompt，甚至先微调模型，但架构层的问题没想清楚。我见过不少项目死在“模型输出质量还行，但上线后谁也说不清楚它调了哪些数据、走了哪些链路”这种状态。所以我们在架构设计阶段就确定了四层分工：业务数据层、知识召回层、模型推理层、应用编排层。

2.1 业务数据层的核心是“广告要素”而不是“原始日志”

营销广告文案生成，输入的不是用户的一句话，而是一个结构化的投放需求。我们需要把运营同学配置的活动信息转化成模型能理解的“广告要素”，例如：

• 活动名称、优惠类型、优惠门槛、有效期
• 目标人群（司机端/货主端，城市，车型，活跃度分层）
• 触达渠道（短信、Push、App弹窗、落地页）
• 语气限制（平台调性、品牌词、禁用词）
• 期望的行动引导（领取券、报名活动、查看规则）

这些要素统一存成JSON结构，作为提示词中“活动信息”字段传入。这里有个容易被忽略的细节：**原始活动配置里经常有大段运营备注文本，是写给人看的，不适合直接丢给模型。**我们专门写了一个“要素提取模块”，用大模型把非结构化的运营需求解析成标准字段，再进入文案生成环节。这一步能把后续的幻觉率降低不少。

2.2 知识召回层：品牌规范和历史素材不用塞进上下文

第一次做广告文案生成的时候，我们尝试把品牌规范、违禁词表、历史高点击文案全部塞进提示词，结果很不理想。上下文一长，模型反而抓不住重点，输出文案里经常出现和当前活动无关的表述。

后来改成RAG（检索增强生成）的思路：先按活动行业、品类、目标人群三个维度，从素材知识库中召回最相似的3到5条历史文案；再按渠道和用户群体召回对应的表达偏好规则，和品牌规范一起作为“参考信息”传给模型。召回的内容会被注入提示词的“参考案例”部分，而没有相关性的知识不会进入上下文。

这里再说一个我们踩过坑后才补上的模块：**上下文去重。**大模型对重复信息很敏感，案例库里如果反复出现相似的措辞，模型就容易“模仿过头”，产出一眼看过去还是旧模板的句子。我们在召回后加了去重逻辑，确保注入的参考案例风格差异尽量大。

2.3 模型推理层的部署与调用策略

模型层我们部署了两个实例：一个面向“实时生成”场景，比如App弹窗里根据用户行为即时生成一句话利益点，需要几百毫秒内返回；一个面向“批量生成”场景，比如对昨日新增的1000条Push文案做批量产出，可以用更大的模型，花几分钟没关系，但质量和多样性要更好。

实时场景用的是自部署的Qwen2.5-7B-Instruct配合vLLM做推理加速。为什么选7B？因为广告文案属于短文本生成，对世界知识的要求不高，但对指令跟随和格式规范的要求很高，7B模型在充分微调或加上好的few-shot之后，产出的质量已经能和14B打平。批量场景用的是Qwen2.5-14B，配合更长的上下文，用来处理复杂活动和长文案落地页。

模型调用层我们用了一套统一接口，屏蔽了底层模型差异。接口入参是一个定义好的“生成任务”，出参是一个标准化的“文案候选+结构化标签”。这样后续如果想换成更新的模型，不需要改应用层代码，只要把模型适配器换掉就行。

2.4 应用编排层：SSE流式输出不是给用户看的，是给编辑审核页用的

热搜里经常看到“通过SSE流式输出实现大模型回答实时渲染”，很多团队把这个能力直接用到C端对话场景。我们不太一样，货拉拉的广告文案生成主要面向运营人员和风控审核，流式输出用在了“人工编辑工作台”上，好处是生成效率可见、体验更顺滑，编辑不用盯着空白页等5秒。

应用层还做了一件事：生成任务的全链路追踪。每一条文案从“输入要素”到“模型输出”再到“人工审核通过”，都有自己的traceID。这样出了问题可以回溯到是哪一轮提示词、哪个模型版本、哪一次召回导致的。这个能力在后面的效果复盘和问题排查中帮了大忙，强烈建议所有做类似项目的人一开始就埋好。

3. 广告文案智能化生成的核心实现：提示词工程与输出约束

提示词工程听起来很基础，但广告文案这个场景有个特殊性：**它对“词面”的约束极高，而对“语义”的约束相对宽松。**模型可能生成一句非常通顺的话，却把“优惠券面额20元”写成了“新用户立减20”，这属于事实性错误，会直接造成资损或客诉。所以我们把输出约束分成三层：格式约束、事实约束、风格约束。

3.1 三层约束的提示词设计

第一层是格式约束，要求模型必须以JSON结构输出，包含title（标题）、content（正文）、reason（生成依据）。第二层是事实约束，在提示词里单独设置一个“事实清单”段落，列出本次活动的真实规则，并明确要求“只允许组合事实清单中的信息，禁止推断优惠金额、有效期、适用范围”。第三层是风格约束，针对不同渠道给不同表达倾向，比如短信要求短句加紧迫感，Push要求突出利益点，落地页要求口语化和信任感。

下面是我们一个经过多轮迭代后的Prompt结构，已经脱敏，保留了核心设计思路：

你是一名货运平台的广告文案专家，请根据“活动信息”和“参考案例”为指定渠道生成一组广告文案。 活动信息: {结构化活动JSON} 事实清单: 1. 优惠类型: 新客立减券 2. 适用车型: 小面、中面 3. 优惠金额: 首单立减10元 4. 有效期: 领取后7天 5. 限制条件: 仅限未下单新用户 参考案例: {召回的相似历史文案} 生成要求: - 只在事实清单范围内编写文案，不得出现任何事实清单中没有的优惠信息。 - 根据渠道[{channel}]调整表达方式。 - 必须给出3个文案方向，每个方向侧重点不同。 - 返回格式为JSON数组，每个元素包含title, content, reason。 禁止事项: - 禁止使用“点击链接”“立即下载”等诱导性词汇以外的违规词。 - 禁止编造价格、折扣、活动时间。 - 禁止使用夸大宣传用语。

这里的核心是“事实清单”单独成段。我们试过把活动规则混在描述文本里，模型仍然容易漏掉或发挥，单独列出来并配“禁止事项”后，事实层面的幻觉明显下降。

3.2 输出校验不只是做格式检查

大模型输出JSON后，我们并不直接入库，而是先过一个“可计算校验层”。具体做的事包括：

• 用正则提炼出所有金额、时间、加减乘除表述，和事实清单做交叉比对
• 检查是否出现禁用词、竞品词、绝对化用语
• 用情感极性模型过滤负向表达，避免出现“不再担心”这类看似没问题但实际含有负面暗示的句子

这一步非常关键。我们早期上线时曾出现过一条文案，模型把“拉货”语境输出成“搬运东西”这种口语化表达，没问题，但有一次把“货主”写成了“老板”，在司机端语境下显得不够友好。这种问题靠规则很难完全覆盖，至少要把“称呼类敏感词”纳入禁用清单。

3.3 用“多样性控制”让批量生成不千篇一律

批量生成一定会遇到的坑：给同一个活动生成100条文案，可能前50条都非常相似。我们采用了三个办法控制多样性。第一，提示词中要求模型“给出3个不同侧重点的方向”，比如价格敏感型、时效敏感型、安全保障型。第二，在推理时调整温度参数，从默认的0.7提高到0.9，同时配合Top-p采样。第三，在生成完成后做一层语义去重，用向量模型计算两两相似度，把相似度高于0.92的候选合并。

这里有一个比较容易翻车的细节：**温度开太高会让文案变得“飘”，甚至出现语法错误。**我们在实际测试中把温度从0.7调到0.9之后，点击率数据略有提升，但审核驳回率从2%涨到了5%。后来加了针对性的约束，只允许在“风格描述词”范围内变化，不允许改变句式结构，才把驳回率压回去。

3.4 人工审核工作台的交互设计

模型生成好之后，审核人员不是一个个看原始文案，而是看到一个“候选池”，每个候选旁边带着结构化的reason（生成依据）。审核员可以一键采纳，也可以直接编辑。被采纳和被修改的文案都会回流到历史素材库，变成下一轮RAG的参考案例。这就是我们实际运转的“人机协同”循环。

我建议所有做内容生成类项目的团队都重视这个交互设计。很多项目失败不是因为模型不够好，而是因为人工审核的成本太高，审核员宁可自己写也不想用你的系统。有了reason字段和快捷采纳按钮之后，我们的审核效率提升了大约40%，审核员也愿意主动用这个系统了。

4. 个性化投放与动态落地页：让大模型参与“买量以后”的承接

广告文案生成只是第一步，我们在项目中期把大模型的应用延伸到了“落地页动态生成”和“个性化投放”两个场景。这部分的业务价值更大，但实现复杂度也更高。

4.1 司机端和货主端的意图识别

货拉拉的广告触达不只有App内部渠道，还有外部信息流、短视频平台等买量场景。买量核心痛点在于：用户点击广告进来之后，如果落地页内容和广告创意不匹配，流失率会非常高。以前的做法是人工配置通用落地页，一个活动一个页面，所有用户看到的都一样。大模型介入后，我们可以根据用户点击广告时携带的参数、设备信息、渠道来源，先对用户做一次“意图判断”。

意图判断不是简单的城市判断，而是更细的语义理解。比如同一个“拉货”关键词，来自货主端的用户可能想找“同城搬运”，来自司机端的用户可能想看“平台运力需求”。我们用大模型对点击行为做短文本分类，结合历史订单数据和设备标签，生成一个动态的“用户画像摘要”。这个摘要会作为落地页生成的输入条件。

4.2 动态落地页：从“改标题”到“改利益点结构”

动态落地页一开始我们只让大模型改标题和首屏文案。后来发现，不同用户对利益点的敏感顺序不一样。有的用户关心价格，有的用户关心服务保障，有的用户关心接单效率。如果落地页的整个利益点结构都能动态调整，转化效果会好得多。

实现上并不复杂：先把落地页拆成几个固定区块，比如标题区、优惠区、服务保障区、底部行动引导区。大模型根据用户画像摘要，决定每个区块的展示内容和展示顺序，并在服务保障区从知识库中召回对应的保障条款文案。为了确保排版不出问题，最终输出的是一个结构化的区块配置JSON，前端再按JSON渲染。

4.3 个性化投放的代价是“一客一落地页”的成本模型

很多团队会忽略一个问题：个性化内容意味着每个点击用户都对应一次模型调用。如果买量峰值带来的流量是每分钟上万级别，模型推理的算力成本和延迟就会直接变成瓶颈。

我们做了三件事来缓解。第一，对用户意图做缓存，同一用户短期内的画像摘要不重复计算。第二，针对低频访问的长尾用户，直接用规则模板渲染落地页，只有命中特定兴趣标签的用户才走大模型动态生成。第三，把模型推理拆成“粗排”和“精排”：先用小模型判断用户是否值得个性化，再调用大模型生成最终内容。这样实际走大模型的流量只占总流量的两成左右，而这两成用户贡献了大部分转化增量。

这个方案上线后，我们对落地页的平均停留时长和转化率做了对比。个性化落地页的转化率比通用落地页高出约18%到25%，不同活动类型波动挺大。但值得注意的是，个性化并非在所有场景下都有效，比如纯品牌曝光类活动，个性化反而会让页面承载过多信息，造成用户迷茫。所以个性化投放要选场景，不是越多越好。

5. 踩坑实录：幻觉数据、素材安全、成本失控的完整排查链路

这一节我把项目过程中最典型的几类问题捋一遍，这些问题在文档里很少被写透，但实际做项目时几乎都会遇到。

5.1 第一个坑：模型把活动规则“说圆了”，但实际是编的

上线后的第一个星期，我们发现有一条Push文案在描述优惠时说“老用户最高可享8折”，但该活动的实际情况是“老用户可领满100减20券”。模型很聪明地把“满100减20”换算成“最高8折”，听起来完全合理，但这是模型自己做的数学换算，不在事实清单范围内。

排查链路是这样的：先沿着traceID找到生成参数，确认提示词里的“事实清单”确实没有8折相关信息；再对比历史素材库，发现有一条类似活动的历史文案中恰好出现过“最高可享8折”的表述，被RAG召回了；最后确认是模型在推理时将参考案例中的营销话术和当前活动要素混在了一起。

解决方案有两步：第一步，事实校验层增加“折扣一致性检测”，凡是出现百分比折扣和实际优惠金额不一致的文案，一律打回重写；第二步，RAG召回时过滤掉“优惠信息与当前活动不一致”的参考案例，避免模型被带偏。

5.2 第二个坑：投毒测试出来的“漏网之词”

这里说的投毒测试是指通过构造恶意输入，检测模型生成内容是否会被诱导到违规方向。我们做了一轮针对广告语境的对抗测试，发现模型在极少数情况下会把“新用户”写成“新手”，把“司机师傅”写成“老师傅”。单独看这些词不算违规，但在特定方言地区，“老师傅”可能让人联想到年龄歧视。

这个问题靠增加禁用词表解决不彻底，因为禁词表不可能覆盖所有“方言敏感词”。我们的对策是：在模型推理后加一层“方言与地域敏感词检测器”，这个检测器本身也是一个轻量模型，专门对输出文案做多标签分类。一开始会增加几十毫秒延迟，但在安全性和长期维护成本面前，这几十毫秒完全可以接受。

5.3 第三个坑：成本失控不是模型贵，是因为“重复生成”

项目初期，为了追求输出质量，我们在每个生成任务里让模型生成5个候选文案。结果一个月下来，推理成本比预期高了3倍。后来一查，发现大量生成请求的提示词几乎完全一样，比如同一活动在不同渠道下，除了channel参数不同，其他内容完全相同。

后来我们加了两层缓存：第一层是“要素级缓存”，如果活动信息和参考案例完全相同，直接复用之前已审核通过的文案；第二层是“相似生成缓存”，对向量相似度极高的活动配置，直接复制结果并做轻量改写。两层缓存上线后，模型调用量下降了60%以上，整体成本只相当于原来的40%左右。

这里有一个心得：成本优化要从“减少无效生成”入手，而不是单纯换更便宜的模型。无效生成不只是浪费算力，还会带来审核员的工作量淤积，因为审核员看到大量候选时容易产生疲劳。

5.4 第四个坑：效果归因不统一导致模型迭代方向摇摆

我们早期迭代模型时，以“点击率是否提升”作为唯一指标。后来发现点击率受投放渠道、素材尺寸、投放时段的影响非常大，同一批文案在不同渠道上的点击率差异可能超过一倍。如果我们只看点击率来反推模型好坏，很容易被渠道因素干扰，得出错误结论。

最终我们把评估体系改成“三明治结构”：底层看生成合规率（是否通过自动校验、是否被审核驳回）、中间层看内容有效性（点击率、转化率）、顶层看业务收益（ROI、客诉量）。模型迭代时以底层合规率为准，渠道投放优化时看中间层和顶层指标。这样每个环节各司其职，不会相互甩锅。

6. 效果复盘：从人工写稿到人机协同，数据上的收益有多大

项目运行稳定后，我们做了一次全身性的效果复盘。这里列出的数据是脱敏后的范围值，不同活动和不同投放周期会有波动，但整体趋势是可以参考的。

这里最让我觉得值得分享的不是点击率数字，而是团队工作方式的改变。过去的运营同学每天花大量的时间在“写文案、改文案、催设计出图”上，现在他们把更多时间花在“定义活动要素、配置事实清单、审核候选文案、复盘效果数据”上。这个转变本质上让人的精力从重复劳动转向了决策和判断。

审核驳回率稳定在4%左右的水平，这意味着模型生成的文案有96%可以直接被采纳或微调后采纳。那4%里有一半以上是“风格不符合渠道调性”，比如在短信任写了太长的口语化表达，真正的合规性问题已经降到了千分之几。

还有一组隐藏数据：客诉量。我们特别关注“因优惠信息不准确”导致的客服咨询量，上线大模型文案生成之后，这条客诉类目不仅没有上升，环比还下降了10%。这正是事实清单和自动校验环节起到的实际作用——它让生成过程本身就带着可追溯、可核对的事实依据。

7. 最后想替所有做类似项目的同学总结三句体己话

第一，做广告文案生成，别把“生成得像人写的”当成第一目标。第一目标应该是“生成内容可安全上线”。先把事实校验、违规检测、人工审核闭环跑通，再回头优化文风和创意，顺序不能反。

第二，多花点时间在“数据回流”上，比调一版更好的prompt值钱得多。我们迭代提示词的依据不是感觉，而是每周从审核工作台和投放反馈中导出的真实case。每一次“被驳回”“被修改”“低点击率”的文案，都是在帮模型指出明确的优化方向。没有回流的数据，模型再聪明也学不会业务偏好。

第三，项目的成功离不开所有“看起来不酷”的环节。很多团队一上来就奔着微调大模型去，但我个人认为，在大模型应用项目里，提示词工程、知识召回、输出校验这些基础环节的重要性和优先级远高于微调本身。我们是在把前三者打磨明白之后才做了轻量微调，那一轮微调确实让生成口吻更贴合货拉拉不同端用户的表达习惯，但如果没有前期打底，微调只会放大系统性的错误。

这套“大模型在货拉拉营销广告的应用实践”做下来，我最直接的感觉是：大模型不是在替营销团队“写作文”，而是在帮整个团队搭建一套全新的创意生产系统。系统里最值钱的部分，恰恰是那些让模型“不犯错”和“学了能改”的工程能力。