从 OpenASR 到桌面端：把技术能力做成产品

CLI 能证明能力存在，但桌面端要解决的是另一类问题：用户怎么开始，如何配置模型，任务执行到哪里了，失败后应该怎么恢复。

openasr-app 承担的是 OpenASR 的产品层。它不重复实现内核，而是把桌面端、Web、共享包、模型目录和分发策略组织起来，让底层能力变成可以被普通用户使用的产品。

桌面端需要更强的解释能力。命令行用户能接受参数、日志和错误码，桌面端用户更依赖清楚的状态：当前模型是否可用，服务是否启动，音频是否离开本机，转写任务是否还能继续。一个状态写不清楚，用户就会怀疑整个系统是否可靠。

桌面端不是给 CLI 套一层界面。它更像一台状态机：配置什么时候保存，后台服务什么时候启动，模型目录怎么展示，失败之后提示什么，任务中断后能否恢复。每个问题单独看都不大，连在一起就是用户对产品的判断。

做桌面端最容易被忽视的是“开始之前”的体验。CLI 用户知道要传参数、看日志、装模型；桌面端用户只会看到一个窗口。窗口打开后，如果模型状态不清楚、服务还没准备好、按钮可以点但没有反馈，技术能力再强也会显得不可靠。

这种不可靠感往往来自很小的断点。配置保存慢半拍，用户看到的是“保存中”；daemon 没有按时 ready，用户看到的是“功能不可用”；健康检查通过但模型还没加载，用户看到的是“为什么还是不能转写”。产品体验不是单个页面决定的，而是这些状态之间有没有被接住。

OpenASR 的开源内核负责信任边界、运行时和模型包规则；openasr-app 负责产品体验、桌面壳、站点和商业相关能力。这个边界很重要。信任相关的能力应该留在开源内核里，让用户和开发者都能检查；产品层则负责把这些能力组合成更完整的使用流程。

这类产品的产品需求不能只写“优化启动体验”。更可靠的写法是把启动拆成可观测状态：配置已保存，daemon 已启动，健康检查通过，模型包校验成功，转写任务进入队列。产品经理理解这些工程约束，不是为了替代工程师，而是为了把需求写到可以验证的粒度。

桌面端还有一个长期取舍：哪些能力留在开源内核，哪些能力放在产品层。信任相关的能力越靠近内核，越容易被检查，也越不依赖某个商业界面。产品层则应该承担组织流程、降低理解成本、处理边界状态的工作。这个边界划清楚，项目后面才不会越做越乱。

把技术能力做成产品，最有感触的一点是，用户很少关心内部结构是否漂亮。他关心的是第一次能不能跑起来，失败时能不能知道原因，下一步是否明确。工程质量最后会以一种很日常的方式出现：按钮有没有反应，状态有没有更新，错误有没有说人话。