企业官网建设流程全解析

国庆假期的前两个晚上，我都在听一支旧录音笔里的会议录音。一个小时的内容，两倍速回放也要从头听到尾才能找出重点，最崩溃的是要找第38分钟的一句话，要么反复拖进度条，要么干脆把整段再听一遍。后来实在受不了，我把录音笔扔进了抽屉，然后打开购物车，加了一张开发板、一块数字麦克风、两颗18650电池。三天之后，我手边多了一块总成本199元的开源AI录音卡：本地录音、FunASR离线转写、50+语种识别、多人说话区分，最后DeepSeek把文字变成思维导图，录音模式续航能到20小时。

接下来我把整个项目的设计思路、三天排期、各个技术环节的落地细节以及踩过的坑一次说清楚，包括成本拆解和复现清单。

1. 先说结论：一块199元的录音卡，凭什么能替掉上千元的AI录音笔

1.1 普通录音笔和我真正需要的差距

普通录音笔其实只做了一件事：把声音存下来。听起来没问题，但对需要“整理信息”的人来说，真正的成本从录音结束才开始。一小时录音，回听一小时，整理要点又半小时；如果临时要找某个人说的某句话，传统录音笔的体验几乎是灾难。我之前也用手机录音，虽然随时能录，但一来容易被通知打断，二来录一上午手机就发烫，三来所有音频都堆在手机里，最后还是要手动处理。

市面上的“AI录音笔”确实把转写做成了标配，但价格基本从大几百到上千元，而且多数是封闭系统：不能用自己喜欢的中文离线模型，不能自定义转写流程，也不能把总结结果接到自己的笔记工作流里。我想要的是一个能自己决定每一步的采集设备：便宜、开源、录音时长足够长、转写完全本地化、总结部分可以用自己习惯的大模型API。所以干脆自己动手，三天时间做一块“开源AI录音卡”。

1.2 产品逻辑：录音卡只做采集，桌面工作流做转写和总结

这块卡的工作链路可以概括成一句话：按键录音，存到TF卡；回到电脑后，把卡里的音频批量交给FunASR离线转写；转写文本带着时间戳进入DeepSeek，再被整理成Markdown格式的思维导图。

这里有一个关键决定：FunASR不跑在录音卡上，而是跑在电脑上。原因很简单，在199元硬件和20小时续航两个约束下，让MCU跑ASR模型完全不现实。我的“离线”定义是：音频文件和转写过程都不离开本地这台电脑。录音卡端只做采集，不联网、不转写、不上传，这样可以把整机功耗压得非常低；回到电脑后，FunASR在本地CPU上完成转录，再把纯文本交给DeepSeek做结构化总结。音频永远不下发，这对我这种经常录访谈、录会议的人非常重要。

1.3 三天做出来的东西能干什么

最终作品可以做到：按一下开始录音，再按一下暂停；每个录音文件以日期和时间命名，直接落在TF卡里；支持连续录音20小时以上，基本覆盖一天不充电的使用；回电脑后运行一条桌面工作流，中文音频走FunASR离线转写，多语种音频自动分流给多语种模型，输出带时间戳的全文；DeepSeek把全文压缩成三层左右的思维导图大纲，可以导入常见的思维导图工具继续编辑。

适合谁，我列个范围：经常整理会议纪要的上班族，需要回看课堂重点的学生，做访谈和播客的人，以及所有对音频隐私敏感、不想把录音传到云端的用户。如果你只是想找个“能录音的玩具”，那这个项目反而没必要做；它的价值在于构建一整套从声音到结构化文字的完整流水线。

2. 三天开发路线：WorkBuddy怎么把硬件、转写和总结串起来

2.1 WorkBuddy在项目里的实际角色

完整项目其实由四块组成：硬件、MCU固件、电脑端转写脚本、LLM总结提示词。如果靠传统流程一步步来，光调试USB串口、搭Python环境、调提示词就可能耗掉两天。这次我用了WorkBuddy，它是一个面向设备端加AI工作流的低代码工作台，可以理解为把“固件骨架生成”“硬件调试”“桌面端数据处理”“LLM节点编排”放在同一个项目画布里。

我实际使用的方式是这样的：先建一个项目，把录音卡作为一个“设备”注册进去，WorkBuddy会生成一份可编译的固件工程，包括按键扫描、LED状态、录音到SD卡的底层驱动骨架，省掉了从头查寄存器的时间。然后在电脑端节点区里，把“导入音频”“FunASR转写”“语种路由”“DeepSeek总结”“导出Markdown”这五个节点拉出来连好，每个节点只需要填参数和脚本路径。整个项目从零到跑通，三天时间基本是够用的。

2.2 Day 1：硬件搭好，固件能录音

第一天我做的全是“能不能录”的事。把数字麦克风焊到转接板上，接到ESP32-S3的I2S接口；TF卡槽接好SPI线；电池通过充电保护模块供电，用一颗自锁开关做整机电源；加两颗按键，一颗录音/暂停，一颗长按标记重点段落（会在文件名里追加一个marker后缀）。

固件端的逻辑也不复杂：按下录音键，SD卡里新建一个WAV文件，麦克风以32kHz、16bit、单声道的格式连续采样并写入；再按一次，关闭文件、进入待机。为了防止按键抖动误触发，我在固件里做了50ms消抖和2秒长按确认，宁可多按一下也不要误启停。第一天结束时，已经能用按键录出一段能正常播放的WAV，这个里程碑比什么都重要。

2.3 Day 2：本地FunASR转写流水线跑通

第二天不碰硬件，专攻转写。我在电脑上装了FunASR及其依赖，下载了中文离线模型。WorkBuddy里的“FunASR转写节点”实际上会调用一个Python脚本，批量扫描SD卡目录下的WAV文件，对每个文件做三件事：VAD切分、语音识别、结果合并。脚本最终输出两个文件：一个带时间戳的全文txt，一个按说话段落分行的精简版。

这一步完成后，我先把一段20分钟的会议录音丢进去测试，第一次跑出了带标点和数字格式化（比如把“三千二百”转成3200）的文本，效果比预期好。当然后来也踩了不少坑，比如模型首次加载特别慢、长音频内存占用暴涨、标点恢复在语速极快时会乱断句，这些第三节会展开讲。

2.4 Day 3：DeepSeek总结、外壳和整机压测

第三天同时推进三件事。第一件，在WorkBuddy里把DeepSeek总结节点接上，测试提示词，把转写文本转成Markdown大纲；第二件，把3D打印的外壳装起来，用热熔胶固定电池和麦克风，确保按键手感正常；第三件，连续录音压测，我特意把设备开着录了一整个下午，晚上看文件时长和电量，顺便验证了它不会中途过热。

最后再跑一遍完整链路：录音卡回放的是一段课堂讨论现场录音，转写后DeepSeek生成了一份包含“核心问题、各方观点、结论、待办事项”四个分支的思维导图。到这里，这块成本199元的录音卡已经完成从物理采集到结构化输出的全部闭环。

3. FunASR离线转写与多人识别的落地细节

3.1 为什么选FunASR而不是云端ASR

作为一个长期在意音频隐私的人，我把FunASR放在第一选择。它能完全本地部署，不需要把音频传出去，也不按小时计费；中文识别效果在开源方案里属于第一梯队，并且把VAD、标点恢复、逆文本正则化这些常见后处理都打包进了一套API里，省去自己拼多个模型的麻烦。对批量转写场景，它的Python接口非常友好，把目录一整个丢进去就能得到时间戳文本。

需要说明的是，标题里说的“离线语音转写”就是指FunASR跑在本机，录音数据不出本地。如果你的电脑性能一般，CPU跑一小时音频大概需要1至3分钟，完全可接受；有GPU最好，速度能拉到接近实时。部署时注意把模型下载到固定缓存目录，第一次运行会比较慢，之后秒加载。

3.2 部署参数和转写节点配置

在WorkBuddy的转写节点里，我用的是这个组合：离线VAD模型负责切分语音段，中文Paraformer模型负责识别，再挂标点恢复和逆文本正则化模型做后处理。对一个WAV文件，核心流程就是“读音频、VAD分段、逐段识别、合并”。如果音频超过一小时，建议先按VAD的结果把静音段切掉再批量跑，不然内存会吃紧；我实测一段70多分钟的音频，直接整文件跑内存明显上涨，切片后再跑，内存占用大幅下降，速度反而更快。

脚本输出我做成两种：全文版保留起止时间，方便回放定位；精简版只保留每句话的内容和说话段落序号。转写精度在安静房间、普通话、单人的情况下，主观感觉可以到很高水平；有背景音乐或多人叠话时，错误会明显增加，这属于模型适用边界，不要指望它比人耳强。

3.3 多人识别：怎么区分谁说了哪句话

标题里的“多人识别”，我实现的方式是说话人分离。思路比较简单：先用VAD把音频切成一个个短句，每句话通过说话人嵌入模型提取一个向量，再把所有向量做聚类，让同一人的句子尽量聚到同一类。最后把类别编号写进时间戳，比如[00:03:12-00:03:20] speaker_1: ...。如果会议里你认识这几个人，用后处理脚本把speaker_1替换成名字就行。

实际操作中，聚类个数需要先预估。我用的聚类算法是凝聚层次聚类，n_clusters设为4，刚好对应那次四人讨论；设少了会把不同人合成一个，设多了会把一个人拆成两半。说话人分离对音频质量比较敏感，麦克风最好放在几个人的中间，距离超过两米效果会明显下降，两人同时抢话时也会串，这些都不是模型能解决的物理问题。

3.4 踩过的最疼的几个坑

第一，模型首次加载慢得要命。离线模型动辄几百兆，第一次调用要解压和初始化，我一度以为脚本卡死了。解决办法是提前跑一个空音频热身，或者设置固定的模型缓存目录。

第二，标点恢复不是万能的。快速抢话、重复语气词、话没说完被打断，标点模型经常点错。我后来把转写文本交给DeepSeek清洗时，专门加了一条“不要补造原文中不存在的观点”，幻觉风险低了很多。

第三，时间戳会有小偏差。因为VAD切段后独立识别，每段之间会有一点边缘吞字，导致时间戳偏差在几百毫秒到一秒之间。定位一句话没问题，但要做逐字字幕对齐就不够准，这种需求建议换帧级对齐方案。

4. 50+语种覆盖：多语言识别方案的真实边界

4.1 中文之外，凭什么敢说50+语种

这里必须诚实说：FunASR生态里表现最好的是中文，而50+语种这个能力来自配套的多语种开源语音模型。我的思路是把它们组合起来：中文和英文优先走FunASR离线转写，因为速度和中文后处理最好；日、韩、法、西、德等语种音频，则分流给多语种模型SenseVoice。它在公开描述里支持50+语种识别，还在同一套模型里输出语言标签和事件标签，这是我把“50+语种”写进标题的底气。

多语种模型确实比较大，CPU推理速度比中文Paraformer慢不少。所以我的工作流里加了一个“语种路由节点”：先截取前15到20秒音频，让多语种模型快速判断语言标签；如果是中文或英文，切回加速通道；如果属于小语种，才进入完整识别流程，并把语言标签写进输出文件名。这个策略让大多数中文场景不牺牲速度，同时又保留了多语种能力。

4.2 一个模型打天下，在语音里行不通

很多人以为语音识别应该像翻译一样一个模型通吃，实际情况差很远。不同语种的音素、重音、书写规则差异太大，单一模型为了覆盖更多语种，在每个语种上通常都要让出一部分精度。中英文还好，因为它们训练数据最多；日语的长音和促音、法语的连读、带口音的德语，单模型很容易翻车。

所以我的做法是：先判语言，再选模型。中文永远走FunASR，其它语种走多语种模型。表面上是多了一步，实测比“无论什么音频都硬塞给同一个模型”的准确率要稳得多，尤其在中文和外语混杂的会议上，优势非常明显。

4.3 实测语种表现

我简单测过几段公开的新闻音频（时长都在3分钟左右），主观结果如下：

这些结果和模型训练语料的丰富程度直接相关。标题里写“50+语种”，我的实际态度是：作为能力覆盖是达标的，作为可靠识别率则要看语种和口音。把它当多语种音频搜索索引来用，压力不大；但如果是商务级交传录音，请务必人工校对。

4.4 多语种方案的使用建议

结合这次实战，我建议这样用：混合语种的会议，先做语言分段再分别转写；单一大段小语种音频，不要迷信配置高，把时长控制在5分钟一段以防上下文错乱；带专有名词的音频，在提示词或脚本里注入术语表。最重要的是，千万不要为了炫“多语种”就把所有中文音频也塞给多语种模型，同一段录音，中文专用模型明显更准，数字和单位格式化也更好。

5. DeepSeek从转写文本到思维导图：提示词设计与效果调优

5.1 为什么选DeepSeek当总结大脑

转写只是第一步，真正把录音变成可用的笔记，还得靠LLM做归纳。我选DeepSeek的原因有三点：它对中文长文本的理解和归纳能力在同价位里表现突出；API定价对我的高频整理场景很友好；而且它的输出适合严格结构化，我在提示词里要求“只输出Markdown无序列表”，它基本能稳定遵守。

在整条流水线里，DeepSeek拿到的输入是带时间戳的转写文本，而不是原始音频。这一步极其关键，它等于在隐私边界上做了一层过滤——录音音频只存在于我的电脑，发出去的只是剥离了音频特征的文字内容。加上我本身也不会上传包含真实姓名和敏感细节的原文，而是先要求模型做脱敏替换，这属于使用习惯层面的自我保护。

5.2 可复制的提示词模板

我给DeepSeek总结环节设计的提示词，稳定跑了十几个录音文件，效果比较可靠，可以直接套用：

你是一个会议/录音整理助手。我将给你一段带时间戳的语音转写文本，请你： 1. 先通读全文，找出真正核心的主题，不要被闲聊带偏； 2. 输出一份Markdown无序列表，最多4层，根节点作为一级标题； 3. 每个节点尽量不超过15个字，保留关键数字和人名（人名可用A/B/C代替）； 4. 对不确定的内容标注[存疑]，绝不编造原文没有的信息； 5. 最后单独列出“待办事项”和“可以忽略的寒暄”。 文本： {{TEXT}}

这个模板的好处在于两条硬限制：明确要求“不编造”，并用“[存疑]”兜底；明确要求分“核心内容”和“待办事项”，让输出天然适合做行动清单。如果你是整理访谈而不是会议，可以把它改为“按提问顺序保留问答结构”，默认模板也够用。

5.3 长文本分块与结果合并

DeepSeek的上下文窗口足够长，但一次性塞进两小时的转写文本，输出质量会下降，容易出现前详后略。我的经验是按VAD句子切块，每30分钟左右一段，分别让模型总结，再把各段的Markdown大纲合并。合并时让DeepSeek做“去重和层级合并”，它在几千字规模上的处理非常稳，不会丢关键信息。

分块还有一个额外好处：可以中途人工干预。假设第二段里某个讨论特别重要，我可以单独对第二段追加提问“这段里A提出了哪三个理由”，得到一个更细的子大纲，插入到原大纲对应位置。这比整篇一次性总结灵活得多。

5.4 从Markdown大纲到可视化思维导图

DeepSeek输出的是标准Markdown无序列表，接下来只要做一次格式转换就能变成思维导图。我的做法是保存为.md文件后，用markmap这类工具把它渲染成可交互的HTML思维导图；也可以直接放进支持大纲导入的思维导图软件里编辑，比如常见的XMind流程。如果你不想装新工具，还有个更朴素的办法：把大纲直接扔到支持Markdown的笔记软件里，折叠列表本身就等价于一个思维导图。

我之前试过让模型直接输出XMind格式，结构表达确实更丰富，但一来输出不稳定，二来格式脆弱，一个小括号错误整个文件就解析失败。Markdown是最简单、最不容易出错的中间格式，后续想转成任何工具都方便。强烈建议你也用Markdown做中间层。

5.5 效果调优：术语表、去口语化和多次总结

最后分享三个调优细节。第一，专业术语很容易被转写模型写错，我准备了一个术语表文件（一行一个正确写法），在给DeepSeek的提示词末尾追加“以下专有名词请按括号内写法修正”，人名、产品名、缩写的错误率立刻降下来。第二，语气词、重复词、口头禅会消耗LLM的注意力，我在转写后先跑一个正则脚本把“嗯、啊、就是、然后”这类高频词做温和清理，再送进总结，输出明显更干净。第三，一次总结不一定够，正式场合的录音我会让它连续生成三版不同详略的大纲，一份极简版用于快速同步，一份完整版用于写文档，一份带时间戳跳转版用于复盘。

6. 20小时续航与复现清单：物料、功耗和开源内容

6.1 为什么这块卡能连续录音20小时

续航的秘密不在电池多大，而在“不该干活的时候绝对不干活”。录音时它只做两件事：麦克风采样和写TF卡，主频不用拉满，Wi-Fi完全不打开，屏幕根本不用亮。待机时直接进深度睡眠，只保留一颗按键的中断唤醒，整机电流能压到微安级别。再加上转写和总结都在电脑端完成，录音卡本身不需要承担任何AI计算，这是20小时续航最核心的前提。

用一个简单公式估算续航：续航约等于电池容量乘以电源效率，再除以平均工作电流。我用的电池是两颗18650并联，标称总容量5000mAh；连续录音实测整机电流约180mA（含TF卡写卡损耗），按0.9的效率系数算下来是5000×0.9÷180=25小时左右。为了给电池老化留余量，我把标称续航写成20小时，非常保守，实测从满电录到自动关机超过23小时。

6.2 三个关键硬件决定

第一个决定是主控功耗档位。我选了带低功耗模式的ESP32-S3，并把CPU频率限制在160MHz，录音时跑80MHz就足够。第二是电源架构。输入电池电压经一颗低静态电流的LDO稳压给主控，按键开关放在电池和LDO之间，待机时整条电源链路断开，避免漏电。第三是存储选择。TF卡写卡功耗比NAND Flash方案略高，但胜在容量便宜、换卡方便，32G的卡够录20小时以上，完全没有容量焦虑。

值得注意的一个经验：便宜的TF卡在断续写入时可能掉速，造成录出来的音频有卡顿。我最后用的是一张标注A1以上的卡，并且把写入方式设置成每次写8KB块，实测连续录音过程中没有出现坏块问题。如果你测出音频有咔哒声，不用怀疑算法，先查卡。

6.3 各档位电流与实测续航

实测在一个充电周期里：上午连续录音4小时，中午深度睡眠2小时，下午再录5小时，晚上读取文件半小时，24小时后电池电压从4.15V降到3.92V，距离关机还有明显余量。所以“20小时长续航”不是空话，它是把低功耗做到位以后的正常结果。

6.4 199元物料清单

很多人关心这199元到底买了什么，我列一份当时的采购清单，单价是大概行情，不同时间段会有点浮动：

合计下来大约150元到180元之间，剩余预算用来买若干备用麦克风和线材。实际上如果手里有现成的开发板和电池，成本还能再压到100元以内。所以“199元”是一个留了余量的目标值，不是死线。

6.5 开源仓库里放了什么

为了让其他人能复现，我把项目按四层开源了：第一层是硬件，包括原理图和PCB工程文件、3D打印外壳STL；第二层是MCU固件，包括按键消抖、WAV写入、电量读取的完整源码；第三层是电脑端工作流，WorkBuddy项目文件、FunASR转写脚本、多语种路由脚本都放在里面；第四层是LLM提示词模板和示例输出。你只需要照着BOM买料，按仓库里的README烧录固件，然后在电脑上配置好Python和WorkBuddy环境，就能从零复现这块卡。

如果你不想自己焊板子，也可以先只复用电脑端工作流：用手机录音，传到电脑后用同一套FunASR离线转写和DeepSeek总结脚本，同样能得到思维导图。硬件部分只是让采集环节更省心，真正的核心价值都在软件工作流里。

最后说一个我重做一遍一定会改的地方：麦克风模块的排线一开始被我焊得太长，导致录音底噪偏大，后来换成10厘米以内的短线，底噪立刻小了很多。这类低功耗采集设备，排线长短、焊点松紧、TF卡速度等级，这些细节往往比算法调参更影响实际听感。如果你也想做一个属于自己的AI录音卡，建议从小批量原型开始，录一段、听一段、改一段，再逐步把功能加完整。