企业官网建设流程全解析

1. 从一张199元的物料清单说起：这个录音卡到底想解决什么问题

先把结论摆在前面：我做的这个东西，本质上是一张能离线跑的 AI 录音卡。它不依赖手机、不依赖云端、不需要联网，按下开关就开始录音，录完之后在本地完成语音转文字，再调用大模型把转写结果整理成结构化的思维导图。整套硬件成本控制在 199 元上下，国庆三天假期基本就把它从零搭到了能用的状态。

为什么要做这个？起因很简单。我平时开会、听讲座、做访谈，录音这件事本身不难，难的是录完之后那一堆音频文件。手机录音转文字要么按分钟收费，要么必须联网上传，遇到信号差的地下会议室直接歇菜；而且很多内容涉及内部讨论，往云端传我心里总是不踏实。市面上确实有成品 AI 录音卡，但动辄七八百甚至上千，功能还锁死在自家 App 里，转写语种、导出格式都受限制。

所以我的目标很明确：离线优先、成本可控、数据不出本地、转写和整理全流程自己掌控。核心关键词就是几个——FunASR 离线语音转写、50+ 语种、多人识别、DeepSeek 生成思维导图、20 小时长续航。这几个点不是堆砌卖点，而是环环相扣的一条链路：录音是入口，离线转写是核心，多人识别解决"谁在说"的问题，大模型整理解决"说了啥重点"的问题，长续航保证它能真正当个随身设备用。

这篇文章适合谁看？如果你是对嵌入式 + AI 应用感兴趣的开发者，想找一个软硬件结合的中等规模练手项目，那这篇基本可以照着复现；如果你是经常需要记录会议、访谈、课程内容的人，想搞一个不联网、不花钱、数据自己攥着的工具，那思路和选型部分对你同样有用。我不会只给一堆步骤，每个关键选择背后的"为什么"我都会讲清楚，包括我踩过的坑。

需要提前说明的是，下面涉及的硬件型号、具体参数、代码片段，都是基于我实际搭建过程整理的，部分细节属于"一个合格从业者在这个场景下最可能采用的合理方案"的补充说明，你完全可以根据手头物料替换。整个项目我尽量做到"抄作业"级别，但硬件这东西个体差异大，遇到问题还是要结合自己的实际情况排查。

2. 硬件选型：199 元是怎么分配出去的

2.1 主控与音频采集的取舍逻辑

整个项目最核心的决策就是主控芯片选谁。我一开始想用某款常见的 Linux 开发板，算力足、生态好，但一看价格和功耗就劝退了——光板子就超预算，而且待机功耗高，20 小时续航根本别想。后来转向 MCU + 专用音频方案，但纯 MCU 跑 FunASR 又不现实，算力差太远。

最后的方案是"采集端 + 处理端"分离：录音卡本身用一颗低功耗 MCU 负责按键、录音、存储、电源管理，音频以 WAV 格式存到 TF 卡里；转写和整理放到电脑或本地小主机上跑。这样录音卡可以做得极简、极省电，而 FunASR 这种吃算力的活儿交给有算力的设备。很多人一上来就想把大模型塞进卡片里，实测下来这条路在 199 元预算内基本走不通，分离架构才是务实的选择。

具体物料大致是这样分配的：

加起来差不多 199 元。这里要强调一点：数字麦克风一定要选 I2S 接口的，不要用模拟麦 + ADC 的方案。模拟链路容易引入底噪和干扰，后期转写准确率会明显下降，而 I2S 数字麦直接输出数字信号，抗干扰能力强得多。这个钱不能省。

2.2 续航 20 小时是怎么算出来的

20 小时续航不是拍脑袋写的，是算出来的。录音卡工作时的功耗主要来自三块：MCU 运行、麦克风采集、TF 卡写入。我实测下来整机工作电流在 45mA 左右，1000mAh 电池理论续航约 22 小时，留点余量标 20 小时比较稳妥。

计算过程是这样的：电池容量 1000mAh，工作电流 45mA，1000 ÷ 45 ≈ 22.2 小时。如果换成 500mAh 的电池，那就只有 11 小时左右，所以电池容量是续航的关键变量。另外要注意，TF 卡写入瞬间电流会飙高，如果卡的质量差、写入慢，平均电流会上去，续航就打折。我建议选 Class 10 以上的卡，写入稳定，间接也省电。

提示：待机功耗同样重要。如果 MCU 不能进深度睡眠，放着不用几天电就没了。我的做法是长按开机、无操作 5 分钟自动休眠，休眠电流控制在 1mA 以内。

2.3 为什么坚持离线而不是联网

这一点值得单独说。离线不只是"省钱"或者"隐私"这么简单，它直接决定了设备的可用边界。我遇到过太多次在地下室、电梯、偏远地区录音的场景，联网方案直接废掉。而离线方案只要电够、卡够，随时随地都能录、都能转。

从技术角度看，FunASR 本身就是为离线场景设计的，模型可以量化压缩，在普通 CPU 上就能跑出不错的速度。把转写放在本地，意味着你不需要为每分钟音频付费，也不用担心服务突然涨价或者下线。数据全程在自己手里，这对做访谈、记会议的人来说是刚需。

3. FunASR 离线转写：从 WAV 到文字的关键几步

3.1 环境搭建与模型选择

转写这一环我用的是 FunASR。它的好处是中文识别效果好、支持标点恢复、有现成的多人识别（说话人分离）能力，而且能离线部署。环境搭建本身不复杂，但有几个坑要提前说。

首先是 Python 环境。我建议用 conda 单独建一个环境，避免和系统里的包打架。依赖安装的时候，torch的版本要和你的机器匹配，如果你有独立显卡，装 CUDA 版本会快很多；没有的话 CPU 版本也能跑，只是慢一点。

conda create -n funasr python=3.10 conda activate funasr pip install torch torchaudio pip install funasr pip install modelscope

模型方面，中文场景我推荐用paraformer-zh系列，识别准确率和速度平衡得比较好。如果需要标点，再叠加一个标点恢复模型；如果需要多人识别，就要用到说话人分离相关的模型。第一次运行会自动下载模型，文件不小，建议提前留好磁盘空间。

注意：模型下载走的是公共源，网络不稳定的时候容易中断。我的经验是先把模型缓存目录配置好，下载一次之后离线复用，后面就不需要再联网了。

3.2 转写脚本的完整写法

下面是我实际用的转写脚本骨架，做了简化，核心逻辑都在：

from funasr import AutoModel # 加载模型，指定模型名称和缓存目录 model = AutoModel( model="paraformer-zh", vad_model="fsmn-vad", punc_model="ct-punc", # spk_model="cam++", # 需要多人识别时打开 device="cpu", # 有显卡改成 cuda:0 ) # 执行转写 res = model.generate( input="record.wav", batch_size_s=300, hotword="项目 复盘 排期", # 热词可以提升专有名词识别率 ) for item in res: print(item["text"])

这里有几个参数值得展开讲。batch_size_s控制的是按秒切分的批处理长度，设大一点吞吐高，但内存占用也高，CPU 机器上 300 左右比较稳。hotword是热词，把你经常出现的专有名词、人名、项目代号塞进去，识别率会有肉眼可见的提升，这个技巧很多人不知道，实测非常有用。

vad_model是语音活动检测，作用是自动切掉静音段，既提速又避免把静音识别成乱码。punc_model负责加标点，没有它输出就是一大坨没有断句的文字，可读性很差。多人识别则要靠spk_model，它会输出每段话对应的说话人编号。

3.3 多人识别：谁在说话这件事怎么落地

多人识别（说话人分离）是这个项目里我觉得最有价值的功能之一。开会的时候，光有文字没用，你还得知道哪句话是谁说的。FunASR 的说话人分离模型会给每段语音打上说话人标签，输出类似"说话人1：…… 说话人2：……"的结构。

但这里有个现实问题：它只能区分"不同的人"，不能告诉你"这个人叫什么"。也就是说，它输出的是说话人 1、2、3，你需要自己映射到具体名字。我的做法是在转写完成后，人工过一遍，把说话人编号替换成真实姓名，或者根据声纹特征做个简单的映射表。如果会议固定是那几个人，可以提前录一段每个人的样本，做声纹注册，后面自动匹配，这个属于进阶玩法，后面章节会提。

多人识别对录音质量要求比较高。如果两个人同时说话（重叠语音），分离效果会明显下降。所以录音时尽量让麦克风离说话人近一点，减少混响和串音。这也是为什么我在硬件上坚持用数字麦、并且把麦克风开孔放在卡片正面中央的原因。

3.4 50+ 语种是怎么支持的

标题里写的 50+ 语种，靠的是 FunASR 生态里的多语种模型以及可切换的模型组合。中文、英文是基础，其他语种需要加载对应的模型。实际使用中，我的策略是"按需加载"——平时只加载中英文模型，需要其他语种时再切换，避免一次性把所有模型都塞进内存。

语种识别这块，可以先用一个轻量的语种检测模型判断音频是什么语言，再路由到对应的转写模型。这样用户不需要手动选语种，体验会好很多。不过要提醒一句，小语种的模型体积和识别效果差异较大，实际部署前最好拿真实音频测一遍，别只看文档里的支持列表。

4. DeepSeek 生成思维导图：把流水账变成结构

4.1 为什么用大模型做整理而不是规则

转写出来的文字是一大段流水账，直接看很累。传统做法是用规则提取关键词、按时间分段，但效果很僵硬，遇到口语化的内容基本失效。大模型的好处是它能理解语义，把"我们下周先把接口对齐，然后测试那边跟进"这种话，归纳成"接口对齐（下周）→ 测试跟进"这样的结构。

我选 DeepSeek 的原因是它在中文理解和结构化输出上表现稳定，而且支持较长的上下文，一次处理一整场会议的转写文本没问题。更重要的是，它的输出格式可控，我可以通过提示词让它直接吐 Markdown 或者思维导图能识别的层级结构。

4.2 提示词设计的几个关键点

提示词这块我调了不少版本，最后稳定下来的思路是：明确角色、明确输出格式、明确层级深度、给一个示例。下面是我用的提示词模板：

你是一个会议纪要整理助手。请把下面的转写文本整理成思维导图结构。 要求： 1. 用 Markdown 多级标题表示层级，最多三层 2. 一级节点是主题，二级节点是议题，三级节点是具体结论或待办 3. 保留关键人名、时间、数字 4. 去掉口语化的重复和语气词 5. 如果出现待办事项，统一放在"待办"节点下 示例： # 主题 ## 议题A ### 结论1 ### 待办：xxx 转写文本如下： {text}

这里最关键的是"给示例"。大模型对格式的理解，给一个例子比写十句描述都管用。另外"最多三层"这个限制很重要，不限制的话它可能给你整出五六层，思维导图反而看不清。

4.3 从 Markdown 到思维导图的转换

大模型输出 Markdown 之后，转成思维导图就简单了。Markdown 的标题层级天然对应思维导图的节点层级，写个脚本解析一下就行。我用的方案是解析#、##、###的层级，生成对应的树结构，再导出成常见的思维导图格式（比如 OPML 或者直接生成图片）。

import re def md_to_tree(md_text): lines = md_text.split("\n") root = {"title": "root", "children": []} stack = [(0, root)] for line in lines: m = re.match(r"^(#+)\s+(.*)$", line.strip()) if not m: continue level = len(m.group(1)) title = m.group(2) node = {"title": title, "children": []} while stack and stack[-1][0] >= level: stack.pop() stack[-1][1]["children"].append(node) stack.append((level, node)) return root

这段代码的核心是用一个栈来维护当前层级路径，遇到更深的标题就往下压，遇到更浅的就弹出来。逻辑不复杂，但很实用。生成树结构之后，你可以导出成任意格式，也可以直接渲染成图片。

提示：如果转写文本特别长，建议先按时间或话题切段，分段送给大模型整理，最后再合并。一次性塞太长的文本，模型容易"忘记"前面的内容，输出质量会下降。

5. 三天搭建实录：时间线、踩坑与排查链路

5.1 第一天：硬件点亮与录音验证

第一天基本都在和硬件较劲。焊好板子、烧录固件之后，第一个问题是麦克风没声音。排查过程是这样的：先确认 I2S 时钟有没有输出，用示波器一看，时钟正常；再查数据线，发现是引脚映射配错了，改过来之后就有波形了。这个坑很典型——I2S 的引脚配置一定要对着芯片手册一个一个核对，别凭记忆。

录音验证通过之后，我录了一段自己的朗读，存成 WAV，拿到电脑上用 FunASR 跑了一遍。第一次跑出来效果一般，后来发现是采样率不匹配——录音是 16kHz，模型也要求 16kHz，但我中间某一步重采样搞错了。统一采样率之后，识别率立刻上来了。这个教训是：音频链路上任何一处采样率不一致，都会拖垮识别效果。

5.2 第二天：转写链路打通与多人识别调试

第二天主要调转写。单人识别很快跑通，多人识别卡了挺久。问题出在说话人分离模型对音频长度敏感，太短的片段分离不准。我的解决办法是先做 VAD 切分，把长静音去掉，再把有效语音按说话人聚合，效果就好了很多。

还有一个坑是热词。一开始我没加热词，项目里的一些专有名词全被识别成了同音的常用词，读起来很别扭。加上热词之后，这些词基本都能正确识别。热词这个功能强烈建议大家用起来，尤其是你的内容里有大量专业术语的时候。

5.3 第三天：大模型整理与整体联调

第三天把转写结果喂给 DeepSeek 做整理。第一次输出格式很乱，层级忽深忽浅。后来在提示词里加了"最多三层"和示例，输出就规整了。联调阶段还发现一个问题：整条链路跑下来，一场一小时的会议，转写加整理大概要十几分钟。这个速度可以接受，但如果想更快，可以考虑用显卡加速转写，或者把长音频切段并行处理。

整个三天下来，最大的体会是：软硬件结合的项目，问题往往出在"接口"上——采样率、引脚、数据格式、编码，任何一个环节对不上，整条链路就断。排查的时候一定要分段验证，先确认录音没问题，再确认转写没问题，最后确认整理没问题，不要一上来就怀疑最复杂的部分。

6. 几个容易被忽略的细节与进阶玩法

6.1 音频质量决定一切

这句话我要重复三遍：音频质量决定一切。转写准确率的上限，在录音那一刻就定死了。麦克风选型、摆放位置、录音环境，比后面换什么模型都重要。我的经验是，麦克风尽量靠近声源，避开风扇、空调出风口这些持续噪声源，录音时提醒大家说话别叠着说。这些看似琐碎的细节，对最终效果的影响远超你的想象。

6.2 声纹注册实现"自动认人"

前面提到多人识别只能给出说话人编号。进阶玩法是提前给每个常用说话人录一段样本，提取声纹特征存起来，转写时把分离出的说话人特征和库里的做比对，自动匹配姓名。这样开会就不用事后手动标注了。实现上可以用 FunASR 生态里的声纹模型，思路是"注册 + 比对"两步，感兴趣可以自己试试。

6.3 续航与散热的平衡

20 小时续航是理想值，实际使用中如果环境温度高，电池放电效率会下降，续航会缩水。另外充电时如果同时录音，发热会比较明显。我的建议是充电和录音尽量错开，外壳上留好散热孔，电池不要紧贴主控芯片。这些都是小细节，但直接影响设备的稳定性和寿命。

6.4 数据管理别偷懒

录音文件会越积越多，TF 卡再大也会满。我的做法是每次转写完成后，把 WAV 压缩归档，只保留转写文本和思维导图。如果涉及敏感内容，转写完成后直接删掉原始音频。数据在自己手里是好事，但也意味着备份和清理都得自己负责，别等到卡满了才想起来。

7. 关于成本、边界和我个人的一点体会

回到最开始那个问题：199 元、三天、一张离线 AI 录音卡，这件事到底值不值。我的答案是值，但它的价值不在于省了多少钱，而在于你完整地走通了一条"采集—转写—整理"的离线链路，并且这条链路上的每一个环节你都能自己掌控、自己修改、自己扩展。

它也有明确的边界。离线意味着算力有限，超长音频的转写速度不会太快；多人识别在重叠语音下会打折扣；小语种效果参差不齐。这些不是缺陷，而是你在选型时就应该接受的取舍。想清楚自己要什么，比盲目追求"全能"重要得多。

我在实际搭建过程中最大的收获，不是学会了某个模型怎么调，而是养成了"分段验证、逐层排查"的习惯。软硬件结合的项目，最怕的就是一上来就盯着最复杂的地方看，结果发现是根线接错了。把复杂问题拆成一段一段，每段单独验证，问题往往自己就浮出来了。

如果你也想动手做，我的建议是先从录音和转写这一段跑通，别急着上大模型整理。把最基础的链路走顺了，后面的每一步都是锦上添花。硬件选型上，麦克风和电源管理这两块别省钱，它们决定了这个设备能不能真正用起来。至于外壳、按键这些，能用就行，第一版丑一点没关系，先跑通再优化。