企业官网建设流程全解析

1. 复刻 Microduck 前，先想清楚你到底要做个什么

Microduck 是我最近折腾得最上头的开源项目，没有之一。说它是“鸭子”，它其实是一个能听懂人话、能开口回应、能转动脑袋看你的桌面级语音交互机器人。GitHub 上那个经典形象——一只黄色的机器小鸭，底座配了一块屏幕，头顶顶着一颗摄像头，看起来像个玩具，但拆开之后里面塞了一整套语音交互链路：麦克风阵列拾音、唤醒词检测、语音识别（ASR）、大模型推理、语音合成（TTS）、舵机控制，甚至还有一套基于 LoRA 的本地微调方案，可以让这只鸭子用你想要的人设说话。

我为什么强调“先想清楚你要做什么”？因为市面上的复刻教程十有八九只讲两步：下载代码、跑起来。然后新手兴冲冲 clone 下来，pip install一堆依赖，跑了个 demo，发现鸭子只会重复固定的几句话，摄像头画面也调不出来，舵机嘎吱嘎吱乱转，模型推理慢得跟树懒一样，最后热情耗尽，项目吃灰。这个项目真正的价值不在于“跑通”，而在于理解它把“语音机器人”这件事拆成了哪几个模块，每个模块在真实硬件上是怎么协作的。

Microduck 的定位非常像斯坦福的 OpenDuckmini（也就是网上常说的“机器鸭”），但它在开源社区里被进一步做了一些简化：硬件上尽量选用容易买到的舵机、麦克风阵列和开发板，软件上把模型推理、语音识别、语音合成全部抽象成了独立服务，模型训练也提供了一条完整的 LoRA 微调路径。所以它特别适合三种人：想入门多模态硬件交互的嵌入式开发者、想低成本体验大模型微调全流程的研究生、以及单纯想给桌面添一个能聊天的小玩意的极客。

我在完整复刻了一遍之后，最深的感受是：这项目给人的第一印象是“一个会动的语音助手”，但它真正教会我的，是一套“如何把云端大模型能力搬到本地硬件上”的工程方法论。接下来我就把我从零开始复刻的完整过程、中间踩过的坑、每个关键模块的取舍逻辑，全部摊开来讲。

2. 核心拆解：Microduck 各个模块都在干什么

2.1 它本质上是一个“循环”而不是一个“机器人”

先把这只鸭子的内部逻辑拆开看，你会发现它不是一个传统意义上的机器人，而是一个不断循环的交互闭环：

麦克风采集语音 → 唤醒词检测（Wake Word） → 语音识别（ASR） → 大模型生成回复（LLM） → 语音合成播放（TTS） → 头部舵机做出反馈动作 → 回到等待唤醒状态。

这个闭环里每一步都是一个独立模块，模块之间通过消息队列或 WebSocket 通信。这跟很多新手直觉里“一个程序干所有事”的思路完全不同。设计成独立服务的好处非常明显：任何一个环节挂了，其他模块不受影响；模型推理速度慢不会阻塞语音采集；你可以单独替换掉其中某一个模型而不需要动其他代码。这是我在复刻过程中认为最重要的架构思想，也是最值得迁移到其他项目里的经验。

具体到实现层面，Microduck 的主控程序通常跑在 Linux 开发板上（树莓派 4B 或类似配置），负责调度。语音识别用 faster-whisper 这类开源模型，大模型推理可以用 llama.cpp 加载量化后的开源模型（比如 Qwen 系列），语音合成选的是 Edge-TTS 或 Piper 这类轻量方案。舵机控制则通过 PCA9685 模块输出 PWM 信号，控制鸭子头部左右转动和上下点头。

2.2 为什么要用“本地大模型 + 可选云端”混合方案

Microduck 在模型调用上做了一个很聪明的设计：默认支持本地部署小模型，但也留了云端 API 的接口。这个混合方案我一开始不太理解——既然都开源了，为什么不直接用最好的模型？后来在复刻过程中才明白，这是对成本和体验的精准平衡。

本地部署意味着没有网络延迟，TTS 播报和头部动作可以做到跟对话几乎同步，鸭子看起来更“活”。但本地跑大模型吃内存和算力，开发板上跑 7B 模型已经很吃力，所以 Microduck 默认给的是量化到 4bit 的 1.8B 或 3B 级别小模型。这个规模放在 8GB 内存的开发板上能用 CPU 勉强推理，虽然生成速度不算快，但鸭子说一句话等两三秒，还在可接受范围内。反过来，如果你接云端大模型 API，回复质量会大幅提升，但每次对话都会有网络延迟，而且你得自己承担调用费用。

我在实际使用时用的是“本地模型保底、云端模型增强”的策略：默认唤醒后走本地小模型，保证离线也能用；当用户问一些需要长回答的问题时，我再手动切到云端大模型。Microduck 的代码里留好了这个切换的配置文件，改起来就是改几行 YAML，大家拿到手之后完全可以按自己需求调整。

2.3 别小看那只“会动的脑袋”：舵机联动设计

很多人复刻 Microduck 时，把 90% 的精力放在模型和语音上，最后卡在了“鸭子头不会动”或者“舵机抖动”这种看似不起眼的小问题上。实际上，头部动作恰恰是这个项目最有“灵性”的部分。Microduck 的舵机设计非常克制：头部只有两个自由度，左右偏航（Yaw）和上下俯仰（Pitch），底座固定，没有行走机构。这保证了结构简单、重心稳定，同时两个舵机已经足够表达“点头”“摇头”“左顾右盼”这些基本情绪。

控制逻辑上，Microduck 并不做复杂的视觉追踪，而是让舵机的动作跟系统状态绑定。比如：唤醒时头转向声源方向；识别语音时轻微点头表示“在听”；TTS 播放时嘴巴（如果有舵机控制的话）或头部有节奏地微动；待机时每隔几秒做一次缓慢的环视。这些动作被封装成一组“姿态模式”，大模型返回的文本如果包含特定情感标签，系统还能映射到对应的动作序列。这种设计给了我很大启发：交互机器人的“萌感”不在于自由度多，而在于动作和语义是否匹配。

3. 硬件选型与准备：照着买不踩坑

3.1 主控板：别只看算力，还要看外设接口

Microduck 的主控板选择，我在调研时发现社区里主要有两种方案。第一种是树莓派 4B（8GB 版本），Linux 生态最完善，各种驱动一应俱全，USB 麦克风阵列和摄像头基本都是即插即用。第二种是 RK3588 系列的开发板，NPU 算力强很多，跑起本地模型来速度更快，但驱动和软件生态相对折腾一些，很多教程都是针对树莓派写的，用 RK3588 的话要自己适配一部分代码。

我最终选了树莓派 4B 8GB，原因很朴素：资料多。Microduck 官方文档默认支持树莓派，社区里踩坑贴也最多，遇到问题基本直接搜就能找到答案。这里有一个重要提醒：不要买 2GB 或 4GB 内存的版本。本地跑 ASR 加上大模型推理，内存少了直接 OOM，我第一次用 4GB 版本试跑 3B 量化模型，系统直接卡死，换 8GB 之后流畅度完全不一样。

3.2 舵机和驱动板：角度和电流是关键

Microduck 的头部动作不复杂，所以对舵机的要求并不高。社区里用的比较多的是 SG90 或 MG90S 这类 9g 微型舵机，价格便宜、扭矩适中，带动这只鸭子的小脑袋绰绰有余。需要注意的一点是：Microduck 头部结构件如果是 3D 打印的，重量会比原版稍重，建议直接上 MG90S 金属齿轮版本，铜齿轮舵机耐磨损，避免长时间转动后出现虚位抖动。

舵机驱动板我选择的是 PCA9685 模块，这是一块 16 通道 12 位 PWM 驱动板，通过 I2C 接口跟树莓派通信。为什么要用独立的 PWM 驱动板而不是直接用树莓派 GPIO 输出 PWM？主要原因有两个。第一，树莓派本身的 PWM 通道数量有限且精度一般，PCA9685 可以输出多路独立 PWM，方便后续扩展。第二，舵机控制需要稳定频率（通常 50Hz），PCA9685 用晶振产生时钟，抖动比软件模拟 PWM 小很多。实际测试下来，用 PCA9685 驱动舵机，转动平滑度明显好于 GPIO 直接驱动，这个钱花得值。

3.3 拾音方案：阵列麦克风远比你想象的重要

语音交互项目里，麦克风是决定用户体验的第一道关卡。Microduck 放在桌面上的使用距离大约是一米到两米，普通 USB 麦克风在这个距离上拾音质量非常差，背景噪声一大，ASR 识别率直接崩。社区里普遍推荐 ReSpeaker 2-Mic 或 4-Mic 阵列麦克风，这类麦克风自带回声消除和波束成形功能，可以在一定程度上过滤环境噪声，还能粗略判断声源方向。

我实测下来的经验是：4-Mic 版本比 2-Mic 版本在声源定位上强很多，但价格也贵了一倍。如果你的使用场景是安静的桌面环境，2-Mic 完全够用；如果房间里有空调声、键盘声，建议直接上 4-Mic。另外，麦克风阵列接入树莓派之后一定要注意采样率配置，默认可能是 16kHz，但 faster-whisper 对 16kHz 的效果已经不错，如果你用其他 ASR 引擎，可能需要重采样到对应采样率，这个后面排查部分会细说。

3.4 外壳与组装：3D 打印优先，手工改造可行

Microduck 项目提供了一个非常可爱的鸭子外壳 STL 模型，可以直接 3D 打印。如果你手边没有 3D 打印机，也可以考虑用 EVA 泡沫和热熔胶手工打造——网上有人这么做出来，虽然精细度差一些，但 DIY 的乐趣更足。我在组装时遇到的一个问题是：打印出来的壳体公差控制不好，舵机转轴和头部连接件卡不住。解决办法是打印时把连接件的孔径调大 0.2mm，或者直接用 M2 螺丝加固。还有一个实用小技巧：在舵机臂和 3D 打印件之间垫一层薄橡胶垫片，可以消除舵机运转时的哒哒声，这个细节很多教程没有提到。

组装顺序建议是：先装舵机、再装头部结构件、最后装入麦克风和屏幕。千万别先装屏幕再接舵机线，否则后期理线会非常痛苦。Microduck 的底座空间不大，需要合理规划走线，建议用扎带把舵机线、USB 线分别固定，避免转动时线缆缠绕。

4. 软件环境搭建与核心配置

4.1 系统基础与依赖安装：别急着跑代码

Microduck 的软件环境我建议用 Docker 和裸机部署两种方式分别考虑。如果你只想测试，不想把宿主机环境搞乱，直接用它项目仓库里的 docker-compose.yml 起一套容器，所有依赖都封装好了。但如果计划改代码、调试模型，Docker 模式会有点隔靴搔痒，我最终选择的是裸机部署，这样跑起来更直接，资源占用也更少。

系统层面建议用 Raspberry Pi OS Lite（64 位），不要装带桌面的完整版，因为桌面环境会吃掉不少内存，对本地模型推理来说很不划算。基础依赖主要是 Python 3.10+、PortAudio、ffmpeg、espeak-ng 这些。有一个细节：Microduck 的代码里对 ALSA 音频设备有依赖，装系统后你可能需要在alsa-base.conf里手动指定默认声卡为 USB 麦克风，否则 Python 会读不到音频流。这个坑我在第一次启动时被卡了将近半天，后面排查部分会详细说明。

4.2 服务的分层启动策略：按依赖顺序来

Microduck 的软件架构里，各个服务之间是有依赖关系的，启动顺序不对会出现各种诡异问题。我的经验是严格按照下面这个顺序来：

1. 启动音频服务：确保麦克风设备可以被系统识别和访问，这一步可以用arecord -l验证。
2. 启动 ASR 服务：faster-whisper 模型加载比较慢，先把它拉起来，常驻内存。
3. 启动 LLM 推理服务：llama.cpp 加载 GGUF 量化模型，同样常驻。
4. 启动 TTS 服务：Piper 或 Edge-TTS 的 HTTP 接口。
5. 启动舵机控制服务：初始化 PCA9685，把舵机调整到初始角度。
6. 最后启动主控制程序：它负责把前面几个服务串起来。

为什么要按这个顺序？因为主控制程序启动时会检查各服务是否就绪，如果 ASR 还没加载完就启动主程序，它会默认跳过语音识别，出一些很难排查的隐性 bug。用 Docker Compose 的话，可以在配置里加上健康检查来管理依赖，裸机部署的话，可以写一个简单的 systemd 启动序列，我的做法是给每个服务写一个 service 文件，用After=和Requires=控制依赖，这样重启机器后所有服务自动拉起，不用每次都手动敲命令。

4.3 关键参数配置：采样率、唤醒词、模型路径

Microduck 有一个全局配置文件（config.yaml），里面有几个关键参数值得单独拿出来说。

第一个是音频参数。sample_rate默认是 16000，但如果你用 ReSpeaker 2-Mic，它默认输出可能是 48000，这时候你需要让 ASR 服务做输入重采样。faster-whisper 内部会处理重采样，但如果你是从 PyAudio 直接读取原始流，需要自己加一步重采样逻辑，可以借助soundfile或者librosa来做。我当时忽略了这一点，结果 ASR 识别出来全是乱码，排查了很久才发现是采样率不匹配。

第二个是唤醒词配置。Microduck 默认使用 openWakeWord 这个开源唤醒词库，它提供的预训练模型里没有“小鸭”这类词。好在它支持自定义唤醒词训练，训练数据只需要录制几段特定词语的音頻，就可以生成一个轻量级唤醒模型。我在 30 分钟内就训练出了一个“你好小鸭”的唤醒词，识别准确率在安静环境下能达到 90% 以上，这个能力非常实用。

第三个是模型路径。如果你下载了不同的量化模型，需要把local_llm下的model_path改成对应的 GGUF 文件路径，同时注意n_ctx（上下文长度）的设置，8GB 内存的树莓派建议设置为 2048，超过这个值容易爆内存。上下文长度越小，回复越“健忘”，但换来的是更快的推理速度，对鸭子这种短对话场景，2048 是平衡点。

4.4 让系统开机自启：别做每次手动敲命令的人

Microduck 配好之后，每次开机手动启动 6 个服务是件很反人类的事情。我的方案是为每个服务写一个 systemd 单元文件，设置好依赖关系，然后用systemctl enable让服务开机自动拉起。这里有一个容易忽视的坑：如果你的主控制程序依赖桌面环境（比如用了某些 GUI 库），在 systemd 服务里运行时是没有 DISPLAY 环境变量的，需要手动export DISPLAY=:0，否则程序会启动失败。Microduck 默认没有 GUI 依赖，但如果你自己改了代码加了可视化面板，就要留意这个问题。

5. 模型训练：让鸭子拥有你的专属人设

5.1 训练之前的准备：选底座模型还是用别人训好的

Microduck 热度高，很大一部分原因在于它提供了相对完整的本地微调链路。你可以让这只鸭子用模仿“你”的语气说话，或者拥有某个特定角色的性格。要做到这一点，需要对底座模型做 LoRA 微调。LoRA 的原理简单说就是冻结大模型原始权重，只在旁边接入一小部分可训练的低秩矩阵，用少量数据就能完成领域适配，非常节省显存和训练时间。

底座模型选择上，社区里用 Qwen 系列和 ChatGLM 系列的都有。Qwen-1.8B 或 Qwen-3B 这类小模型，是树莓派本地推理能够承载的上限附近，也是微调时比较合适的底座选择。如果你的电脑有 8GB 以上显存，本地训练这些模型完全没有压力；即便是纯 CPU 训练 1.8B 的 LoRA，也只是慢一点，不至于跑不动。

5.2 数据准备：200 条高质量对话足矣

很多人对微调有误解，觉得数据越多越好。实际上，对于 LoRA 微调这种轻量方案，喂给它 2 万条杂乱数据，效果远不如给它 200 条对提升效果目标明确的高质量对话。我在准备数据时用的格式是 OpenAI 的 ChatML 格式，每个样本包含 system prompt、user 和 assistant 三段。system prompt 用来定义人设，比如“你是小鸭，一只生活在书桌上的机器鸭，性格活泼但不聒噪，说话简短有时带点幽默感”。user 和 assistant 则是对应的对话对。

数据质量上，要特别留意人设的一致性和回答风格的统一。我建议把数据按场景分类整理，比如打招呼场景、介绍自己场景、讲冷笑话场景、拒绝回答场景等。这样训练出来的鸭子说话风格稳定，不会一会儿像个客服，一会儿又像个机器人。收集数据的方法可以天马行空：你可以在电脑上写一批模拟对话，也可以用别的大模型生成一批然后人工修改，甚至可以直接去翻 GitHub 上现成的开源对话数据集，但要记得过滤掉对不适用于目标人设的部分。

5.3 训练实操：用 LlamaFactory 完成全流程

训练工具我选的是 LlamaFactory，这是一个开源的微调框架，界面化程度高、文档全、对新手极其友好。它同时支持 LoRA 训练和 GGUF 导出，正好对应 Microduck 需要的模型链路。

训练流程大致分三步。第一步，用 LlamaFactory 的 WebUI 配置模型路径和数据集路径；第二步，设置 LoRA 超参数：r（秩）通常取 8 或 16，alpha取 16 或 32，batch_size根据显存调整，learning_rate一般 1e-4 到 2e-4；第三步，开始训练，训练完成后将 LoRA 权重合并回底座模型，导出成 HuggingFace 格式，再用 llama.cpp 量化转换成 GGUF 文件，放到树莓派上替换原来的模型。

我实际训练 200 条数据，用 6GB 显存跑一个 epoch，大约 10 分钟完成，转换出 4bit 量化 GGUF 文件之后，模型文件大小约为 1.1GB，放到树莓派上加载运行毫无压力。整个过程快到超出我的预期，也让我意识到：在 2025 年，普通个人开发者微调小模型的成本和门槛，真的已经低到了一个很夸张的地步。

5.4 训练效果评估与常见误区

训练完之后，不要急着部署到鸭子头上。先在电脑上用同一套测试集做对比测试：在训练前跑一遍旧模型，记录回复；然后加载 LoRA 微调后的模型，跑同样的输入，对比风格差异。我在这个环节发现了一个常见误区：如果训练数据里只有“输出风格”但不含足够多样化的“用户提问”，模型只会学到一种类型的回复套路，换一个问法就露馅。所以数据准备阶段，同一个意思尽量写多个不同的问法，这样才能让模型真正学会“在不同语境下保持人设”，而不是死记硬背回答。

6. 实际联调中的问题排查与优化心得

6.1 音频链路不通：麦克风读不到数据怎么办

这是新手复刻 Microduck 遇到率最高的一个问题，我自己就差点折在这里。现象是程序能启动，但字幕区域始终没有识别结果。排查路径有固定套路：先检查硬件层，用arecord -l看系统是否识别到了 USB 麦克风；然后检查 ALSA 默认设备，用arecord -d 3 test.wav录一段然后播放验证；最后检查 Python 层能否访问设备。Microduck 默认使用的 PortAudio 库，在树莓派上经常会遇到设备编号漂移问题——插拔 USB 设备后索引变了，导致 Python 读的设备和实际麦克风不是同一个。我最后的解决办法是使用设备名称而不是数字索引来指定输入设备，比如plughw:Microphone，这样即使 USB 重新枚举也没问题。

6.2 TTS 播报卡顿：缓冲区参数调优

TTS 声音发闷、卡顿，或者播报时像机器人变声，这类问题需要从两个方向排查。第一个方向是模型本身的原因：Piper 这类本地 TTS 模型有不同音色和质量等级，默认音色在某些环境下会跟音乐噪声混合，换一个音色模型或者调低语速就能缓解。第二个方向是音频缓冲区的问题：PyAudio 在树莓派上默认的输出延迟不匹配会导致声音断续。我的经验是将frames_per_buffer从默认的 1024 调整到 512，sampling_rate保持 22050（Piper 的默认采样率），延迟明显下降，播报流畅度提升了一个档次。

如果你用的是流式 TTS（边生成边播放）方案，还需要在代码里做音频队列管理，避免生成速度跟不上播放速度导致卡顿。一个简单的方案是：把 TTS 生成出的音频块放入线程安全的队列，播报线程从队列中读取并播放，队列为空时静默等待而不是关闭音频流。这个设计让 TTS 的响应速度和稳定性都提升很多，是复刻 Microduck 过程中最值得借鉴的代码技巧之一。

6.3 大模型推理速度优化：多了一层“预生成”逻辑

树莓派用 CPU 跑 3B 量化模型，初次加载模型需要约 20 秒，生成一个字大约要 0.5 秒。这意味着对话时用户说完话到鸭子回复的延迟可能在 7 到 10 秒。这个体验说实话不太行，但 Microduck 给出了一个非常优雅的优化思路：预热加预生成。预热指的是在系统启动时就把模型加载进内存并跑一遍简单输入，避免首次推理时加载时间的突然延迟。预生成则是在用户说话的同时，后台先根据最近一次的对话上下文生成一部分可能的回复候选，等 ASR 结果出来之后直接匹配最接近的候选并播报，大幅缩短响应时间。

我在实际使用中手动调低了n_ctx到 1024，虽然上下文变短了，但推理速度肉眼可见地提升，对于桌面陪伴型对话来说，这个取舍很值得。

6.4 舵机抖动与发热：从机械结构到 PWM 频率

舵机抖动问题和 PWM 频率、供电稳定性都有关系。树莓派的 GPIO 输出电压不够稳定，几个舵机同时动作时容易拉低电压，导致抖动甚至舵机抽搐。解决办法有两条：一是用外部 5V 电源给 PCA9685 供电，树莓派只发控制信号；二是把舵机供电和主控供电隔离，避免互相干扰。我在给 PCA9685 加装独立电源之后，抖动问题基本消失。

PWM 频率方面，SG90 舵机的工作频率是 50Hz，对应 20ms 的脉宽周期，脉宽在 0.5ms 到 2.5ms 之间对应 0 到 180 度。PCA9685 模块内部有一个 PRE_SCALE 寄存器来设置 PWM 频率，Microduck 的代码里默认设置是 50Hz，但个别舵机对频率敏感，稍微调整到 60Hz 后转动更平滑。这个参数你在硬件不同批次之间都可能需要微调，不是固定的。

6.5 常驻服务内存占用过高的排查技巧

Microduck 跑起来之后，树莓派内存经常会出现告警。用htop一看，faster-whisper 的 Python 进程占了 2GB，llama.cpp 流程占 3GB，再加上系统本身和 TTS 服务，8GB 内存确实有点紧张。排查思路是：优先给 LLM 推理服务分配固定内存，然后限制 ASR 进程的 CPU 和内存占用。还有一个容易被忽略的点：faster-whisper 默认会预分配较大计算图，但实际用不到，可以在初始化时设置cpu_threads=4和compute_type=int8，显存换成内存的理论上int8类型能省一半内存占用。实测下来，这两个参数调优后 ASR 进程的 RSS 从 2GB 降到 1.2GB，效果立竿见影。

7. 复刻完成后的扩展方向：从“鸭子”到“你的鸭子”

如果你已经成功复刻了一只 microduck 并让它正常跑起来，我建议下一步不要急着换模型，而是先做一个只属于自己的小功能。我的做法是给它加了一个“天气查询”技能：通过麦克风说“小鸭今天天气怎么样”，系统自动识别意图，调用一个天气 API 获取数据，然后让 LLM 组织成拟人化的回答，最后 TTS 播报。这个功能虽然简单，但完整地走了一遍“语音识别→意图识别→工具调用→回复生成→语音播报”的链路，比改模型参数能学到的东西多十倍。

另一个扩展方向是结合视觉能力。Microduck 头顶有一颗摄像头，目前只用来看画面、把图像推送到屏幕，但其实完全可以接入视觉语言模型（VLM），让鸭子“看到”你桌上的东西并做出反应。比如你拿着一杯咖啡问它“这是什么”，它能回答“看起来是一杯美式咖啡”。这个改造需要额外的模型部署，对树莓派的性能来说有一定压力，但用轻量级 VLM 模型加量化部署，还是可以跑起来的。我目前正在做这个方向，等调通了再写一篇详细的分享。

如果你愿意折腾，还可以把 Microduck 接入 NTFY 这类推送服务，让它主动提醒你日程；或者接入安卓手机通过蓝牙控制，做成一个“桌面小管家”。开源项目的魅力就在于，它给了一个可跑通的底座，而往上堆什么能力完全取决于你的想象力。

8. 写在最后的几点实在心法

复刻 Microduck 最大的收获，不是真的让一只鸭子在桌面上跟我聊天，而是打通了从硬件到模型、从数据到部署的整条链路。我以前写嵌入式代码时很少考虑模型推理的资源和延迟，以前微调模型时也从不关心最终要怎么部署到低算力设备上。Microduck 把两者强行拉到一起，让我被迫从端到端的角度去思考一个真实产品该怎么设计。

如果你想复刻这个项目，我给你三条具体的建议。第一，严格按照官方文档的硬件清单来下单，不要自作聪明随便替换型号，尤其在麦克风和舵机这两个部件上，社区验证过的东西会帮你省掉大量排查时间。第二，数据准备阶段把你想让鸭子说什么、不说什么先想清楚，写下来，再开始标注数据，这比先跑起来再补数据高效得多。第三，遇到问题先自己去日志里找线索，再上 GitHub Issues 搜关键词，大多数坑你不是第一个踩的人，但自己找到答案的过程会加深记忆。

最后分享一个小技巧：在树莓派上跑完 Microduck 后，记得给系统做一个完整镜像备份。我因为反复改配置弄坏了三次系统，每次重装加配置都要花两个小时。做一次dd镜像备份，哪怕真的搞坏了，一条命令就能恢复。这一点，我踩过坑之后才懂它的含金量。