AI录音卡技术——科普文

从 MEMS 采集到 LLM 后处理 · 端云协同架构全览

▲ 典型 AI 录音卡端云分层架构（Edge → Transport → Cloud → App）

2025 年以来，Plaud、钉钉 A1、讯飞录音卡等产品把一条旧赛道重新点燃：信用卡大小的磁吸硬件，背后接的是 ASR + LLM 的完整语音理解管线。它不是「加了 AI 的录音笔」，而是一套 offline-first 的语音数据采集与结构化系统。本文从工程视角拆解其硬件栈、音频前端、同步策略与云端推理链路。

01 产品定义：采集器，不是播放器

从系统架构看，AI 录音卡处于「感知层」：负责把非结构化的声学信号，转化为可索引、可检索、可下游消费的文本资产。输出物不是 .wav，而是带时间戳的 transcript + 结构化 summary。

典型数据流：Mic Array → AFE（音频前端）→ Encoder（OPUS）→ Local Flash → Sync → ASR → LLM Post-process → App/Workflow。

02 硬件栈：3mm 机身里的工程约束

▲ 磁吸卡片式：机身极限压缩下的声学 + 续航权衡

声学：2~4 颗 MEMS 麦克风 + 可选 VPU（Voice Processing Unit）；高端型号（如 Plaud Note Pro）做 beamforming，远场拾音 3~5m

传感：部分卡片集成压电振动传感器（VCS），用于通话侧录——下文详述

编码：OPUS 16kHz / mono 为主流，码率 16~32kbps，兼顾体积与 ASR 友好度

存储：32~64GB 本地闪存，offline-first：弱网/飞行模式可录，回连后批量 sync

连接：BLE 5.0 控制面 + Wi-Fi Direct 传大文件（部分型号）；充电多为磁吸或 USB-C

续航：连续录音 20~50h（取决于采样策略与 DSP 负载），待机可达 30~60 天

工程要点：机身厚度被压在 3~4mm 时，电池、天线、麦阵的 layout 是零和博弈。「轻薄」和「远场 SNR」往往不可兼得，产品会在 Enhance / Endurance 模式间做 trade-off。

03 音频前端（AFE）：决定 ASR 上限的隐形层

▲ 声学信号进入云端前的关键处理阶段

原始 PCM 直接送 ASR 在真实场景下几乎不可用。设备端或近端必走 AFE 管线：

VAD Voice Activity Detection——切分有效语音段，降低无效上传与算力浪费

AEC Acoustic Echo Cancellation——消除扬声器回声，电话会议场景必备

NS Noise Suppression——抑制稳态噪声（空调、风扇）；大厂会做场景化噪声库（讯飞宣称 80+ 类）

AGC Automatic Gain Control——远近说话人响度归一，避免 ASR 因动态范围崩溃

做完 AFE 后编码为 OPUS 帧（常见 20~60ms/frame），写入本地队列。这与实时语音 Agent 的上行链路同源——区别只是 AI 录音卡把「实时」换成了「异步批量」。

04 通话录音的工程 Hack：VCS 振动传导

iOS / Android 对第三方 App 录通话有严格限制——这是 OS 级隐私策略，不是 bug。

卡片式产品的解法：在手机背面贴一颗 Voice Conduction Sensor（压电/振动传感器）。它不采空气声场，而是感知机身振动——听筒/扬声器发声时，金属/玻璃背板会产生可检测的机械波。硬件 toggle 切换到「Call Mode」后，VCS + 空气麦双通道采集，绕过软件层通话录音禁令。

Phone Call Mode:
  Air Mic  ──┐
             ├──> Mix / Align ──> OPUS ──> Flash
  VCS Piezo ─┘     (time sync critical)

这是典型的 hardware workaround：工程上有效，但依赖手机材质、贴合度、通话音量，且可穿戴形态（NotePin、吊坠）通常不具备 VCS，只能走 speakerphone 降级方案。

05 同步策略：Offline-First 与隐私边界

·录时不上云：音频先落本地 Flash，降低实时带宽压力，也满足高敏场景合规诉求

·增量 sync：App 唤起后通过 BLE 传元数据、Wi-Fi 传音频包，支持断点续传

·端侧加密：部分产品（UMEVO 等）宣称 AES 设备端加密，密钥策略决定能否过企业安全审查

·云端推理：ASR / LLM 多在服务端执行，数据出境、留存周期、训练 opt-out 是 ToB 采购必问项

架构取舍：Ambient Always-on（Limitless 路线）走 cloud-first，数据主权风险高，2025 年底 Limitless 被 Meta 收购后硬件停产——行业向 intentional recording（按键/长按触发）收敛。

06 云端管线：ASR → Diarization → LLM

音频上云后的处理可分三级，每级有独立的技术选型空间：

L1 · ASR
  Whisper 系、Conformer-Transducer、GPT-4o-transcribe 等；支持 streaming / batch 两种模式。方言、口音、领域词表（热词）决定 CER/WER。

L2 · Diarization
  Speaker Diarization（说话人聚类 + 分段），输出「谁在什么时间说了什么」。会议室多人场景的核心能力，算力成本高于纯 ASR。

L3 · LLM Post-process
  摘要、action items 提取、模板化输出（会议纪要 / 访谈 / 销售跟进）。Plaud 等多模型路由（GPT / Claude / Gemini），国内产品多绑星火、通义等。

进阶玩法：Shadow AI / Agentic 路线（TicNote）在 transcript 之上做跨文档 RAG 和推理，把单次录音接入个人知识库——这已经超出「转写工具」，进入 voice-as-data-source 范畴。

07 形态分流：卡片 vs 可穿戴的设计权衡

▲ 三种硬件形态及其传感能力差异

08 软件架构：四条技术路线

▲ 产品层分化：同一硬件形态，不同 downstream 集成深度

SaaS 工具链（Plaud / UMEVO）
  硬件获客 + 订阅变现；核心是 Template Engine 和多模型 API 编排，弱绑定办公生态，跨平台能力强。

Workflow Agent 入口（钉钉 A1）
  录音→ 结构化 → 待办/审批/CRM 流转，硬件是 Agent OS 的数据探针，价值在 downstream automation 而非转写精度本身。

Voice KB / RAG（TicNote / 讯飞）
  强调长期知识沉淀、行业词库、跨会话检索；ASR 热词 + 领域 LM 是护城河。

生态配件（飞书× 安克）
  深度绑定单一协作平台，录音自动入库；换生态 = 硬件贬值，但内循环效率最高。

09 工程落地：选型与避坑清单

·拾音距离 vs 机身厚度：宣称 10m 远场需验证 SNR 和 beamforming 是否开启

·通话录制的合法合规：VCS 绕过了 OS 限制，但不绕开法律对告知同意的约束

·ASR 计费模型：订阅分钟数、说话人分离、多语言是否另收费——TCO 常被低估

·数据驻留：录音是否用于模型训练、留存多久、是否支持私有化部署

·生态锁定：飞书/钉钉配件在生态外几乎无价值，独立品牌则看 API 开放度

·白牌方案：华强北百元同款只有壳，ASR/LLM 质量取决于背后接哪家 API

结语

AI 录音卡的技术本质，是把语音链路里「采集」和「理解」两段解耦又串联：端侧做好 offline-first 采集与 AFE，云端做好 ASR + LLM 推理，应用层决定数据最终流入 SaaS、Agent 还是 Knowledge Base。

硬件门槛并不高——MEMS、BLE、OPUS、云端 API 均已 commodity 化。真正的壁垒在：远场声学调校、领域 ASR 优化、摘要模板工程，以及与工作流的集成深度。

TL;DR
AI 录音卡 = Offline-First 语音采集终端 + AFE/OPUS 端侧管线 + 云端 ASR/Diarization/LLM + 下游工作流集成。选型先看传感能力（有无 VCS）和数据流去向（独立 SaaS vs 办公生态）。