MiniMax 的 AI 接口把文本生成和语音合成拆成两类端点，各自独立调用、独立计价。理解这个拆分，接入方案就清楚了：要文字对话走文本端点，要配音走语音端点，两个都要就串起来调。两类端点的关系像前后工序，理解了顺序，参数怎么填也就有了方向。参数细节以官方文档为准，本文讲结构与思路。
两类端点的职责边界
文本端点负责对话与生成，输入消息数组，输出回答文本；语音端点负责把文本转成语音，输入文字与音色参数，输出音频文件。两类端点地址不同、参数不同、计价单位也不同：文本按 token，语音通常按字符数计，具体以定价说明为准。分开设计的意义在于自由组合：你可以只调语音端点转自己的稿子，不必同时调用文本生成。判断你的需求属于哪类端点，看输出物就行：产出文字走文本，产出音频走语音，两者都产出的需求拆成两步分别调。
文本端点的调用要点
文本端点的调用要素与通用对话接口一致：模型名、messages 数组、输出上限。要点在系统提示词的设计：角色、语气、输出格式定清楚，返回内容才稳定。做内容生产流水线时，把格式要求写死在 system 里，比如「输出 JSON，含标题与正文两个字段」，下游解析会省很多事。输出格式用 JSON 还有一个好处：校验容易，格式不对立刻能发现，比在自由文本里找问题省事得多。回答质量不稳定时，先检查 system 是否被后续消息覆盖，system 的权重靠每次请求都带上。
语音端点的参数选择
语音端点重点选三样：音色（平台提供预置音色列表，以官方列表为准）、语速语调、音频格式。长文本要分段送入合成，每段控制在合理长度，再在应用层拼接音频，单段过长既容易出错也更难定位问题。数字、英文、标点的读法先试听一小段验证，尤其价格、日期这类容易读歧义的内容。音色选型先在官方试听页对比，选与内容气质匹配的：资讯类偏沉稳，故事类偏亲切，别只看音色名字。试听时重点听三类词：人名、数字、多音字，这三类读错最影响观感。
一条流程串联两个端点
典型串联是内容播报类应用：文本端点先产出稿件，程序校验格式与长度，再把定稿送进语音端点合成音频。串联时要处理中间态：文本生成失败要中断流程，合成前做一遍格式与内容检查。两个端点的用量分开记录，成本归因才清楚。校验环节用清单：长度上限、敏感词、多音字标注、数字读法，逐项过完再送合成，返工率明显下降。
语音端点合成的人声，商用要注意什么？
- 两类端点能共用一个 API Key 吗？：通常可以，同一账户的密钥按权限覆盖各端点，具体以平台密钥管理说明为准。要按端点分别记账，靠应用层埋点实现。密钥泄露的影响范围覆盖两类端点，轮换密钥时两类调用都要同步更新。
- 语音合成的文本长度有上限吗？：单次请求有长度限制，超长分段合成再拼接，段与段之间留静音间隔衔接更自然，具体上限以官方文档为准。分段点选在句号处，别在逗号或词中间断开，拼接处的语流才自然。
- 先文本后语音，延迟怎么压？：两条路。文本端点用流式输出，边生成边把完成的句子送进语音端点；或者把固定话术预合成缓存，动态部分才实时合成。预合成缓存要设版本管理，话术改版后旧音频及时下线，避免新旧混用。
