会议录音转行动项：用 Scribe 转写，并保留可核查的时间出处

可靠的会议处理流程应分开保存录音、逐字转写和带出处的行动项草案。摘要写得流畅，不等于忠实保留了原话；JSON 里出现一个任务，也不等于负责人已经确认，或项目系统已经创建工单。

本文通过 Ofox，用 elevenlabs/scribe_v2 转写一段 43.92 秒合成录音，再把含词时间戳的结果交给 openai/gpt-6-luna。脚本特意包含明确分工、无人负责的事项、未定发布日期和未批准预算。文本模型返回草案与待确认问题，没有发送消息或创建外部任务，原始文件和响应可下载。

会议内容是原创虚构场景，声音由语音模型生成。名字不是实际参会者，也不是验证过的声纹身份。API 调用真实，不代表会议真实，更不证明系统已解决真人会议噪声或多人分离问题。

先规定什么叫可审核的交付

最小交付包应包含原录音、原始 ASR、修订后的转写、带引文和时间的行动项、未决问题及审核结果。不同阶段分开保存，避免后续编辑覆盖模型真正返回的内容。

一个任务不能只有漂亮的一句话，还要分清事项、负责人、日期和批准状态。没有证据的字段保留 null 或“待确认”，不能为了填满表格而猜测。

工具包包含 meeting-script.txt、合成会议音频、meeting-transcript.json、extract_actions.py、提取请求和原始结果。无需上传真实私人会议，就能检查这条链路。

虚构会议合成音频

1. 使用获授权素材，保留时间线

真实工作录音要遵守组织对录制、存储和访问的要求。不要因为模型可能需要上下文，就顺带上传密码、访问令牌或无关个人资料。

本次 Ofox 路由接受 WAV、MP3。转换视频时保存原件，记录选用了哪个音轨、是否裁掉开场；后面的每条引用必须指向正确时间线。

示例脚本生成一段 43.92 秒 MP3，故意区分这些句子：

• Leo 在 2026 年 10 月 15 日前检查 API 示例。
• 日语旁白还没有负责人。
• 发言者不能批准生产发布。
• 发布日期未定，确认前不要发邀请。
• 讨论过 30 美元测试预算，但没有批准。

这些差异就是测试重点。丢掉“不要”后提取“发邀请”，或把讨论预算写成费用已授权，都会产生看似合理却错误的工作清单。

2. 用 Scribe 转写，保留原响应

设置 OFOX_API_KEY，安装 requests、FFmpeg 和 ffprobe，在工具包目录运行：

python3 audio_api.py transcribe \
  --input meeting.mp3 \
  --output my-meeting-transcript.json

客户端通过 multipart 调用 /v1/audio/transcriptions，模型为 elevenlabs/scribe_v2，格式为 verbose_json。先查 Ofox Scribe 模型页，不假定原生供应商的所有参数都经此路由开放。

编辑前保存原文件。本例 JSON 含完整文本及词起止时间，把口语日期规范化为“October 15th, 2026”。这不代表模型知道任意会议的当前日期，也不能推出“下周五”总能被安全换算。

录音 43.92 秒，末词结束于 43.74 秒。文件时长、末词终点和用量分别保留，不能用其中一个数替代另一个，更不能直接推导结算金额。

接口失败时保存错误和请求 ID，不把错误正文当转写交给后续模型。只有文本、没有时间时可以做摘要草案，但不能声称已经具备核实过的时间出处。

3. 优先复核影响决策的词句

先查姓名、日期、数字、否定词和权限表述。本文有原创脚本可供对照；真实会议中录音仍是主要证据，幻灯片、议程和旧记录只能辅助理解术语，不能悄悄改写讲话内容。

校对记录包括原 ASR、修订词句、时间区间、理由和审核者。听不清就标注不确定，不能因为某人靠近发言位置，或平时负责类似工作，就把任务自动分配给他。

本次响应没有验证过的说话人标签。“Leo speaking”是脚本故意念出的内容，不是声学系统证明某位员工发言。后续提示词明确禁止据此推断真实身份。

真实多人会议的打断、争论、重叠发言需要另外评估。单一合成声音的短样例没有测试噪声、口音、串音和多人交叠，不能将结果推广到所有团队会议。

4. 要求文本模型返回带证据的草案

提取阶段同时输入文本和真实词数组，要求仅使用这些资料，保留未知值、否定约束，区分承诺和建议，不发送消息、不操作项目系统。

完整请求见 actions-request.json，核心规则如下：

只使用提供的 ASR 文本和词时间戳。
返回 actions、decisions、open_questions。
每项包含 task、owner、due_date、status=proposed、
原文 supporting_quote，以及对应词的 start/end 秒数。
未知字段为 null，区分承诺、提议与否定表述。
不要根据念出的姓名推断声学身份。
不要虚构批准，不发消息，不创建任务。

工具包的 extract_actions.py 使用 openai/gpt-6-luna 调用 /v1/chat/completions，保存原结果。发现 actions-response.json 已存在会停止；若有意再次付费调用，使用独立工作副本或明确版本化输出。

示例通过提示词要求 JSON，没有声称 API 强制执行了结构化输出 schema。正式系统仍须解析、验证字段；“看起来像 JSON”不等于通过业务校验。

换一场会议时明确修改输入文件，并保存提示词版本。格式完全正确，但读的还是教程录音，得到的仍是错误交付。

5. 检查实际结果，也保留不完美之处

样例把 actions 分成 commitments、proposals、negations，并返回 decisions 与 open_questions。所有行动状态均为 proposed。一次输出的嵌套结构不应被当成模型未来必然遵守的固定协议。

模型还把“I can review the example”列为另一项建议，可能与 API 检查重叠。导出前应判断是否同一件工作，不能因为两条引文都真实，就自动生成重复任务。

样例 decisions 为空，预算保留为未决事项，没有杜撰批准。但这是精心设计的短例子，不是实际会议中永不犯错的证明。

一种合理人工整理方式是：保留明确的 API 检查，将产品演示保留为无人负责的提议，保留三个待确认问题，把不发邀请作为约束。该整理与原始 actions-response.json 分开，不能覆盖原结果。

6. 校验引文、时间和未知字段

先做确定性检查：解析 JSON、核对必需字段、拒绝异常时间。引用区间既要在录音范围内，也要对应引文首尾词；一个数字没超出总时长，并不证明它指向正确句子。

将引文与转写匹配，若规范化空白和标点，记录规则。不要采用过宽的模糊匹配，把“批准”和“没有批准”当成相似可互换。预算引文必须保留否定批准的后半句。

再审语义。真实引文也可能支撑不了模型结论。“不能批准生产发布”是限制，不是上线许可；“日期未定”不能被另一项任务的截止日填补。

界面上保留未知字段。负责人为空，不自动变成上传者、主持人或第一个出现的名字；没有期限，不默认今天。下游工具强制要求这些字段时，先进入待审队列，不为满足表单而编造数据。

7. 提取与创建任务分开

本文停在草案，不建工单、不发邮件、不加日历。即使两个 API 都是 HTTP 200，识别和解释仍可能出错。

连接项目工具前，规定谁批准、看哪些证据。把引文、音频时间与建议负责人、日期放在一起，记录接受、修改或拒绝，并将外部任务绑定已审核版本。

真正创建任务时使用去重或幂等标识，例如审核后的会议版本加行动项 ID，避免重新总结就重复建单。修改任务也应先检查变化，不悄悄覆盖之前已确认的承诺。

会后人员改变决定，属于后续任务历史，应保存新的来源，不能反写到逐字稿里，造成当时已经说过的假象。

8. 按环节排错

转写失败检查格式、认证与具体错误。本项目曾遇到上游额度问题，恢复后通过新请求确认可用；钱包余额本身不足以诊断路由。

转写不全先查音轨、输入录音及上传是否完成。文本模型输出 JSON 不合法，保留原结果，修复提取或解析环节，不必重新上传同一段音频。

模型猜负责人或日期时，加强证据约束并复核实际样本。提示词更长不保证服从，要用无人负责、暂定日期、否认批准及互相矛盾等测试案例检验流程。

长会议分段要保留偏移，处理重复与后文推翻前文的情况。工具包是透明的短录音示例，不是完整的长会议编排系统，不宣称未经测试的时长上限或跨会议记忆。

9. 衡量可用结果，而非摘要长度

记录多少条原样接受、修改、拒绝或合并，并记录审核时间和人工发现的漏项。生成了多少条 bullet，远不如这些指标有意义。

成本上分开记录 ASR 秒数与文本 token；元数据有助于匹配账单，但不把未经对账的估算写成真实发票。

真正完成的标准是：可追溯、经过审核、未知值保留的工作清单。如果摘要丢掉邀请限制或虚构预算批准，即使漂亮简短，也没有完成任务。