Step 5 Preview 加 StepAudio 3：手搓一个能实时对话的 AI 深夜电台

为什么想做一个"能对话"的电台，而不是一个播放器

大部分所谓 AI 电台，本质上还是歌单 + TTS 播报。你点一首歌，它念一段串词，然后继续放歌。交互是单向的，你没法真正"插话"。

我想做的场景不一样：深夜两点，你睡不着，打开电台，它先搭一句话，比如"今晚外面挺安静的，你那边呢？“你回一句"有点烦”，它不会立刻放歌，而是顺着往下聊，聊到你情绪缓下来了，再自然地说"我给你放首慢的"。整个过程是来回对话的，音乐只是收尾。

这个需求拆开看，其实就是一个实时语音 Agent：语音输入 → 文本理解与生成 → 语音输出，中间还要能被打断。模型选型上我用 Step 5 Preview 做对话大脑，StepAudio 3 做语音合成。下面讲具体怎么搭。

先说明一点：Step 5 Preview 和 StepAudio 3 是阶跃星辰的模型，官方对外的调用方式、支持的参数、是否原生支持流式音频，这些细节在不同时间点会有变化。本文里我没有逐一验证的接口参数，会明确标出来，你落地前请以官方最新文档为准。

整体架构：先把"电台感"和"对话能力"分开

一开始我犯了个错，把"电台人设"和"对话逻辑"混在一段 prompt 里，结果模型一会儿像 DJ、一会儿像客服。后来我把职责拆清楚了。

整体链路是这样的：

1. 前端采集麦克风音频，做 VAD（语音活动检测），判断用户是否在说话、是否说完。
2. 用户说完，把音频转成文本（ASR 部分本文不展开，假设已有文本输入）。
3. 文本进入 Step 5 Preview，带上电台人设 + 对话历史 + 当前状态（是否该放歌）。
4. 模型输出文本回复，同时给出一个"动作标签"，决定是继续聊还是插播音乐。
5. 文本送进 StepAudio 3 合成语音，流式播放。
6. 播放期间如果检测到用户说话，立刻打断，停止播放，回到第 1 步。

这里最关键的设计是第 4 步的动作标签。如果只让模型自由发挥，它很容易在你刚说"我有点累"的时候就急着放歌，节奏很怪。所以我让模型在回复末尾输出一个结构化标记，类似这样：

{"say":"累了就别硬撑了，我陪你待一会儿。","action":"chat","mood":"calm"}

action只有两个值：chat（继续聊）和play（插播音乐）。mood用来调节 TTS 的语气。这样电台的"节奏感"就由代码控制，而不是全靠模型自觉。

【关键结论】把"说什么"和"接下来做什么"拆成两个字段，是让对话节奏稳定的核心。纯自然语言输出很难稳定控制节奏。

电台人设的 prompt 怎么写才不油腻

深夜电台最怕的就是假温柔。“亲爱的听众朋友，欢迎收听今晚的节目"这种一开口就出戏。我在 prompt 里明确禁止了几类表达：不要用"亲爱的”“听众朋友们”，不要每句都加感叹号，不要强行正能量。

我的 system prompt 大致是这样组织的（简化版）：

你是一个深夜电台的陪伴者，不是主持人，也不是客服。 说话风格： - 短句为主，一次说一到两句，不要长篇大论 - 不要用"亲爱的""听众朋友"这类称呼 - 不要急着给建议，先接住对方的情绪 - 允许沉默，允许说"嗯，我在听" 当前状态：{state} 对话历史：{history} 用户说：{user_input} 请输出 JSON： {"say": "...", "action": "chat 或 play", "mood": "calm/warm/low"}

这里有个细节值得说：我把对话历史做了截断，只保留最近 8 轮。深夜聊天很容易聊很长，历史一长，Step 5 Preview 的响应会变慢，而且模型会开始"总结"之前的对话，反而显得刻意。截断之后，回复更自然，延迟也降下来了。

另外state这个变量很重要。它记录当前是不是已经在放歌、放了多久、用户是不是刚打断过。比如用户刚打断过一次，模型就不该马上又想放歌，否则会显得很烦。这一点我是靠实测调出来的，不是拍脑袋写的。

StepAudio 3 的流式合成怎么接

语音这块，我的思路是边生成边播放，而不是等整段文本合成完再放。深夜电台的回复一般就一两句，但如果等整段合成，用户会明显感觉到"卡一下"。流式的话，第一句声音出来得快，体感差别很大。

StepAudio 3 的调用，我按官方文档的方式走。这里我要诚实说：不同版本的 SDK 对流式返回的封装不太一样，有的返回 bytes 分片，有的返回 base64，本文代码按"返回 bytes 分片"这个假设写，你实际接入时先打印一下返回类型再决定怎么处理。

核心逻辑大概是这样：

importasyncioimportaiohttpasyncdefsynthesize_stream(text:str,mood:str,api_key:str):""" 调用 StepAudio 3 做流式语音合成。 注意：endpoint 和参数名请以官方文档为准，这里只是结构示意。 """payload={"text":text,"voice":"night_radio",# 音色名，实际取值看官方文档"speed":0.95,# 深夜语速略慢一点"emotion":mood,# 对应 prompt 里的 mood 字段}headers={"Authorization":f"Bearer{api_key}","Content-Type":"application/json",}asyncwithaiohttp.ClientSession()assession:asyncwithsession.post("https://api.stepfun.com/v1/audio/speech",# 占位，请替换为真实地址json=payload,headers=headers,)asresp:asyncforchunkinresp.content.iter_chunked(4096):ifchunk:yieldchunk

emotion这个字段是我比较在意的点。深夜电台如果所有话都是一个语气，听着像导航。mood从 Step 5 Preview 传下来，calm就用平稳语气，low就压低一点。但 StepAudio 3 具体支持哪些 emotion 取值、是否真的支持这个参数，我这边没有逐个验证，你接入时先确认。

播放侧我用的是pyaudio，边收边写：

importpyaudioasyncdefplay_stream(stream_chunks):p=pyaudio.PyAudio()out=p.open(format=pyaudio.paInt16,channels=1,rate=24000,# 采样率要和你合成返回的一致output=True,)try:asyncforchunkinstream_chunks:out.write(chunk)finally:out.stop_stream()out.close()p.terminate()

【踩坑提醒】采样率一定要对齐。StepAudio 3 返回的采样率如果和你pyaudio.open里的rate不一致，声音会变调，要么像快进要么像慢放。我一开始就是这里没对上，查了半天以为是模型问题。

打断处理：这才是"实时"的灵魂

如果说前面都是常规活，那打断处理是真正决定体验的地方。

深夜聊天，用户经常会在电台说到一半的时候插话。如果电台还在自顾自播，用户会立刻觉得"这是个机器"。所以打断必须快，最好在 200ms 内停掉播放。

我的做法是：播放和 VAD 检测跑在两个协程里，共享一个interrupt_event。

importasyncioclassRadioSession:def__init__(self):self.interrupt_event=asyncio.Event()self.playing=Falseasyncdefspeak(self,text:str,mood:str,api_key:str):self.playing=Trueself.interrupt_event.clear()asyncdef_play():chunks=synthesize_stream(text,mood,api_key)asyncforchunkinchunks:ifself.interrupt_event.is_set():return# 被打断，立刻停止awaitaudio_out.write(chunk)try:await_play()finally:self.playing=Falseasyncdeflisten(self):"""持续监听用户语音，检测到说话就打断当前播放"""whileTrue:detected=awaitvad.detect_speech()ifdetectedandself.playing:self.interrupt_event.set()

这里有个容易忽略的点：打断之后，对话历史里要不要保留被打断的那半句？我一开始把完整回复都塞进历史，结果模型以为它"已经说完了"，下一轮接话就错位。后来改成：被打断时，只把已经播出去的那部分文本记进历史，没播的部分丢掉。这样上下文是准的。

【注意】VAD 的灵敏度要调。太灵敏，电台自己播放的声音会被麦克风收进去触发误打断；太迟钝，用户插话半天没反应。我的做法是播放期间把 VAD 阈值调高一点，或者直接做回声消除。这一步没有银弹，得按你的硬件环境调。

几个实际用下来值得说的判断

跑了一段时间，有几个感受。

第一，延迟的瓶颈往往不在模型，而在链路切换。Step 5 Preview 生成文本其实挺快，真正拖时间的是"文本生成完 → 发起 TTS → 第一个音频包回来"这一段。所以我后来做了个优化：不等整段文本生成完，一旦模型输出里say字段闭合，就先拿这部分去合成，后面的字段再补。这个需要模型输出顺序稳定，我这边是先输出say再输出action，能配合上。

第二，别让模型太主动。深夜陪伴类场景，用户要的是"被接住"，不是"被安排"。我在 prompt 里加了"允许沉默"，模型回复变短之后，整个氛围反而更好。这个不是技术问题，是产品判断。

第三，情绪状态要跨轮传递。我一开始每轮都重新判断情绪，结果模型一会儿觉得你 calm 一会儿觉得你 low，语气跳来跳去。后来我把mood做成一个带衰减的状态变量，新的判断只做微调，不直接覆盖。这样语气是连续变化的。

defupdate_mood(current:str,new:str,weight:float=0.3)->str:"""带权重的情绪更新，避免语气突变"""ifcurrent==new:returncurrent# 简单实现：新情绪权重不够就不切换ifweight>=0.5:returnnewreturncurrent

这个实现很粗糙，但方向是对的：状态要平滑，不能每轮重置。

这套东西适合什么，不适合什么

我得说清楚边界。这套方案适合的是"陪伴型、低信息密度"的对话场景——深夜电台、冥想引导、睡前闲聊。它不适合需要精确信息输出的场景，因为我把模型回复限制得很短，牺牲了信息量。

另外，Step 5 Preview 和 StepAudio 3 的具体参数、计费、并发限制，这些我都没有系统验证过，本文里凡是标了"以官方文档为准"的地方，都请你自己核对一遍再上生产。我写的是架构思路和踩过的坑，不是一份可以直接复制的接入文档。

如果你也想做类似的东西，我建议先从"纯文本对话 + 固定语音播报"跑通链路，确认对话节奏舒服了，再上流式 TTS 和打断。节奏是灵魂，语音只是外壳。节奏不对，声音再自然也像个念稿机器。