很多语音产品一开始都会选择 Web。部署快、分享方便、表单也现成。但 Voxt 从一开始就没有把主流程放在浏览器里，因为我们的目标不是做一个“能说话的网页”，而是让语音真正进入每天的写作动作。
浏览器不是写作发生的地方
用户真正输入内容的地方很分散：
- 邮件客户端
- 文档工具
- 即时通讯软件
- IDE 和终端
- 各类带输入框的原生应用
如果每次都要先切到一个网页，说完以后再复制回去，语音只会变成一层额外摩擦。它不但没有加速，反而插入了新的上下文切换。
桌面入口解决的是连续性
Voxt 选择菜单栏和全局快捷键，不是为了“更像 macOS 应用”，而是为了保住输入动作的连续性。一个可靠的语音工作流至少要满足几件事：
- 触发足够快。
- 说完以后结果能直接回到当前焦点位置。
- 用户不用关心当前是在邮件、文档还是聊天窗口里。
- 后处理规则可以根据当前应用自动变化。
这几件事放在 Web 环境里都能做一部分，但很难自然地组合成一个稳定主流程。
语音不是单一步骤
Voxt 里真正发生的事情通常不是“录音转文字”这么简单。一次按键后面，可能会接上：
- 转录清洗
- 自动补标点
- 专有名词纠错
- 翻译
- 改写
- 按应用场景追加提示词
这些步骤只有贴近桌面上下文才有意义。用户在邮件里需要更正式的结果，在聊天软件里需要更短、更口语化的表达，在文档里可能更关心结构和语气统一。
Web 仍然有价值，但不是主执行面
这不代表网站不重要。网站更适合承载：
- 产品说明
- 下载分发
- 更新日志
- 博客内容
- 面向搜索引擎的入口页
但真正高频、低延迟、对焦点敏感的语音输入过程，还是应该留在桌面。
我们在优化的不是“能不能说”，而是“能不能直接用”
Voxt 的产品判断一直比较简单：如果语音结果还需要用户自己搬运、再编辑、再切换一次上下文，那它就没有真正完成任务。桌面化不是包装，而是让语音输入变成一种可以长期依赖的写作基础设施。