会话总览 01
从「接管任意视频声音并实时同传」的构想，到可交付的桌面应用；以下数字来自会话运行记录。
≈7.6h累计活跃构建时间
1,614工具调用（Read 575 / Edit 383 / Bash 258）
9 次长上下文压缩（最大 177K tokens）
3 次产品更名：SimulMT → 回响 → 声译
2 次需求方向调整（URL 扩展 → 通用平台）
同一个问题，用户报了不止一次 02
复发 = 前一次修在表象或修错了环境。这是全会话最深的信号。
「本地音视频」点击无反应根因：先用 Chromium 验收通过就交付，但用户用的是原生 WKWebView 窗口；两次修复都改在浏览器链路上
× 3 次环境错配
三档语音策略听感无差别根因：策略参数没有贯通到独立播放器进程，界面选了「保真」，播放器仍在跑默认逻辑
× 2 次链路断裂
刷新后重复加载模型 / 状态丢失根因：界面状态、后端会话、本地持久化三条生命周期各自为政，刷新即重建
× 2 次状态割裂
字幕几个字一断、语速忽快忽慢根因：把模型每 800ms 的翻译增量直接当完整句子送去合成播放
× 2 次语义错位
五个深层问题 03
按代价排序。前两个不伤功能，伤信任。
① 验收环境 ≠ 用户环境，且「已验收」曾被过早宣称
表象11-01 早上称「服务已启动」，用户打不开后承认其实没运行；「本地音视频」在自动化浏览器里通过，在用户的原生窗口里无反应
根因模拟链路 / 构建通过 / Chromium 真机 / 用户原生环境是四个不同等级，交付时未标注等级，默认按最高级宣称
教训：每条验收结论带证据等级标签（模拟／构建／真机-代理环境／真机-用户环境）。用户环境的差异（WKWebView、音频设备占用、辅助功能权限）必须在验收清单里逐项显性核对。
② 流式模型的「上下文」被当成无限资源，10 分钟就崩
表象同传约 10 分钟出现 82% 预警，随后 model stream ended unexpectedly，第 888 个音频回合时 16K KV 耗尽、进程崩溃
根因把 llama-mtmd-cli 当作可以永远吃下去的无状态流；上下文治理（轮转 / 重置 / 采样器清理）在设计阶段缺席，靠崩溃补课
教训：长会话流式系统里，上下文窗口是和时间、内存同级的一等资源。第一版就必须回答：何时轮转、保留多少、如何重置、采样器状态如何清理——而不是等 82% 预警出现。
③ 会话 / 模型 / 上下文三条生命周期绑在一起，缺陷级联
表象刷新页面重复加载十几 GB 模型；换音源混入旧字幕时间轴；翻译方向绑定模型加载；两个「清空」入口逻辑打架
根因三样东西本应独立演进（模型常驻、会话即音源、上下文可重置），早期实现把它们耦合在「一次开始」按钮上
教训：「新音源 = 新会话、方向属会话、模型全局常驻」这三个原则被用户逼问出来之后才确立。它们本应在协议 v1 里就是公理。
④ UI 策略没有贯通到执行链路，功能名存实亡
表象「跟得紧 / 自然流畅 / 完整优先」三档切换，用户实测「都一样」
根因策略只影响模型分段参数，启动会话时没有传给独立的播放器进程；直到 11-02 深夜复查才发现这个断点
教训：任何「用户可见的选项」都要追一条端到端的参数传递链：UI → 控制面 → 数据面 → 执行进程。少任何一环，选项就是摆设。
⑤ 9 次上下文压缩，跨时段恢复靠「压缩摘要」续命
表象压缩点全部落在跨时段恢复任务的时刻；最大上下文 177K tokens
根因三天构建全在一个会话里进行，Read/Edit 的高频往返让上下文持续膨胀
教训：超过一天的长构建，应把进度固化到仓库内的 DESIGN / PROGRESS 文档（本项目已有 LIVE.md 雏形），让新会话冷启动，而不是依赖压缩摘要接力。压缩摘要会静默丢失细节。
做对了什么 04
架构经受住了两次需求转向
事实「URL 浏览器扩展」→「通用音频平台」的方向调整，以及后来的产品化重构，都没有推翻组件化 + 能力协商的骨架，只换了适配器与 UI
启示：先冻结组件边界与协议（v1 兼容升级），再写实现——这是本会话回报最高的一次决策。
修根因，不修表象
事实字幕碎读 → 改为按标点动态组句，而不是加大模型块牺牲延迟；上下文崩溃 → 进程内 KV 轮转 + 重启兜底，而不是盲目调大窗口；TTS 忽快忽慢 → 按说话人语速匹配倍率
启示：用户描述的是症状（「几个字一停」），工程修复要落在产生症状的机制上（调度间隙 + 固定高速 + 积压加速）。
原型先行、评审冻结、再动手实现
事实15:27 要求「先研究功能合理性」→ 三套可点击原型 → 用户选定「回响」→ 当天 19:18 正式落地。返工被压缩到一轮
启示：对「体验对不对」这类无法用测试断言的问题，可点击原型是最便宜的验证器，比先实现再挨批快得多。