我让 Claude 把它的代码改了一下，在接收到 WebSocket 消息时，直接把原始数据输出到一个文件里。
这么一看，又推翻了一些之前的猜想：
1. 转录和润色并没有分开进行（或者至少不是在客户端做两次请求），而是在服务端一次性返回最终结果。
2. 它虽然是流式接收，但并不是流式返回。它有一个 Audio Session Ending 事件，发生之后应该就在服务端开始了润色。
3. 服务端润色完毕后，会再次返回 Audio Processing Completed 事件，然后给出最终的文字结果。
根据上面的这些分析，我们大致可以得出一个服务端工作流程的结论：
1. 服务端采用流式接收，并同步流式发给支持实时转录的供应商接口。
2. 由于服务端实现了实时转录，因此在我们说话的过程中，文字已经逐步转录出来并记录在服务端了。
3. 当客户端结束录音的那一刻，服务端接收到结束消息并停止实时转录，随后将已经转录出的文字进行大模型的润色改写。
所以从停止录音到返回的时间基本上取决于文字的长度，而不是录音文件的时长。例如我刚才测试时，文字较少的情况下，最后两个事件之间的间隔只有2秒；但如果我说一大段话，最后两个事件的间隔可能有4秒。
这么一看，又推翻了一些之前的猜想：
1. 转录和润色并没有分开进行（或者至少不是在客户端做两次请求），而是在服务端一次性返回最终结果。
2. 它虽然是流式接收，但并不是流式返回。它有一个 Audio Session Ending 事件，发生之后应该就在服务端开始了润色。
3. 服务端润色完毕后，会再次返回 Audio Processing Completed 事件，然后给出最终的文字结果。
根据上面的这些分析，我们大致可以得出一个服务端工作流程的结论：
1. 服务端采用流式接收，并同步流式发给支持实时转录的供应商接口。
2. 由于服务端实现了实时转录，因此在我们说话的过程中，文字已经逐步转录出来并记录在服务端了。
3. 当客户端结束录音的那一刻，服务端接收到结束消息并停止实时转录，随后将已经转录出的文字进行大模型的润色改写。
所以从停止录音到返回的时间基本上取决于文字的长度，而不是录音文件的时长。例如我刚才测试时，文字较少的情况下，最后两个事件之间的间隔只有2秒；但如果我说一大段话，最后两个事件的间隔可能有4秒。