# 录音与转录

围绕团队所需的证据设计录音方案。来电者的回应、语音信箱和双方通话录音是不同的需求。在构建审核流程之前，先确定采集来源及产生该采集的通话。

## 明确录音需求

1. 说明采集目的以及谁需要审核录音。
2. 确定音频来源。检查所连接的应用程序录制的是接收到的音频、生成的提示语还是两者都录制。PBX（企业电话路由系统）或联络中心的录音有其自身的来源和权限。
3. 纳入与对话场景相适应的通知和征得同意的流程。
4. 定义采集窗口、访问权限和保留要求。当工作流要求时，在敏感输入之前停止采集；隐藏按键遥测数据并不会从音频中移除语音内容。
5. 确定工作流是否需要转录。音频采集成功和转录成功是两个独立的结果。

如果你的 PBX 或对话运行时负责录制通话，请明确标注来源系统。迁移电话连接并不会迁移其现有的录音存档。

## 准备受控采集测试

使用团队可控的号码。测试预期的开始、停止和挂断行为，包括在正常采集窗口之前结束的短通话。确认哪个参与者的音频可听到，以及预期的音频是否已保留。

将通话标识和录音标识与结果一起保存。一个会话可以关联多个通话段，但仅凭会话标签无法确定哪个通话段产生了录音。[通话日志](/docs/guides/voice/call-log)提供电话结果。

通过所连接的接口发现工作区可用的录音操作，并在使用前阅读其当前约定。不要从通话记录的读取操作推断录音命令。

## 区分处理状态

分别检查音频可用性和转录处理状态。待处理的转录、转录失败和音频不可用需要不同的应对方式。空文本并不能证明参与者没有说话。

通话可能在处理完成之前结束。在检查产物的后续状态时，保留最终的电话结果。如果已保留的音频过期，重试播放无法恢复它。

当转录内容有歧义时，在可用的情况下审核源音频。姓名、日期和数字可能被错误识别。将重要操作与执行该操作的系统进行核实。

## 审核访问权限和保留策略

使用拥有该产物的系统的权限。与授权同事共享受控的通话引用或录音引用，而不是将音频复制到无关的记录中。将临时播放 URL 视为临时访问，而非持久的存档引用。

检查所使用产物的实际保留策略和过期时间。不要假设通话记录、音频和转录在相同时间段内可用。

## 确认业务结果

将源音频、转录、生成的摘要和业务结果区分开来。摘要可以帮助审核者发现问题；预订、支付或客服系统才能确认操作是否完成。

在审核中记录缺失或不完整的证据。通话完成并不意味着录音存在，仅凭转录也不能证明每个参与者的声音都被采集到。

## 后续步骤

- [通话序列](/docs/guides/voice/call-sequences)
- [通话日志](/docs/guides/voice/call-log)
- [语音事件](/docs/guides/voice/events)

## Related resources

- [What is a voice API?](/explained/voice/what-is-a-voice-api) (answer)
- [Voice](/products/voice) (product)
- [Voice overview](/docs/guides/voice/overview) (docs)

[Get an implementation brief](/learn/workspace?topic=voice)