Step Audio 3 这类转写服务负责把音频变成带结构的结果，业务侧负责把结果改成业务上正确的内容。两件事交付物不同，验收方式也不同。搞反的典型表现是：业务同学抱怨「转写不准」，转写侧却拿不到任何可改的输入；或者业务侧改完只留一份成品文本，改了什么、为什么改，没人能复现。先把交接物定下来，争论才有落点。
把分工按交付物切开：转写侧交付带字段的转写结果，验收看字段是否齐全、时间戳是否对齐、音频是否被完整覆盖；业务侧交付校对表，验收看每条修正是否都有原文定位、修改原因和修改人。适用于转写后需要人工复核的流程。转写侧不对专有名词、同音字和语义正确性负责，这部分只能由业务侧在校对环节判定。
把一次转写的输出字段列全
交接不能靠口头描述「返回的那些东西」。建议在转写侧和业务侧之间固定一个交付包，字段按实际返回内容填写，接口没返回或暂时不确定的，统一写「待确认」，不要凭印象补。下面是一份通用骨架，字段名按你实际接到的响应替换。
{
"segment_id": "seg-0001",
"text": "这一段的转写文本",
"start_ms": 0,
"end_ms": 3200,
"speaker": "spk_1",
"language": "zh",
"confidence": null,
"model": "step-audio-3",
"request_id": "...",
"audio_ref": "meeting-01.wav"
}用途说明：segment_id 是后面校对表关联的主键；start_ms/end_ms 用于回听定位；speaker 通常只是聚类标记，不等于真实身份，映射到人名要业务侧做。验证方式：挑一条音频重新跑一次，把接口响应和交付包逐字段比对，缺哪个补哪个，比不出来的写进待确认清单，不要留在聊天记录里。
划出转写侧能保证与不能保证的部分
责任边界写清楚，归因争论会少很多。下面两组清单建议直接放进交接文档，每项都配上验证方式。
转写侧能保证的（可验证）
- 音频可解码、时长与分段覆盖：用
ffprobe看音频时长，与最后一段end_ms对比。 - 时间戳单调不重叠：脚本检查每段
start_ms < end_ms，且下一段start_ms不小于上一段end_ms。 - 文本非空：过滤
text为空或只有标点的段，计入待确认。 - 字段完整性：按字段清单逐项判断是否为 null 或缺失。
- 接口层可追溯：
request_id、状态码、错误信息能在日志里查到。
转写侧不能保证的（只能由业务侧判定）
- 专有名词、品牌名、人名拼写：业务侧对照术语表核对。
- 同音字、多音字在具体句子里的正确写法：看上下文，由业务侧决定。
- 说话人归属的业务正确性：转写侧给的是声纹聚类，谁是「张经理」需要业务侧映射。
- 数字、金额、日期的业务口径：听到的读音是转写结果，格式化成什么要业务侧定。
- 断句和表达是否符合业务习惯：只能通过人工抽样比对发现。
验证方式上，前一组可以用脚本和日志自动跑；后一组没有自动判据，只能体现在校对表的修正记录里。把这两组混在一起谈，就会出现「模型不准」和「流程不对」互相甩锅。
定义业务校对的输入与输出
输入是两样东西：字段齐全的转写交付包，以及校对规范（术语表、修改原因枚举）。输出不是一份改好的文本，而是三样东西：修正后文本、校对表、未决项清单（听不清或需要业务确认的段）。
segment_id,原文,修正,修改原因,修改人,修改时间,状态逐列用途：segment_id 指回转写结果，保证改动可定位；原文 建议原样拷贝，不要边改边覆盖；修改原因 用固定枚举，例如 同音字 / 专有名词 / 标点断句 / 说话人 / 漏字多字 / 听不清待确认；修改人 用于回溯口径差异；状态 区分已确认和未决。不要让人自由填写原因，否则后面统计不出来，也没法判断该改转写配置还是改业务术语表。
定一条验收口径并连续跑三次
抽样方法和统计方式要写成文字，而不是留在某个人的习惯里。抽样建议按时间分层：每隔固定时长取一段，或者用固定随机种子从 segments.jsonl 里抽固定条数，条数先定一个团队能承受的值，写进文档。
python3 - <<'PY'
import json, random
rows = [json.loads(l) for l in open('segments.jsonl', encoding='utf-8')]
random.seed(42)
sample = random.sample(rows, min(50, len(rows)))
with open('sample_run1.jsonl', 'w', encoding='utf-8') as f:
for r in sample:
f.write(json.dumps(r, ensure_ascii=False) + '\n')
PY统计方式：按校对表的「修改原因」分类计数，输出每类条数和未决条数，不要只给一个总数。三次的安排可以是：第一轮固定种子抽一批，第二轮换种子抽同样条数，第三轮让另一位执行人用同一脚本重跑第一轮的样本。对比记录表建议如下，跑完三次再判断口径是否稳定。
轮次,抽样文件,样本条数,同音字,专有名词,标点断句,说话人,漏字多字,听不清,执行人如果三次的分布方向差异明显，先怀疑抽样和判定标准，再怀疑转写配置。风险边界：小样本只能反映被抽到的部分，不要用它去推断整体质量，也不要把单次结果当成长期结论。
把反复出现的争议项写回流程
同一个争论出现第二次，就应该写进文档而不是继续在群里讨论。争议记录建议用固定格式：
争议点,出现位置,次数,当前处理,判定人,记录时间,状态写回位置分三处：属于术语和表达习惯的，写进校对规范文档的争议项附录；属于字段缺失、时间戳偏移、说话人标记这类接口问题的，写回转写交付包的字段说明，标注为待确认或已知限制；涉及判定人的决定，写进验收记录，方便下一轮复用。触发重新评审的条件建议明确列出来：同一争议在两轮验收中重复出现；转写接口字段或模型版本发生变更；业务术语表更新；未决项条数超过团队事先约定的阈值。阈值定多少由团队按自己的复核能力约定，写进文档即可，不要拍脑袋。