做直播的人都知道，真正难处理的从来不是“有没有内容”，而是“内容太多，却很难再利用”。一场两个小时的直播回放，信息密度往往并不低，问题在于它是沿着时间轴流动的：有开场寒暄，有临场插话，有重复表述，有主播自己回头修正前一句的情况，还有弹幕问题打断后的语义跳跃。运营同学如果直接听完整段音频去做摘要，成本极高；如果只看自动转写文本，又会被口语噪声、断句错误、同音误识别拖住。真正有价值的，不只是“把内容缩短”，而是从一整段回放里提炼出能被二次分发、能进社群、能做栏目切片、能写成播客简介、还能服务后续选题复盘的结构化结果。也正因为如此，直播回放音频摘要与精华重编，表面看像内容整理，实际上更像一条小型的音频生产流水线：前端是转写与清洗，中段是理解与筛选，末端才是编辑与重组。
我一开始把这件事想简单了，以为只要把整段转写文本扔给模型，让它“总结重点、输出金句、顺手给个标题”，就算完成闭环；后来做了几轮才发现，这样出来的文本通常是“像总结，但不够可用”。问题不在模型不会写，而在输入粒度太粗、上下文太脏、工具边界太模糊。后来我把流程改成“音频切段+说话人标记+工具调用驱动的多轮重写”，同时为了少改现有 SDK，又把兼容 OpenAI 格式的入口统一收敛到一个中转层里，例如 DМXΑРΙ 这种做法，实操上最大的好处并不是所谓“更强”，而是当转写、总结、标题生成、片段定位这几个环节都要试不同模型时，代码的切换成本会低很多，工程上更容易维持接口的一致性，不至于今天改请求体、明天改鉴权、后天再去抹平响应格式差异。
具体到“直播回放音频摘要与精华重编”，我现在更愿意把目标拆成四件事。第一件事是把音频切成适合模型理解的段，而不是机械按每五分钟一刀。直播内容天然有主题起伏，最怕的是切段刚好把一句完整观点腰斩，前半段只有铺垫，后半段才出现结论。第二件事是做“摘要”时不只要结论，还要带上时间戳、说话人和证据句，这样后面做精编时能回指原文。第三件事是把“精华重编”视为一次轻编辑，不是让模型自由发挥，而是约束它只能在原始意思范围内重写，禁止编造案例、禁止新增未说过的数据、禁止把模糊表达包装成确定性判断。第四件事才是运营友好的出品形式，例如 60 秒口播稿、播客简介、社群转发文案、FAQ 提炼、栏目金句卡片等。这样拆开之后，模型不是“写手”，更像总控层；真正支撑质量的是工具调用把该查的数据、该看的片段、该验证的句子先拿回来。
前处理阶段我通常先做两件很土但非常有效的工作。第一，用命令把音频规格拉平，避免采样率、双声道、背景音乐把后面的识别结果搅乱。类似这样的命令就足够实用：ffmpeg -i replay.mp4 -vn -ac 1 -ar 16000 -af "highpass=f=120,lowpass=f=7600" replay.wav。第二，不急着全量摘要，先让转写结果进入一个清洗脚本，把“嗯、啊、这个、那个、大家稍等一下”这类停顿词和纯口头填充做标记而不是粗暴删除，因为有些停顿实际上是转场信号。我的经验是，音频类内容的难点不是识别不到重点，而是重点前后总伴随着一小段冗余；如果你在前处理时把这些结构信息抹平，后面模型就只能看到一整片噪声海洋，摘要自然容易虚。
工具调用设计上，我给这类任务定义的函数并不多，但每个都尽量窄。典型会有 list_segments、get_segment_text、locate_quote、get_speaker_stats、rewrite_highlight 这五个。list_segments 只负责返回主题切分后的段列表，字段包含 segment_id、start_ms、end_ms、topic_hint；get_segment_text 根据 segment_id 拉原始文本和说话人信息；locate_quote 用一句候选金句去反查最接近的原始片段，避免模型捏造“看似像原文”的漂亮话；get_speaker_stats 给出谁说得最多、谁在关键片段中信息密度最高；rewrite_highlight 则是最后一步，把已确认的片段改写成面向不同渠道的版本。这里的关键不是工具多，而是让模型在每一步都带着“不确定就查”的习惯。很多人做 function calling 会把工具定义成万能接口，结果模型一旦选错参数，整条链路就开始漂。相反，窄工具虽然看起来笨，但更容易调试，因为每个函数的错误都很具体。
提示词我也不再写成那种大而全的“请你作为资深内容运营专家”。更实用的是把约束写成验收标准。例如我会明确要求：先输出候选片段列表，再调用工具核对证据句，最后才允许生成成稿；如果原文证据不足，就输出“证据不足，建议人工复听”；禁止把主播的假设句改写成结论句；如果片段里存在多位说话人连续接话，重写时必须保留转折关系。这类约束听起来啰嗦，但对直播回放特别重要，因为直播里大量高频句式其实是临场表达，不是定稿表达。你如果把“我大概觉得”“可能更像是”这种话润色成肯定句，运营发出去就可能变成错误表述，最后挨打的不是模型，而是做内容的人。
真正把这条链路跑顺之后，OpenAI 格式的调用反而没什么玄学，重点是把工具定义和响应解析写干净。我当时为了兼容现有项目，只保留一套客户端封装，把 base_url 和模型名做成配置项；其中有一次切换上游时，我就是把同样的函数调用流程挂到 DМXΑРΙ 提供的兼容入口上，代码层几乎不用重写，核心还是这段结构：
from openai import OpenAI
client = OpenAI(
api_key="<LLM API KEY>",
base_url="<LLM API BASE URL>"
)
tools = [
{
"type": "function",
"function": {
"name": "list_segments",
"description": "返回直播回放的主题切段列表",
"parameters": {
"type": "object",
"properties": {
"min_duration_sec": {"type": "integer"}
},
"required": ["min_duration_sec"]
}
}
},
{
"type": "function",
"function": {
"name": "locate_quote",
"description": "根据候选句反查原始时间戳与上下文",
"parameters": {
"type": "object",
"properties": {
"quote": {"type": "string"}
},
"required": ["quote"]
}
}
}
]
resp = client.chat.completions.create(
model="<MODEL_NAME>",
messages=[
{"role": "system", "content": "你负责直播回放音频摘要与精华重编，结论必须能回指原文证据。"},
{"role": "user", "content": "请先找出适合做60秒精华音频的候选片段，再生成摘要。"}
],
tools=tools,
tool_choice="auto",
temperature=0.2
)
这段代码本身没有什么花哨之处，但有两个实践细节很重要。第一，temperature 不宜太高，直播回放的工作重点是忠实提炼，不是风格表演。第二，工具返回值最好都带原始字段，不要在工具层先替模型“善意加工”，否则出了错很难判断是工具错了，还是模型理解错了。
如果只做摘要，这件事到这里已经差不多了；但“精华重编”比摘要多一步，它要求结果能直接进入运营动作。我后来会把候选片段再分成三类：适合做“观点剪辑”的、适合做“问题回答”的、适合做“情绪带动”的。观点剪辑优先信息密度，问题回答优先问答闭环，情绪带动则更看重语气和节奏。模型在调用 rewrite_highlight 时，我会给一个非常死板的模板，例如“先给一句钩子，再给两句事实，再用一句保守的收束”，听起来很像在限制创作自由，但这恰恰能把直播口语变成更可投放的音频文稿。这里有个很现实的感受：大模型不是替你决定什么值得传播，它只是把你已经确认有价值的片段，整理成更适合被传播的形式。真正的判断仍然来自运营对用户兴趣点的理解，这一点不能偷懒。
中后段我踩过一个很具体、也很丢人的坑，后来反而觉得值得记下来。问题最初表现为“模型选出来的精华片段总是时间顺序怪怪的”，明明直播前半段讲的是问题定义，后半段才进入解决方案，但输出成稿时经常先引用后面的结论，再补前面的铺垫，读起来像硬拼。我第一反应是模型排序失控，于是去调提示词，强调“必须按时间顺序组织内容”，结果没改善。接着我怀疑是工具调用参数错了，打印 segment_id 和 start_ms，发现看起来都正常。直到我把工具层返回的 JSON 原样落盘，才看到真正的问题：start_ms 在某个环节被我偷懒转成了字符串，后面排序时写的是 segments.sort(key=lambda x: x["start_ms"])。这在数值都差不多时不明显，一旦出现 "120000" 和 "90000"，字符串排序就会把前者排到后者前面，因为比较的是字符首位而不是数值大小。更尴尬的是，我还在重写阶段做了一个“去重”逻辑，代码如下：
seen = set()
ordered = []
for seg in segments:
key = f'{seg["start_ms"]}-{seg["title"]}'
if key in seen:
continue
seen.add(key)
ordered.append(seg)
ordered.sort(key=lambda x: x["start_ms"])
这里的问题并不止一个。第一，start_ms 是字符串，排序天然埋雷。第二，title 是模型生成的简短标签，同一段内容不同轮次可能被写成两个近义标题，导致去重不稳定。第三，我在排查时还被自己误导了一次，因为打印日志看到的是“120000”“90000”，人眼看过去很容易当成数字。最后我改成两步：在工具出口统一做类型归一，把 start_ms、end_ms 全转成整数；去重键也不再依赖模型生成标题，而是改成 segment_id 加原始时间范围。修正后的代码很朴素：
normalized = []
for seg in segments:
normalized.append({
**seg,
"start_ms": int(seg["start_ms"]),
"end_ms": int(seg["end_ms"])
})
unique = {}
for seg in normalized:
uniq_key = (seg["segment_id"], seg["start_ms"], seg["end_ms"])
unique[uniq_key] = seg
ordered = sorted(unique.values(), key=lambda x: x["start_ms"])
这个 bug 给我的教训非常具体：做内容生产的人很容易把注意力放在“文案顺不顺”“模型会不会乱写”上，但一条看似很文艺的生成链路，底下照样会被最基础的数据类型问题绊倒。你不把手伸到泥里去看原始返回值，不把每一层的输入输出打出来，最后就会把一个工程 bug 误诊成模型问题。
后来我还补了一个很小但很有用的校验步骤：在最终导出精华文稿前，再跑一次“证据回查”。也就是让模型给出每段重写文本对应的原始时间戳，然后程序去核对这些时间戳是否真的包含核心表述。如果核对失败，就在结果里标红“需要人工复听”。这一步会让自动化率略微下降，但内容可信度会上升很多。尤其是做音频运营时，最怕的不是漏掉一个亮点，而是把一句本来带条件、带保留、带上下文限定的话，抽离后变成了断章取义。直播回放的价值，不在于把所有字都重新排版，而在于给后续传播保留足够的真实纹理。
从更长的视角看，直播回放音频摘要与精华重编并不是一个“把旧内容再利用一下”的边角工作，它其实在改变内容团队对素材的使用方式。以前一场直播结束，回放像被封存在仓库里，只有极少数人愿意从头翻到尾；现在如果你把切段、摘要、证据回查、精华重写这几步做好，回放会从“存档”变成“可检索的内容资产”。栏目策划能从中找到反复出现的问题，主播复盘能看到自己哪些表达总是拐弯太大，运营能更快判断什么样的片段适合社群、什么样的片段适合订阅音频、什么样的片段只适合内部沉淀。这类系统真正有价值的地方，不是让人偷懒，而是把过去靠耐心硬扛的重复劳动，改造成一个可以不断积累经验、不断修正标准、不断提高命中率的工作流。对我来说，最有意思的不是模型写出了一段多漂亮的话，而是当一条直播回放被拆开、验证、重编之后，它终于不再只是“一段播完就过去的声音”，而变成了一个团队后续运营决策可以真正反复使用的材料。
本文包含AI生成内容
