1. 电商文案批量生成的项目背景与核心痛点做电商这行的朋友应该都有体会一个店铺动辄几百上千个SKU每个商品的主图、详情页、短视频脚本、站内信、推送文案加起来就是几千条文案需求。以前靠运营团队手写一个熟练文案一天能产出30到50条质量过关的商品描述遇到大促节点文案需求翻三倍人力根本顶不住。我去年接手一个服饰类目的项目光是夏季上新就有800多个SPU每个SPU要配5条不同风格的卖点文案算下来4000条团队三个人写了两周还没写完最后上线时间硬生生拖了三天。这就是电商文案批量生成这个需求真正被逼出来的场景。它不是我想用大模型玩点新花样而是我有一堆文案要写人不够、时间不够、预算也不够。大模型在这里扮演的角色很明确一个能理解商品属性、能模仿指定语气、能批量输出结构化文本的生产力工具。但问题在于直接把商品标题扔给大模型让它写出来的东西往往不能用——要么太泛要么不符合平台调性要么批量跑起来成本高得离谱。所以这个项目的核心命题其实是两个第一怎么让大模型写出来的文案真正可用第二怎么把这件事的工程化成本压到可接受的范围内。前者是效果问题后者是成本问题两者缺一不可。我见过不少团队效果调得不错但一算账发现每条文案的成本比人工还贵项目直接黄了。也见过成本压得很低但文案质量惨不忍睹运营还得逐条改等于白做。这篇文章我会把这两个问题拆开讲透。从整体架构设计、提示词工程、批量生成的工程化实现到成本拆解的每一个细节包括token计算、模型选型、缓存策略、并发控制再到实际跑下来踩过的坑和排查技巧。适合正在做或者准备做电商文案批量生成的开发者和运营负责人参考不管你是刚接触大模型应用还是已经在跑批量任务但成本压不下来应该都能找到能直接抄作业的东西。2. 整体方案设计与技术选型思路2.1 为什么不做微调而是走提示词工程路线一提到大模型做垂直领域任务很多人第一反应是微调。但我实际跑下来电商文案批量生成这个场景微调的性价比并不高。原因有三个。第一电商文案的风格变化太快。今天流行绝绝子明天流行松弛感下个月可能又是另一种话术。微调一次模型训练数据标注加训练时间加验证少说一周等模型上线流行语已经过时了。提示词工程改几个词就能切换风格迭代速度完全不是一个量级。第二微调需要大量高质量标注数据。你要微调一个能写好电商文案的模型至少需要几千条商品属性到优质文案的配对数据。这些数据谁来标运营标出来的东西带有强烈个人风格标注一致性很难保证。而且不同类目的文案差异极大服饰和美妆的写法完全不同一个模型很难通吃。第三成本结构不同。微调是一次性投入大推理成本低提示词工程是推理成本略高但没有训练成本。对于中小团队来说前期拿不出那么多标注预算提示词工程是更务实的起点。等业务量稳定了、数据积累够了再考虑用积累的高质量数据做微调这才是合理的路径。我最终选的方案是基座模型 结构化提示词模板 少样本示例 后处理校验。这个组合在效果和成本之间取得了比较好的平衡。2.2 模型选型的三个维度效果、成本、可控性模型选型不能只看哪个模型写得好要同时考虑三个维度。效果维度上我实测下来7B到14B参数量的模型在电商文案这个任务上已经够用了。再大的模型边际收益递减明显但成本是线性甚至超线性增长的。我拿同一个商品分别让几个不同量级的模型写7B模型写出来的东西在信息准确度上和70B差距不大主要差距在语言流畅度和创意性上但这两点通过提示词优化可以补回来不少。成本维度上核心指标是每百万token的价格。这里有个容易被忽略的点输出token的成本通常是输入token的2到4倍。电商文案生成是典型的输入短、输出长任务输入可能就50个token的商品信息输出要200到300个token的文案。所以算成本的时候不能只看输入价格要把输出的权重放大。可控性维度上我倾向于选择支持结构化输出JSON mode的模型。批量生成最怕的就是模型输出格式不稳定一会儿多一段解释一会儿少一个字段后处理解析起来极其痛苦。支持JSON mode的模型可以直接约束输出格式省掉大量正则清洗的工作。综合下来我的选型策略是主力用中等量级模型跑批量任务少量高价值商品用大模型兜底。比如日常批量生成用7B模型客单价高、转化要求高的爆款商品用14B或更大模型单独跑。这样整体成本可控关键位置的效果也有保障。2.3 批量生成的架构分层整个系统我分成了四层每层职责清晰方便单独优化和替换。数据层负责商品信息的读取和清洗。商品数据通常来自ERP或商品中台字段格式五花八门有的标题里带一堆促销词有的属性字段是空的。这一层要做的是把原始数据标准化成模型能理解的输入格式。提示词层负责模板管理和动态组装。不同类目、不同文案类型标题、卖点、详情、推送对应不同的模板。模板里预留变量槽位运行时把商品数据填进去。推理层负责调用模型API或本地推理服务处理并发、重试、限流。这一层是成本控制的主战场。后处理层负责校验输出、去重、敏感词过滤、格式规范化。模型输出不能直接入库必须过一遍校验。这四层之间通过消息队列解耦数据层往队列里扔任务推理层消费任务后处理层再消费推理结果。这样做的好处是任何一层出问题都不会阻塞其他层而且可以独立扩容。3. 提示词工程的核心细节与实操要点3.1 结构化提示词的四个必备模块我试过很多种提示词写法最后稳定下来的模板包含四个模块角色设定、任务描述、输出格式约束、少样本示例。缺一个效果都会打折扣。角色设定不是随便写一句你是一个电商文案专家就完事了。要具体到类目和风格。比如你是一个专注女装类目的电商文案写手擅长用小红书风格的短句突出面料质感和穿搭场景。角色越具体模型输出的风格越稳定。任务描述要明确输入是什么、输出是什么、有什么约束。比如根据以下商品信息生成3条商品卖点文案每条不超过30字必须包含至少一个具体卖点面料、版型、场景不能出现绝对化用语。输出格式约束我强烈建议用JSON。比如要求输出{selling_points: [..., ..., ...]}这样的结构。这样后处理直接解析JSON就行不用写一堆正则。少样本示例是提升效果最明显的手段。给2到3个高质量的输入输出示例模型就能模仿出差不多的风格。示例的选择很关键要覆盖不同的商品类型和文案风格让模型知道边界在哪里。3.2 少样本示例的选择与排列技巧少样本示例不是随便找几条文案放进去就行。我踩过的坑是示例质量参差不齐模型学到的风格就不稳定示例太单一遇到没见过的商品类型就翻车。我的做法是每个类目准备3组示例分别对应基础款功能款场景款三种商品类型。比如女装类目基础款示例是一条简约T恤的文案功能款示例是一条防晒衣的文案场景款示例是一条连衣裙的文案。这样模型见过的输入模式更丰富泛化能力更强。示例的排列顺序也有讲究。我把效果最好的示例放在最后因为模型对靠近输出位置的示例关注度更高。另外示例之间用明确的分隔符隔开避免模型把多个示例混在一起。还有一个细节示例里的商品信息要和实际输入的商品信息字段对齐。如果示例里商品信息有面料字段实际输入里没有模型可能会编造面料信息。所以示例的字段结构要和实际数据保持一致。3.3 提示词模板的版本管理与A/B测试提示词是要迭代的没有一版就完美的模板。我建议从一开始就做版本管理每次修改都记录改了什么、为什么改、效果变化如何。我的做法是用一个简单的YAML文件管理模板每个模板有版本号、适用类目、适用文案类型、创建时间、效果指标。运行时根据商品类目和文案类型选择对应模板。A/B测试方面我会把同一批商品分别用两个版本的模板跑然后让运营盲评打分。打分维度包括信息准确度、语言流畅度、转化引导力三个维度每个维度1到5分。跑够100个样本后看平均分差异超过0.5分才认为有显著差异。这里有个经验提示词的改动要小步快跑一次只改一个变量。同时改角色设定和输出格式你根本不知道是哪个改动起了作用。我一般一次只调一个模块观察效果后再决定下一步。3.4 输出格式约束与JSON mode实战JSON mode是批量生成的救命稻草。没有它的时候模型输出经常是好的以下是三条卖点1. ... 2. ... 3. ...你还得写正则去提取。有了JSON mode直接约束输出结构解析成功率从70%提到99%以上。但JSON mode也有坑。有些模型虽然支持JSON mode但在字段值里还是会塞一些多余的解释。比如要求输出{selling_points: [...]}它给你输出{selling_points: [这条裙子很好看注突出了版型优势]}。括号里的内容就是多余的。我的处理方式是在提示词里明确写字段值中不要包含任何解释性文字只输出文案本身。同时在少样本示例里展示正确的输出格式让模型有样学样。另外JSON mode下模型偶尔会输出不合法的JSON比如少个引号、多个逗号。后处理层必须做JSON解析的异常捕获解析失败的走重试逻辑。我实测下来加了JSON mode之后解析失败率在1%以下重试一次基本都能成功。4. 批量生成的工程化实现与成本拆解4.1 批量任务的数据流与并发控制批量生成的核心是把几千条商品数据高效地喂给模型同时控制好并发既不把API限流打爆也不让机器闲着。我的数据流是这样的数据层从数据库读取待生成商品列表按类目和优先级排序分批写入Redis队列。推理层启动多个worker消费队列每个worker从队列取一条任务组装提示词调用模型拿到结果后写入结果队列。后处理层消费结果队列做校验和清洗最后写回数据库。并发控制的关键是动态调整并发数。固定并发数要么浪费资源要么触发限流。我的做法是监控API的响应时间和错误率如果响应时间变长或出现429错误就自动降低并发如果响应稳定且错误率低就逐步提高并发。这样能在不触发限流的前提下最大化吞吐。具体参数上我初始并发设为5每成功处理100条且平均响应时间低于2秒并发加1上限20。一旦出现429错误并发直接减半并暂停30秒再恢复。这套策略跑下来整体吞吐比固定并发高了40%左右。4.2 Token成本的精算模型成本拆解必须精确到每条文案。我建了一个成本计算模型输入是商品信息长度和输出文案长度输出是单条成本。先算token数。中文场景下1个token大约对应1.5到2个汉字。商品信息平均80个汉字约50个token。输出3条卖点每条30字共90字约60个token。加上提示词模板本身的token角色设定、任务描述、示例大约300个token。所以单次请求的输入token约350输出token约60。然后看价格。假设模型输入价格是每百万token 1元输出价格是每百万token 3元。单次请求成本 350/1000000 * 1 60/1000000 * 3 0.00035 0.00018 0.00053元。也就是大约0.5厘钱一条。但这是理想情况。实际跑下来重试、失败、示例token的重复计算都会推高成本。我实测的有效成本大约是理论值的1.5到2倍。所以单条文案的实际成本在0.001元左右。如果一天生成1万条成本约10元。一个月30万条成本约300元。这个成本相比人工写作一条文案按5元算30万条就是150万几乎可以忽略不计。4.3 缓存策略与去重机制批量生成里有个巨大的浪费很多商品信息高度相似比如同一款衣服的不同颜色商品描述几乎一样只是颜色字段不同。如果每个都单独调模型就是重复花钱。我的做法是在推理层前面加一层缓存。缓存key是商品信息的哈希值去掉颜色、尺码等可变字段后的哈希。如果缓存命中直接返回缓存结果只把可变字段替换进去。这样同款不同色的商品只需要调一次模型。缓存命中率我实测在30%到50%之间取决于商品库的重复度。服饰类目因为同款多色命中率能到50%以上。3C类目因为每个SKU差异大命中率只有20%左右。但不管多少省下来的都是纯利润。去重机制是另一层保险。后处理层会对生成的文案做相似度检测如果两条文案的相似度超过90%就把后一条标记为待人工确认避免批量生成出一堆雷同文案。4.4 失败重试与降级方案批量任务最怕的是跑到一半挂了前面跑的全白费。所以失败重试和降级方案必须提前设计好。我的重试策略是单条任务失败后重试2次每次间隔指数退避1秒、2秒、4秒。如果3次都失败把任务写入死信队列不阻塞后续任务。死信队列里的任务可以人工排查后重新投递。降级方案分两级。第一级是模型降级如果主力模型连续失败自动切换到备用模型通常是更小或更便宜的模型保证任务能跑完质量稍差可以接受。第二级是任务降级如果整体失败率超过20%暂停批量任务转为人工处理同时报警通知。我踩过的坑是有一次API大面积故障重试逻辑疯狂重试把配额全耗光了导致后面恢复后也没配额可用。后来加了全局失败率监控失败率超过阈值直接熔断不再重试等故障恢复后再手动重启任务。5. 常见问题与排查技巧实录5.1 模型输出不稳定怎么排查输出不稳定是最高频的问题。表现是同一批商品有的文案很好有的完全不能用。排查思路是分层定位。先看是不是提示词的问题。把出问题的商品信息单独拿出来手动调一次模型看输出是否稳定。如果手动调也不稳定说明提示词对这个类型的商品覆盖不够需要补充示例。再看是不是数据的问题。检查出问题的商品信息是否有缺失字段、格式异常、特殊字符。我遇到过商品标题里带emoji导致模型输出乱码的情况清洗掉就好了。最后看是不是模型本身的问题。有些模型在特定输入下会抽风输出完全无关的内容。这种情况只能通过重试或换模型解决。5.2 批量任务中途失败的恢复方法批量任务跑到一半失败最怕的是不知道跑到哪了。我的做法是每条任务处理完就更新数据库状态记录已处理标记。任务重启时只捞未处理和处理失败的记录已处理的跳过。另外结果写入用幂等设计。同一条商品重复生成时用商品ID作为唯一键新结果覆盖旧结果不会产生重复数据。如果失败原因是API故障等故障恢复后直接重启任务即可。如果是数据问题导致某几条一直失败把这几条单独拎出来人工处理不要让它阻塞整个批次。5.3 成本突然飙升的排查清单成本飙升通常有几个原因我整理了一个排查清单。排查项可能原因解决方法输入token变长提示词模板被改长或商品信息字段增多检查模板版本精简不必要的字段输出token变长模型输出变啰嗦或输出条数增加检查输出格式约束限制条数和字数重试率上升API不稳定或提示词导致解析失败查看错误日志定位失败原因缓存命中率下降商品库重复度降低或缓存key设计不合理检查缓存key是否包含可变字段并发数过高动态并发策略失效触发限流后重试检查并发控制逻辑降低上限我遇到过一次成本翻倍排查下来是提示词模板里不小心多放了一个示例输入token直接多了200。所以模板改动后一定要重新算一遍token成本。5.4 文案质量人工抽检机制批量生成不能完全放手不管必须有人工抽检。我的做法是每天随机抽取5%的生成结果让运营按三个维度打分信息准确度有没有编造商品信息、语言流畅度读起来顺不顺、转化引导力有没有购买冲动。抽检结果低于阈值时触发提示词优化流程。连续三天低于阈值暂停批量任务全面排查。抽检还有个作用是发现系统性问题。比如某天抽检发现大量文案都用了同一个句式说明模型陷入了模式化输出需要调整提示词里的示例多样性。6. 实操心得与后续优化方向6.1 我踩过的三个大坑第一个坑是过度依赖大模型。一开始我什么文案都让大模型写包括一些简单的字段拼接比如颜色红色这种。后来发现这些简单任务用规则引擎就够了根本不需要调模型。把简单任务剥离出去后模型调用量降了30%成本直接下来一大截。第二个坑是忽略输出长度控制。早期没有限制输出字数模型有时候写嗨了一条卖点写100多字token成本翻倍不说运营还得手动删。后来在提示词里硬性限制每条不超过30字输出token立刻稳定了。第三个坑是没有做灰度发布。有一次改提示词模板直接全量上线结果新模板对某个类目效果极差当天生成的几千条文案全部返工。后来改成先跑100条灰度人工确认没问题再全量。6.2 成本还能怎么压除了前面说的缓存和任务剥离还有几个压成本的方向。批量请求合并。如果API支持一次请求处理多条商品可以把10条商品信息打包成一个请求共享提示词模板的token。这样输入token的复用率提高整体成本能降20%左右。但要注意单次请求的token上限别超了。错峰调用。有些API在低峰期有折扣或者本地推理在夜间电价低的时候跑更划算。把非紧急的批量任务放到低峰期跑能省不少。模型蒸馏。如果积累了大量高质量的输入输出对可以用这些数据蒸馏一个小模型专门跑这个任务。蒸馏后的模型推理成本可能只有原模型的十分之一效果能保留80%以上。这是长期优化的方向。6.3 从批量生成到智能推荐的延伸文案批量生成跑通之后积累的数据其实很有价值。每条文案的转化率、点击率、停留时长都是宝贵的反馈信号。用这些数据可以反过来优化提示词甚至训练一个文案质量评分模型自动筛选出高潜力文案。再往前一步可以把文案生成和商品推荐结合起来。根据用户的浏览历史动态生成个性化的文案。比如同一个商品对价格敏感的用户突出折扣信息对品质敏感的用户突出面料工艺。这就从批量生成升级到了个性化生成价值更大当然工程复杂度也更高。我现在正在跑的一个实验是用历史转化数据微调一个文案评分模型批量生成后先过评分模型只保留高分文案进入人工抽检环节。这样人工抽检的工作量能减少70%整体效率又上了一个台阶。这个方向后续我会单独写一篇拆解感兴趣的朋友可以关注。 
长河君 · 2026/10/2 14:36:33 · 阅读 1.2k 电商文案批量生成实战：提示词工程与成本优化全解析
1. 电商文案批量生成的项目背景与核心痛点做电商这行的朋友应该都有体会一个店铺动辄几百上千个SKU每个商品的主图、详情页、短视频脚本、站内信、推送文案加起来就是几千条文案需求。以前靠运营团队手写一个熟练文案一天能产出30到50条质量过关的商品描述遇到大促节点文案需求翻三倍人力根本顶不住。我去年接手一个服饰类目的项目光是夏季上新就有800多个SPU每个SPU要配5条不同风格的卖点文案算下来4000条团队三个人写了两周还没写完最后上线时间硬生生拖了三天。这就是电商文案批量生成这个需求真正被逼出来的场景。它不是我想用大模型玩点新花样而是我有一堆文案要写人不够、时间不够、预算也不够。大模型在这里扮演的角色很明确一个能理解商品属性、能模仿指定语气、能批量输出结构化文本的生产力工具。但问题在于直接把商品标题扔给大模型让它写出来的东西往往不能用——要么太泛要么不符合平台调性要么批量跑起来成本高得离谱。所以这个项目的核心命题其实是两个第一怎么让大模型写出来的文案真正可用第二怎么把这件事的工程化成本压到可接受的范围内。前者是效果问题后者是成本问题两者缺一不可。我见过不少团队效果调得不错但一算账发现每条文案的成本比人工还贵项目直接黄了。也见过成本压得很低但文案质量惨不忍睹运营还得逐条改等于白做。这篇文章我会把这两个问题拆开讲透。从整体架构设计、提示词工程、批量生成的工程化实现到成本拆解的每一个细节包括token计算、模型选型、缓存策略、并发控制再到实际跑下来踩过的坑和排查技巧。适合正在做或者准备做电商文案批量生成的开发者和运营负责人参考不管你是刚接触大模型应用还是已经在跑批量任务但成本压不下来应该都能找到能直接抄作业的东西。2. 整体方案设计与技术选型思路2.1 为什么不做微调而是走提示词工程路线一提到大模型做垂直领域任务很多人第一反应是微调。但我实际跑下来电商文案批量生成这个场景微调的性价比并不高。原因有三个。第一电商文案的风格变化太快。今天流行绝绝子明天流行松弛感下个月可能又是另一种话术。微调一次模型训练数据标注加训练时间加验证少说一周等模型上线流行语已经过时了。提示词工程改几个词就能切换风格迭代速度完全不是一个量级。第二微调需要大量高质量标注数据。你要微调一个能写好电商文案的模型至少需要几千条商品属性到优质文案的配对数据。这些数据谁来标运营标出来的东西带有强烈个人风格标注一致性很难保证。而且不同类目的文案差异极大服饰和美妆的写法完全不同一个模型很难通吃。第三成本结构不同。微调是一次性投入大推理成本低提示词工程是推理成本略高但没有训练成本。对于中小团队来说前期拿不出那么多标注预算提示词工程是更务实的起点。等业务量稳定了、数据积累够了再考虑用积累的高质量数据做微调这才是合理的路径。我最终选的方案是基座模型 结构化提示词模板 少样本示例 后处理校验。这个组合在效果和成本之间取得了比较好的平衡。2.2 模型选型的三个维度效果、成本、可控性模型选型不能只看哪个模型写得好要同时考虑三个维度。效果维度上我实测下来7B到14B参数量的模型在电商文案这个任务上已经够用了。再大的模型边际收益递减明显但成本是线性甚至超线性增长的。我拿同一个商品分别让几个不同量级的模型写7B模型写出来的东西在信息准确度上和70B差距不大主要差距在语言流畅度和创意性上但这两点通过提示词优化可以补回来不少。成本维度上核心指标是每百万token的价格。这里有个容易被忽略的点输出token的成本通常是输入token的2到4倍。电商文案生成是典型的输入短、输出长任务输入可能就50个token的商品信息输出要200到300个token的文案。所以算成本的时候不能只看输入价格要把输出的权重放大。可控性维度上我倾向于选择支持结构化输出JSON mode的模型。批量生成最怕的就是模型输出格式不稳定一会儿多一段解释一会儿少一个字段后处理解析起来极其痛苦。支持JSON mode的模型可以直接约束输出格式省掉大量正则清洗的工作。综合下来我的选型策略是主力用中等量级模型跑批量任务少量高价值商品用大模型兜底。比如日常批量生成用7B模型客单价高、转化要求高的爆款商品用14B或更大模型单独跑。这样整体成本可控关键位置的效果也有保障。2.3 批量生成的架构分层整个系统我分成了四层每层职责清晰方便单独优化和替换。数据层负责商品信息的读取和清洗。商品数据通常来自ERP或商品中台字段格式五花八门有的标题里带一堆促销词有的属性字段是空的。这一层要做的是把原始数据标准化成模型能理解的输入格式。提示词层负责模板管理和动态组装。不同类目、不同文案类型标题、卖点、详情、推送对应不同的模板。模板里预留变量槽位运行时把商品数据填进去。推理层负责调用模型API或本地推理服务处理并发、重试、限流。这一层是成本控制的主战场。后处理层负责校验输出、去重、敏感词过滤、格式规范化。模型输出不能直接入库必须过一遍校验。这四层之间通过消息队列解耦数据层往队列里扔任务推理层消费任务后处理层再消费推理结果。这样做的好处是任何一层出问题都不会阻塞其他层而且可以独立扩容。3. 提示词工程的核心细节与实操要点3.1 结构化提示词的四个必备模块我试过很多种提示词写法最后稳定下来的模板包含四个模块角色设定、任务描述、输出格式约束、少样本示例。缺一个效果都会打折扣。角色设定不是随便写一句你是一个电商文案专家就完事了。要具体到类目和风格。比如你是一个专注女装类目的电商文案写手擅长用小红书风格的短句突出面料质感和穿搭场景。角色越具体模型输出的风格越稳定。任务描述要明确输入是什么、输出是什么、有什么约束。比如根据以下商品信息生成3条商品卖点文案每条不超过30字必须包含至少一个具体卖点面料、版型、场景不能出现绝对化用语。输出格式约束我强烈建议用JSON。比如要求输出{selling_points: [..., ..., ...]}这样的结构。这样后处理直接解析JSON就行不用写一堆正则。少样本示例是提升效果最明显的手段。给2到3个高质量的输入输出示例模型就能模仿出差不多的风格。示例的选择很关键要覆盖不同的商品类型和文案风格让模型知道边界在哪里。3.2 少样本示例的选择与排列技巧少样本示例不是随便找几条文案放进去就行。我踩过的坑是示例质量参差不齐模型学到的风格就不稳定示例太单一遇到没见过的商品类型就翻车。我的做法是每个类目准备3组示例分别对应基础款功能款场景款三种商品类型。比如女装类目基础款示例是一条简约T恤的文案功能款示例是一条防晒衣的文案场景款示例是一条连衣裙的文案。这样模型见过的输入模式更丰富泛化能力更强。示例的排列顺序也有讲究。我把效果最好的示例放在最后因为模型对靠近输出位置的示例关注度更高。另外示例之间用明确的分隔符隔开避免模型把多个示例混在一起。还有一个细节示例里的商品信息要和实际输入的商品信息字段对齐。如果示例里商品信息有面料字段实际输入里没有模型可能会编造面料信息。所以示例的字段结构要和实际数据保持一致。3.3 提示词模板的版本管理与A/B测试提示词是要迭代的没有一版就完美的模板。我建议从一开始就做版本管理每次修改都记录改了什么、为什么改、效果变化如何。我的做法是用一个简单的YAML文件管理模板每个模板有版本号、适用类目、适用文案类型、创建时间、效果指标。运行时根据商品类目和文案类型选择对应模板。A/B测试方面我会把同一批商品分别用两个版本的模板跑然后让运营盲评打分。打分维度包括信息准确度、语言流畅度、转化引导力三个维度每个维度1到5分。跑够100个样本后看平均分差异超过0.5分才认为有显著差异。这里有个经验提示词的改动要小步快跑一次只改一个变量。同时改角色设定和输出格式你根本不知道是哪个改动起了作用。我一般一次只调一个模块观察效果后再决定下一步。3.4 输出格式约束与JSON mode实战JSON mode是批量生成的救命稻草。没有它的时候模型输出经常是好的以下是三条卖点1. ... 2. ... 3. ...你还得写正则去提取。有了JSON mode直接约束输出结构解析成功率从70%提到99%以上。但JSON mode也有坑。有些模型虽然支持JSON mode但在字段值里还是会塞一些多余的解释。比如要求输出{selling_points: [...]}它给你输出{selling_points: [这条裙子很好看注突出了版型优势]}。括号里的内容就是多余的。我的处理方式是在提示词里明确写字段值中不要包含任何解释性文字只输出文案本身。同时在少样本示例里展示正确的输出格式让模型有样学样。另外JSON mode下模型偶尔会输出不合法的JSON比如少个引号、多个逗号。后处理层必须做JSON解析的异常捕获解析失败的走重试逻辑。我实测下来加了JSON mode之后解析失败率在1%以下重试一次基本都能成功。4. 批量生成的工程化实现与成本拆解4.1 批量任务的数据流与并发控制批量生成的核心是把几千条商品数据高效地喂给模型同时控制好并发既不把API限流打爆也不让机器闲着。我的数据流是这样的数据层从数据库读取待生成商品列表按类目和优先级排序分批写入Redis队列。推理层启动多个worker消费队列每个worker从队列取一条任务组装提示词调用模型拿到结果后写入结果队列。后处理层消费结果队列做校验和清洗最后写回数据库。并发控制的关键是动态调整并发数。固定并发数要么浪费资源要么触发限流。我的做法是监控API的响应时间和错误率如果响应时间变长或出现429错误就自动降低并发如果响应稳定且错误率低就逐步提高并发。这样能在不触发限流的前提下最大化吞吐。具体参数上我初始并发设为5每成功处理100条且平均响应时间低于2秒并发加1上限20。一旦出现429错误并发直接减半并暂停30秒再恢复。这套策略跑下来整体吞吐比固定并发高了40%左右。4.2 Token成本的精算模型成本拆解必须精确到每条文案。我建了一个成本计算模型输入是商品信息长度和输出文案长度输出是单条成本。先算token数。中文场景下1个token大约对应1.5到2个汉字。商品信息平均80个汉字约50个token。输出3条卖点每条30字共90字约60个token。加上提示词模板本身的token角色设定、任务描述、示例大约300个token。所以单次请求的输入token约350输出token约60。然后看价格。假设模型输入价格是每百万token 1元输出价格是每百万token 3元。单次请求成本 350/1000000 * 1 60/1000000 * 3 0.00035 0.00018 0.00053元。也就是大约0.5厘钱一条。但这是理想情况。实际跑下来重试、失败、示例token的重复计算都会推高成本。我实测的有效成本大约是理论值的1.5到2倍。所以单条文案的实际成本在0.001元左右。如果一天生成1万条成本约10元。一个月30万条成本约300元。这个成本相比人工写作一条文案按5元算30万条就是150万几乎可以忽略不计。4.3 缓存策略与去重机制批量生成里有个巨大的浪费很多商品信息高度相似比如同一款衣服的不同颜色商品描述几乎一样只是颜色字段不同。如果每个都单独调模型就是重复花钱。我的做法是在推理层前面加一层缓存。缓存key是商品信息的哈希值去掉颜色、尺码等可变字段后的哈希。如果缓存命中直接返回缓存结果只把可变字段替换进去。这样同款不同色的商品只需要调一次模型。缓存命中率我实测在30%到50%之间取决于商品库的重复度。服饰类目因为同款多色命中率能到50%以上。3C类目因为每个SKU差异大命中率只有20%左右。但不管多少省下来的都是纯利润。去重机制是另一层保险。后处理层会对生成的文案做相似度检测如果两条文案的相似度超过90%就把后一条标记为待人工确认避免批量生成出一堆雷同文案。4.4 失败重试与降级方案批量任务最怕的是跑到一半挂了前面跑的全白费。所以失败重试和降级方案必须提前设计好。我的重试策略是单条任务失败后重试2次每次间隔指数退避1秒、2秒、4秒。如果3次都失败把任务写入死信队列不阻塞后续任务。死信队列里的任务可以人工排查后重新投递。降级方案分两级。第一级是模型降级如果主力模型连续失败自动切换到备用模型通常是更小或更便宜的模型保证任务能跑完质量稍差可以接受。第二级是任务降级如果整体失败率超过20%暂停批量任务转为人工处理同时报警通知。我踩过的坑是有一次API大面积故障重试逻辑疯狂重试把配额全耗光了导致后面恢复后也没配额可用。后来加了全局失败率监控失败率超过阈值直接熔断不再重试等故障恢复后再手动重启任务。5. 常见问题与排查技巧实录5.1 模型输出不稳定怎么排查输出不稳定是最高频的问题。表现是同一批商品有的文案很好有的完全不能用。排查思路是分层定位。先看是不是提示词的问题。把出问题的商品信息单独拿出来手动调一次模型看输出是否稳定。如果手动调也不稳定说明提示词对这个类型的商品覆盖不够需要补充示例。再看是不是数据的问题。检查出问题的商品信息是否有缺失字段、格式异常、特殊字符。我遇到过商品标题里带emoji导致模型输出乱码的情况清洗掉就好了。最后看是不是模型本身的问题。有些模型在特定输入下会抽风输出完全无关的内容。这种情况只能通过重试或换模型解决。5.2 批量任务中途失败的恢复方法批量任务跑到一半失败最怕的是不知道跑到哪了。我的做法是每条任务处理完就更新数据库状态记录已处理标记。任务重启时只捞未处理和处理失败的记录已处理的跳过。另外结果写入用幂等设计。同一条商品重复生成时用商品ID作为唯一键新结果覆盖旧结果不会产生重复数据。如果失败原因是API故障等故障恢复后直接重启任务即可。如果是数据问题导致某几条一直失败把这几条单独拎出来人工处理不要让它阻塞整个批次。5.3 成本突然飙升的排查清单成本飙升通常有几个原因我整理了一个排查清单。排查项可能原因解决方法输入token变长提示词模板被改长或商品信息字段增多检查模板版本精简不必要的字段输出token变长模型输出变啰嗦或输出条数增加检查输出格式约束限制条数和字数重试率上升API不稳定或提示词导致解析失败查看错误日志定位失败原因缓存命中率下降商品库重复度降低或缓存key设计不合理检查缓存key是否包含可变字段并发数过高动态并发策略失效触发限流后重试检查并发控制逻辑降低上限我遇到过一次成本翻倍排查下来是提示词模板里不小心多放了一个示例输入token直接多了200。所以模板改动后一定要重新算一遍token成本。5.4 文案质量人工抽检机制批量生成不能完全放手不管必须有人工抽检。我的做法是每天随机抽取5%的生成结果让运营按三个维度打分信息准确度有没有编造商品信息、语言流畅度读起来顺不顺、转化引导力有没有购买冲动。抽检结果低于阈值时触发提示词优化流程。连续三天低于阈值暂停批量任务全面排查。抽检还有个作用是发现系统性问题。比如某天抽检发现大量文案都用了同一个句式说明模型陷入了模式化输出需要调整提示词里的示例多样性。6. 实操心得与后续优化方向6.1 我踩过的三个大坑第一个坑是过度依赖大模型。一开始我什么文案都让大模型写包括一些简单的字段拼接比如颜色红色这种。后来发现这些简单任务用规则引擎就够了根本不需要调模型。把简单任务剥离出去后模型调用量降了30%成本直接下来一大截。第二个坑是忽略输出长度控制。早期没有限制输出字数模型有时候写嗨了一条卖点写100多字token成本翻倍不说运营还得手动删。后来在提示词里硬性限制每条不超过30字输出token立刻稳定了。第三个坑是没有做灰度发布。有一次改提示词模板直接全量上线结果新模板对某个类目效果极差当天生成的几千条文案全部返工。后来改成先跑100条灰度人工确认没问题再全量。6.2 成本还能怎么压除了前面说的缓存和任务剥离还有几个压成本的方向。批量请求合并。如果API支持一次请求处理多条商品可以把10条商品信息打包成一个请求共享提示词模板的token。这样输入token的复用率提高整体成本能降20%左右。但要注意单次请求的token上限别超了。错峰调用。有些API在低峰期有折扣或者本地推理在夜间电价低的时候跑更划算。把非紧急的批量任务放到低峰期跑能省不少。模型蒸馏。如果积累了大量高质量的输入输出对可以用这些数据蒸馏一个小模型专门跑这个任务。蒸馏后的模型推理成本可能只有原模型的十分之一效果能保留80%以上。这是长期优化的方向。6.3 从批量生成到智能推荐的延伸文案批量生成跑通之后积累的数据其实很有价值。每条文案的转化率、点击率、停留时长都是宝贵的反馈信号。用这些数据可以反过来优化提示词甚至训练一个文案质量评分模型自动筛选出高潜力文案。再往前一步可以把文案生成和商品推荐结合起来。根据用户的浏览历史动态生成个性化的文案。比如同一个商品对价格敏感的用户突出折扣信息对品质敏感的用户突出面料工艺。这就从批量生成升级到了个性化生成价值更大当然工程复杂度也更高。我现在正在跑的一个实验是用历史转化数据微调一个文案评分模型批量生成后先过评分模型只保留高分文案进入人工抽检环节。这样人工抽检的工作量能减少70%整体效率又上了一个台阶。这个方向后续我会单独写一篇拆解感兴趣的朋友可以关注。