逐字稿文字預覽
你有没有过这种很无力的经验? 叫AI帮你整理一份跨部门的会议报告。 做到一半它忘了你要求的章节格式,用语音助手查形成。 旁边同事插句话,它就把指令听成完全不相干的内容。 只要任务超过三个步骤,需要跨两个以上工具,最后交付的结果一定歪掉大半。 你大概也听过很多人说AI已经很聪明了,但真的拿来干活,总是卡在这些最不起眼的小地方。 2026年9月的头两天 Meta接连丢出了两项更新 没有吹什么通用人工智能的牛皮 却精准踩中了这些大家天天吐槽的痛点 一个负责把真实世界里的声音听得更清楚 一个负责把复杂的常任务做得更稳 有人看完数据说Meta终于要在代理人战场超车了 也有人冷静算完成本 发现事情根本没有这么简单 今天我们就不吹不黑 把官方技术文件第三方独立评测 还有那些藏在角落的小字限制 全部摊开来讲 看看这两款产品到底走到了哪一步 又有哪些东西是营销不会告诉你的 我们不从结论讲起 因为真正有价值的判断往往都藏在每一个 但是后面 先帮大家把最容易搞混的产品线界限画清楚 这也是很多自媒体最常讲错的地方 9月1日登场的是Muse Voice Transcribe语音转写模型 9月2日接棒上线的是Muse Spark 1.3代理人模型 两天连续发布核心产品 这在Meta Superintelligence Labs的历史上并不常见 也能看出他们在2026年下半年的竞争焦虑 但更重要的是 很多人到现在还搞不清楚 Muse Spark和Muse Glimmer 根本是两条完全不同的路线 不能混为一谈 Muse Spark走的是云端前沿代理人路线 权重完全必圆 目前只开放API呼叫 官方只说未来有开放权重的规划 但既没有时间表 也没说会用哪种授权条款 所以你绝对不能把它理解成 马上就可以下载来本地跑 而Muse Glimmer是拥有300亿参数 采用Apache 2.0授权的本地方案 主打消费级显示卡就能执行 讲白一点 Spark负责把能力堆到最高 强企业级和高端开发者市场 Glimmer负责把能力扑到最广 占领开源生态和终端装置 这种双轨策略其实刚好对应了Meta在AI产业的定位转变 前几年大家提到Meta的AI第一个想到的就是Lama系列开源模型 靠免费打天下 跟OpenAI的全B原路线正面抗衡 但到了2026年 整个行业的竞争已经从比参数 比跑分 进到比代理人 比落地场景的阶段 Meta必须拿出足够强的B原顶端产品 才能跟GPT系列 Gemini系列抢商业客户 同时又不能丢掉开源生态的优势 为什么要花这么多时间讲这件事 因为如果你误以为 Spark 1.3是开源模型 就会产生错误的部署预期 如果你以为Glimmer只是Spark的缩小版 就会低估两者在设计目标上的根本差异 另外从迭代节奏来看 Muse系列从7月的1.1版 首次连上邮件行事例 并能制作投影片到8月初1.2版聚焦大型程式库与复杂真错 甚至能连续1000多次工具呼叫 在24小时内反复编写编译GPU核心程式 8月中再加入图像与视频理解能力 到9月的1.3版转向打磨长期任务的可用性 几乎保持每个月一次大版本更新的速度 这种快速迭代在AI圈不算稀奇 但难得的是Meta几乎每一版都会附上明确的内部对比数据 同时引用第三方评测结果 给了外界一个相对透明的观察窗口 很多人只盯着分数涨了多少 却忽略了每一代版本的定位差异 Spark 1.3并不是全面碾压1.2的终极进化 而是针对代理人任务的可靠性做了针对性强化 甚至在部分涨上下文指标上还出现了小幅退步 这种有得有失的升级 恰恰说明模型能力不是简单的线性叠加 而是一连串的取舍与权衡 如果你只看营销文案里的亮点 很快就会在实际使用中发现落差 如果你翻完这次的全部技术文件 会发现最核心的关键词 不是更高的分数 也不是更多的参数 而是长任务代理人 什么意思 就是让AI不再只是一次性回答一个问题 而是像一个真正的执行助理一样 接下一个模糊的需求 自己拆解步骤 呼叫工具 遇到问题回头问你 碰到危险操作 先停下来确认最后再交付完整的成果 这听起来很美好 但过去大部分代理人模型的问题无非三种 要么不敢动手只会空泛回答 要么乱动手做到一半偏离目标 更常见的是干到一半彻底忘了最原始的要求 Spark 1.3就是冲着这些痛点做的优化 举个很实际的场景 如果你跟模型说 帮我整理上礼拜的三场客户会议记录 做成部门简报 把每个客户的行动项列出来 最后寄给主管 换做之前的模型 很可能做到一半就忘了要按客户分类 或者漏了寄信的步骤 甚至为了凑数编造几个不存在的行动项 而Spark 1.3的处理逻辑会完全不同 一开始如果觉得需求不够清楚 它会主动追问你 简报要的是正式版本还是讨论版 行动项要不要加上预计完成时间 寄信的时候要不要附上原始记录档 执行过程中如果发现某份会议记录打不开或者权限不足 它会停下来跟你要资讯 而不是硬着头皮编一个结果 如果碰到删除档案 发送批量邮件 修改正式环境设定这类有不可逆风险的操作 它一定会先跳出确认 问你确定要执行吗 不会自己直接动手 更重要的是 它能分辨你现在是在补充当前任务的资讯 还是要打断手头的事做别的 又或者是要开启一个全新的任务 这听起来好像是基础能力,但在多轮对话里,很多模型会把用户随口的插画当成新指令,直接把之前的上下文全部覆盖掉,导致任务做到一半就断了。 针对长期任务最常见的约束遗忘问题,Spark 1.3也做了专门强化。 比如你一开始就说过 所有输出都要用正体中文 不能用外部图片素材 数据不能超过指定范围 他会在整个执行过程中 反复检查这些条件 而不是跑个五六步之后就全忘了 最关键的一点 是他对自身能力边界的判断 过去很多代理人模型 最危险的习惯 就是任务做不完的时候 会假装做完了 然后生成一份 看起来很完整的报告 里面全是编造的数据和结论 普通用户根本看不出来 Bug1.3在训练时特别强化了这点遇到做不到的地方 他更倾向于直接说 我卡在这里了 我缺少这个资讯 而不是硬凑出一份看似完美的答案 Meta内部工程师对比1.2版本后发现 新版本平均减少了20%的工具呼叫次数 同时减少了25%的token消耗 这两个数字其实比跑分更有意义 工具呼叫减少代表模型更清楚 什么时候该用什么工具 不会无脑尝试所有选项来回绕路 Token消耗减少 代表推理效率提升 单位任务的成本直接下降 很多人不知道代理人任务的成本 通常是纯问答的3到5倍 因为要不断多轮推理 呼叫工具修正路线 所以效率的提升 直接决定了这项技术 能不能大规模商业化 不过也要说清楚 这两个数字是Meta内部测试场景下的结果 不是第三方独立评测 实际业务中因为场景更复杂 不一定能复现同样的比例 官方也举了几个典型的常任务场景 官方也举了几个典型的常任务场景,比如工程领域的CAD模型搭配流体模拟数据。最后按指定章节输出PDF报告,音乐制作领域根据时间码定位错误音符,从重复段落里挑出合适的替代片段。 保持所有音轨长度不变 再重新混音 这些场景的共同点就是步骤多 中间产物多 需要跨工具协作 差一步整个结果就不能用 从这个角度看 Spark 1.3根本不是一个聊天更厉害的模型 而是一个干活更稳的模型 它的评价标准早就不是会不会写诗 能不能解数学题 而是能不能在100步之后 还不偏离最初的目标 聊完了官方自己讲的升级 我们来看看第三方独立评测的数据 验证一下这些能力到底有没有落到实处 这次的数据全部来自Artificial Analysis 这是目前业界专门做代理人模型评测的独立机构 不是Meta自己跑的分 参考价值相对高一些 在他们的综合智慧指数榜单上 Spark 1.3的Shy版本拿到61分 还在有限预览阶段的Max版本拿到62分 比起1.2版本的57分 Exia整整涨了4分 在AI评测里 4分的涨幅算不算大 要看在哪个区间 如果从30分涨到34分 那只是入门级的进步 但从57分涨到61分已经是第一梯队模型的明显提升 因为越往上 每一分的难度都越高 更有竞争力的其实是成本XJ版本完成一项综合指数任务 平均花费0.55美元 在所有得分超过59分的模型里是最低的 我们可以简单对比一下 同级别里 OpenAI的GPT-4O Advanced 做类似任务 大概要1.2美元 Anthropic的Cloud Opus 则要1.5美元左右 Meta差不多只要一半的价格 这对于需要大量呼叫API的企业用户来说 吸引力非常大 我们再拆开看具体任务的表现 Tile3-Bench Banking 是专门的银行代理人基准测试 模拟金融场景下的多步骤任务 1.2版本 当时只拿到35%的通过率 SHAE版本提升到47% MAX版本更是达到52% 这个涨幅其实相当惊人 说明模型在处理合规 要求高步骤繁琐的金融任务时 可靠性比上一代强了很多 但也要客观说 47%的通过率 依然代表超过一半的任务 没办法完美完成 距离真正取代人类专员 还有非常远的距离 大概相当于入行半年的助理水平 Terminal-Bench 2.1是终端指令执行测试 1.2版本通过率80% X-Shy提升到85% Max到86% 这个分数看起来很高 但终端任务相对结构化 指令对错的标准很明确 能拿到高分并不意外 参考价值不如真实工作场景 真正值得注意的反而是一项退步的指标 AA-LCR长上下文基准 1.2版本有83%的正确率 1.3版本降到了79% 为什么长上下文能力反而退步了 难道模型越更新越差吗 当然不是 背后的原因是Spark 1.3调整了策略 遇到不确定的资讯 它更倾向于拒绝回答 而不是硬猜一个答案 也就是说它宁可少说几句 也不说错话 这种策略在AA-Omniscience准确率指标上 也能看出来 表面上准确率小幅回落 但幻觉率明显降低了 这其实是一个非常重要的取舍 你要更高的召回率 还是更高的准确率 对于普通用户来说 可能希望AI什么都能答 哪怕错一点也没关系 但对于企业用户 尤其是金融 医疗 法律这些领域 一个错误的答案 代价可能比没有答案大得多 之前就有企业用初代代理人模型 处理报销审核 结果模型编造了很多不存在的单据 造成了不小的财务漏洞 所以现在越是面向企业的模型 越把不编造放在比达对更高的优先级 从这个角度看 这项退步反而是一种进步 代表模型开始往实用化的方向走 而不是为了跑分应凑答案 另外很多人忽略的一点是 MAX版本的分数虽然更高 但代价是运算算力大幅增加 根据Artificial Analysis的测试 在GDPVAL-AAVFE任务里 MAX版本比SY多消耗约62%的推理量 就算是银行代理任务 也多了28%的算力 为什么会差这么多 因为MAX版本会做更多的自我检查 走更多的思维步骤 相当于人做事情的时候反复检查好几遍 自然更费时间更费算力 但正确率也更高 这其实带出了未来AI商业模式的一个可能方向 以后的模型不会只有单一档位 而是会根据任务的风险等级调整推理强度 低风险的闲聊 查资料用低档速度快又便宜 高风险的财务 法律任务用高档 更慢 更贵 但更可靠 用户可以按自己的需求选 而不是为了偶尔的高需求 全程付最贵的价格 当然 目前这还只是观察 Meta并没有正式推出这种分级定价 但从技术设计上 已经具备了这样的基础 最后 还要再强调一次 Max版本目前只是有限预览 只有少数合作机构和企业能拿到权限 普通开发者根本呼叫不到 所以你看到62分那个数字的时候 要知道它背后是更高的成本 更严格的访问限制 不能拿它去跟别人全面开放的API比 然后说Meta已经赢了 这种对比并不公平 看完了负责思考和执行的大脑 我们再转过头来讲这次连发的另一款产品 负责感知输入的耳朵 Muse Voice Transcribe 很多人第一眼看到它 会觉得不就是个语音转文字吗 有什么特别的 但实际上它的设计思路 跟传统的自动语音识别完全不一样 传统的ASR比如Whisper 走的是离线转写路线 拿到整段音频之后再慢慢处理 可以利用上下文反复修正 准确率很高 但延迟也大 根本没办法用来做实时对话 而以前的实时语音助手 比如手机上的Siri Google助理 为了追求低延迟 只能听一小段就马上输出 结果准确率很差 稍微吵一点 有两个人叠话或者混个外文单字 结果就歪掉 Muse Voice Transcribe想解决的 就是又要准又要快 还要懂真实对话这个老难题 它的做法是把音频切成80毫秒的小块 每秒处理12月5日次 每一小块音频先转换成一个软Token 模型在判断是要继续等后面的声音 还是立刻输出文字 等到音频完全停止 系统会加入一个特殊标记 让模型把剩下没输出的文字一口气吐出来 其中最关键的技术叫做自适应延迟 模型不会给每个字都设定一样的等待时间 简单确定的内容就立刻输出 碰到需要后文才能判断的同音词 专有名词 就稍微多等一点点音频再决定 这其实很像人类的同步口译 译员会根据句子的难度 调整自己的滞后时间 不会一味求快 也不会一味求准 训练的时候 Meta把词 错误率和延迟时间 一起放进强化学习的奖励函数里 如果模型只追求准确 每句话都等很久 得分不会高 只追求速度 输出一大堆错字同样过不了关 最终目标就是在准确率和反应速度之间找到最佳平衡点 那实际表现如何 在Artificial Analysis的流逝语音榜单上 Muse Voice Transcribe的最终词错误率约3.1% 直接登上第一名 这个数字是什么概念?在流逝实时的场景下,3.1%已经非常接近人类专业数据员的水平,人类大概是2%到3%左右,相当于每讲100个字只错3个。 不过这里必须先打个预防针 这个成绩是英语流逝对话的测试结果 绝对不能直接套用到所有语言 所有场景 中文因为同音字多 声调复杂 同样的模型词错误率通常会比英语高2到3个百分点 如果是嘈杂环境 多人强化 或者带方言口音 表现还会再打折扣 官方也明确说 模型训练覆盖了70多种语言 其中只有25种经过充分验证 其他语言可能只是有训练过 但没有经过严格的效果评测 除了基础的转写准确率 还有几个功能特别值得一提 首先是原生的说话人分离 而且支持20人以上同时发言 传统的会议转写通常是先做语音识别 再另外用一套声文系统 判断每段话是谁说的 两个系统的时间轴 只要差一点点就会出现文字 人认错的情况 Meta是在同一个生成过程里 加入说话人切换标记和身份标签 检测到换人就先标一轮新发言 等听到足够声音再确定身份 时间轴的准确度会高很多 官方展示的长对话里包含多人插话 重叠发言 自然停顿
本次執行流程與問題處理
下達指令
預期流程
- 下載與語音辨識
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：382.0 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：53.6 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.7 秒
關係：依序執行
結果：完成
4. 句子密度平衡
工具：videonote_balance_sentence_units.py
處理：平衡句子長度與密度
產出：sentence_units.json（句子單元）
耗時：0.7 秒
關係：依序執行
結果：完成
5. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.8 秒
關係：依序執行
結果：完成
6. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.8 秒
關係：依序執行
結果：完成
7. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.8 秒
關係：依序執行
結果：完成
8. 逐字稿交叉檢查
工具：videonote_cross_check_transcript.py
處理：交叉檢查逐字稿與來源字幕
產出：transcript_crosscheck_report.json（交叉檢查）
耗時：0.9 秒
關係：依序執行
結果：完成
9. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.9 秒
關係：依序執行
結果：完成
10. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：174.9 秒
關係：依序執行
結果：完成
11. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：1.0 秒
關係：依序執行
結果：完成
12. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：1.0 秒
關係：依序執行
結果：完成
手動來源字幕
- 尚未產生
自動來源字幕
Whisper 字幕
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.whisper.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- 逐字稿可先使用，但有待校正清單
segment=596 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。