1. 从一张199元的物料清单说起：这个项目到底在解决什么问题
国庆假期第三天，我把最后一块亚克力面板用M2螺丝拧进外壳的时候，桌上那台巴掌大的设备终于亮起了呼吸灯。它没有屏幕，只有一个按键和一颗全向麦克风，插上Type-C就能当录音笔用，拔下来连上电脑，本地跑完语音转写，再调用大模型把整段会议内容整理成一张思维导图。整套硬件成本算下来199元，其中最大头的支出是那颗双麦克风阵列模组和一块10000mAh的电池。
做这个东西的起因很朴素。我平时开会、采访、听讲座的频率很高，市面上的AI录音笔要么贵得离谱，要么必须把音频传到云端才能转写，涉及一些内部讨论的内容时，我总是不太放心。更麻烦的是，很多产品转写完就是一大段文字，还得自己再花半小时去梳理结构。我想要的东西其实很简单：一个能离线转写、支持多人区分、还能自动帮我整理成思维导图的录音设备，而且成本要压到普通人随手就能做出来的程度。
这个项目适合几类人参考。第一类是对嵌入式硬件感兴趣、想找一个完整练手项目的开发者，从选型、焊接、外壳设计到固件烧录，全流程都能走一遍。第二类是经常需要处理录音素材的内容工作者，比如记者、播客主、课程助教，可以直接照着这套方案复现一台属于自己的设备。第三类是对离线语音识别和大模型应用感兴趣的技术爱好者，FunASR的本地部署、说话人分离、DeepSeek的思维导图生成，这几个环节拆开来看都是很实用的技能点。
需要提前说明的是，199元这个数字是纯物料成本，不含任何工具费用。如果你手头没有电烙铁、热风枪、万用表这些基础工具，实际投入会更高一些。另外，这个项目的核心价值不在于硬件本身有多精巧，而在于它把"离线语音转写"和"大模型结构化输出"这两件事串成了一条完整的链路，硬件只是这条链路的入口。理解了这条链路，你完全可以把同样的思路迁移到其他场景，比如把家里的旧手机改造成离线会议记录终端，或者给树莓派加一个麦克风阵列做成常驻的语音笔记设备。
2. 硬件选型：为什么是这几个模块，而不是更便宜或更贵的方案
2.1 主控芯片的取舍：ESP32-S3还是树莓派Zero 2W
主控是整个项目的地基，选错了后面全是坑。我最初考虑过三个方案：ESP32-S3、树莓派Zero 2W、以及某款国产的RISC-V开发板。最后选了ESP32-S3，原因很具体。
ESP32-S3的优势在于它自带USB OTG和I2S接口，可以直接接数字麦克风，不需要额外的音频编解码芯片。它的双核240MHz主频处理音频流绰绰有余，而且功耗控制得非常好，配合深度睡眠模式，整机待机功耗可以压到毫安级别。更重要的是，它的开发环境成熟，Arduino和ESP-IDF两条路都能走，社区里关于I2S录音的示例代码非常多，遇到问题容易找到参考。
树莓派Zero 2W的性能更强，理论上可以直接在上面跑轻量级的语音识别模型，但它的功耗太高了，一块10000mAh的电池撑不过8小时，而且价格也比ESP32-S3贵不少。至于那款RISC-V开发板，生态还不够完善，I2S驱动和USB音频类的支持都不太稳定，调试成本太高，不适合作为一个假期项目。
这里有一个容易被忽略的细节：ESP32-S3的USB OTG功能需要确认你买的是支持原生USB的型号，有些模组只引出了UART，插上电脑只能看到串口，看不到U盘或音频设备。我用的是一块带16MB Flash和8MB PSRAM的模组，PSRAM对于音频缓冲很重要，没有它的话，长时间录音容易丢帧。
2.2 麦克风阵列：双麦还是四麦，数字还是模拟
麦克风的选择直接决定了录音质量和后续的多人识别效果。我最终用的是一颗双麦克风数字阵列模组，I2S接口，支持波束成形。为什么不上四麦？因为四麦阵列的尺寸更大，对结构设计的要求更高，而且对于录音笔这种近距离使用场景，双麦已经足够覆盖180度范围内的声源定位。
数字麦克风和模拟麦克风的区别也值得说清楚。模拟麦克风输出的是电压信号，需要经过ADC采样才能变成数字信号，这个过程容易引入底噪。数字麦克风（比如INMP441、ICS-43434这类）直接输出I2S数字信号，抗干扰能力强，信噪比更高。我实测下来，在同样的电路布局下，数字麦克风的底噪比模拟方案低了将近10dB，这对于后续的语音识别准确率影响很大。
还有一个参数是灵敏度。我选的这颗模组灵敏度是-26dBFS，属于中等偏上的水平。灵敏度过高容易在嘈杂环境下削波，过低则录不到远处的说话声。如果你主要在会议室使用，-26dBFS是个比较稳妥的选择；如果经常在户外采访，可以考虑-38dBFS的型号，但需要配合软件增益来补偿。
2.3 电池与电源管理：20小时续航是怎么算出来的
20小时续航这个数字不是拍脑袋来的，我实际测算过。整机的工作电流在录音状态下大约是45mA，转写和思维导图生成是在电脑端完成的，不计入设备功耗。10000mAh的电池按标称容量算，理论续航是10000/45≈222小时，但实际电池的可用容量通常只有标称的80%左右，再考虑电源转换效率（我用的LDO效率大约85%），实际可用续航大约是222×0.8×0.85≈151小时。
那为什么标称20小时？因为我给设备加了一个常亮的呼吸灯和一颗状态指示灯，这两颗LED的功耗加起来大约是8mA。另外，麦克风阵列模组本身也有约5mA的静态电流。把这些算进去，总工作电流大约是58mA，实际续航大约是151×45/58≈117小时。但这是在理想条件下的数字，实际使用中会有温度变化、电池老化等因素，所以我保守地标了20小时，留足了余量。
电源管理部分我用了一颗TP4056充电芯片加一颗DW01保护芯片，这是最经典的锂电池管理方案，成本低、可靠性高。需要注意的是，TP4056的充电电流默认是1A，对于10000mAh的电池来说偏小，充满需要10小时以上。如果你希望充电快一点，可以把PROG电阻换成1.2kΩ，充电电流提升到1.5A，但要注意芯片的散热。
2.4 外壳与结构：3D打印还是亚克力堆叠
外壳我试过两种方案。第一种是3D打印，用PETG材料，优点是造型自由度高，可以把麦克风开孔、按键位置、USB接口都一体化设计出来。缺点是打印精度有限，麦克风开孔如果不够光滑，会影响高频响应。第二种是亚克力堆叠，用激光切割出几层板子，再用铜柱和螺丝固定。优点是精度高、质感好，缺点是设计周期长，每一层都要单独画图。
最后我选了亚克力堆叠方案，因为麦克风开孔对精度的要求比较高，3D打印的层纹会影响声学性能。具体做法是：顶层板开两个直径4mm的圆孔，正对麦克风阵列的两个拾音孔；中间层留出电池和主板的安装空间；底层板开一个Type-C接口的方孔和一个按键孔。层与层之间用M2铜柱连接，整体厚度控制在18mm以内。
这里有一个实操心得：亚克力板的厚度建议选2mm，太薄容易变形，太厚会增加整体重量。激光切割的时候，圆孔的直径要比麦克风拾音孔的实际尺寸大0.2mm左右，给装配公差留余量。另外，亚克力板在切割后边缘会有毛刺，用细砂纸打磨一下，否则容易划伤手指。
3. 离线语音转写：FunASR的本地部署与调优
3.1 为什么选FunASR而不是其他开源方案
离线语音转写的开源方案有不少，我对比过Whisper、Kaldi和FunASR。Whisper的识别准确率很高，但它的模型体积大，推理速度慢，在普通笔记本上跑实时转写比较吃力。Kaldi的定制化能力强，但配置复杂，学习曲线陡峭，不适合快速出成果。FunASR的优势在于它针对中文场景做了大量优化，模型体积适中，推理速度快，而且支持说话人分离和标点恢复，这几个功能正好是我需要的。
FunASR的另一个好处是它提供了完整的Python接口，可以很方便地集成到我的处理流程里。我只需要把录音文件传进去，它就能输出带时间戳和说话人标签的文本。而且它的模型可以量化压缩，量化后的模型体积只有原始模型的三分之一左右，推理速度还能提升30%以上，对于本地部署来说非常友好。
3.2 环境搭建：从零到跑通第一条转写
环境搭建这一步我踩了不少坑，这里把完整的流程和注意事项写清楚。首先，Python版本建议用3.8到3.10，太新的版本可能会有依赖冲突。我用的是一台装了Ubuntu 22.04的旧笔记本，显卡是GTX 1050 Ti，4GB显存，跑FunASR的量化模型完全够用。
第一步是创建虚拟环境，这一步很重要，因为FunASR的依赖比较多，直接装在系统环境里容易和其他项目冲突。命令如下：
python -m venv funasr_env source funasr_env/bin/activate第二步是安装FunASR和相关的依赖。官方推荐用pip安装，但有些依赖需要从源码编译，所以建议先装好基础的编译工具：
sudo apt-get install build-essential python3-dev pip install funasr pip install modelscope第三步是下载模型。FunASR的模型托管在ModelScope上，国内下载速度比较快。我用的模型是paraformer-zh，这是针对中文优化的通用模型，识别准确率和速度都比较均衡。下载命令如下：
from modelscope.hub.snapshot_download import snapshot_download model_dir = snapshot_download('damo/speech_paraformer-large_asr_nat-zh-cn-16k-common-vocab8404-pytorch')第四步是跑通第一条转写。这里有一个细节需要注意：FunASR默认的采样率是16000Hz，如果你的录音文件是其他采样率，需要先做重采样，否则识别结果会乱码。我写了一个简单的脚本来自动处理：
from funasr import AutoModel import librosa model = AutoModel(model=model_dir) audio, sr = librosa.load('test.wav', sr=16000) res = model.generate(input=audio) print(res[0]['text'])实测下来，一段10分钟的会议录音，在GTX 1050 Ti上转写大约需要40秒，速度是可以接受的。如果你没有独立显卡，用CPU跑也可以，但速度会慢3到5倍，建议把模型换成更小的量化版本。
3.3 说话人分离：多人识别的实现逻辑与参数调整
多人识别是这个项目的核心功能之一。FunASR本身提供了说话人分离的模型，但需要单独加载。它的原理是先通过声纹特征把不同说话人的片段聚类，再和转写结果对齐。实际使用中，有几个参数会直接影响分离效果。
第一个参数是cluster_threshold，它控制聚类时的距离阈值。这个值越小，聚类越严格，说话人分得越细；值越大，越容易把不同说话人合并成同一个。我实测下来，对于3到5人的会议场景，这个值设在0.6到0.7之间比较合适。如果是两人对话，可以调到0.5左右。
第二个参数是min_duration，它控制最短的语音片段长度。如果设得太小，一些语气词会被误判成独立的说话人；设得太大，短促的发言又会被漏掉。我一般设在0.5秒左右，这个值对于大多数会议场景都适用。
第三个参数是num_speakers，如果你提前知道参会人数，可以直接指定，这样聚类效果会更好。如果不确定，就让它自动推断，但自动推断在人数较多时容易出错。
这里有一个实操心得：说话人分离的效果和录音质量强相关。如果麦克风离说话人太远，或者环境噪音太大，声纹特征会失真，分离效果会大打折扣。我的建议是，在会议场景下，把录音设备放在桌子中央，确保每个说话人距离麦克风不超过3米。如果条件允许，可以让每个人先单独说一句话作为声纹注册，这样分离准确率会显著提升。
3.4 标点恢复与文本后处理：让转写结果能直接读
FunASR的原始输出是没有标点的，一大段文字读起来很费劲。它提供了一个标点恢复模型，可以自动加上逗号、句号、问号等。加载方式和主模型类似：
punc_model = AutoModel(model='damo/punc_ct-transformer_zh-cn-common-vocab272727-pytorch')标点恢复之后，还需要做一些后处理。比如，把"嗯""啊""那个"这类语气词过滤掉，把重复的词合并，把数字和英文缩写规范化。我写了一个简单的后处理脚本，用正则表达式处理这些情况。实测下来，经过后处理的文本，可读性提升非常明显，基本上可以直接拿去做会议纪要。
还有一个细节是时间戳的对齐。FunASR输出的时间戳是字符级别的，如果你需要按段落或按说话人切分，需要自己写逻辑来合并。我的做法是：先按说话人切分，再在每个说话人的片段内按标点切分，这样得到的段落结构最接近自然阅读习惯。
4. 从转写文本到思维导图：DeepSeek的提示词设计与结构化输出
4.1 为什么用大模型生成思维导图，而不是规则引擎
把一段会议记录整理成思维导图，本质上是一个信息抽取和结构化的任务。传统的做法是用规则引擎，比如提取关键词、按标题层级归类。但规则引擎的局限性很明显：它无法理解语义，遇到口语化的表达、隐含的逻辑关系、跨段落的主题关联时，往往力不从心。
大模型的优势在于它能理解上下文，能识别出"这段话虽然在讲技术细节，但本质上是在支撑某个业务决策"这类隐含关系。我试过用规则引擎处理一段产品评审会的录音，结果生成的思维导图支离破碎，很多关键决策点都被漏掉了。换成DeepSeek之后，它能把讨论过程中的不同观点、决策依据、待办事项都梳理得清清楚楚。
当然，大模型也不是万能的。它的输出有随机性，同样的输入可能生成不同的结构。所以我在提示词里做了很多约束，确保输出的格式稳定、层级清晰。
4.2 提示词模板：如何让模型输出可直接渲染的Markdown
我用的提示词模板经过了好几轮迭代，核心思路是：给模型一个明确的角色、一个清晰的任务描述、一个具体的输出格式示例，以及一组约束条件。模板大致如下：
你是一名专业的会议纪要整理助手。请将以下会议转写文本整理成思维导图，使用Markdown的标题层级表示。 要求： 1. 一级标题是会议主题，二级标题是主要议题，三级标题是具体讨论点。 2. 每个讨论点下面用无序列表列出关键信息，包括决策、依据、待办事项。 3. 如果原文中有明确的行动项，用"待办："开头单独列出。 4. 不要添加原文中没有的信息，不要做主观评价。 5. 输出纯Markdown，不要用代码块包裹。 会议转写文本： {transcript}这个模板的关键在于第4条约束。如果不加这一条，模型很容易"脑补"一些原文没有的内容，导致思维导图和实际讨论对不上。加上之后，输出的准确性明显提升。
还有一个技巧是，在提示词里给一个简短的示例。比如：
示例输出： # 产品评审会 ## 1. 功能优先级讨论 ### 1.1 核心功能范围 - 决策：第一版只做录音和转写，不做实时翻译 - 依据：开发周期只有两周，实时翻译的技术风险太高 - 待办：某开发者负责在周三前给出转写模块的接口文档有了这个示例，模型输出的格式会稳定很多，基本不需要二次调整。
4.3 调用DeepSeek的工程细节：超时、重试与成本控制
调用DeepSeek的API看起来简单，但实际工程中有几个细节需要注意。第一个是超时设置。会议转写文本通常比较长，如果超时设得太短，请求会被中断。我一般把超时设在60秒，对于大多数会议记录都够用。如果文本特别长，可以先做分段摘要，再把摘要合并。
第二个是重试机制。网络请求偶尔会失败，如果没有重试，整个流程就会卡住。我的做法是设置3次重试，每次间隔2秒，如果3次都失败，就把这段文本标记为"待处理"，继续处理后面的内容，最后再统一重试。
第三个是成本控制。DeepSeek的API是按token计费的，虽然单价不高，但如果每天处理大量录音，累积起来也是一笔开销。我的优化策略是：先用FunASR的标点恢复和文本后处理把冗余内容去掉，再把精简后的文本传给DeepSeek。实测下来，经过预处理的文本，token数量能减少30%左右，成本也相应降低。
还有一个细节是并发控制。如果你同时处理多个录音文件，不要一次性把所有请求都发出去，否则容易触发限流。我一般设置最多3个并发，既能保证效率，又不会触发限制。
4.4 思维导图的渲染与导出：从Markdown到可视化
DeepSeek输出的是Markdown格式的文本，要变成可视化的思维导图，还需要一步转换。我试过几种方案，最后选的是用Markmap这个工具。它可以把Markdown直接渲染成交互式的思维导图，支持缩放、折叠、导出为HTML或SVG。
安装和使用都很简单：
npm install -g markmap-cli markmap meeting_notes.md -o meeting_notes.html生成的HTML文件可以直接在浏览器里打开，效果很直观。如果你需要导出为图片，可以用Puppeteer把HTML截图，或者用Markmap的SVG导出功能。
这里有一个实操心得：Markmap对标题层级的深度有限制，如果层级太深，渲染出来的图会非常宽，不好阅读。我的做法是在提示词里限制最多三级标题，超过三级的内容用列表表示。这样生成的思维导图结构清晰，层次分明，适合在屏幕上查看或打印出来。
5. 整机联调：从录音到思维导图的完整链路验证
5.1 固件端的录音逻辑：缓冲区管理与文件写入
固件端的核心任务是稳定地采集音频并写入存储。ESP32-S3的I2S接口可以配置为DMA模式，音频数据直接通过DMA搬运到内存缓冲区，CPU只需要在缓冲区满的时候把数据取走写入SD卡。这种方式的优点是CPU占用率低，不容易丢帧。
缓冲区的大小需要仔细权衡。太小的话，CPU频繁中断，影响其他任务的执行；太大的话，内存占用高，而且一旦断电，缓冲区里的数据会丢失。我最终设的是双缓冲，每个缓冲区4096字节，对于16000Hz、16bit、单声道的音频来说，大约对应128毫秒的数据。这个粒度既能保证实时性，又不会给CPU太大压力。
文件写入用的是FATFS文件系统，SD卡通过SPI接口连接。这里有一个坑：SPI的时钟频率不能设得太高，否则在写入大文件时容易出错。我一开始设的是40MHz，结果录了半小时后文件损坏。后来降到20MHz，连续录了5小时都没有问题。另外，建议在每次写入后调用f_sync，确保数据真正落盘，避免突然断电导致文件丢失。
5.2 电脑端的处理流水线：自动化脚本的编排
电脑端的处理流程我写成了一个Python脚本，整个流水线是这样的：检测到设备插入后，自动挂载SD卡，把新的录音文件拷贝到本地，然后依次调用FunASR做转写、说话人分离、标点恢复，再把处理后的文本传给DeepSeek生成思维导图，最后用Markmap渲染成HTML。
这个脚本的关键在于错误处理和日志记录。每一步都可能出错，比如SD卡挂载失败、模型加载超时、API请求失败等。我的做法是每一步都用try-except包裹，出错时记录详细的日志，并继续执行后续步骤。这样即使某一步失败，也不会影响整个流程的其他部分。
还有一个优化点是增量处理。脚本会记录已经处理过的文件，避免重复转写。我用的方法是在文件名里嵌入时间戳，处理完成后在本地数据库里标记。这样每次插入设备，只会处理新增的录音文件，效率高很多。
5.3 实测数据：转写准确率、分离效果与端到端耗时
我用三段不同场景的录音做了实测。第一段是3人会议，时长25分钟，环境噪音约45dB；第二段是单人讲座，时长50分钟，环境噪音约40dB；第三段是2人访谈，时长15分钟，环境噪音约50dB。
转写准确率方面，单人讲座的场景最好，字准确率大约96%；3人会议的场景大约92%，主要错误集中在人名和专业术语上；2人访谈的场景大约90%，环境噪音对准确率的影响比较明显。
说话人分离的准确率，3人会议场景下大约85%，主要问题是偶尔会把两个声音相似的人合并；2人访谈场景下大约95%，效果比较理想。
端到端耗时方面，25分钟的会议录音，从转写到生成思维导图，总共耗时约3分钟，其中转写占2分钟，说话人分离占30秒，DeepSeek生成思维导图占20秒，渲染占10秒。这个速度对于日常使用来说完全可以接受。
5.4 那些让我熬夜的坑：I2S时钟配置、SD卡兼容性与API限流
I2S时钟配置是我遇到的第一个大坑。ESP32-S3的I2S时钟源可以选择PLL_D2或APLL，我一开始用的是默认的PLL_D2，结果录音里总有周期性的杂音。后来查了很久资料，发现是时钟抖动导致的，换成APLL之后杂音就消失了。这个问题的隐蔽性很强，因为杂音不是一直有，而是每隔几秒出现一次，很容易被误认为是麦克风的问题。
SD卡兼容性是第二个坑。我手头有几张不同品牌的SD卡，其中一张在写入时总是随机失败。后来用示波器看SPI波形，发现是这张卡的响应速度比较慢，在高频时钟下跟不上。解决办法是把SPI时钟降到10MHz，虽然写入速度慢了一点，但稳定性大大提升。所以建议大家在选SD卡的时候，尽量选Class 10以上的品牌卡，杂牌卡虽然便宜，但调试成本太高。
API限流是第三个坑。我一开始没有做并发控制，一次性发了10个请求，结果触发了限流，后面的请求全部失败。后来加了信号量控制，最多同时发3个请求，就再也没出现过问题。另外，建议在请求之间加一个短暂的延迟，比如200毫秒，这样对API服务端也更友好。
6. 成本拆解与可复用的经验总结
6.1 199元物料清单的逐项拆解
把物料清单摊开来看，每一项的选择都有明确的理由。主控模组45元，选的是带PSRAM的版本，贵了5元但值得；麦克风阵列模组38元，双麦数字阵列，信噪比和灵敏度都够用；电池25元，10000mAh的聚合物锂电池，容量和体积的平衡点；电源管理芯片和外围元件12元，TP4056加DW01的经典组合；SD卡模块8元，SPI接口，支持最大32GB的卡；亚克力外壳和螺丝15元，激光切割加M2铜柱；按键、LED、Type-C接口等杂项10元；PCB打样和运费46元，用的是5cm×5cm的双层板，打样5片。
合计199元。如果你手头已经有SD卡和Type-C线，实际支出还能再低一些。如果批量做，PCB和外壳的成本还能进一步摊薄。
6.2 如果重新做一次，我会改哪三个地方
第一个改动是加一个物理的录音/停止开关。现在只有一个按键，短按开始录音，长按停止，操作逻辑不够直观。如果加一个拨动开关，状态一目了然，误操作的概率也会降低。
第二个改动是把SD卡换成eMMC芯片。SD卡的兼容性问题让我吃了不少苦头，eMMC的稳定性更好，而且可以直接焊在PCB上，省去了卡座的空间。虽然成本会高一些，但可靠性提升明显。
第三个改动是加一个低功耗的RTC芯片。现在的设备没有时间戳功能，录音文件只能靠文件名来区分。加一个RTC之后，可以在录音文件里嵌入精确的时间信息，后续整理素材会方便很多。
6.3 这套方案还能怎么扩展：从录音笔到常驻会议终端
这个项目的核心链路是"离线录音→本地转写→大模型结构化→可视化输出"，这条链路可以迁移到很多场景。比如，你可以把设备固定安装在会议室的天花板上，接上常电，做成一个常驻的会议记录终端。每次会议结束后，自动生成纪要并推送到指定的邮箱或协作平台。
也可以把麦克风阵列换成更高阶的型号，支持更远的拾音距离和更精确的声源定位，适合大型会议室。或者把主控换成性能更强的模组，直接在设备端跑轻量级的语音识别模型，彻底摆脱对电脑的依赖。
如果你对硬件不感兴趣，只想要软件方案，也完全可以。把FunASR和DeepSeek的调用逻辑封装成一个桌面应用，配合一个普通的USB麦克风，同样能实现离线转写和思维导图生成。硬件只是载体，核心价值在于这条处理链路本身。
6.4 给想复现的朋友几条实在建议
第一，先跑通软件链路，再动手做硬件。很多人一上来就买物料、焊板子，结果软件环境配不起来，硬件做好了也用不了。正确的顺序是：先在电脑上把FunASR和DeepSeek的流程跑通，确认转写和思维导图生成的效果符合预期，再去考虑硬件的事情。
第二，麦克风的选择比主控更重要。录音质量的上限是由麦克风决定的，主控只影响处理速度。如果预算有限，宁可把主控换成便宜一点的型号，也要保证麦克风的品质。
第三，不要追求一次到位。我的第一版设备只有一个按键和一颗LED，连外壳都没有，就是一块裸板加一个电池。但就是这版最简陋的设备，帮我验证了整条链路的可行性。后面所有的优化，都是在这个基础上迭代出来的。
第四，做好数据备份。录音文件是原始素材，一旦丢失就无法恢复。我的做法是每次录音结束后，自动把文件同步到两个不同的存储位置，确保万无一失。
第五，关注模型的更新。FunASR和DeepSeek都在持续迭代，新版本的模型在准确率和速度上都会有提升。定期更新模型，能让你的设备保持最佳状态。
