直播开播前最怕什么不是设备出问题也不是样品没到而是商品详情页翻了七八遍真到开麦那一刻还是只会干巴巴念参数容量多少、材质是什么、保修几年。念完三分钟评论区就开始刷“主播你是不是刚来的”。我在同行的交流群里聊过这个痛点很多人反馈基本一致——知道一款产品有哪些卖点和能用一张嘴把它讲得让人想下单完全是两码事。后来我写了一个小工具把商品介绍原文丢进去自动生成一条完整的带货口播稿。从开场怎么切入、中间卖点怎么展开、场景怎么描绘、到最后怎么引导下单全部按直播节奏排好。今天把整个思路、代码实现以及我实际测试过程中踩过的坑完整分享出来。如果你也在做直播运营或者负责给主播写话术这篇内容可以直接拿去抄作业。1. 项目整体设计思路为什么做了这个自动生成口播稿的工具1.1 这个工具解决的真实问题先说清楚我做这个工具之前遇到的困境。当时我手头有几场直播要播商品是临时确定的主播对品牌不熟运营给过来的资料就是一张商品介绍截图上面写着“采用某工艺”“通过某认证”“售后无忧”这种套话真正能转化成口播内容的信息少得可怜。我把商品介绍复制出来逐字看发现两个核心问题。第一信息罗列不等于表达逻辑。详情页把卖点全部堆在一起看起来处处是亮点但口播时不可能从头念到尾观众根本记不住。第二书面语和口语之间隔着一层。商品介绍里写“杯身采用高硼硅玻璃材质耐冷耐热温差可达120摄氏度”直播的时候这么说没问题但没有情绪、没有画面感观众听完就过去了。于是我就想能不能用代码把这段过程自动化。让程序读商品介绍先拆出核心卖点再按照主播的说话逻辑重新组织语言。一开始我尝试过写规则模板比如把“材质316不锈钢”套进“我们这款杯子的内胆用的是XXXX”但很快发现不行因为商品介绍的表达方式千奇百怪有的写“采用”有的写“选用”有的直接写“316不锈钢内胆”规则根本覆盖不全。后来我转向用语言模型来做语言重构效果一下子好起来了。1.2 产品形态与技术选型的思考这个工具的产品形态非常简单就是一个命令行脚本加一个提示词模板。用户把商品介绍粘贴到一个文本文件里运行脚本几分钟后得到一份口播稿。技术选型上我重点比较过两条路线。第一条路线是纯规则抽取加模板填充优点是不依赖外部接口自己写个几百行Python就能跑响应速度快成本为零。但它只能做信息搬运不能做语言风格转换生成出来的内容听起来还是像说明书。第二条路线是调用语言模型接口让模型基于商品信息重新创作口播稿。缺点是会消耗一定的接口费用但生成质量明显高出一个台阶语气、节奏、场景感都出来了。我最终选了第二种方案没有做成本太高的微调。原因在于此时项目还处于试用阶段商品种类又很杂微调模型需要准备不同品类的口播样本工作量远大于直接靠提示词引导。语言模型本身就见过大量直播话术文本只要提示词给得准确它就能输出风格对口的内容。实践下来这个做法完全够用后面如果品类更专一了再做针对性优化也不迟。1.3 流程上要解决的三个关键点整个流程我当时拆成了三个关键点。第一个关键点是商品信息的清洗和结构化不能把一整段商品介绍直接扔给模型那样生成出来的内容没有重点信息密度也会被稀释。第二个关键点是提示词的设计这是整个项目能成的主要原因。第三个关键点是生成结果的后处理需要控制字数、保持分段结构附加上适合主播查看的排版。这三个点听起来简单但我实际踩了不少坑。比如信息清洗商品介绍里经常混着活动说明、售后条款、店铺公告之类的内容直接进模型会让它抓不住主次。再比如提示词设计一开始我写得比较随意没有约束“不得编造参数”模型就把商品介绍里没提到的东西也给编进去了后来加上了明确的约束条件。这些细节我放在后面几节详细讲。2. 核心细节解析商品介绍到口播稿的完整转化链路2.1 第一步文本清洗与卖点结构化任何商品介绍在到达提示词模板之前都得先经过一次处理。我最初写了一个极其简单的清洗函数核心逻辑就是把文本按换行符拆开去掉明显的广告词和无效字符再把包含冒号的句子单独提取出来作为候选卖点。实际操作的时候发现这里有个坑很多商品详情页里的卖点并不是“参数数值”这种标准格式而是一整句描述。比如“这款加湿器运行时的噪音只有35分贝晚上开着睡觉也不会被打扰”。这种情况下按冒号拆分就不太顶用。后来我调整了策略用语言模型本身来做抽取把整段商品介绍交给模型让模型从中提取不超过八个核心卖点。这一步的效果变化非常明显。模型提取卖点的本质是在做信息压缩它会自动把“容量大、续航久、颜值高、能摔”这种零散表达归纳成几条有逻辑的要点。另一个好处是卖点被一次性提取出来后提示词模板就能稳定地引用它们生成的每一条口播稿都以这些卖点为准不会出现模型自己加戏的情况。2.2 第二步提示词工程里的口播稿结构设计口播稿不是一长段话它需要有自己的节奏。我在设计提示词的时候给口播稿定了一个固定的五段结构开场、用户痛点、核心卖点、生活场景、转化引导。这五个部分分别对应直播话术里最常用的几个功能段。开场的作用是抓住注意力我特意在提示词里要求“不要用‘家人们’这种烂大街的开场”避免生成内容千篇一律。痛点段落要把消费者在购买前最纠结的问题写出来比如怕保温杯漏水、怕加湿器太吵、怕小家电发回来就坏了。核心卖点段必须逐条讲清参数背后的价值不能只说“这个杯子保温十二小时”得补充说“早上装的热水下午开会回来喝还是烫嘴的”。生活场景段要把产品放进一个具体的画面里比如上班通勤、车里使用、放在办公室桌面。最后的转化引导段则给出价格理由、限时信号、购买动作提示。这个结构本身并不神秘很多带货团队自己的话术脚本就是这么写的。我做的是把它固化到提示词里让每次生成的内容都有稳定的骨架。下面是当时的提示词模板把它放在脚本里循环使用你是有着多年一线经验的带货主播擅长把商品资料讲得生动、可信、有人情味。 请根据我提供的商品信息和卖点写一段适合直播场景的口播稿。 商品名称{name} 商品信息 {info} 要求 1. 开头用一句吸引人的话切入不能使用“家人们”或“老铁们”开头。 2. 按“开场→用户痛点→核心卖点→生活场景→转化引导”的顺序展开。 3. 每个卖点展开时先讲参数再讲对应场景让观众直观感知。 4. 语言口语化句式要短方便主播直接照着念。 5. 只能使用商品信息里出现过的资料不得编造性能或参数。 6. 全文控制在400到600字。 7. 输出时用【开场】【痛点】【卖点】【场景】【转化】这五个标识分段。这里有一个很关键的小技巧要求模型“先讲参数再讲场景”这句话解决了大多数口播稿干瘪无味的问题。很多模型直接生成的稿子会把卖点列成清单而加上这句之后每个卖点后面都会跟着一句生活化的例子听感立刻不一样了。2.3 第三步生成结果的后处理与输出排版模型返回的内容直接打印出来其实也能用但为了让我在直播时看得舒服我做了两步后处理。第一步是分段格式整理把【开场】【痛点】这些标识行空出来方便一眼定位。第二步是去重和查错模型偶尔会把两个卖点讲成差不多的内容或者出现错别字我在本地跑一遍最简单的相似度检查把重复从句标记出来。这一步不算复杂但很实用。主播在镜头前扫稿子一眼就能看到现在讲到哪个阶段不用在一大段文字里找位置。下面这段代码就是我做后处理时用的骨架很简单但确实能提升体验import re def format_script(raw_text): section_tags [开场, 痛点, 卖点, 场景, 转化] for tag in section_tags: pattern rf【{tag}】 raw_text raw_text.replace(f【{tag}】, f\n\n【{tag}】) lines [line.strip() for line in raw_text.split(\n) if line.strip()] return \n.join(lines) def check_duplicate(sections): # 简单检查相邻段落是否存在重复表述 for i in range(1, len(sections)): prev sections[i - 1][:20] curr sections[i][:20] if prev curr: print(重复内容提示, sections[i][:30], ...)3. 实操演示与核心代码实现3.1 环境准备与依赖安装这个工具的运行环境很常规只要有一台能联网的电脑装好Python环境就行。依赖库方面只需要用来发HTTP请求的requests库其他都可以用标准库完成。以模拟项目X为例我当时的操作流程如下。首先创建一个虚拟目录把项目文件都放在里面。然后安装requestspip install requests接着新建一个Python文件比如命名为generate_script.py把后面要写的代码都放进去。这个项目没有数据库、没有前端所有过程都在命令行里完成。对一个内部工具来说这种形态反而最稳定不用考虑部署和交互设计打开终端就能用。3.2 完整代码商品介绍转口播稿的主要流程我在实际开发过程中把代码分成了四个函数分别负责读文件、解析商品信息、构建提示词、生成和保存结果。整体逻辑很直白大家可以直接照着改造。import requests import json import sys # 这里填写你在用的语言模型接口地址和密钥 API_URL 你的接口地址 API_KEY 你的密钥 def read_product_file(file_path): with open(file_path, r, encodingutf-8) as f: return f.read().strip() def extract_selling_points(raw_text): # 调用模型抽取卖点控制在6到8个避免信息过载 prompt f 从下面的商品介绍中提取不超过8个核心卖点。 每个卖点用一句话概括不要带数字序号。 商品介绍 {raw_text} resp call_model(prompt) points [line.strip() for line in resp.split(\n) if line.strip()] return points def build_prompt(product_name, selling_points): info_block \n.join(f- {point} for point in selling_points) prompt f 你是有着多年经验的带货主播请根据商品信息和卖点写一段适合直播口播的稿子。 商品名称{product_name} 商品信息 {info_block} 要求 1. 开头要抓人不要使用“家人们”开头。 2. 按“开场→痛点→卖点→场景→转化”的顺序写。 3. 每个卖点都要先讲参数再落到具体使用场景。 4. 语言口语化让人能直接照着念。 5. 只准使用商品信息里出现过的内容禁止编造。 6. 全文450到600字。 7. 用【开场】【痛点】【卖点】【场景】【转化】分段。 return prompt def call_model(prompt): payload { messages: [{role: user, content: prompt}], temperature: 0.7 } headers { Content-Type: application/json, Authorization: fBearer {API_KEY} } resp requests.post(API_URL, headersheaders, datajson.dumps(payload), timeout60) data resp.json() return data[choices][0][message][content] def main(): if len(sys.argv) 3: print(用法: python generate_script.py 商品介绍.txt 商品名称) return file_path sys.argv[1] product_name sys.argv[2] raw_text read_product_file(file_path) selling_points extract_selling_points(raw_text) print(提取到的卖点) for p in selling_points: print(-, p) prompt build_prompt(product_name, selling_points) script_text call_model(prompt) print(\n生成的口播稿\n) print(script_text) if __name__ __main__: main()这段代码的核心就三步先抽取卖点再拼提示词最后请求模型。其中温度参数我放在0.7之前试过更低的值生成内容不够生动试过更高的值内容又容易出现不稳定的说法。0.7是个比较稳的选择。3.3 实际效果展示一条普通商品介绍生成的口播稿这里用一个日常商品举例。假设你拿到的是某品牌保温杯的介绍里面提到这些内容316不锈钢内胆、保温12小时、杯盖可拆卸、容量480毫升、重量轻、支持车载杯架、锁扣防漏、亲肤涂层。把这些写进一个文本文件里按上面的脚本跑一遍生成结果大概长这样【开场】 说实话我用过不下二十个保温杯能同时把“保温”和“轻便”做好的没几个。今天这个杯子第一次拿在手里我就觉得该上直播。【痛点】 很多人买保温杯最怕两件事一是早上装的热水下午就凉了二是放在包里突然漏水电脑手机遭殃。这两个问题在普通保温杯上太常见所以我特意挑了这个杯子来测。【卖点】 它内胆用的是316不锈钢比常见的304耐腐蚀性更强装咖啡、装果茶都没问题。官方说保温12小时我自己试的是早上九点灌的热水到下午五点多喝还是明显烫嘴。容量480毫升一瓶矿泉水的体积不到通勤包里随便放。重量也很轻单手握得住倒满水也不会觉得沉。杯盖是旋开的里面的密封圈能拆下来洗不用担心藏污纳垢。底部做了防滑开车放在杯架里也很稳。【场景】 早上出门前灌一杯热水到公司忙完一上午想起来喝一口温度刚刚好。出差在高铁上放在桌板杯座里不占地方单手开盖也不费劲。周末爬山背在侧兜里即使颠来颠去也没漏过水。【转化】 这款杯子现在活动价不到几十块钱平时专卖店单买要贵不少今天直播间再送一个同色杯刷。数量就这批货拍完就恢复原价了。一号链接点进去领一张券再下单到手就是折扣价。这条稿子基本可以直接给主播用里面的参数都来自原始商品介绍模型没有自己发挥。你可能会注意到它连价格都没编因为原文里没有价格信息这在提示词里约束过了。价格信息由运营在直播时补充更稳妥。3.4 批处理与定制化扩展如果你一次要准备多款商品的口播稿那就没必要一款一款地运行。可以将脚本改成遍历某个文件夹里的所有文本文件批量生成一次性输出到一个总目录里。我当时做的是把生成结果按文件名存成多个md文件方便按场次查看。另外一个比较实用的扩展是差异化风格切换。比如有些产品适合温柔亲切的讲解风格有些产品适合干脆利落的测评风格我后来在提示词里增加了一个风格参数def build_prompt_with_style(product_name, selling_points, style): style_desc { 亲切: 语气温和多用生活化类比, 专业: 语气客观侧重参数和对比, 活泼: 语气高亢多用短句和设问 }.get(style, 自然) prompt f 你是一位有经验的带货主播风格是{style_desc}。 请根据商品信息和卖点写一段口播稿。 商品名称{product_name} 商品信息 {info_block} return prompt这个扩展让我处理不同品类时省了不少事。一个美妆类的商品用亲切风格更合适一个数码类的商品用专业风格更容易建立信任感这比所有商品都用同一种模板强得多。4. 实操中遇到的高频问题与排查技巧4.1 生成内容太书面化不像说话这是最常见的翻车现场。第一批稿子生成出来后我拿给身边一位经验丰富的直播运营看对方反馈“语句很通顺但不像人说话太有章法了”。问题出在提示词里没有强调“口语化”的落地方式。后来我改了策略在提示词里增加了两条约束一条是“句式要短能断成两句就不要连成一句”另一条是“允许使用‘说实话’‘你想想看’这类语气词”。这两条加进去之后效果立竿见影生成内容明显更有对着镜头聊天的感觉。如果试了这两个约束还是觉得不够口语还可以提供一个“参考风格段落”给模型让它模仿那个段落的语气。比如找一段你直播间状态最好的录像转成文字把它粘贴在提示词末尾作为风格参照效果往往比单纯描述“口语化”要好。4.2 模型偶尔编造商品介绍里不存在的参数这个问题我在早期经常遇到模型为了把画面感拉满会自己补上一些听起来合理的参数。比如商品介绍根本没提售后时长它写出“一年只换不修”商品介绍没写容量它能编一个“380毫升”。解决思路分两层。第一层是在提示词里明确写“只能使用商品信息里出现过的内容不得编造参数”。这一层能挡掉大部分问题。第二层是在后处理时做关键词校验拿生成文本去和原始介绍比对凡是出现在口播稿里但没在原文中出现过的数字都用正则标记出来让运营人工确认。这个数字校验其实很好写import re def check_madeup_numbers(generated_text, original_text): gen_nums re.findall(r\d(?:\.\d)?\s?(?:毫升|克|度|小时|%|天|年)?, generated_text) orig_nums set(re.findall(r\d(?:\.\d)?\s?(?:毫升|克|度|小时|%|天|年)?, original_text)) suspicious [num for num in gen_nums if num.strip() not in orig_nums] return suspicious这个办法不一定百分之百准确因为有些单位词原文里可能换了一种写法但至少能提示你哪几个数字需要人工确认。宁可多查一步也好过开播后被人发现数据对不上。4.3 生成的稿子逻辑顺序乱卖点讲完又回头讲参数有段时间生成的稿子结构没问题每个段落都带上了【开场】【卖点】标识但段落内部有点乱比如“卖点”部分先讲了容量又跳回讲材质再跑回讲保温能力。整体听下来没有递进感。我在检查时发现问题出在提示词里没有规定卖点介绍的顺序。于是我在卖点步骤里加了一条规则“按用户关心的程度排列卖点把最重要的三个卖点放最前面次要信息往后放。”同时我让抽取卖点时按权重排序先输出用户决策时最看重的卖点。这样修改后生成的内容逻辑明显顺了很多因为模型在组织段落时会默认先讲权重高的卖点。4.4 不同商品品类效果差异很大如何处理品类的适配性同一个模板用在保温杯、加湿器、无线耳机上效果都不一样。数码类商品用户比较看重对比参数所以提示词里应该注重横向对比个护类商品用户偏重体验描述所以预告里要多加使用感受食品类商品更依赖卖点和场景描绘所以要把“吃”的画面写出来。这个阶段的处理方式是给每个大类准备一份独立的提示词模板放在项目的prompts目录下运行时按品类参数去选择对应的模板。模板之间的差别不算大无非是在“卖点讲解”和“场景描绘”两个环节里做调整但带来的观感提升非常明显。用户觉得你在认真做各个品类的直播话术而不是一条模板套所有商品。4.5 API接口调用的稳定性问题批量生成口播稿的时候会遇到接口超时、请求频率限制之类的问题。前期我在批量跑50条商品的时候大概有四五次请求超时导致脚本中断。处理方式有两个。第一个是在请求方加超时重试机制第二次请求如果再次失败就跳过这个商品把它记录下来稍后单独重跑。第二个是在循环调用时加一个暂停间隔比如每5条暂停2秒避免触发频率限制。下面这段重试逻辑我直接放进call_model函数里后续再没有因为网络问题中断过流程def call_model_with_retry(prompt, retries3): for attempt in range(retries): try: return call_model(prompt) except Exception as exc: print(f第{attempt 1}次请求失败: {exc}) time.sleep(3) raise RuntimeError(三次重试都失败了请检查接口状态)4.6 让口播稿更有人味的小技巧最后再补充一个我从测试中摸出来的小技巧。如果你觉得模型生成的稿子过于平铺直叙可以在提示词里加一个“个人使用体验”的描述请求让口播稿以第一人称插入一句真实感很强的细节比如“我自己的这个已经用了三周底部没有磨损”之类的表述。但这句话必须在原始商品介绍能支撑的范围内写不能凭空造。还有一个更省事的方法是在生成之后做一次人工改写。不用改全部只需要把开场和转化这两段改成你自己平时直播的风格就行。模型提供的中间素材已经很扎实了开头和结尾按你的个人表达习惯改一下整条稿子就跟你自己写出来的一样。我跑到后面基本形成了一套固定流程模型生成人工微调开头结尾再拉到直播间实测。整个过程能比我以前纯手写快出几倍时间。这个项目本质上没有多新的技术但胜在把“怎么把话说得让人愿意听”这个经验用代码和提示词固定下来了。我在实际使用中最大的感受是真正难的不是调用模型而是搞清楚一条好口播稿需要哪些结构、哪些信息该先讲、哪些话术容易踩到可信度风险。把这些想透工具本身反而简单。后面如果你想扩展还可以在生成稿子之外加上敏感词检查、违禁广告法词汇过滤、甚至是按直播间在线人数动态调整话术这些功能每一条都值得再单独写一篇。