阿飞输入法 开发文档（V2.0）   一、项目概述（先讲明白我们要做个啥） 我们要做的阿飞输入法，本质是一个Windows后台常驻的语音辅助工具，不是传统的系统级输入法，核心定位就像一个「时时刻刻待命的助理」——平时安静挂在后台不打扰，用户。按快捷键就立刻响应，帮你把语音转成文字，还能搞定会议纪要这类长语音需求。 核心目标用户是视障群体，完美兼容争渡读屏、NVDA等主流读屏软件，同时拓展了长语音识别能力，不局限于单纯的打字输入，要做能覆盖日常聊天、开会记录全场景的实用工具。 核心功能清单 1. 核心语音输入：按Ctrl键开始录音，再按一次Ctrl键停止录音，识别完成的文字自动插入到当前光标停留的输入框，全系统所有软件（微信、浏览器、Word等）通用 ​ 2. 双识别模式（菜单可切换）： ​ - 实时流式识别：默认模式，边录边上传，低延迟，适合日常打字聊天 ​ - 长语音/会议纪要模式：适合开会、讲课场景，全程录音结束后一次性识别，对接豆包大模型生成结构化纪要，支持重点提炼 ​ 3. 全局快捷键： ​ -  Ctrl ：启动/停止录音 ​ -  Alt+P ：一键呼出阿飞输入法主菜单 ​ -  Alt+Q ：一键退出软件 ​ 4. 基础菜单功能：主菜单包含个人中心（对接飞言TTS账号）、识别模式切换、基础设置、关于我们 ​ 5. 账号与风控：完全复用飞言TTS现有的账号体系、权限、计费和风控规则，无需重复开发 ​ 6. 无障碍全适配：所有操作都有语音反馈，界面全兼容读屏软件，全程支持键盘操作，无需鼠标 ​ 7. 多端联动：PC端是阿飞输入法，同时在飞言TTS网页端（含安卓端）集成同款录音识别能力，安卓用户只需安装APP，打开网页就能使用   二、核心业务全链路（一步看懂完整流程） 整个业务逻辑非常清晰，从触发到出结果，全程就这几步： 1. 软件启动后，自动最小化到系统托盘，后台静默运行，不占用前台窗口，只监听我们设定的全局快捷键 ​ 2. 按下快捷键触发对应操作： ​ - 按 Ctrl ：当前没在录音就启动录音，同步播放“开始录音”语音提示；正在录音就停止录音，播放“正在识别”提示 ​ - 按 Alt+P ：直接呼出软件主菜单界面 ​ - 按 Alt+Q ：直接关闭退出软件 ​ 3. 录音停止后，根据用户选择的识别模式，调用对应的豆包语音识别接口： ​ - 实时模式：录音过程中已分片上传音频，停止后直接获取最终识别文本 ​ - 纪要模式：把完整录音文件传给豆包录音文件识别接口，同时调用大模型生成结构化会议纪要 识别完成的内容统一放在我的纪要列表下。同时以弹窗的形式告诉用户，你的纪要创建好了，既要可以支持用户进行复制、保存等操作。网页端和移动端创建的录录音纪要可以进行下载成txt进行保存。​ 4 Pc端的阿飞输入法普通模式识别成功之后，服务端返回的结果。. 拿到识别结果后，通过Windows系统原生接口，把文字模拟成手动打字的动作，自动插入到用户当前光标停留的输入框中，同时读屏软件会自动朗读输入的内容 ​ 5. 全流程同步对接飞言TTS账号体系，完成权限校验、调用量统计、风控拦截，全部复用现有能力，无需额外开发   三、技术选型（主推.NET WinForms方案，讲清为什么选它） 我们最终确定的核心技术栈是 .NET 8 + WinForms，完全对标争渡之多云的成熟技术路线，也是最适配我们需求、对大家最友好的方案，核心优势非常明确： 为什么选.NET WinForms？ 1. 对熟悉Web开发的同学极度友好，几乎零学习成本 ​ - C#的核心语法和JavaScript/TypeScript高度相似，async/await异步写法、事件监听、类这些大家天天用的逻辑，C#里几乎一模一样，1-2天就能上手写核心代码 ​ - 开发逻辑和Web里「写DOM+绑定事件」完全一致，就是「拖拽控件+绑定事件」，没有额外的思维门槛 ​ - 所有功能都有成熟的开源库和现成示例，不用从零造轮子，直接拿来就能用 ​ 2. 彻底解决内存占用问题，性能拉满 ​ - 后台常驻内存仅8-15MB，和之多云的占用几乎一致，哪怕录音识别的峰值内存也不会超过50MB，老旧电脑也完全不卡顿 ​ - 无需打包浏览器内核，安装包体积极小，用户下载安装都很方便 ​ 3. 兼容性无敌，尤其适配视障用户需求 ​ - 纯Windows原生应用，直接调用系统底层接口，和所有Windows软件、现有输入法都不会冲突 ​ - 所有控件原生支持Windows无障碍接口，和争渡读屏、NVDA的兼容性是所有方案里最好的，不用额外折腾适配 ​ 4. **微软官方长期维护，生态稳定，坑少，出问题有海量中文教程和解决方案 各模块对应技术选型（全是现成工具，不用从零写） 表格 功能模块 选用工具/库 直白说明 核心框架 .NET 8 + WinForms 微软官方原生Windows开发框架，轻量稳定，上手快 全局快捷键监听 MouseKeyHook 开源库 几行代码就能实现Ctrl、Alt+P、Alt+Q的全局按键监听，完美适配我们的交互需求 音频采集处理 NAudio 开源库 .NET生态最成熟的音频库，直接就能录制符合豆包ASR要求的音频，还能做降噪、静音检测 接口对接 原生HttpClient/WebSocket 对接豆包ASR、飞言TTS接口，和Web里调用后端接口的逻辑完全一致 文本插入光标 Windows原生SendInput接口 模拟真实手动打字，和用户自己敲键盘完全一致，所有软件都兼容，读屏能正常朗读 无障碍适配 WinForms原生控件 所有控件自带无障碍属性，加个描述文本就能完美适配读屏软件 备选方案补充 如果大家完全不想接触新语言，还是想用熟悉的HTML/CSS/JS技术栈，可以选Tauri 2.0方案，零前端学习成本，内存占用也只有Electron的1/10，但无障碍兼容性和原生性不如.NET WinForms，所以优先推荐.NET方案。   四、核心功能实现逻辑（只讲逻辑，不堆专业术语） 1. 全局快捷键监听模块 - 软件启动就注册全局键盘监听，只关注我们设定的三个快捷键操作，过滤其他无关按键 ​ - 做防抖和状态锁：比如按Ctrl时，先判断当前有没有在录音，没在录就启动录音，正在录就停止，避免重复触发 ​ - 不抢占读屏软件的全局快捷键，完全不干扰读屏软件的正常运行 2. 音频采集与处理模块 - 严格按照豆包ASR的要求录制音频：16kHz采样率、16bit位深、单声道PCM编码，保证识别准确率 ​ - 实时模式下，每200ms录制一个音频分片，实时上传给豆包ASR，最大程度降低延迟 ​ - 自带降噪和静音检测，过滤掉无语音的空白音频，提升识别准确率，减少无效流量 3. 豆包语音识别对接模块 - 核心对接两个豆包官方接口： ​ - 双向流式ASR接口：给实时输入模式用，边录边传，首字延迟低，适合日常打字场景 ​ - 录音文件识别接口：给会议纪要模式用，支持长音频识别，同时对接豆包大模型做纪要结构化提炼 ​ - 内置鉴权、断网重连、超时重试、错误提示机制，保证运行稳定 ​ - 调用逻辑和Web里对接后端接口完全一致，就是发送请求、接收结果，没有额外学习成本 4. 文本插入核心模块 - 用Windows系统原生的SendInput接口，把识别出来的文字，模拟成用户手动敲键盘的动作，输入到当前光标处 ​ - 核心优势：不用管用户当前在哪个软件、哪个输入框，系统会自动把文字插到光标停留的位置，和真实手动打字完全一致，100%兼容所有软件，读屏软件也能正常捕获输入内容并自动朗读 5. 界面与菜单模块 - 软件默认后台运行，只有按Alt+P才会呼出主界面，不占用前台窗口 ​ - 主界面菜单极简：个人中心（登录飞言TTS账号、查看调用额度）、识别模式切换、基础设置、关于我们 ​ - 所有界面元素都添加无障碍标签，读屏软件能正常识别朗读，全程支持键盘操作，无需鼠标 6. 账号与风控模块 - 完全复用飞言TTS现有的接口能力，包括用户登录、权限校验、调用量统计、风控拦截 ​ - 每次调用识别接口前，先校验用户是否有可用额度、是否触发风控拦截，校验通过才会放行 ​ - 无需重新开发后端体系，直接对接现有能力，大幅减少开发量 7. 无障碍适配模块 - 操作全程有语音反馈：按下Ctrl启动录音播“开始录音”，停止录音播“正在识别”，识别成功/失败都有对应提示 ​ - 所有界面控件都有正确的无障碍属性，读屏软件能正常识别和朗读 ​ - 输入逻辑和真实打字完全一致，读屏软件能正常捕获并朗读输入的文本内容，不干扰读屏软件的正常运行   五、多端适配说明 我们的能力不局限于PC端的阿飞输入法，同时覆盖移动端用户需求： 1. PC端：就是本次开发的阿飞输入法，主打Windows系统全局语音输入、会议纪要，满足电脑端用户的核心需求 ​ 2. 网页/安卓端：在现有的飞言TTS网页中，集成豆包录音文件识别能力，安卓用户无需单独下载APP，打开手机浏览器进入飞言TTS网页，就能使用录音转文字、纪要生成的功能，满足移动端的使用需求   六、开发难度&周期预估（给大家吃定心丸） 针对熟悉Web开发的同学，所有模块都有现成的开源库和示例代码，几乎没有技术门槛，开发周期非常可控： 表格 模块 难度等级 预估开发时间 备注 项目搭建与基础界面 极低 半天 Visual Studio一键创建项目，拖拽控件即可完成界面搭建 全局快捷键监听 极低 半天 直接用MouseKeyHook库，现成示例直接套用 音频采集与处理 低 1天 NAudio有成熟示例，直接按豆包要求配置参数即可 豆包ASR+飞言接口对接 低 1-2天 和Web里调用后端接口逻辑完全一致，无学习成本 文本插入核心功能 低 1天 有现成的封装代码，直接套用即可 菜单界面与无障碍适配 极低 半天 原生控件自带无障碍能力，补充描述文本即可 打包与部署 极低 半天 Visual Studio一键打包成exe安装包 整体预估：核心功能1周即可完成开发，再用1周做兼容性测试、读屏适配、bug修复，总计2周左右就能产出可上线的版本。   七、兼容性与安全规范 1. 兼容性说明 - 支持Windows 10 1903及以上版本、Windows 11全版本，兼容32位/64位系统 ​ - 兼容所有主流Windows输入法，不会产生冲突 ​ - 完美适配争渡读屏、NVDA、Windows讲述人等所有主流读屏软件 2. 安全与隐私规范 - 音频数据仅在录音期间临时存储在内存中，识别完成后立即销毁，不本地保存用户录音文件 ​ - 所有音频、文本数据传输均采用加密协议，保证数据传输安全 ​ - 严格遵循飞言TTS的风控规则，对违规内容进行拦截，不存储、不传播用户的识别内容 ​ - 应用仅申请必要的系统权限（麦克风、网络访问），无需管理员权限即可正常运行

都是电脑的

豆包这款软件里面也支持上传音频进行录音纪要啊，那你开发的这个工具优势在哪里呢？

这功能新一点的手机系统都自带了吧，算是端侧AI里最容易实现的功能之一了，第三方也有替代品

那视频生成你们需要吗？刚好豆包的视频生成模型2.0开放了。

我认为对于视障用户这也是个小众需求，要用的话肯定也是直接用豆包的app。建议还是关注文本转语音和语音转文本这方面吧，比如你可以做一个安卓端的语音转文本引擎，做成可以让天坦输入法调用的形式，之前那个 TTS 不知道是不是还是浏览器套壳，如果做成 TTS 引擎能直接让阅读这样的 APP 调用那可玩性会高很多，纯个人看法仅供参考。

做成语音库是吧？那行，回头我鼓捣鼓捣。

游戏语音转文字还挺不错的。让用户在游戏中直接动嘴就能够在对话框中输入文字，这样他就不需要右手离开鼠标了，这倒是挺不错。这个功能可能就更加偏向正常视力的用户了，因为眼神不好的朋友们很少用鼠标。 这样的话还是要嵌入到一款输入法里面去。所以做一款游戏输入法吧

那做游戏输入法，那不更没人用了。

会有人用的。电脑输入法切换那么容易，如果这个输入法适合在游戏中用，那么玩家在游戏中就切换到这个输入法就行了。只是面临两个问题 一是没有护城河，别的输入法很容易做出同样的功能。 第二没法变现。

我需要豆包tts1.0和2.0当读平音库

语音转文本引擎真的强推荐

那行，我们研究一下怎么弄，不过做出来之后不好用，不要骂我们哈。具体哪里不好用呢？一，非常的烧钱，二，速度特别的慢，可能你滑一下焦点，你可能得等个几秒，读屏才会有声音。

如果语音转文本，其实那延迟是能接受的，文本转语音双向流式api也能用

要不语音引擎交给我，我来帮你

好的，没问题，我的qq号码，2767964115

微信手机同号，16782075245

跟你们相比，我的发言就有点若有若无了，嘿嘿。其实我很想要一个手机版的文档编辑器，支持很多格式的文档,目前虽然很多。但是无障碍的支持真的好差啊，我妹之前给我一个文档编辑器，但是它只支持txt格式的，其他的不支持。这让我在交文稿的时候真的很头疼。还得弄到豆包上，又弄豆包来改革是

可以做一个离线的 T T X 呀，有些 T T X 软件用的不就是自然离线的吗？在线的也是调用其他的 A P I，或者就是从服务器那边转化的

我们，飞言 TTS而本质上就是一个ai聚合平台，将豆包，声音复刻等模型通通整合在一起供大家调用。根本没有办法做离线语音库啊，我们根本没有豆包的离线语音包。

啊哈，楼主是否有重启光明论坛的计划