2026-07-23，我给 MeetingRelay 跑了一场 61 分钟的真实设备会议。那天我关心的已经不只是按钮能不能点、测试能不能绿。我想知道一个更具体的问题：它能不能在一场完整会议里持续听、持续写、持续保存，最后还能把结果拿出来。
那时的 MeetingRelay 是一个给我自己用的 Windows 本地会议转写工具。桌面层用 Tauri，音频从 CPAL/WASAPI 进来，经过 16 kHz 单声道重采样、混音和端点分段，再交给 Sherpa / SenseVoice 做本地 CPU ASR。final 文本必须先落到 SQLite/WAL，UI 才把它当成已保存内容。这个顺序看起来很朴素，但我很在意它，因为会议记录最怕“看起来有，结束后没有”。
这次验收跑的是 package-local personal release，由当时的已验证源码生成。机器就是我平时开发用的 Windows 电脑，模型选择中文，输入来自默认麦克风。整个过程连续运行 01:01:04，麦克风累计 175,902,720 帧。最后 UI 里能看到 25/25 条 final，停止时完成最后一次 flush，队列清到 0，应用回到 READY。
我一直盯着队列。大约第 17 分钟，它短暂顶到 8/8。这个数字出现时，我停下来等了一会儿，没有继续操作，也没有急着判定失败。它没有报应用错误，也没有把尾段吞掉后继续装作顺利。大约一分钟后，队列自己回到 0。第 54 分钟附近又短暂到 1/8，30 秒内清空。对我来说，这比一张绿色截图更有价值：它说明这个链路在压力冒头的时候还有恢复余量。
结束后我按平时真正会用的方式验了一遍。“复制全部转写”成功；同一个快照导出了 JSON、Markdown 和 TXT，大小分别是 7,810 bytes、1,022 bytes、938 bytes。重新打开最近会议后，还是同一个会议快照，还是 25/25 条结果。工作集检查点大约在 362.6-362.7 MB，私有内存大约 331.7-331.8 MB，没有看到持续增长的趋势。
跑完以后我又补了一轮回归：前端 15/15 通过，Rust workspace 96 passed / 1 ignored，Clippy 零警告，Sherpa native smoke、personal release 构建和持续集成检查都通过。自动化测试负责守边界，真实长会负责回答“我敢不敢在会议里开着它”。
这次记录也刻意留下了没有通过的部分。系统输出通道这一轮累计是 0 帧，所以它只证明麦克风长会链路通过，不能拿来证明电脑声音回环可用。代表性会议内容下的准确率和延迟，我也还没有给最终主观结论。英日语质量同样不能从这场中文长会外推。
我现在愿意说：MeetingRelay 的本地麦克风转写、SQLite/WAL 持久化、停止收口、复制、三格式导出和重开链路，已经经受住了一次 61 分钟真实设备会议。剩下的边界继续写在清单里。这样做慢一点，但我以后回头看这段开发记录时，知道哪些结论是真正跑出来的。
后来
8 月我发布了 v0.1.3。识别多了一条 GPU 路径：装好以后可以用 Cohere Transcribe 2B 做高质量识别，SenseVoice 继续作为 CPU 选项；翻译可以接 Ollama、LM Studio 或兼容 OpenAI 的服务，失败时不影响原文；还加了可以拖动、调字号的悬浮字幕。分块识别也从 2 秒临时文字、8 秒定稿收紧到大约 1 秒和 4 秒。
「先落盘、再显示」这条顺序没有变。打包版在真机上的快语速和原生窗口交互还在验收，这次长会留下的那几条边界，我也还没有划掉。