为什么想做一个能对话的电台而不是一个播放器大部分所谓 AI 电台本质上还是歌单 TTS 播报。你点一首歌它念一段串词然后继续放歌。交互是单向的你没法真正插话。我想做的场景不一样深夜两点你睡不着打开电台它先搭一句话比如今晚外面挺安静的你那边呢“你回一句有点烦”它不会立刻放歌而是顺着往下聊聊到你情绪缓下来了再自然地说我给你放首慢的。整个过程是来回对话的音乐只是收尾。这个需求拆开看其实就是一个实时语音 Agent语音输入 → 文本理解与生成 → 语音输出中间还要能被打断。模型选型上我用 Step 5 Preview 做对话大脑StepAudio 3 做语音合成。下面讲具体怎么搭。先说明一点Step 5 Preview 和 StepAudio 3 是阶跃星辰的模型官方对外的调用方式、支持的参数、是否原生支持流式音频这些细节在不同时间点会有变化。本文里我没有逐一验证的接口参数会明确标出来你落地前请以官方最新文档为准。整体架构先把电台感和对话能力分开一开始我犯了个错把电台人设和对话逻辑混在一段 prompt 里结果模型一会儿像 DJ、一会儿像客服。后来我把职责拆清楚了。整体链路是这样的前端采集麦克风音频做 VAD语音活动检测判断用户是否在说话、是否说完。用户说完把音频转成文本ASR 部分本文不展开假设已有文本输入。文本进入 Step 5 Preview带上电台人设 对话历史 当前状态是否该放歌。模型输出文本回复同时给出一个动作标签决定是继续聊还是插播音乐。文本送进 StepAudio 3 合成语音流式播放。播放期间如果检测到用户说话立刻打断停止播放回到第 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:fBearer{api_key},Content-Type:application/json,}asyncwithaiohttp.ClientSession()assession:asyncwithsession.post(https://api.stepfun.com/v1/audio/speech,# 占位请替换为真实地址jsonpayload,headersheaders,)asresp:asyncforchunkinresp.content.iter_chunked(4096):ifchunk:yieldchunkemotion这个字段是我比较在意的点。深夜电台如果所有话都是一个语气听着像导航。mood从 Step 5 Preview 传下来calm就用平稳语气low就压低一点。但 StepAudio 3 具体支持哪些 emotion 取值、是否真的支持这个参数我这边没有逐个验证你接入时先确认。播放侧我用的是pyaudio边收边写importpyaudioasyncdefplay_stream(stream_chunks):ppyaudio.PyAudio()outp.open(formatpyaudio.paInt16,channels1,rate24000,# 采样率要和你合成返回的一致outputTrue,)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_eventasyncio.Event()self.playingFalseasyncdefspeak(self,text:str,mood:str,api_key:str):self.playingTrueself.interrupt_event.clear()asyncdef_play():chunkssynthesize_stream(text,mood,api_key)asyncforchunkinchunks:ifself.interrupt_event.is_set():return# 被打断立刻停止awaitaudio_out.write(chunk)try:await_play()finally:self.playingFalseasyncdeflisten(self):持续监听用户语音检测到说话就打断当前播放whileTrue:detectedawaitvad.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:float0.3)-str:带权重的情绪更新避免语气突变ifcurrentnew:returncurrent# 简单实现新情绪权重不够就不切换ifweight0.5:returnnewreturncurrent这个实现很粗糙但方向是对的状态要平滑不能每轮重置。这套东西适合什么不适合什么我得说清楚边界。这套方案适合的是陪伴型、低信息密度的对话场景——深夜电台、冥想引导、睡前闲聊。它不适合需要精确信息输出的场景因为我把模型回复限制得很短牺牲了信息量。另外Step 5 Preview 和 StepAudio 3 的具体参数、计费、并发限制这些我都没有系统验证过本文里凡是标了以官方文档为准的地方都请你自己核对一遍再上生产。我写的是架构思路和踩过的坑不是一份可以直接复制的接入文档。如果你也想做类似的东西我建议先从纯文本对话 固定语音播报跑通链路确认对话节奏舒服了再上流式 TTS 和打断。节奏是灵魂语音只是外壳。节奏不对声音再自然也像个念稿机器。
为什么想做一个能对话的电台而不是一个播放器大部分所谓 AI 电台本质上还是歌单 TTS 播报。你点一首歌它念一段串词然后继续放歌。交互是单向的你没法真正插话。我想做的场景不一样深夜两点你睡不着打开电台它先搭一句话比如今晚外面挺安静的你那边呢“你回一句有点烦”它不会立刻放歌而是顺着往下聊聊到你情绪缓下来了再自然地说我给你放首慢的。整个过程是来回对话的音乐只是收尾。这个需求拆开看其实就是一个实时语音 Agent语音输入 → 文本理解与生成 → 语音输出中间还要能被打断。模型选型上我用 Step 5 Preview 做对话大脑StepAudio 3 做语音合成。下面讲具体怎么搭。先说明一点Step 5 Preview 和 StepAudio 3 是阶跃星辰的模型官方对外的调用方式、支持的参数、是否原生支持流式音频这些细节在不同时间点会有变化。本文里我没有逐一验证的接口参数会明确标出来你落地前请以官方最新文档为准。整体架构先把电台感和对话能力分开一开始我犯了个错把电台人设和对话逻辑混在一段 prompt 里结果模型一会儿像 DJ、一会儿像客服。后来我把职责拆清楚了。整体链路是这样的前端采集麦克风音频做 VAD语音活动检测判断用户是否在说话、是否说完。用户说完把音频转成文本ASR 部分本文不展开假设已有文本输入。文本进入 Step 5 Preview带上电台人设 对话历史 当前状态是否该放歌。模型输出文本回复同时给出一个动作标签决定是继续聊还是插播音乐。文本送进 StepAudio 3 合成语音流式播放。播放期间如果检测到用户说话立刻打断停止播放回到第 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:fBearer{api_key},Content-Type:application/json,}asyncwithaiohttp.ClientSession()assession:asyncwithsession.post(https://api.stepfun.com/v1/audio/speech,# 占位请替换为真实地址jsonpayload,headersheaders,)asresp:asyncforchunkinresp.content.iter_chunked(4096):ifchunk:yieldchunkemotion这个字段是我比较在意的点。深夜电台如果所有话都是一个语气听着像导航。mood从 Step 5 Preview 传下来calm就用平稳语气low就压低一点。但 StepAudio 3 具体支持哪些 emotion 取值、是否真的支持这个参数我这边没有逐个验证你接入时先确认。播放侧我用的是pyaudio边收边写importpyaudioasyncdefplay_stream(stream_chunks):ppyaudio.PyAudio()outp.open(formatpyaudio.paInt16,channels1,rate24000,# 采样率要和你合成返回的一致outputTrue,)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_eventasyncio.Event()self.playingFalseasyncdefspeak(self,text:str,mood:str,api_key:str):self.playingTrueself.interrupt_event.clear()asyncdef_play():chunkssynthesize_stream(text,mood,api_key)asyncforchunkinchunks:ifself.interrupt_event.is_set():return# 被打断立刻停止awaitaudio_out.write(chunk)try:await_play()finally:self.playingFalseasyncdeflisten(self):持续监听用户语音检测到说话就打断当前播放whileTrue:detectedawaitvad.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:float0.3)-str:带权重的情绪更新避免语气突变ifcurrentnew:returncurrent# 简单实现新情绪权重不够就不切换ifweight0.5:returnnewreturncurrent这个实现很粗糙但方向是对的状态要平滑不能每轮重置。这套东西适合什么不适合什么我得说清楚边界。这套方案适合的是陪伴型、低信息密度的对话场景——深夜电台、冥想引导、睡前闲聊。它不适合需要精确信息输出的场景因为我把模型回复限制得很短牺牲了信息量。另外Step 5 Preview 和 StepAudio 3 的具体参数、计费、并发限制这些我都没有系统验证过本文里凡是标了以官方文档为准的地方都请你自己核对一遍再上生产。我写的是架构思路和踩过的坑不是一份可以直接复制的接入文档。如果你也想做类似的东西我建议先从纯文本对话 固定语音播报跑通链路确认对话节奏舒服了再上流式 TTS 和打断。节奏是灵魂语音只是外壳。节奏不对声音再自然也像个念稿机器。
