直播前两小时，脚本还没出来，AI 要么直接报错，要么吐一半停住，要么给你一段没法照着念的废话。这类问题九成不是模型不行，而是输入太长、格式要求太糊、或者接口本身在超时。这篇按报错类型给出排查顺序和修正动作，改完再跑一遍就能定位到底卡在哪一步。
直播前两小时，脚本还没出来，AI 要么直接报错，要么吐一半停住，要么给你一段没法照着念的废话。这种事挺常见，但九成不是模型不行，而是输入太长、格式要求太糊、或者接口本身在超时。急着改提示词之前，先搞清楚卡在哪一层，能省掉大半天折腾。
下面按报错类型给出排查顺序和修正动作：先分类，再缩输入、锁格式，最后讲重试和降级。每一节都能直接照着做，改完再跑一遍，就能定位到底卡在哪一步。有一点先说明：如果问题出在接口层（限流、鉴权、超时），改提示词是白费力气，得先解决连接本身。
先分清是哪一类报错，别上来就改提示词
报错不是一种东西。接口层的问题（超时、限流、鉴权失败）和模型层的问题（拒答、答非所问）处理方式完全不同。判断方法很简单：看返回的 HTTP 状态码和错误文案。4xx 开头多数是参数或鉴权，5xx 或超时是服务端，这两种都跟你的脚本内容没关系。
| 报错类型 | 典型表现 | 先做什么 |
|---|---|---|
| 接口层 | 超时、限流、鉴权失败 | 去站内测速页量延迟基线，别动提示词 |
| 模型层 | 拒答、答非所问、中途截断 | 检查输入长度和内容是否触发限制 |
| 格式层 | 该给 JSON 却给散文、字段缺失 | 把输出结构写死成模板再跑 |
- 同一段提示词换个模型跑，如果只有某一家报错，基本能判断是这家接口或参数问题
- 记录报错时的输入长度和商品数量，很多直播脚本报错其实是上下文塞太满
- 接口层的问题改提示词没用，先去站内测速页量一遍延迟基线，确认是网络还是服务端
- 把报错文案原样存下来，后面复盘和提工单都用得上，别凭记忆描述
输入太长最容易被忽略：把商品表拆开喂
一场直播几十个 SKU 全塞进一次请求，很容易触顶，或者让模型后半段开始敷衍——前面的品讲得详细，后面的品只剩一句「这个也很好」。解决办法不是换个更强的模型，而是按价格带或品类分批，每批生成一段，最后拼起来。
- 先压商品信息商品参数、卖点、尺码表这类结构化信息，先压成短字段再进提示词。别把整张表格原样贴进去，字段名能用缩写就用缩写。
- 先要骨架再扩写让模型先输出脚本骨架（开场、讲品顺序、逼单点），确认骨架对了再逐段扩写。比一次要完整长稿稳得多，也方便中途调整顺序。
- 按批跑，别一次要全一批控制在你能口述完的规模，跑完一段存一段。确实要长稿，参考站内提示词技巧页里的上下文与分块说法，把长任务拆成多次短请求。
什么情况下不适用？如果整场直播只有三五个品，拆批反而增加拼接成本，一次跑完更省事。拆批主要针对品多、参数密的场景。
格式收不住：把脚本结构写死成模板
格式层的报错最气人：内容有了，但没法用。常见原因是你在同一段提示词里既要自然语言、又要严格 JSON，模型两头不靠。要么只要求纯文本，要么只要求结构化字段，别混着来。
- 明确规定输出结构，比如每段必须包含「话术正文／停顿提示／上链接时机」三行，缺一不可
- 要求纯文本或指定分隔符，别在同一段里既要自然语言又要严格 JSON
- 给一到两个示例段落作为格式样板，比讲一堆规则有效
- 拿不到想要格式时，把要求降到只剩「分行＋小标题」，先保证能产出，再逐步加约束
格式要求越具体，模型越不容易跑偏；但具体要求不能靠形容词，得靠可照抄的样板。
还有一个容易忽略的点：如果脚本要交给下游工具处理，格式就必须是机器能解析的，这时候宁可牺牲文字的自然度。如果只是给人念，那就别强迫模型输出 JSON。
跑不稳时的重试与降级动作
限流和超时是常态，处理方式比报错本身更重要。连续硬打只会让情况更糟，正确做法是拉开间隔重试，同时准备一条降级路径，保证临开播手里有稿可用。
- 指数退避重试遇到限流或超时，间隔逐次拉长再重试，别连续硬打。第三次还失败就切备用方案。
- 准备精简版兜底内容要求砍到只剩开场和三个核心卖点，保证有稿可用。兜底稿不好看没关系，能撑过前十分钟就行。
- 主备模型分开配置主模型连续失败两次就切备用，别临开播还在等。备用模型的选择到站内模型库页面对照当时的可用情况。
- 记录每次失败参数报错文案、请求参数、模型名都存下来，是复盘下一次最快的方式。积累几轮就能看出是哪类输入在触发报错。
开播前按这个顺序过一遍
这套顺序的核心是：先确认通不通，再确认内容对不对，最后确认念着顺不顺。顺序反了会白折腾，尤其是先改提示词再查网络那种。
- 先确认接口连通和延迟，再谈内容质量
- 商品信息按批次整理好，每批控制在你能口述完的规模
- 提示词里写清受众、价格定位、直播时长和禁止出现的表述，这些比堆形容词有用
- 最后通读一遍，凡是自己念着别扭的句子直接划掉，机器写的稿子必须过一遍人嘴
如果排查完还是搞不定，可能不是提示词的问题，而是这家接口本身不稳。这时候去站内中转站可信度检测页面看看当时的状态记录，再决定要不要换一条线路。具体的价格、延迟和可用性数字，到站内对应页面核对当时的情况，别用旧印象判断。
下一步先把测速和状态核对做完，再回头改提示词，能省掉一半以上的无效调试。→常见问题
脚本生成到一半突然断了，是模型能力不够吗？
多数情况不是。先看是不是上下文塞太满、或者接口读取超时。把商品分批、要求模型先出骨架再扩写，断流概率会明显下降。如果只在某一家接口上出现，换源对比一下就能确认是接口侧的问题。参考 /tools/speed-test 量一遍延迟再做判断。
同样的提示词昨天能跑通，今天报错，怎么查？
按顺序看三件事：接口是否限流或临时不可用、模型是不是被平台换掉了、你自己的输入是不是变长了。前两项去站内服务状态页和模型库核对，第三项自己比较两次请求的商品数量。三个都排掉还报错，就把提示词简化到最小可复现版本再试。
AI 写的直播脚本为什么总是没法直接念？
通常是没给场景约束：受众、价格带、直播时长、要不要逼单，这些缺一个，输出就会偏成通用文案。把结构写死成固定小节，再给一段你自己满意的示例当样板，比反复强调「要口语化」有用。最后一定要人工过一遍嘴。
