直播开播前最怕什么？不是设备出问题，也不是样品没到，而是商品详情页翻了七八遍，真到开麦那一刻还是只会干巴巴念参数：容量多少、材质是什么、保修几年。念完三分钟，评论区就开始刷“主播你是不是刚来的”。我在同行的交流群里聊过这个痛点，很多人反馈基本一致——知道一款产品有哪些卖点，和能用一张嘴把它讲得让人想下单，完全是两码事。
后来我写了一个小工具，把商品介绍原文丢进去，自动生成一条完整的带货口播稿。从开场怎么切入、中间卖点怎么展开、场景怎么描绘、到最后怎么引导下单，全部按直播节奏排好。今天把整个思路、代码实现，以及我实际测试过程中踩过的坑完整分享出来。如果你也在做直播运营，或者负责给主播写话术，这篇内容可以直接拿去抄作业。
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为例，我当时的操作流程如下。首先创建一个虚拟目录，把项目文件都放在里面。然后安装requests：
pip 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", encoding="utf-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": f"Bearer {API_KEY}" } resp = requests.post(API_URL, headers=headers, data=json.dumps(payload), timeout=60) 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, retries=3): 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 让口播稿更有人味的小技巧
最后再补充一个我从测试中摸出来的小技巧。如果你觉得模型生成的稿子过于平铺直叙，可以在提示词里加一个“个人使用体验”的描述请求，让口播稿以第一人称插入一句真实感很强的细节，比如“我自己的这个已经用了三周，底部没有磨损”之类的表述。但这句话必须在原始商品介绍能支撑的范围内写，不能凭空造。
还有一个更省事的方法，是在生成之后做一次人工改写。不用改全部，只需要把开场和转化这两段改成你自己平时直播的风格就行。模型提供的中间素材已经很扎实了，开头和结尾按你的个人表达习惯改一下，整条稿子就跟你自己写出来的一样。我跑到后面基本形成了一套固定流程：模型生成，人工微调开头结尾，再拉到直播间实测。整个过程能比我以前纯手写快出几倍时间。
这个项目本质上没有多新的技术，但胜在把“怎么把话说得让人愿意听”这个经验，用代码和提示词固定下来了。我在实际使用中最大的感受是，真正难的不是调用模型，而是搞清楚一条好口播稿需要哪些结构、哪些信息该先讲、哪些话术容易踩到可信度风险。把这些想透，工具本身反而简单。后面如果你想扩展，还可以在生成稿子之外加上敏感词检查、违禁广告法词汇过滤、甚至是按直播间在线人数动态调整话术这些功能，每一条都值得再单独写一篇。
