课程导入：TinyML验收指标表的背景、目标、在AIoT项目中的价值，以及本课程的学习路径

TinyML（微型机器学习）正从实验室走向产业落地，但大量AIoT项目在交付验收环节陷入困境：模型在开发板上精度尚可，部署到现场却频繁误报；功耗标称值漂亮，实际电池续航却缩水一半；内存占用看似达标，设备运行一周后却因碎片化重启。这些问题的根源，往往不是算法不够先进，而是缺少一套贯穿项目全生命周期的验收指标体系。本课程旨在构建一张“TinyML验收指标表”，将资源预算（内存、Flash、算力、功耗）与业务指标（准确率、时延、鲁棒性、成本）统一纳入管理框架，让项目团队在需求阶段就能定义“可验收”的目标，在开发阶段持续对照预算红线，在交付阶段用同一张表完成量化评估。

上图展示了本课程的核心心智模型：资源预算域与业务指标域通过“TinyML验收指标表”形成双向约束关系。左侧资源域回答“硬件能不能撑住”，右侧业务域回答“模型有没有用”，而中间的指标表则是双方沟通的“契约”。这张表不是静态文档，而是随项目迭代持续更新的活工具——需求变更、硬件选型调整、模型压缩策略都会引起表中数值的联动变化。

1.1 TinyML验收指标表的背景：为什么传统验收方式失效

传统嵌入式开发验收通常关注功能正确性和硬件规格，而云端AI项目验收关注模型精度和吞吐量。TinyML项目恰好横跨这两个领域，导致验收时出现“三不管”地带：硬件工程师认为模型精度是算法团队的事，算法工程师认为内存溢出是驱动的问题，项目经理则拿着两份对不上的报告无从决策。更深层的矛盾在于指标粒度不匹配——硬件规格书给出的是“典型值”，而模型推理时的内存峰值可能比典型值高30%；算法报告中的“准确率”是在PC上用浮点模型跑出来的，部署到MCU上经过int8量化后可能下降2-5个百分点。

另一个背景是AIoT项目的长尾效应。一个智能家居方案可能包含温湿度传感、人体检测、语音唤醒三个模型，每个模型单独验收都合格，但组合运行时Flash超限、中断优先级冲突、电源纹波干扰等问题才暴露。验收指标表需要从“单模型视角”升级为“系统视角”，把多个模型共享的MCU资源、总线带宽、电源轨纳入统一预算。

1.2 验收指标表的目标：从“模糊期望”到“可测量契约”

本课程要构建的验收指标表，核心目标有三个。第一，建立统一的度量语言：让硬件工程师、算法工程师、产品经理用同一张表沟通，每个指标都有明确的定义、单位、测量条件和容差范围。第二，实现预算的量化管理：像管理财务预算一样管理MCU资源，每个模块（模型推理、传感器驱动、通信协议栈）都分配明确的内存和算力配额，超支时能快速定位责任模块。第三，支持全生命周期追踪：从需求阶段的预估，到开发阶段的实测，再到量产阶段的抽检，指标表始终是唯一的参考基准。

指标表的设计遵循“SMART原则”的变体——针对TinyML场景，我们强调Specific（指标定义到具体硬件型号和软件版本）、Measurable（所有指标必须可量化测试）、Achievable（阈值基于硬件实测而非理论峰值）、Relevant（每个指标都关联到业务价值）、Traceable（每个指标都能追溯到需求来源或风险项）。例如，“内存占用”不能只写“≤50KB”，而要明确为“在Cortex-M4@80MHz、FreeRTOS 10.4.1、CMSIS-NN 4.0.0环境下，模型推理峰值RAM（含输入/输出张量、中间激活、堆栈）≤48KB，且连续运行72小时无内存碎片溢出”。

1.3 在AIoT项目中的价值：三个真实场景的启示

场景一：工业预测性维护。某工厂在振动传感器上部署异常检测模型，初期只关注准确率（目标95%），忽略了推理时延。实际部署后发现，MCU完成一次FFT+推理需要380ms，而设备振动周期是200ms，导致采样混叠、误报率飙升。引入验收指标表后，将“端到端时延≤150ms”设为硬性指标，倒逼算法团队将模型从LSTM替换为1D-CNN+剪枝，最终在时延达标的同时准确率保持93%。

场景二：智能穿戴设备。一款手环的跌倒检测功能，实验室测试准确率98%，但用户实际佩戴时因手臂摆动幅度大，误报率高达每天3次。验收指标表增加了“鲁棒性测试”维度：在行走、跑步、挥手、弯腰等10种干扰动作下，误报率≤0.5次/天。这个指标直接改变了数据采集策略——团队补充了200小时的真实运动数据，并引入数据增强技术。

场景三：智慧农业监测。太阳能供电的土壤传感器节点，原设计功耗预算为平均电流≤2mA，但实际部署后因无线重传频繁，平均电流达到3.8mA，电池续航从设计的6个月缩短到2个月。通过指标表拆解发现，通信模块功耗占比68%，而模型推理仅占12%。团队优化了通信协议（改为事件驱动上报），并将模型量化到int8，最终平均电流降至1.6mA。

项目阶段	验收指标表的作用	典型输出物
需求分析	将业务需求转化为可量化的技术指标，明确约束边界	指标表v0.1（预估阈值）、风险清单
方案设计	硬件选型与模型结构选择的依据，进行预算分配	资源预算分配表、模型压缩目标
开发调试	持续对照预算红线，定位超支模块	实测数据记录、超支分析报告
系统集成	多模型/多传感器联合测试的验收基准	集成测试报告、指标表v1.0
量产交付	抽检标准、生产测试依据、售后问题追溯	产测规范、指标表v1.1（含容差）

1.4 本课程的学习路径：从理论到实战的五个台阶

课程共30章，按“认知→构建→应用→优化→治理”五个阶段递进。第一阶段（第1-5章）建立基础认知：理解MCU资源约束、模型量化原理、功耗测量方法。第二阶段（第6-12章）学习指标表的构建方法：如何定义指标、设置阈值、设计测量实验。第三阶段（第13-20章）聚焦实战应用：针对图像分类、语音唤醒、异常检测等典型场景，演示如何用指标表指导模型压缩、硬件选型和系统调优。第四阶段（第21-26章）深入优化策略：内存池管理、算子融合、动态电压频率调整（DVFS）等高级技术如何与指标表联动。第五阶段（第27-30章）讨论治理与演进：多项目指标复用、自动化测试平台搭建、指标表的版本管理。

每章都遵循“原理→方法→案例→复盘”的结构。原理部分讲清楚“为什么”，方法部分给出可操作的步骤和模板，案例部分用真实项目数据演示完整流程，复盘部分总结常见误区和改进方向。建议学习者准备一个自己的项目作为“练习场”，每学完一章就尝试将对应方法应用到项目中，这样30章学完后，你将拥有一份完全定制化的TinyML验收指标表。

1.5 常见误区与总结复盘

误区一：指标越多越好。有些团队试图把所有能测的参数都列入验收表，导致表格冗长、维护成本高、关键指标被淹没。实际上，一张有效的指标表通常控制在15-25个指标之间，且每个指标都要有明确的决策阈值。如果某个指标超差但不会影响业务目标，就应该从表中移除。

误区二：阈值设置过于激进。为了追求“性能最大化”，将内存占用设为芯片规格的95%，功耗设为电池容量的极限值。这会导致量产时因器件批次差异、温度变化而大面积失效。正确的做法是预留15-20%的余量，并将“典型值+最坏情况”同时写入指标表。

误区三：忽略测量方法的一致性。同一个内存指标，用不同编译器版本、不同优化选项、不同RTOS配置测出的结果可能相差20%。指标表必须绑定测量环境（工具链版本、编译选项、外设配置），否则验收时会产生争议。

误区四：把指标表当作一次性文档。项目启动时制定了指标表，之后就束之高阁，直到验收时才翻出来。正确的做法是每周更新一次，将最新的实测数据填入，并标注与预估值的偏差。当偏差超过10%时，需要触发评审，判断是否需要调整方案或修正指标。