一份虚构家具店录音稿中，说话人零说“我去确认星期五能否送货”。摘要却变成“店长已承诺周五送达”。这里跨过了两道未经核实的门：这是谁，以及他说的话是否构成承诺。本文是一张录音稿编辑单，不是实际录音分析。先保留匿名说话人标签，不要直接把摘要写进客户订单。

Amazon Transcribe 的说话人分离功能会给不同说话人的文本分配独特标签，并提供发言时间段。[1] 文档示例里的 spk_0 是输出标签，不是员工账户。我们的使用建议是把“这个声音分到哪组”和“这位员工是谁”分开记录；不因出现顺序、座位或某个名字被提到，就自动认领身份。

AWS 的输出说明包含逐词时间和置信分数。[2] 这些字段可帮助定位核对，却不是业务承诺的批准记录。即使“确认”这个词被正确转写，也不能把“去确认能否送货”改成“已确认送货”。这是我们对业务使用的分析：把原句、解释和确认状态放在不同字段，不用一个漂亮摘要覆盖三者。

我们建议每条重要结论附上受控录音引用、起止时间、原始标签、经人工核实的姓名及核实人。姓名不确定就留空，重叠发言或听不清就标待核对。只在已获录音与使用许可的范围处理资料，并限制访问和保留时间。不要为了让更多人复核，把整段客户录音散发到无关群组。

这家虚构店的安全改稿是：某位尚未核实身份的参与者提出去确认周五能否送货，交期仍待负责人确认。复核者应回听相关片段，必要时询问参与者；身份确认后，再单独确认交期权限和结论。更正姓名也要重查基于该姓名生成的任务，而不只是修正文稿中的一个字。

本次建议验收分别看文字、说话人对应和业务含义。用已授权的短片段，请复核者检查否定句、条件句、插话及身份未明的片段；记录纠正和未解决项。这里未做真实录音测试。上线前确定谁能确认身份、谁能批准承诺，以及错误如何回传，才能让自动摘要成为协助，而不是替人认领责任。