电商文案这个场景看起来只是让模型写几句卖点但真正落到批量生产问题会立刻从模型会不会写变成成本扛不扛得住、吞吐跟不跟得上、质量稳不稳定。我前后帮三个团队搭过类似的文案流水线从最初直接用在线API硬怼到后来改成本地小模型打底 大模型兜底 模板约束的混合架构中间踩的坑足够写一篇长文。这篇就把电商文案批量生成这件事从成本结构和工程化两个维度彻底拆开讲适合已经会用大模型API、但一上量就发现账单失控的开发和运营同学。1. 先算清楚一笔账电商文案批量生成的成本到底花在哪很多人做成本优化第一反应是换个便宜的模型。这个思路不能说错但往往优化不到点子上因为电商文案的成本结构里模型单价只是其中一项而且经常不是最大那一项。1.1 单条文案的真实成本拆解我们先把一条文案的成本拆成四块输入token、输出token、重试开销、人工兜底。前两块是显性的后两块是隐性的而隐性成本经常被忽略。假设一个商品需要生成标题1条、卖点5条、详情页段落3段、短视频口播1条。粗算下来输入大概800 token商品参数、类目、风格要求、few-shot示例输出大概600 token。如果用的是中等价位的模型按每百万token输入几块钱、输出十几块钱来算单条成本其实很低低到你会觉得这有什么好优化的。但问题在于批量。一个中型店铺一次上新可能就是几千个SKU每个SKU还要生成多语言、多平台版本。这时候单条成本乘以几万账单就出来了。更要命的是重试模型偶尔会输出格式不对、包含违禁词、或者干脆跑题你需要重新调用重试率哪怕只有15%成本就直接上浮15%。提示统计成本时一定要把重试调用单独记账否则你永远不知道真实单价是多少。我见过一个团队以为自己单条成本是2分钱实际算上重试和失败请求是3分5差了将近一倍。1.2 为什么换便宜模型经常是伪优化便宜模型的问题不在单价在于它需要更多次的交互才能达到可用质量。一个强模型可能一次就给你合格输出一个弱模型你可能要重试三次、或者加更长的提示词、或者事后用另一个模型来修正。这些都会把省下来的单价吃回去。我做过一组对比同一个商品集用强模型一次通过率约88%用弱模型一次通过率约61%。弱模型单价是强模型的三分之一但算上重试和额外提示词长度最终单条成本只便宜了不到20%而人工审核的负担翻了一倍。人工审核的时间成本才是真正的大头。所以成本优化的正确顺序应该是先降重试率再降单条token最后才考虑换模型。顺序反了越优化越乱。1.3 一个可复用的成本估算表下面这张表是我自己用的估算模板你可以直接套。关键是把有效单条成本算出来而不是看模型标价。成本项计算方式典型占比输入token提示词长度 × 调用次数 × 输入单价20%~30%输出token平均输出长度 × 调用次数 × 输出单价30%~40%重试开销单条成本 × 重试率10%~25%人工兜底审核条数 × 单条审核时长 × 人力时薪15%~35%基础设施队列、存储、日志、监控5%~10%看这张表你会发现人工兜底和重试加起来经常超过一半。这就是为什么纯靠调模型价格做优化天花板很低。2. 批量生成的工程化骨架从单次调用到流水线单次调用大模型生成文案谁都会写。难的是把它变成一条稳定、可观测、可回滚的流水线。这一节讲骨架怎么搭。2.1 任务拆分把生成文案拆成可并行的原子任务不要把一个SKU的所有文案塞进一次调用。原因有三个一是输出太长容易截断或质量下降二是失败时整批重来浪费大三是不同文案类型对提示词的要求不一样混在一起提示词会变得又长又糊。我的做法是按文案类型拆成独立任务标题任务、卖点任务、详情段落任务、口播任务。每个任务有自己的提示词模板、自己的输出格式约束、自己的重试策略。这样一个任务失败只影响它自己其他任务照常跑。拆分之后一个SKU会变成4到6个原子任务这些任务之间没有依赖可以完全并行。并行度上去了整体吞吐自然就上去了。2.2 队列与限流别让并发把你自己打挂批量生成最容易出的事故是脚本一跑几千个请求同时发出去要么被服务端限流封一段时间要么把自己的出口带宽打满要么账单在几分钟内飙升到一个吓人的数字。正确做法是引入一个任务队列控制并发数。并发数怎么定我的经验是从小往大试先设5观察成功率和响应时间稳定后加到10、20。找到那个再往上加成功率就开始掉的临界点然后停在临界点的70%左右留出余量。限流还要分两层一层是总并发限制一层是速率限制比如每分钟最多N个请求。有些服务端对突发流量敏感对持续速率反而宽容所以速率限制比并发限制更重要。import time from concurrent.futures import ThreadPoolExecutor def rate_limited_call(tasks, max_per_minute60, workers8): interval 60.0 / max_per_minute last [0.0] def wrapped(task): now time.time() wait interval - (now - last[0]) if wait 0: time.sleep(wait) last[0] time.time() return call_model(task) with ThreadPoolExecutor(max_workersworkers) as pool: return list(pool.map(wrapped, tasks))这段代码很粗糙但思路是对的用时间间隔控制速率用线程池控制并发。生产环境建议换成成熟的任务队列组件别自己手搓。2.3 幂等与断点续跑批量任务的生命线批量任务跑到一半挂了是常态不是意外。网络抖动、服务端超时、进程被杀都会发生。如果你的任务不能断点续跑每次都要从头再来那成本和时间都受不了。实现断点续跑的核心是幂等每个原子任务有一个唯一ID比如SKU编号加文案类型任务开始前先查这个ID有没有成功记录有就跳过没有才执行。执行成功后立刻落库不要等整批跑完再统一写。这里有个坑落库和调用之间如果进程挂了会出现调用了但没记录的情况重跑时会重复调用。解决办法是调用前先写一条进行中状态调用成功后改成成功。重跑时遇到进行中的根据时间戳判断是超时还是真的在跑超时的就重试。2.4 输出校验把不合格的挡在入库之前模型输出不可控所以每次调用后必须校验。校验分几层格式校验是不是合法JSON、字段全不全、长度校验标题是不是超了平台限制、内容校验有没有违禁词、有没有明显跑题、重复校验和已有文案是不是太像。校验不通过的不要直接丢弃也不要直接入库而是打上标记进入重试队列。重试时可以换一个提示词变体或者换一个模型提高通过率。我一般会给每个任务设最多3次重试3次还不过就进人工队列。人工队列的量要监控如果持续偏高说明提示词或模型选型有问题得回头调。3. 提示词工程在批量场景下的特殊打法单条生成时提示词可以写得很精细、很个性化。批量场景下提示词必须标准化、模板化否则你没法管理几千个变体。3.1 模板变量化把可变部分抽出来提示词模板里固定的是指令、格式要求、风格约束可变的是商品信息。把可变部分做成变量用占位符替换。这样一套模板可以服务所有同类商品维护成本极低。但要注意变量不是越多越好。变量太多模型容易顾此失彼。我的经验是核心变量控制在5到8个超出的信息要么合并要么放到few-shot示例里体现。3.2 few-shot示例的选择比数量更重要很多人以为few-shot示例越多越好其实不是。示例太多会挤占输入token还会让模型倾向于模仿示例的具体内容而不是学习风格。我一般放2到3个示例关键是示例要覆盖不同的商品类型和风格让模型知道风格是统一的内容是变化的。示例的选择还有个技巧优先选那些结构清晰、卖点突出的示例而不是选最长的。模型会模仿示例的结构示例结构乱输出结构就乱。3.3 用结构化输出约束降低重试率让模型自由发挥重试率一定高。用结构化输出比如要求返回JSON指定字段名和类型重试率能降一大截。因为格式错误是最常见的失败原因约束住格式就消灭了一大类重试。如果模型支持JSON模式或函数调用一定要用上。如果不支持就在提示词里明确给出JSON示例并在校验层严格检查。校验失败的重试可以在提示词里加上上次输出格式错误请严格按JSON返回这样的反馈通过率会明显提升。3.4 提示词版本管理别让改动变成玄学提示词一改输出质量就变这是常态。问题是如果你不记录版本出了问题根本不知道是哪次改动导致的。所以提示词必须版本化每次改动记录改了什么、为什么改、改完效果如何。我的做法是把提示词存成文件用版本号命名每次调用记录用了哪个版本。这样出问题时可以快速回滚也可以对比不同版本的效果。这个习惯看起来麻烦但真出事的时候能救命。4. 模型选型与混合架构不是越强越好也不是越便宜越好电商文案这个任务其实对模型的要求是分层的。标题和卖点需要创意和语言能力详情段落需要信息组织能力口播需要口语化能力。不同层可以用不同模型。4.1 分层用模型强模型做创意小模型做填充我的混合架构是这样的标题和核心卖点用强模型因为这两块最影响点击和转化值得花钱详情段落和口播用中等模型因为这两块更依赖信息完整度而不是创意一些格式化的字段比如规格参数描述用本地小模型或者规则模板几乎零成本。这样分层之后整体成本能降40%以上而质量下降感知不明显。因为用户最在意的标题和卖点还是强模型在写。4.2 本地部署小模型的适用边界本地部署小模型比如用常见的开源推理框架跑7B到14B的模型在批量场景下很有吸引力因为边际成本几乎为零。但它有明确的适用边界适合格式固定、创意要求低、对延迟不敏感的任务。不适合的场景也很明确需要强创意、需要复杂推理、需要多语言高质量输出的任务。硬用小模型做这些重试率和人工兜底成本会把省下来的钱全吃回去。本地部署还要考虑硬件成本。一张消费级显卡能跑什么规模的模型、并发能到多少这些都要实测。别看着参数漂亮就上实际吞吐可能只有预期的三分之一。4.3 缓存与去重被低估的成本杀手电商文案有个特点很多商品的卖点是高度相似的。同一类目的商品参数差不多卖点也差不多。这时候缓存就非常有价值。做法是对输入做归一化去掉商品名、去掉具体数值生成一个语义指纹先查缓存。命中缓存就直接复用或微调不调用模型。我实测过在一个SKU高度同质的类目里缓存命中率能到30%以上直接省掉三成调用。去重是另一回事生成完之后检查新文案和已有文案的相似度太像的要么丢弃要么重写。这能避免店铺里出现大量雷同文案对平台体验也好。5. 实测中的坑那些文档不会告诉你的问题这一节是我踩过的坑按严重程度排。5.1 长尾商品拉低整体通过率头部商品的文案好生成因为信息全、卖点清晰。长尾商品信息残缺模型容易瞎编。我遇到过模型给一个信息不全的商品编出了不存在的材质和产地如果直接入库就是事故。解决办法是在提示词里明确信息不足时不要编造用占位符标注并在校验层检查有没有占位符。有占位符的进人工队列补信息而不是让模型硬编。5.2 并发上去了成功率反而掉了前面提过并发不是越高越好。我实测过一个服务并发从10加到30成功率从97%掉到82%响应时间翻了三倍。原因是服务端有隐性限流超过阈值就降级。所以并发要压测找到拐点。而且不同时段服务端的负载不一样白天高峰期和凌晨的拐点可能不同。生产环境最好做动态调整根据实时成功率反馈来调并发。5.3 成本监控滞后发现时已经超支很多人是月底看账单才发现超支。这时候已经晚了。正确做法是做实时成本监控每调用一次就累加成本设一个日预算阈值超过就告警甚至自动暂停。成本监控还要能按维度拆按任务类型、按模型、按类目。这样才能定位到是哪个环节在烧钱。我见过一个团队成本异常高拆开一看是某个类目的重试率特别高定位到问题后针对性优化成本立刻降下来。5.4 输出质量波动但没人发现模型输出质量是会波动的可能因为服务端模型更新、可能因为提示词微调、可能因为输入分布变化。如果不做质量监控质量下滑了你都不知道。质量监控可以自动化一部分比如统计重试率、人工修改率、违禁词命中率。这些指标异常就说明质量在变。更精细的可以用一个小模型做质量打分但成本要算进去。6. 一套可落地的批量生成流水线配置把前面的东西串起来给一套我实际用过的配置。6.1 整体架构任务拆分 → 队列 → 限流调度 → 模型调用分层→ 输出校验 → 重试/人工队列 → 入库 → 成本与质量监控。每一环都要有日志每一环都要能单独重跑。6.2 关键参数建议参数建议值说明单任务最大重试3次超过进人工并发数压测拐点的70%动态调整速率限制按服务端文档的80%留余量缓存命中阈值相似度0.9以上按类目调日预算告警预算的80%触发告警质量抽检比例5%~10%人工抽检6.3 监控指标清单必须监控的指标调用成功率、重试率、平均响应时间、单条有效成本、缓存命中率、人工介入率、违禁词命中率。这些指标要能按类目、按模型、按任务类型拆开看。6.4 上线前的压测清单上线前一定要压测小批量跑通全流程、中等批量测吞吐和成功率、大批量测断点续跑和成本。压测用的数据要覆盖头部和长尾商品别只用头部数据测那样测出来的指标是虚高的。7. 成本优化的几个反直觉结论最后分享几个我踩坑后总结的反直觉结论可能和你的直觉不一样。第一个重试率降1个点比模型单价降10%更值钱。因为重试不只是多花一次调用钱还多占一次并发、多一次校验、多一次可能的失败。综合成本远高于单价本身。第二个缓存的价值不在省调用在于稳定。命中缓存的输出是确定的不会波动这对批量生产的质量稳定性帮助很大。第三个人工兜底不是成本是质量保险。完全去掉人工兜底短期省钱长期一定出事故。合理的做法是把人工集中在最关键的环节比如标题和核心卖点其他环节自动化。第四个本地小模型不一定省钱。如果它导致重试率和人工率上升综合成本可能比用在线中等模型还高。要用数据说话别用直觉。第五个成本优化是持续过程不是一次性项目。模型在更新、商品在变化、平台规则在调整上个月的最优配置这个月可能就不是了。所以监控和调优要常态化。这套东西我用了大半年从最初单条成本高、重试率高、人工累到不行到现在流水线基本能自动跑人工只处理少量长尾。核心不是某个技巧而是把成本、质量、吞吐三个指标都纳入监控然后持续调。电商文案批量生成这件事技术门槛不高但工程化门槛不低愿意在细节上花时间的人最后省下来的都是真金白银。