1. 产品定义与需求分析
在动手画原理图或写第一行固件之前，必须先把“我们要做的到底是一台什么设备”讲清楚。STM32N6 是 ST 首款带自研 NPU（Neural-ART，约 600 GOPS 算力）的 MCU，它让“在电池供电的终端上跑音频神经网络”从概念变成可落地的事。但算力强不等于产品成立——真正决定成败的是场景选择、功能边界、性能指标与成本约束这四件事能否对齐。本节以一款典型的“离线语音唤醒 + 关键词识别 + 本地命令词控制”的音频 AI 终端为例，走完从场景到需求文档（PRD）的完整定义过程。
一、先锁定目标场景，再谈功能
音频 AI 终端的场景差异极大：智能家居面板、工业设备语音控制、可穿戴录音笔、车载语音模块，对功耗、延迟、离线率、成本的要求完全不同。我们选择“电池供电的离线语音控制终端”作为本课程的主线产品，理由是它同时压住了三个关键约束：必须离线（隐私与无网环境）、必须低功耗（电池续航）、必须有实时响应（唤醒延迟可感知）。
场景明确后，功能边界随之收敛。核心功能只有三条：
- 始终在线的唤醒词检测：设备处于低功耗监听态，检测到唤醒词后进入命令态；
- 本地命令词识别：识别 10～20 条固定命令（如“开灯”“关灯”“调高音量”），不依赖云端；
- 结果输出与反馈：通过 UART/GPIO 输出识别结果，并用 LED 或蜂鸣器给出状态反馈。
明确“不做什么”同样重要。本产品不做连续语音转写、不做说话人识别、不做云端大模型对话、不做多麦克风阵列波束成形。把这些排除在外，才能把有限的算力、内存和功耗预算集中到唤醒与命令词上。
二、把场景翻译成可测量的性能指标
需求分析最容易犯的错是写“识别要准、功耗要低”这类无法验收的话。必须把每条需求翻译成带数值、带测试条件的指标。下表是本产品的关键性能指标（KPI）定义，数值为教学示例目标，实际项目需按场景重新标定。
| 指标类别 | 指标项 | 目标值（示例） | 测试条件 |
|---|---|---|---|
| 识别性能 | 唤醒词召回率 | ≥ 95% | 安静环境，1 m，正常语速，50 次 |
| 识别性能 | 误唤醒率 | ≤ 1 次 / 24 h | 持续播放背景噪声/电视声 |
| 识别性能 | 命令词准确率 | ≥ 90% | 20 条命令，每词 10 次 |
| 实时性 | 唤醒响应延迟 | ≤ 300 ms | 从词尾到 GPIO 拉高 |
| 实时性 | 命令识别延迟 | ≤ 500 ms | 从词尾到 UART 输出 |
| 功耗 | 监听态平均电流 | ≤ 8 mA | 3.3 V 供电，无外部负载 |
| 功耗 | 命令态峰值电流 | ≤ 120 mA | NPU 推理瞬间 |
| 资源 | 模型占用 Flash | ≤ 1.5 MB | 含权重与元数据 |
| 资源 | 推理占用 RAM | ≤ 512 KB | 含音频缓冲与特征 |
这些指标之间存在强耦合。例如把唤醒召回率从 95% 提到 98%，往往需要更大的模型或更长的音频窗，直接推高 Flash 占用和推理延迟；把监听电流压到 8 mA 以下，可能要求降低麦克风采样率或让 NPU 间歇工作，又会影响召回率。需求分析阶段就要把这些矛盾摆到桌面上，而不是等到调试时才发现指标互相打架。
三、用信号链看清“算力花在哪里”
要判断 STM32N6 是否够用，必须把从声音到结果的信号链拆开，逐段估算数据量和计算量。下图给出本产品的音频处理信号链与各阶段的关键参数，它也是后续固件模块划分的依据。
从信号链可以读出几个关键结论。第一，16 kHz/16 bit 单声道的数据率是 32 KB/s，STM32N6 的音频接口和 DMA 完全能承受，瓶颈不在采集。第二，特征提取每 20 ms 一帧，40 维 Log-Mel 特征约 1.6 KB/帧，这部分计算量适中，可放在 CPU 或 NPU 前置处理。第三，真正吃算力的是 NPU 上的唤醒与命令词模型，必须把模型控制在 1.5 MB Flash、512 KB RAM 以内，才能给协议栈和缓冲留出余量。第四，功耗预算决定了 NPU 不能一直满速跑，监听态应采用“VAD 触发 + 间歇推理”的策略。
四、成本约束反向裁剪需求
成本约束不是最后才算的账，而是从第一天就要参与裁剪。本产品按量产 1 万台估算，BOM 目标控制在 60 元人民币以内（示例假设）。主要成本项包括：STM32N6 主控、MEMS 麦克风、Flash（若片内不足）、电源管理、PCB 与结构件。其中主控占比最大，因此选型时要确认片内 Flash/RAM 是否够用——如果模型加固件超过片内容量，就要外挂 Flash，成本和 PCB 面积都会上升。
成本压力会直接改写需求。例如原计划支持 50 条命令词，但每增加一类命令都要扩充模型和训练数据，模型变大后可能触发外挂 Flash，于是把命令词收敛到 20 条；原计划支持双麦克风降噪，但双麦需要额外麦克风、模拟前端和更复杂的算法，成本与功耗双升，于是改为单麦 + 软件降噪。这些取舍必须在 PRD 里写明理由，否则后续开发会反复摇摆。
五、输出产品需求文档（PRD）
把上述分析固化成一份可执行、可验收的 PRD。以下给出本产品的 PRD 核心字段示例，可直接作为项目起点填写和扩展。
产品名称：离线语音控制终端（STM32N6）
版本：v0.1（需求基线）
目标场景：电池供电、无网络环境的本地语音命令控制
核心功能：
F1 唤醒词检测（始终在线，低功耗）
F2 命令词识别（10~20 条固定命令）
F3 结果输出（UART/GPIO）与状态反馈（LED/蜂鸣器）
功能边界（不做）：
连续语音转写、说话人识别、云端对话、多麦克风波束成形
性能指标（示例目标）：
唤醒召回率 ≥ 95%，误唤醒 ≤ 1 次/24h
命令词准确率 ≥ 90%
唤醒延迟 ≤ 300 ms，命令识别延迟 ≤ 500 ms
监听电流 ≤ 8 mA，推理峰值 ≤ 120 mA
模型 Flash ≤ 1.5 MB，推理 RAM ≤ 512 KB
成本约束：BOM ≤ 60 元（1 万台量产，示例）
关键风险：
R1 监听功耗与召回率冲突 → 采用 VAD + 间歇推理
R2 模型超片内容量 → 优先量化压缩，必要时外挂 Flash
R3 噪声环境误唤醒 → 增加噪声训练集与后处理确认
验收方式：按上表测试条件逐项测量并记录至此，产品定义完成：场景锁定为离线语音控制，功能收敛为唤醒 + 命令词 + 输出，性能指标量化到可验收，成本约束反向裁剪了命令词数量与麦克风方案。这份 PRD 将成为后续硬件选型、模型训练、固件架构和测试用例的共同依据。