企业官网建设流程全解析

先说说背景。货拉拉这家公司，主营同城货运、跨城运输和搬家，用户规模几千万，司机端和用户端的DAU都不低。营销广告的体量非常大——光是一天的Push推送、短信触达、App内弹窗、社交媒体投放，就能产生几千条文案需求；如果再算上不同城市、不同车型、不同用户标签的组合，人工根本写不过来。我们团队从去年开始把大模型引入营销广告体系，从最开始单纯用GPT类API生成文案，到后面自己微调开源模型、搭建RAG知识库、做Agent编排，整个过程踩了不少坑，也沉淀了一些可复用的经验。这篇内容就围绕这个实践来聊，适合那些正在做"大模型 x 营销"或者准备做营销中台改造的同学，尤其是电商、本地生活、出行物流这类强运营属性的平台，我们的问题和解法大概率你们也会遇到。

1. 业务场景：货拉拉营销广告到底需要什么

1.1 货运平台营销的真实痛点

货拉拉的营销场景比普通电商更复杂，因为用户决策链路长，而且带有很强的即时性和本地化属性。用户打开App可能是为了明天搬家，也可能是为了立刻拉一批建材，这两种状态下看到的广告文案完全不能一样。过去的做法是运营团队建一堆文案模板，再用标签拼接的方式组合出"千人千面"的效果，比如"您附近的搬家师傅已就绪"这种话术。模板化的问题很明显：写多了用户会产生模板疲劳，打开率越来越低；同时模板是静态的，无法根据时段、天气、库存运力动态调整。

更麻烦的是素材维度。广告除了文字，还有图片、短剧脚本、语音外呼话术。货拉拉做过不少这类活动，比如"拉货节""搬家季"，需要大量视觉素材和互动内容。以前这些全靠外包设计团队和运营手工磨，一个活动上线光物料准备就要2到3周，等上线的时候市场热点早就过了。运营同学经常抱怨，好创意是有的，但量产不出来，一个活动只能保重点渠道。

投放侧的痛点同样突出。货拉拉的获客渠道分付费投放（信息流、搜索）和自有渠道（Push、短信、应用内消息），每一类渠道都需要对应的广告文案、落地页和人群定向策略。传统的投放优化依赖优化师经验，A/B实验一个一个做，周期长，而且很难把"用户行为"和"文案内容"建立细粒度的归因关系。比如某个渠道的点击率突然下降，优化师没法快速判断是文案问题、出价问题还是人群包过窄。

这正是大模型能切入的地方。LLM天然适合做三件事：文本生成、意图理解、知识组织。营销广告本质上就是"在合适的时间，用合适的语言，把合适的服务推给合适的人"。大模型可以把原来由人完成的创意发散、文案起草、素材标注、内容审核这些环节自动化，而且可以基于实时反馈做迭代。我们在立项的时候就是围绕这四个环节来的：内容生成、用户理解、投放优化、效果复盘。

1.2 大模型能切入的四个环节

第一是内容生成。利用大模型生成活动主题词、Push文案、短信、落地页标题、商品利益点，以及多模态的图片素材（比如用Stable Diffusion或者多模态大模型生成活动海报底图，再用LLM生成配套文案）。我们最开始投入产出的就是这里，因为需求最直接、见效最快。

第二是用户理解。这里的"理解"不是做用户画像标签这种传统东西，而是把大模型变成"语义引擎"，去解析用户的进线诉求。比如用户在App内搜索"搬钢琴"，我们不只是知道"搬家需求"，而是知道这是一个需要专业钢琴搬运、需要气垫膜和固定绳的高价值订单，从而生成更精准的广告文案和调度建议。

第三是投放优化。利用大模型生成"人群包解析报告"和"渠道投放策略建议"。这不是让模型直接改出价，而是让它从历史投放数据中总结规律，输出"哪些人群在什么时间段更容易转化，用什么样的话术刺激"这类可执行建议，辅助优化师决策。

第四是效果复盘。大模型把每周的广告数据报告自动生成摘要，识别异常波动，并关联到可能的原因——比如"点击率下降了，可能是因为上周主打搬家场景，而这周新用户比例增加，新用户对搬家措辞的共鸣度较低"。这个能力帮运营省了大量的读表时间。

这四个环节不是一次性铺开的，而是按季度分批推进。第一阶段只做文案生成，跑通评估流程；第二阶段做知识库和微调，提升内容的业务匹配度；第三阶段才做 Agent 编排。接下来重点讲技术选型和工程落地过程中的细节。

2. 技术选型：不是越大的模型越好

2.1 基础模型对比与实际选型

营销广告场景对模型的要求有几个特点：第一是输出长度不长但必须高度符合业务语境；第二是需要支持多轮改写和微调；第三是单次调用的成本敏感，因为广告文案生成的调用量非常大，一天可能几百万次。如果完全依赖闭源API，费用会非常失控。

所以我们的底座选型是"闭源API + 开源大模型"双轨制。一些复杂的创意发散任务（比如活动主题脑暴、短剧脚本）用更强的闭源模型；而高频、规则化的任务（比如Push文案生成、短信文案改写）用开源自部署模型。开源的候选模型当时主要看了Qwen2.5系列和Llama 3系列。经过一段时间实测，我们最终把主力模型定在Qwen2.5-7B-Instruct和Qwen2.5-14B-Instruct两个规格上。

为什么是Qwen而不是其他模型？几个实际原因：第一，Qwen的中文能力在同尺寸模型里确实靠前，尤其是在营销文案这种"需要一点语言巧思"的任务上，生硬感明显更少；第二，Qwen对Function Call和工具调用的支持比较完整，后续做Agent编排很方便；第三，有大量社区微调案例，我们踩到坑的时候能搜到很多解决方案。14B模型用于质量要求高的场景，7B模型用于成本和延迟敏感的场景。两个模型可以共用一套微调流程，只换底座权重，适配器（Adapter）分开管理，非常灵活。

关于多模态，我们后期也接入了图片生成模型，用来生成活动海报的底图和优惠券的视觉素材。这部分单独做了一个图像服务，和文本生成服务解耦。注意，多模态大模型不是必须的，如果你的营销素材主要靠设计师手工做，我建议先别急着重投入，文本广告的应用边际价值更大。

2.2 微调方案：LoRA与QLoRA的选择逻辑

刚开始我们也想过用闭源API加提示词的方式硬扛。但做了两个月发现不行，因为营销文案有很强的品牌调性，比如货拉拉的"拉货赚钱"口号，就不能让模型随意发挥出"高端物流"的调性。提示词里写了"要符合货运平台风格"，模型还是会不稳定。于是我们决定微调。

从热搜里你应该也看到"大模型微调实战"和"qwen2.5-7b微调行业大模型"这些词越来越火，说明微调已经是一个被广泛验证的技术路径。我们的微调方案首选LoRA，而不是全量微调，原因很朴素：我们的数据量只有几万条，全量微调容易过拟合，而且我们需要快速迭代多个业务线的模型，LoRA可以做到每个业务一个Adapter，最初用一套底座基座，需要切换业务时动态加载不同的LoRA权重，存储开销和训练成本都很低。

QLoRA我们也测过，就是在LoRA的基础上把基座模型量化到4bit后再训练。对于单卡24G显存的机器，QLoRA可以跑14B模型，LoRA只能跑7B或者小规模14B。如果你的资源有限，可以优先QLoRA；如果追求训练稳定性和效果，LoRA更好。我们最终对14B模型使用了QLoRA，对7B模型使用LoRA，因为7B模型直接加载到单卡很轻松，没必要量化引入额外的精度损失。

微调数据方面，我们把历史上所有点击率高于渠道均值1.5倍的文案作为正样本，把低于阈值的作为负样本，让模型学习"什么样的措辞更受欢迎"。具体训练时不是让模型去分类，而是把正样本作为标准答案做条件生成训练，负样本用来构造对比样本做DPO（Direct Preference Optimization）。DPO的效果比单纯SFT要好，因为模型能学到"避免用户不喜欢的话术"，而不仅仅是模仿好文案。

2.3 推理部署策略：vLLM与Ollama的取舍

部署层面，我们分两套环境。开发测试环境用Ollama，因为启动快、配置简单，不需要额外写服务代码，适合算法同学本地验证。生产环境我们用的是vLLM，因为它支持PagedAttention和Continuous Batching，吞吐量比原生Transformers的生成方式高很多。我们压测过，同样一张A10显卡，部署Qwen2.5-7B，用vLLM的并发吞吐量大约是原生推理服务的2.5到3倍，而且长文本生成时的显存占用更稳定。

如果你也需要部署生产环境的大模型，记住几个关键点：第一，使用OpenAI兼容的API接口，这样上层业务代码可以无感切换闭源API和自建模型，我们整个营销系统对外暴露的统一接口就是这种格式；第二，必须开启流式输出（SSE），因为广告文案生成如果让用户等2秒再一次性返回，体验很差，流式可以边生成边展示，首字延迟能做到500毫秒以内；第三，要有完善的监控，包括每秒钟请求数、平均首字延迟、平均Token生成速度、显存占用和GPU利用率，这些指标任何一个异常都可能导致线上事故。

关于"本地部署大模型"和"ollama部署私有大模型"这些热词，如果只是个人玩玩或者做POC，Ollama确实很方便。但假如你做生产环境，还是老老实实用vLLM这类工业级推理框架。Ollama在模型并发、服务稳定性、量化精度控制上还是相对弱一些。

3. 工程化实践：从Prompt到Agent

3.1 提示词工程与上下文工程：营销文案稳定性的第一道防线

很多团队一上来就微调，其实顺序错了。提示词工程是性价比最高的手段，先用好提示词，再考虑微调。我们的Prompt模板经历过四个版本迭代。

第一版是一个简单的指令：给我写一条货拉拉搬家优惠的Push文案，带上限时优惠。结果输出的文案千篇一律，而且格式很乱。第二版加入了角色设定和输出格式要求，比如"你是一位资深用户运营专家，请用口语化的语气生成一条Push文案，不超过30个字，必须包含利益点和紧迫感"。效果好了不少，但内容仍然不够有针对性。

第三版引入了结构化输入。我们把用户特征、活动信息、渠道特征全部作为上下文输入，比如：

{ "user_profile": { "city": "成都", "user_type": "三个月未下单", "last_order_category": "搬家", "preferred_time": "周末上午" }, "campaign": { "name": "周末搬家优惠", "discount": "满80减20", "start_time": "2025-06-14 00:00:00", "end_time": "2025-06-15 23:59:59" }, "channel": "app_push", "output_format": "title: [10字以内]\\n body: [30字以内]\\n action_url: [短链]" }

自从用了结构化输入，模型的输出稳定性大幅提升。这就是为什么"大模型提示词工程与上下文工程"现在被频繁放在一起说——上下文工程不只是往Prompt里塞几个变量，而是把业务语义、场景约束、输出schema都系统化管理起来。

第四版加入了Few-Shot示例。我们从历史点击率最高的文案中挑选了5条不同风格（悬疑型、直接利益型、情感共鸣型、地域型、时效紧迫型）作为示例，每次调用时动态选择最贴近当前用户特征的2到3条放入Prompt。这里有个细节：示例不要只给好的，不给坏的。我们试过在示例中加一条"错误示例：用户不喜欢的文案风格"，模型会明显更懂得规避。

提示词的核心原则可以归纳成三点：第一，角色设定能改变文风；第二，输出schema能改变格式；第三，Few-Shot能改变专业性。做营销广告，这三层缺一不可。

3.2 RAG：把品牌规范和业务知识注入生成过程

光有提示词还不够，因为营销知识是动态的。比如货拉拉在不同时间段有不同的活动政策，价格权益也在调整。如果把这些信息写死在Prompt里，一旦政策变化就得改代码，很不方便。我们引入了RAG（检索增强生成），用向量数据库存储所有活动规则、品牌关键词表、禁忌词表、历史优秀文案库，每次生成前先检索最相关的几条知识作为上下文。

举例说明，运营在后台创建一个新的活动"新人首单立减25元"，并写了活动说明。系统会先把活动说明存入向量库，同时关联到已有的"新用户引导话术"知识块。当用户触发Push生成请求时，RAG会检索"新人首单+立减25元"相关的知识片段，再结合用户画像去生成文案。这样就保证了文案一定包含正确的优惠金额，不会出现"立减30"之类的幻觉金额。

RAG的落地有几个坑要提醒：

• 向量库的切分粒度不要太大，我们最初按整个活动页面切chunk，检索出来很多无关内容，后来改成按"利益点+适用人群+时间限制"切，检索准确率提升明显。
• 混合检索比纯向量检索好。营销文案里经常有"搬家""拉货"这种词，向量相似度不一定抓得住，我们加了BM25关键词召回，再做Rerank，Top1的命中率从62%提升到了89%。
• 知识库需要定期更新和清理。我们每周跑一次脚本，把已过期的活动规则从向量库中移除，避免模型生成时推荐已经下线的权益。

RAG的意义不只是知识补充，它还给模型提供了一条"证据链"。当运营同事问"为什么生成这样一条文案"时，系统可以展示命中了哪些知识片段，这在业务评审时非常重要。广告是强合规场景，任何一句"全场五折"的幻觉都可能带来客诉。

3.3 Agent编排：让大模型真正参与投放决策

把RAG和提示词用好之后，再进一步就是Agent编排。我们做了一个叫"活动操盘助手"的系统，输入一个活动目标和预算，Agent会自动完成以下任务：

第一步，调用意图识别模型解析活动目标，比如"提升老用户复购"就触发"老用户召回策略"。第二步，从用户画像库中圈选目标人群，这一步不是用大模型直接生成SQL，而是让模型通过Function Call调用人群筛选工具，传入结构化参数。第三步，生成多套文案方案并配上预估点击率（这里用了一个小的CTR预测模型做打分）。第四步，根据渠道特点自动选择文案和素材，比如Push渠道用短文案+短链，信息流渠道用视频脚本+落地页。最后，生成完整活动配置工单，交给运营确认后一键发布。

这套Agent的技术架构不复杂，就是一个带工具调用能力的大模型加一个工作流引擎。重点在于每一步都要有"人审"开关，不能完全自动。因为营销涉及用户的钱袋子和品牌形象，任何一环出错都可能是事故。我们把Agent的自动率控制在40%左右，剩下的60%由系统生成建议、人工确认。随着模型效果稳定，再逐步放宽自动执行的范围。

从热搜词"大模型智能体 旅游推荐"能看出来，Agent应用正在各种行业渗透。但营销Agent和泛娱乐Agent有一个本质区别：营销需要可量化的商业目标，每一步都围绕转化率、客单价、ROI来优化，而不是聊得开心就行。所以建议各团队在做Agent时，先把业务指标拆到底，再设计工具链，顺序不能反。

4. 实操记录：一套完整的落地步骤

4.1 数据准备：从历史广告日志里挖金子

数据是微调模型的根基。我们在启动微调前，花了两周时间专门做数据清洗。原始数据是广告投放日志，包含渠道、文案内容、展示次数、点击次数、转化次数、用户标签、时间戳等。第一步做数据去重，把内容完全相同的文案合并，保留累计数据。第二步做质量过滤，把长度小于5个字的、包含明显拼写错误的、没有CTA的文案剔除。第三步做正负样本标注。

正负样本的判定不能只看点击率，因为不同渠道的基准点击率差异很大。比如Push的平均点击率可能只有3%，但短信可能只有0.5%，信息流的点击率又不同。所以我们对每个渠道单独计算中位数，点击率高于渠道中位数1.5倍的算正样本，低于0.8倍的算负样本，中间的部分不参与训练。这样做的目的是让模型学到"相对优秀"而非"绝对点击率高"。

我们还需要广告分层数据。例如一个活动文案可能被推给了不同的人群，同一句话在不同人群上的点击率差异很大。为了简化初版模型，我们只保留那些在至少三个不同人群上都高于中位数的文案做正样本，这样可以减少过拟合。总共筛出正样本2.3万条，负样本1.8万条。说实话，这个数据量训练7B模型不算多，但配合DPO和强基座，效果还是够用的。

4.2 微调实战：基于Qwen2.5-7B的LoRA代码

微调我们基于LLaMA-Factory来做，因为它内置了LoRA、QLoRA、DPO等训练脚本，省了很多底层功夫。关键配置如下：

model_name_or_path: Qwen/Qwen2.5-7B-Instruct dataset: marketing_ad finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 num_train_epochs: 3 learning_rate: 2e-4 per_device_train_batch_size: 4 gradient_accumulation_steps: 8 lr_scheduler_type: cosine warmup_ratio: 0.1

训练过程中有两个需要特别留意的地方：

第一是训练数据格式，LLaMA-Factory要求对话格式的字段。我们把营销场景封装成一个三段式对话：system描述品牌调性和输出约束，user输入用户特征和活动信息，assistant输出标准文案。这样微调出来的模型，推理时也沿用同样的格式，一致性很强。

第二是学习率不要设太大。LoRA的r=16在营销数据上如果学习率超过5e-4，特别容易灾难性遗忘，也就是模型开始生成乱码或者重复文本。另外，alpha是lora_rank的两倍，这是社区验证过的较优默认值，我们试过1倍和4倍，效果都没有2倍稳定。

训练完成后把Adapter保存下来，和基座模型一起加载到vLLM。这里还有一个实用技巧：如果多个业务线各有一个Adapter，一定要在服务启动时一次性加载所有Adapter，然后通过请求里的lora_name字段动态切换，而不是每次都重新加载模型，这样可以节省好几个数量级的切换时间。我们最初就是每次切换都reload模型，接口延迟直接飙到3秒以上，后来改成动态切换后延迟降到了200毫秒。

4.3 部署与评测：不能只看BLEU

部署阶段，我们用vLLM起了两个推理服务，一个跑基座带LoRA，一个跑纯通用模型。对外统一走OpenAI兼容接口，用Nginx做负载均衡和路由，根据请求中的model字段区分调用哪个服务。

刚上线时我们犯过一个低级错误：没有做并发控制和排队机制。广告运营在活动高峰时会一次性批量生成几千条文案，直接把GPU服务打满，导致后面的请求全部排队等待，首字延迟从500毫秒飙升到10秒。后来在API层加了基于Redis的令牌桶限流，又增加了一个异步任务队列：批量请求先落数据库，由Worker从队列中消费再调用大模型，生成完后回调通知前端。用户体验从"等10秒出全部"变成了"先看到生成进度，30秒后查看结果"。虽然表面看起来还是等，但不会因为超时导致失败。

评估维度上，我们分自动化和人工两条线：

• 自动化评分：用中文BLEU和ROUGE跟历史最优文案做相似度对比，此外还加了三个业务指标：利益点完整率（是否包含满减金额、券码、时间）、品牌词规范率（是否出现"货拉拉"正确拼写）、CTA完整率（是否包含行动号召）。
• 人工评分：运营同事按1到5分打分，维度包括相关性、吸引力、合规性、格式质量。每个版本上线前抽200条样本做人工盲评。

实践三个月后，我们发现BLEU和ROUGE与业务指标的相关性其实不强。有的文案ROUGE得分高但因为模仿痕迹太重，点击率反而不高。所以后期我们对自动化评分做了降权处理，人工评分权重提上来，同时直接用线上A/B点击率作为最终裁判。工具指标用于快速筛选，业务指标用于最终决策。

5. 常见问题与排查技巧实录

5.1 模型输出幻觉和违规内容怎么处理

广告内容最怕幻觉。我们遇到过几次模型生成了不存在的优惠，比如活动明明是"满100减10"，模型却写了"全场6折"，原因是训练数据里有过期活动文案，模型学到了不该学的模式。解决分三层：

第一层，Prompt层强约束：在system提示中明确写"优惠金额必须引用用户输入中的campaign字段，禁止编造折扣信息"，同时给出JSON Schema，要求输出时带上discount_source字段，这个字段标注了金额引用的是哪条知识。

第二层，RAG兜底：生成完成后，把输出中的金额类关键词与知识库中的有效活动规则做一次精确匹配校验，如果发现不一致，自动重新生成或进行纠正。这一步我们直接用简单的正则加向量检索做，不需要再调一次模型。

第三层，输出审核服务：所有生成内容过一遍敏感词表和合规规则引擎，比如"全网最低""唯一""绝对"这类广告法禁词直接用黑名单拦截。

对于更隐性的违规（比如过度承诺服务质量），目前的做法是在训练数据中增加人工标注的负面样本，然后定期做RLHF或者DPO迭代。这个方向不能指望一步到位，需要业务同学持续反馈错误案例，沉淀成"违规样本库"，变成我们的负例知识库。

5.2 推理延迟和成本如何平衡

营销广告生成服务有两大成本：GPU硬件成本和API调用成本。我们用自部署模型后，单条Push文案生成的成本大概只有闭源API的十分之一，但GPU资源本身也很贵。平衡手段有三招：

首先是模型分档。最轻量的场景（比如Push内容）用7B模型，承载80%的流量；复杂场景（比如落地页长文案）用14B模型，承载15%流量；剩余的创意性任务（活动主题、视频脚本）才调用闭源API。分档之后，整条链路的单位成本下降了约60%。

其次是输出Token限制。很多营销文案其实20字就够，但模型默认配置可能会输出70到80字，导致推理时间翻倍。我们在API层对所有生成任务都设置了max_tokens上限，Push文案限制32，短信限制48，标题限制12。别小看这个调整，整体吞吐量提升了接近20%。

最后是缓存。同一用户在同一活动周期内点击同一条Push的概率其实很低，但同类型用户之间文案相似度很高。我们做了一层语义缓存：把用户特征向量+活动ID作为key，生成结果缓存5分钟。对于高峰期的批量发送场景，这个缓存可以拦截大约30%的重复生成请求，性价比非常高。

5.3 业务指标提升不明显怎么办

上线大模型后，运营最常问的问题是："点击率提升了吗？"第一个版本我们确实没有达到预期，点击率只比原来的模板系统高了0.2个百分点，几乎可以忽略。后来复盘发现，问题不在模型，而在实验设计。

原来的模板系统用于点击率比较低的角落渠道，而大模型优先接入的却是主Push渠道。主Push本身的点击率基数高，用户已经形成习惯，几行字的变化对点击影响有限。我们调整策略后，先把大模型应用在短信、应用内消息、社交弹窗这些"文案敏感型"渠道上去做A/B测试，效果立刻明显了，点击率普遍提升了1到2个百分点。这告诉我们，大模型营销不是把每个渠道的文案都替换一遍就完事，要找准对内容最敏感的触点。

另一个教训是：不要频繁更换文案风格。模型生成的文案如果天天变，用户会失去辨识度。我们后来固定了每个活动的文案风格候选池，只允许模型在5个风格之间选择，而不是每次都零样本从头生成。这个约束反而让点击率更稳定，因为用户对固定风格产生了预期。

如果你的业务也遇到指标不涨的情况，我建议按这个顺序排查：第一，渠道是否选对了（用文案敏感度分析）；第二，实验是否跑够了周期（至少两轮完整活动）；第三，模型输出的内容是否和活动目标一致（别把促销文案写得像品牌软文）；第四，是否过度依赖模型而忽略了下游的落地页承接。点击率提升不是文案单点的事，落地页如果跟不上，用户点进来也是跳出。

6. 踩坑总结：那些文档里不会写的经验

最后分享几个文字之外的体会。

第一，大模型落地营销广告，组织协作比技术选型难。算法团队和运营团队需要建立一套"共建"机制。我们每周做一次案例评审，运营把本周他们觉得不好用的生成结果贴出来，算法反向拆解是提示词问题、数据问题还是模型问题。这个机制让模型的迭代方向始终贴近业务，而不是算法自嗨。如果没有这个机制，光靠我们自己在办公室闭门造车，可能三个月都摸不透业务侧的真实需求。

第二，不要试图让模型一步到位取代运营。最理想的状态是"模型产出80分的初稿，运营用10分钟调优到90分"。我们之前的误区是想让模型直接输出95分的成品，结果投入了巨大的调优成本，边际收益反而很低。后来我们把生成系统定位为"超级助理"而不是"投放决策者"，运营写文案的时间从每天2小时压缩到20分钟，大家满意度大幅提升。工具的价值不是替代人，而是帮人节约低效劳动。

第三，数据安全要前置考虑。营销文案涉及用户手机号、下单记录、行为轨迹等数据，大模型服务不能直接接触这些字段的原始值。我们做了严密的脱敏处理，所有传入模型的特征都经过映射和泛化，比如精确的下单时间会被转换为"周末上午"这种语义标签，手机号从不会出现在Prompt里。另外，模型服务的访问控制在虚拟私有网络内部，通过网关统一鉴权，外部无法直接访问。这块一定要在项目启动时就规划好，后期补会极其痛苦。

第四，关于微调数据的活水问题。模型上线后不是一劳永逸的，每周都会有新的优秀案例和失败案例。我们搭了一个"案例回流"管道：每次运营在后台手动修改过模型生成的文案，都会自动被记为一条增量样本，每周聚合成微调数据。这样模型会越来越熟悉运营的偏好。这个机制虽然简单，但坚持做了半年后，运营的修改比例从最初的40%降到了大概15%，效果是肉眼可见的。

现在这套系统已经在货拉拉营销侧稳定运行了一段时间，每天生成几万条定制文案，覆盖Push、短信、弹窗、外呼话术等多个场景。我们从最开始的"写着玩"变成了真正能提效的业务工具，中间的过程说不上顺利，但每一步试错都很有价值。如果你们也在考虑把大模型引入营销体系，希望这篇实践记录能帮你少踩几个坑，尤其是在数据准备、指标评估和运营协作这几个方向，多做一点准备，后面会省很多事。