这个旁白是人家博主本人的声音啊。

做语音库的话，我会担心会出事啊。一旦我们这边的豆包资源包用完了，你们的读屏没声音了，那不就坏事了。

做读屏语音库有风险啊，万一我这边的额度用完了，字节跳动拒绝了我的请求，那不就歇菜了，小说就不同了，额度用完了，大不了他就不出声了呗，你们的读屏还是能正常操作啊。

用脚本，字节跳动会封你服务啊。普通用户哪有能力天天跟字节跳动玩猫鼠游戏？

不过虽然项目是别人的，但思路是可行的，

唉，有没有一种可能这个就是人家B站的视频呢？我们就是借鉴别人的思路嘛，是音频里面的项目，他们得让用户自己去抓包，自己部署服务，我们直接将这个步骤省了。用户要使用的时候，直接在我们，飞言 TTS里头获取我们提供的密钥，再粘贴到开源阅读里面就可以用了

那我们肯定会尽量精简步骤啊。

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

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

微信手机同号，16782075245

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

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

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

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

阿飞输入法 开发文档（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的风控规则，对违规内容进行拦截，不存储、不传播用户的识别内容
  ​
  
• 应用仅申请必要的系统权限（麦克风、网络访问），无需管理员权限即可正常运行

这不很正常吗？豆包对接了抖音电商的生态，我甚至还能在豆包里面买东西呢，毕竟豆包自己砸那么多钱去做，肯定不可能就是单纯给我们拿来聊天用的嘛。

手机版开发难度也更大。毕竟手机端我们得面对一堆厂商魔改过的安卓系统。电脑端就不用担心这个烦恼了，只需把它挂在后台，让他监听ctrl键有没有被触发就可以了。

不是说了吗？我这个项目是纯语音输入法。盲文输入法我们也想做啊，但可惜没有现成的框架给我们用，我们不可能从头开始做吧。

毕竟智慧人生它是一个综合性软件，语音输入只是它的一个附加功能。

具体的费用的话，到时候得等我们把产品端上桌，我们才能定啊，不过肯定会比智慧人生便宜，不过现在嘛，我自己连成品我都还没摸到呢。

天坛的字幕识别只能识别你手机播放的电影，我看的电影是在电影院看的电影，能一样吗？一个是你手机本身播放的，一个是荧幕上播放的。