企业官网建设流程全解析

• 桌面应用
• 语音
• AI 应用
• 本地部署

TMSpeech 是一个基于 WASAPI 捕获内音、通过 sherpa-onnx 流式模型实现中文实时语音字幕的 Windows 桌面工具（即"腾讯会议摸鱼工具"）。本文以仓库根目录下的 ROADMAP.md 为骨架，结合 src 目录下的核心源码，逐版本拆解 0.1～1.0 的功能规划、已完成项的实现证据与未完成项的落地路径，帮助你理解该项目的架构演进逻辑，也为二次开发、插件编写和贡献者提供可对照的功能清单。

路线图概览：一张表看懂版本规划

ROADMAP.md 以里程碑（Milestone）的形式组织，从 0.1 一直规划到 1.0，并用复选框[x]/[ ]明确区分"已完成"与"规划中"：

下面逐版本展开，并对照仓库源码给出实现依据。

0.1：跨平台重构与插件生态奠基

路线图 0.1 的两个目标——迁移到 AvaloniaUI、将识别器/语音源/翻译器与程序本体分离——是 TMSpeech 整个架构的基石，在源码中均有完整落点。

AvaloniaUI 跨平台 UI

从项目结构可以看到 UI 层位于 src/TMSpeech.GUI：

• 主窗口、配置窗口、历史记录窗口分别定义于 MainWindow.axaml、ConfigWindow.axaml、HistoryWindow.axaml，以.axaml（Avalonia XAML）描述界面；
• 应用入口 App.axaml 与 Program.cs 组成启动链路；
• 字幕组件位于 CaptionView.axaml，历史记录组件位于 HistoryView.axaml，说明 UI 采用"视图 + 控件 + ViewModel"的常规 MVVM 组织方式（ViewModels）。

路线图明确写的是"首先保证在 Windows 正常运行"，因此即便 UI 框架已具备跨平台能力，当前发布形态仍以 Windows 为准。

插件生态：三大接口与动态加载

0.1 的"插件化"在核心工程 src/TMSpeech.Core/Plugins 中体现为三层接口：

• IPlugin.cs：所有插件的公共契约，包含GUID、Name、Version、SupportVersion、Author、License等元数据，以及LoadConfig(string config)、Init()、Destroy()、CreateConfigEditor()、Available等生命周期方法；
• IAudioSource.cs：语音源，继承IPlugin与IRunable，通过DataAvailable事件向外部推送byte[]音频数据，状态通过SourceStatus（Unavailable/Ready/Busy）上报；
• IRecognizer.cs：识别器，提供Feed(byte[] data)喂入音频，并通过TextChanged（临时结果）与SentenceDone（一句话识别完成）两个事件输出识别文本（TextInfo 附带时间戳）；
• ITranslator.cs：翻译器，仅一个方法string Translate(string text)——这也是 0.5 版本翻译器插件化的基础接口。

插件实际的加载逻辑位于 PluginManager.cs：程序启动时扫描可执行文件目录下的plugins子目录，读取每个插件目录中的tmmodule.json描述文件（结构见 ModuleInfo.cs），再通过自定义PluginLoadContext（AssemblyLoadContext子类）隔离加载程序集，并自动处理原生库（runtimes/win-x64/native等）的解析。仓库内已内置四个官方插件：

• TMSpeech.Recognizer.SherpaOnnx（其 tmmodule.json 声明了apiLevel: 1与程序集列表）
• TMSpeech.Recognizer.SherpaNcnn
• TMSpeech.Recognizer.Command（命令行识别器）
• TMSpeech.AudioSource.Windows（WASAPI 回环/麦克风语音源，含LoopbackAudioSource.cs、MicrophoneAudioSource.cs等）

从PluginManagerImpl的实现可以看到，Plugins、AudioSources、Recognizers、Translators四个字典均以模块ID!插件GUID复合键索引，这就是设置界面中"切换识别器/语音源"数据来源。

0.2：运行异常通知与资源管理器

通知模块

路线图 0.2 的第一项是"实现运行异常通知"，对应核心层 Notification 目录：

• NotificationManager.cs 采用单例模式（NotificationManager.Instance），支持注册多个INotificationService，并有一个全局通知级别_level，只有type >= _level的通知才会被分发；
• INotificationService.cs 定义通知类型枚举NotificationType（Info/Warning/Error/Fatal）与通知服务接口。

有趣的是，通知机制不仅服务于"运行异常"，在源码中还被插件加载、资源下载等场景复用：例如 PluginManager.cs 在解析插件 JSON 失败、加载插件代码失败时会通过NotificationManager.Instance.Notify(..., "错误", NotificationType.Error)提醒用户。

资源管理器

"资源（例如 SherpaOnnx 模型文件）管理"对应 ResourceManager.cs。它统一管理两类资源目录：

• 程序目录下的plugins（随安装包分发，不可移除，CanRemove = false）；
• 用户数据目录下的plugins（用户安装/下载，可移除）。

每个资源目录都以tmmodule.json作为唯一标识描述文件，字段包括id、version、type（plugin/sherpaonnx_model/sherpancnn_model，见 ModuleInfo.cs）、assemblies（插件程序集列表）、install（安装步骤）等。该管理器的实现与路线图 0.4 的"分发渠道"直接关联，详见下文。

0.3：字幕增强与敏感词通知

字幕：锁定、背景色、字体艺术效果

0.3 的字幕能力对应 GUI 层的 CaptionView.axaml 及其代码后置文件，配合主窗口 MainWindow.axaml 实现"歌词字幕"式展示。README 中展示的识别窗口截图：

即为无边框、可拖动、可调整大小的字幕窗口效果。字幕锁定、背景色、字体等配置项可在 ConfigWindow 中调整，配置读写由 ConfigManager.cs 与 ConfigTypes.cs 承担，默认值定义在 DefaultConfig.cs。

敏感词通知

敏感词通知复用 0.2 的通知基础设施，属于对NotificationType的典型业务扩展：当识别文本命中用户配置的敏感词时触发通知。README 中设置页面截图可直观看到相关配置入口：

0.4：插件生态闭环与分发渠道

0.4 是"插件生态"从本地加载走向线上分发的一步，对应源码中的两个关键机制：

插件下载、禁用、自动更新

• 下载任务管理位于 DownloadManager.cs：维护DownloadItem任务表，状态机为Idle → Pending → Downloading → Installing → (Paused/Failed)，支持断点、进度与速度统计；
• 安装过程由ModuleInfo.InstallSteps驱动（ModuleInfo.cs），步骤类型支持download、extract、write_file、write_module_json，即"下载压缩包 → 解压到指定目录 → 写入文件 → 生成模块描述"的声明式安装流程；
• "禁用"与"自动更新"（更新到更高version）的判断依据是Resource.NeedUpdate（远端版本大于本地版本）与本地/远端ModuleInfo的对比，见 ResourceManager.cs。

分发渠道

ResourceManager.GetRemoteResources()（ResourceManager.cs）通过 HTTP 拉取远端marketplace.json（模块市场清单），与本地资源合并后形成"全部资源"列表；网络异常、超时、数据格式错误都有对应的 Warning 通知兜底。这就是路线图所述"资源下载、插件下载"分发渠道的服务端对接实现，UI 层对应 ResourceManagerView 与 ResourceManagerViewModel.cs。

0.5：官方插件与翻译器插件化（规划中）

路线图 0.5 规划了两件事，均未开始（[ ]）：

1. 官方插件的小功能：SherpaOnnx 的英文小写转换、繁简体转换——从现有识别器插件 SherpaOnnxRecognizer.cs 与配置编辑器 SherpaOnnxConfigEditor.cs 的结构看，这类文本后处理最自然的落点是作为独立IRecognizer包装器或新增插件类型；
2. 翻译器插件化：支持谷歌翻译、有道翻译等——基础接口 ITranslator.cs 已在 0.1 就位，PluginManager也已有Translators字典，因此该项更多是"写实现 + 接 UI"，属于接口已预留、实现待补充的状态。

0.6：Linux 跨平台（规划中）

0.6 规划了 Linux 桌面支持：官方实现 PulseAudio 语音源、保证 Linux 上运行一致。从源码可以印证两点：

• 插件加载器 PluginManager.cs 的原生库解析已兼容win-*、linux-*、osx-*三种 RID，LoadUnmanagedDll会依次尝试.dll、.so、.dylib，说明运行时层面已具备 Linux 加载能力；
• 目前仓库中官方语音源只有 Windows 的 TMSpeech.AudioSource.Windows（WASAPI 回环与麦克风），PulseAudio 语音源确实尚属空白，与路线图状态一致。

1.0：分发、自动更新与插件接口稳定（规划中）

1.0 的三个目标目前均为未完成状态：

1. 官方网站：提供下载、文档、社区；
2. 自动更新：核心层已存在占位实现 AutoUpdateManager.cs，其中CheckUpdate()方法仅写了// TODO: implement it并返回null，说明该功能正是 1.0 要落地的目标；
3. 稳定插件接口 + 插件开发文档：当前插件接口以IPlugin/IAudioSource/IRecognizer/ITranslator+tmmodule.json描述文件的形式存在，apiLevel字段（见各插件 tmmodule.json）正是为未来接口版本管理预留的钩子——届时围绕"如何编写并分发插件"的开发文档将极大降低第三方接入门槛。

待办 Issues：已知问题清单

ROADMAP.md 末尾单独列出了尚未纳入具体版本的问题清单，是社区反馈与内部已知缺陷的聚合：

贡献者可以从这些 Issue 入手，它们大多改动范围清晰、与核心架构耦合度低。

小结：如何用路线图指导开发与贡献

从 ROADMAP.md 可以看到 TMSpeech 清晰的演进逻辑：0.1 打好 UI 与插件基座 → 0.2/0.3 补齐通知、资源、字幕体验 → 0.4 打通线上分发闭环 → 0.5/0.6/1.0 走向官方插件矩阵、Linux 与正式分发。对照源码验证时，可以形成一套"路线图条目 → 源码路径"的检查方法：

• 插件生态：看 src/TMSpeech.Core/Plugins 的接口与PluginManager；
• 通知与资源：看 src/TMSpeech.Core/Services/Notification 与 src/TMSpeech.Core/Services/Resource；
• 字幕与 UI：看 src/TMSpeech.GUI 的CaptionView与MainWindow；
• 自动更新：看 AutoUpdateManager.cs 中的TODO占位。

对于计划贡献者，当前最高价值的切入点依次是：完成AutoUpdateManager的TODO、实现 0.5 的官方文本处理插件、补齐 Linux PulseAudio 语音源，以及Issues 清单中改动量较小的历史记录保存与代理设置。

• 桌面应用
• 语音
• AI 应用
• 本地部署