ai浪潮下的产品实践：言录的开发实录

我曾有个代码洁癖：如果一个github项目的贡献者里出现claude bot，我会觉得这是一个不可靠的产品，因为它或许来自一个刚刚学会vibe coding的开发者，不了解软件工程或者设计模式，这会让我有一种莫名其妙的优越感。

这个洁癖显然是狭隘的，并且我自己本身也不是一个高明的程序员，因此面对效率又快又好的ai，我很快接受了它，无论是coding，分析还是炒股，我都下意识的向ai求助，这从我的token消耗上就可见一斑：

前两天看了一个访谈，主持人采访的是某个大学的软件工程院长，问他：面对ai浪潮，软件工程会感到压力吗？院长的回答是：在ai时代，教学的内容不再是怎么写代码，而是为什么要这么写。他以照相机的普及为例，说人人都能拍照，但是还是需要专业的人去学习拍照，表达他们想表达的东西。对此我深以为然，刚好最近在高强度ai coding，这在某种程度上也体现了ai在当下软件开发中的作用，因此就有了这篇内容。

关于会议转写

7月中的时候，去了一次北京见客户。由于有会议纪要的需求，我在网上找了一些相关的会议纪要和转写应用，其中很有代表性的是meetily，讯飞听见和飞书妙记，其中meetily是开源项目，另外两者或多或少都需要付费使用。

从个人体验上来看，飞书妙记的给我的体验是很好的。它在页面上登陆，不需要下载应用，支持多种语言，人声识别精确，并且支持很高质量的图文ai会议纪要。美中不足的是，它不支持字幕翻译，并且智能会议纪要和识别录音都有时长限制。reddit论坛上有不少国外网友提到它，并寻求免费替代产品。

讯飞听见跟飞书妙记差不多，支持应用和页面识别，还支持手机端使用，除了需要付费以外，使用门槛很低，上手也没有什么复杂度，体验感很流畅。它和妙记一样，都是走的websocket，通过api转写内容，所以使用过程中都需要联网，而且也不支持字幕翻译。讯飞听见的智能纪要支持富文本和纯文本，第一时间观感很不错。

meetily则是一个开源软件，github上有近3w个stars。由于免费，我是最早体验它的，不过主要是和海外开发者开会的时候用于记录。它走的是本地部署的转写模型，并且同样支持ai智能转写。在初次安装时，要求下载转写引擎和本地的ai模型。根据文档描述，它用的是Nvidia的Parakeet 0.6b和whisper作为转写模型，这两个的强项都是英语转写，因此对中文的体验并不是很好。ai模型使用的是qwen3.5和gemma3，从分析效率和效果上来看，没有出现严重的幻觉问题。

从使用体验和成本的考量上，这三者都或多或少有一些不太满足我的地方：我更习惯买断制而非订阅制，而市面上并没有特别出彩的中文买断制会议纪要软件，更重要的一点是，好久没有折腾东西了，想做点应用体会一下开发的乐趣。

说干就干

说干就干，我迅速整理了一下需求文档，我想要做的是一个桌面会议转写应用，它需要满足以下几点：

支持实时转写
支持ai会议纪要
支持多语种和翻译
支持配置热词
性能要求低，需要控制能耗

这就是最初的设计文档：

我显然不会自己上手写代码：我上一次认真的coding，还停留在2025年10-12月，那时我还在折腾nextrec。于是我先从后端做起，在一开始我想做的是macos的原生应用，复刻meetliy的架构，用js+rust的架构实现。最初的版本里，由于性能的考量，转写引擎使用的是whisper.cpp，思路是vad识别间隔，然后调用whisper进行高频的转写。

在使用codex高强度vibe了好几天以后，我得到了第一版demo，一个奇丑无比的东西（我实在无法将它称之为应用，并且我没有保留它的其他任何截图）：

显然codex的默认审美非常差：参数外露，没有任何美观的配色和样式。但是比审美更差的是这套转写引擎。由于只是最简单的vad检测+转写，每次都会重新加载模型和推理，加上中文识别的效率很差，直观的体验就是字幕响应很慢，语音开头会被截断，且识别精度很差。

受此重挫，我删除了项目，然后整整2周没有再打开codex。

sherpa-onnx与二度尝试

本来这个想法在尝试后，已经被我打入冷宫，不过在2周后的一天里，我刷到一篇有关asr的综述，它在文中提到了FunASR，一个开源的人声识别工具箱，支持各种开源模型，流式输出，人声识别等功能，不过它是python写的。再次之前，我对于python的部署体验不是很好，这可能和我主要使用fastapi写服务有关，它并不适合打包成常规应用。并且它基于transformers实现，我对它的性能并不抱期望。

在某篇帖子里，有人拿funasr和sherpa-onnx进行了对比，在简单看了下后者的项目描述后，我很快又燃起了动力：sherpa-onnx是一个很全面的项目，首先就是用的都是量化模型，并且支持的model list很广，也支持各种asr相关的api，降噪，vad，流式字幕等等。开源社区里已经有一些高热度的转写项目使用它作为后端。

有了后端引擎，剩下的就是前端设计。有了上次的教训，我在写后端之前就设计好了ui风格，整体少即是多的简洁设计，留白，线条划分。抽了几次卡以后，这回总算是有了应用的设计风格了。

有了codex以后，开发变得轻松很多，我只需要给需求，然后定期让模型做代码审查和性能压测，代码清洗和整理，这个流程下基本可以一定程度的控制技术债的产生。捣鼓了大概一周，8月1号，发布了第一版言录。

踩坑的道路

应用发布的第一个障碍是签名，macos还是windows都对应用有签名要求，未签名用户会在macos上直接报错，需要去终端操作才能使用。这对用户体验是致命的，但是前期我还没有下定决心把这个应用当成真正的产品做，于是纠结要不要花钱申请apple开发者资格。在纠结的那几天里，刚好赶上股票里赚钱了，这成为了我申请apple开发者的临门一脚，哈哈。

在版本更迭的路上，我逐渐遇到和修复了很多bug。

关于应用权限请求

在刚开始的几个版本里，权限申请始终有问题，问题集中在屏幕录制权限和麦克风权限的请求始终有问题，用户首次打开应用时始终没有弹出选项设置框，需要手动去设置里对应用开放权限。最终发现是主进程的权限请求被ui阻塞了。

关于windows

刚开始的版本里，windows用户点击应用图标后会闪退，原因是windows默认的gbk编码，导致加载带中文的json时会无法解析。并且麦克风权限检测也有问题，显示已授权，但实际还是无法检测到麦克风。这是因为Electron的Windows权限API不可靠，不会完整检查windows的应用权限和系统开关。

关于asr精修问题

在好几个版本里，asr的精修都有明显的质量问题：

字符重复：输出的字幕会出现”这这这这个问题”等单字符的重复，最后发现是长时间静音时的循环推理，导致输出重复token。最后是通过正则和后端对输出文本直接做去重。
文字中断：用户在说一句长话时，字幕会切成两句话，语义上不连贯（例如：“我觉得这个方案”，“可以继续推”，“进大家有什”）。最后发现是因为sherpa-onnx的硬规则会在一个时间点后强行截断输出。解决方案是根据句号，逗号，停顿来做语义切分，还加上二阶段的精修，用一个质量更好的模型，专门维护一段时间内的流式字幕。
说话人过度切分：同一个人的连续发言被拆好多个连续的小片段，每段都只有2-3秒。最后解决方法就是合并短停顿的同一个说话人片段。

关于内存溢出和僵尸进程

1小时以上录音点击”会后精修”后，等待5分钟后会提示”处理失败”。原因是转写时将整个音频片段全加载到内存，精修长会议时，worker的进程占用会超过8gb，然后被oom kill。最后改成滑动窗口加载音频进行流式转写。后面还出现了加载llm sidecar以后始终没有释放的僵尸进程。

关于自动更新

在之前的版本里，应用内的更新都是依赖弹窗提示，然后用户点击后跳转github，手动下载完整的release安装包。这种方式效率非常低，因此后面改成了增量更新，每次打包发布时同步上传blockmap和latest.yaml，更新时会对比release的最新版本里的增量内容，然后在应用内进行增量更新和自动安装。

关于后台任务

在好几个版本里，用户无法暂停和取消后台执行的精修任务，ai摘要生成等任务。后来通过加入threading.Event来控制多进程状态。

关于不同llm返回的格式

由于不同llm提供商返回的响应格式不一致（例如，有的返回"choices": [{"message": {"content": "..."}}]，有的返回"content": [{"type": "text", "text": "..."}]），所以有时候摘要生成会失败。最后手搓适配不同格式的返回。

claude code对整个git commit history进行了总结，最后给出了结论：

Brevia 项目在 24 天内完成了从 v0.1.0 到 v1.1.2 的快速迭代，经历了 42 个版本发布和约 40 次 bug 修复。踩坑密度最高的三个领域是：

跨平台适配（编码、行尾符、权限 API）—— 占比 30%
发布流程（签名、公证、自动更新）—— 占比 25%
ASR 质量与性能（精修、内存、实时性）—— 占比 20%

最大的教训：

跨平台项目的复杂度被低估，Windows/macOS 的行为差异远超预期
发布流程必须在类生产环境中端到端测试，不能假设”本地能跑就能发布”
长任务的控制信号、状态机完整性、资源生命周期管理必须在设计阶段就考虑

最有价值的实践：

7 个诊断脚本形成的问题复现工具链
窗口式音频处理解决内存问题
多层回退的 LLM 响应解析器
显式编码声明避免 Windows 乱码

开发中的减法与新主意

原本我设想的只是一个转写工具，支持多语言转写和翻译功能，还支持记录声纹进行说话人识别和语音生成：

不过我自己的体验过程中，发现右边的设置区很少用到，甚至很多时候我只需要看会议字幕。因此在最近的几个版本里，我陆续加上悬浮字幕，并大大精简了整个界面。tts语音生成这种花里胡哨的功能也进行了清理。除此之外，原本每个语言都需要下载各自的语言包，现在也改成通用的转写模型，只对中/英/韩文使用针对性的模型。并且内置的ai模型，也由原来的四个简化到两个。

少即是多。

悬浮字幕

笔记与ai辅助功能

在对整个界面做简化的同时，我逐渐在思考这个应用的其他可能性。由于其他纪要软件都包含笔记的功能，这促使我考虑也同步加入这一功能。

but, what’s the difference?

我不想做个泯然众人的大路货产品，那么要怎么做出差异化？

我想到了用ai辅助笔记：在会议里，有时候不知道面对空白的笔记无从下手，这时候ai辅助输出一些灵感，或许是个不错的idea。于是在简单的设计和尝试以后，我大致确定了设计思路：ai根据最近的字幕内容，总结出不同时间段的会议主题，重要观点，建议思路。用户可以通过批准操作，来让ai输出的建议自动补充到会议笔记里。花了两天时间优化和打磨，最终在v1.1.0版本上线了这个功能。

笔记里的copilot，这个主意不错吧？

关于社区反馈

我在小红书，linkedin，x，reddit上都发了post宣传，其中还在小红书上小小花钱投了点流量，换来了两个真实高质量用户（哈哈哈，转化率还是很高的！）。感谢他们提供的反馈和建议，我在最新的两个版本里修复了一些之前没注意的bug。

至此，随着版本v1.1.2的发布，言录的第一个开发阶段暂告一段落。短期内暂时不考虑新增大的功能更新，只维持日常补丁和bug修复。

2026/8/21 于苏州