端侧AI样机验收：五项工程检查方法，覆盖功能、性能、功耗与稳定性

1. 项目概述

1.1 为什么"样机验收"成了端侧 AI 落地中最容易翻车的一环

先说个自己踩过的坑。早两年做某智能家居项目的端侧语音唤醒方案，模型在实验室跑得好好的，识别率、延迟、功耗各项指标都漂漂亮亮，结果到了样机量产验证阶段，连续三台设备出现唤醒延迟忽高忽低的问题，最后排查了两周才发现是主板供电纹波在低电量模式下异常，导致 NPU 频率被强制压低。这个问题的本质，就是"实验室环境"和"真实样机环境"之间存在巨大的鸿沟，而验收环节恰恰是填平这道鸿沟的关键关卡。

所谓"端侧 AI 样机验收"，我的理解是：在硬件样机从开发板过渡到准量产阶段时，针对 AI 相关的功能、性能、功耗、稳定性和热设计，做一次系统性的、可量化的检查。它不同于常规的硬件测试，也不同于纯软件的功能测试，而是一条横跨算法、驱动、硬件、系统四个层面的综合评估流程。为什么这项工作在行业里越来越受重视？因为端侧 AI 方案的成本结构决定了它没法像云端方案那样"先上线再优化"，样机阶段如果埋了雷，后面开模、量产、售后全都要加倍还债。

1.2 这套五项工程检查方法适合谁用

写这篇文章的初衷很直接：把我在若干个端侧 AI 项目里沉淀下来的验收方法论，整理成一套可复用的工程清单。这套方法主要面向以下几类人：

• 负责端侧 AI 产品硬件的工程师，需要从系统层面判断样机是否达到准量产标准。
• 算法团队里被"模型在开发板上没问题，上了样机就出幺蛾子"折腾过的开发者。
• 产品经理或项目经理，需要在验收评审会上听懂工程师到底在说什么，以及每一项检查背后的风险逻辑。

这套五项工程检查，说白了就是围绕"算力是否够用、功耗是否可控、热是否压得住、系统是否稳定、数据是否可信"这五个维度展开。它们不是并列的五个独立测试，而是环环相扣的一整套工程逻辑。下面两节我先把设计思路讲清楚，再从实操角度逐步拆解每个环节怎么做、会碰到什么问题、怎么排查。

2. 五项工程检查的整体设计与逻辑拆解

2.1 为什么是这五项，而不是跑个 benchmark 就算完

很多团队做样机验收时容易走两个极端：要么只跑一遍标准测试集看精度，要么看一圈跑分软件就宣布"性能达标"。这两种做法其实都没有回答最关键的问题——端侧 AI 场景的真实体验到底能不能被量化验证。

我在设计这五项检查时，参考的框架是把一个端侧 AI 任务拆成五个工程面：

• 功能正确性：模型在样机上的输出，是否和预期一致。包括精度、鲁棒性、边界条件。
• 实时性能：从数据输入到推理结果输出的端到端延迟，是否满足业务约束。
• 资源消耗：CPU、内存、NPU、带宽的占用情况，是否存在异常峰值。
• 功耗与热：典型场景下的平均功耗、峰值功耗、温升曲线，是否在硬件设计阈值内。
• 长时间稳定性：持续运行、反复唤醒、异常打断等工况下，系统是否会出现内存泄漏、性能劣化、死机重启。

这五项合在一起，才构成一个完整的"样机工程体检"。跑 benchmark 只能覆盖第二项里的一部分，模型精度测试只覆盖第一项，而真正导致量产事故的，往往是第三到第五项里那些"实验室里测不出来"的问题。

2.2 检查项之间的依赖关系和验收顺序

五项检查不是随便排的，顺序本身有讲究。我建议按"从外到内、先功能后性能再可靠性"的顺序执行：

1. 先做功能正确性验证，确认模型在样机上"能干活"。
2. 再做延迟和资源占用分析，确认"干得够快、吃得不多"。
3. 然后做功耗与热测试，确认"长期干不烧、不烫手"。
4. 再做稳定性测试，确认"持续干不出毛病"。
5. 最后做数据采集与闭环分析，把样机阶段的量化结果沉淀成验收报告。

这个顺序的逻辑在于：前面的检查是后面检查的前提。如果一个模型在样机上精度都不对，去做功耗测试就是浪费电力；如果延迟都压不下来，做热测试的意义也不大，因为场景根本没跑通。反过来，如果前面四项都过了但稳定性测试挂了，那前面的成绩也要存疑——可能只是"碰巧没触发那个 bug 而已"。

2.3 一套贯穿全程的核心工程原则：量化一切

在所有项目中，我坚持一个原则：不能量化的验收都是无效验收。任何一项检查，最后都要落到具体数字上，而不是"看起来还行""感觉挺快的"这类模糊评价。举个例子，同样是问"唤醒延迟达不达标"，合格的回答应该是："在 16kHz 采样、8 线程 CPU 推理条件下，P50 延迟 38ms，P95 延迟 62ms，符合我们定的小于 80ms 的约束。"而不合格的回答则是："我试了试，感觉挺快的。"

为了实现量化验收，每项检查都需要提前定义：

• 测试环境：样机版本、固件版本、算法版本、测试负载、环境温度。
• 测试指标：具体测什么数字，怎么采样，采多少样本。
• 通过标准：哪些区间是绿灯，哪些是黄灯，哪些是红灯。
• 失败处理：某项不达标时，是允许降级验收，还是一票否决。

这些定义看似基础，但很多项目恰恰死在这上面——因为验收标准是"口头共识"，不同人对"快""稳""省电"的理解完全不同，最后评审会就变成了扯皮会。

3. 核心细节解析与实操要点

3.1 第一项：功能正确性检查，别只盯精度

功能正确性是验收的第一关，但大多数团队在这里都会犯一个错误：只测标准测试集上的平均精度，忽略了真实场景分布对模型的影响。

我的实操经验是，在样机阶段至少要做三类测试：

• 标准测试集评估：用开发阶段划分的测试集做回归，确认模型精度没有因为转换、量化而明显掉点。
• 真实场景样本评估：从目标使用场景中录制一批真实数据，涵盖不同环境噪声、不同用户口音、不同光线条件，评估模型在真实分布上的表现。
• 边界与异常输入测试：短语音、超长语音、静音、爆音、半句话、连续指令，这些边界情况往往能暴露模型和信号处理链路里的隐藏 bug。

举个例子，某个语音识别项目在标准测试集上 WER 只有 4.5%，看起来非常优秀，但当我们录制了一批"远场 + 电视背景声 + 多人交谈"的真实样本后，WER 直接飙到 13%。这说明模型在训练时对噪声鲁棒性不足，而这种问题如果在拿到测试集跑分时不专门验证，是根本发现不了的。

实操中还要注意一个细节：模型转换和量化的正确性验证。很多端侧模型不是直接在框架里跑的，而是经过模型转换、算子融合、INT8 量化等步骤。样机验收时，需要在样机上跑一遍固定输入，把每一层的输出导出来，和原始模型逐层对比，确认转换过程没有引入异常。这一步很多人嫌麻烦不做，但这恰恰是排查"为什么样机上精度和仿真不一致"的最有效手段。

3.2 第二项：延迟与性能检查，端到端才是真性能

性能检查最常犯的误区是只看"模型推理延迟"，而忽略了整个业务链路里其他环节的耗时。一个完整的端侧 AI 任务通常包含：

• 数据采集：麦克风采样、摄像头帧捕获、传感器数据读取。
• 预处理：降采样、去噪、增强、归一化。
• 特征提取：MFCC、embedding、resize 等。
• 模型推理：NPU/CPU/GPU 上的前向计算。
• 后处理：解码、阈值判断、结果格式化。
• 业务响应：UI 更新、状态切换、动作执行。

我在验收时，一定会让团队打上端到端延迟 profiling，也就是从物理输入（比如语音帧进入麦克风、图像帧进入 ISP）到业务产生实际响应（比如指示灯亮起、界面更新）的完整链路耗时。很多时候模型推理只占整个链路耗时的 30%，剩下的都花在数据拷贝、预处理、线程调度上了。

具体操作时，我会建议在代码里打点，用类似clock_gettime或平台自带的 profiling 工具，把每个阶段的耗时记录下来，跑 100 次取分布，然后重点看 P50、P95、P99 三个指标。P50 代表典型体验，P95 和 P99 代表极端情况下会不会卡顿。

除了延迟分布，还需要关注帧率或吞吐量，特别是对实时视频类任务。比如一个目标检测模型要求 30 FPS，那每帧的推理预算就只有 33ms，如果后处理里有个耗时的排序算法，很可能就把预算吃掉了。这里我强烈建议做一次"性能预算表"，把每帧的时间预算按模块拆开，哪个模块超过预算立刻暴露。

3.3 第三项：资源占用分析，隐性风险的重灾区

资源占用分析往往是最容易被低估的一项，因为它在短时间测试里看不出问题，只有在特定场景下才会暴露。比如某个方案在空闲时内存占用只有 80MB，看起来人畜无害，但连续运行 8 小时后内存涨到 240MB，再运行 12 小时后直接被杀掉——这就是典型的内存泄漏。

我建议的资源占用分析包含四个维度：

• CPU 占用率：分线程查看占用，确认模型推理线程是否周期性地抢占大量 CPU。
• 内存占用：关注峰值内存、常驻内存、Native 堆和 GPU/NPU 专用内存。
• NPU/DSP 占用：确认 NPU 是否被正确调度，是否存在频繁加载卸载模型、句柄泄漏。
• 带宽占用：DDR 带宽、总线带宽是否接近瓶颈，尤其在多路数据同时读取时。

实操方面，可以用top、perf、tcpdump（如果是网络相关）、平台厂商提供的 profiling 工具来采样。重点观察以下场景：

• 空闲态：样机什么都不干时，后台 AI 进程是否还在偷偷跑。
• 典型业务态：跑真实业务时，资源占用是否在预期范围。
• 峰值态：多任务并发、高负载运行时，有没有资源争抢和优先级翻转。

我自己遇到过一个很典型的案例：某个端侧人脸检测方案在单路视频流下 CPU 占用 65%，看起来没问题，但一旦切换到双路视频流，CPU 占用直接冲到 120%，系统开始卡顿。后来定位发现，是 ISP 回调线程和 AI 推理线程之间存在锁竞争，导致大量时间消耗在等锁上。这种问题如果不做资源分析，单看功能正常根本发现不了。

3.4 第四项：功耗与热测试，把温度当作功能的一部分

端侧 AI 项目里，功耗和热设计经常被当成"硬件的问题"而甩给结构工程师，但实际经验告诉我，AI 算法的负载特征对功耗和温升的影响极大。同样是做人脸识别，采用定时轮询方案和采用事件触发方案，平均功耗能差出 3 到 5 倍。

在样机验收阶段，我通常把功耗测试拆成四类场景：

• 待机功耗：设备在无任务状态下的功耗，包括低功耗模式是否真正生效。
• 典型运行功耗：连续执行 AI 任务时的平均功耗。
• 峰值功耗：启动、模型加载、高负载推理时的瞬时功耗。
• 关机/充电功耗：非 AI 相关但容易被忽略的底电流。

测试工具方面，常见做法是用高精度功耗仪（或者带电流采样的开发板），以 1kHz 以上的采样率记录电流曲线，然后离线分析。重点关注的点是：

• AI 任务触发瞬间的电流尖峰是否超过电源设计余量。
• 低频占空比运行和连续运行的平均功耗差异。
• 功耗曲线是否存在周期性波动，暗示后台有隐性任务在跑。

热测试和功耗测试是孪生兄弟。因为端侧设备通常没有主动散热，靠的是结构件的被动散热，SoC 附近温度能不能压住，直接决定芯片会不会降频。我的经验是，跑热测试时用热成像仪记录样机表面温度分布，同时用cat /sys/class/thermal/thermal_zone*/temp这类节点记录芯片结温，两者对比才能判断是散热设计不足还是算法功耗过高。

有一个容易翻车的细节：环境温度对热测试结果影响很大。同样的测试在 25 度空调房和 35 度无空调环境里，温升曲线可能相差 10 度以上。所以验收时要写明环境温度条件，或者直接在更高温度环境下做压力测试，留出设计余量。

3.5 第五项：稳定性测试，要跑到"不触发问题"才算数

稳定性测试的终极目标是：在模拟真实用户长期使用的压力下，系统各项指标不劣化、不崩溃、不重启。很多团队做稳定性测试只是跑了 8 小时 endurance test，然后看了一眼没死机就说"稳定"。这个做法有两个问题：

• 8 小时覆盖不到"慢性问题"：比如内存泄漏，有些泄漏 24 小时才累积到临界点。
• 只看"死没死机"忽略了"性能劣化"：系统没崩，但延迟越来越长、帧率越来越低，这种劣化更隐蔽。

我搭建稳定性测试时，会设计一套可循环的业务脚本，模拟真实用户操作序列，同时周期性记录系统指标：

• 内存占用曲线，判断是否存在增长趋势。
• 延迟分布随时间的推移，判断是否出现劣化。
• 帧率/吞吐量变化，判断是否有隐藏的后台任务抢占资源。
• 系统日志中是否出现异常报错、超时、看门狗复位。

一个实操建议：稳定性测试时长尽量跑满 72 小时，至少也要 48 小时。如果项目周期紧张，宁可减少并发场景，也不要缩短时长。因为很多端侧 AI 问题在 48 小时内一定会暴露，而 8 小时测试大概率只能抓到"偶发问题"里最活跃的那部分。

另外补充一个经验，稳定性测试最容易被忽略的是中断和异常打断。比如语音唤醒场景中，用户可能随时打断、随时重新唤醒；视频检测场景中，画面可能频繁切换，算法需要不断重新初始化。这些中断场景要在稳定性测试里被高频触发，因为上下文切换、模型重载、缓冲区重置往往就是内存泄漏和句柄泄漏的温床。

4. 实操过程与核心环节实现

4.1 搭建一套可复用的验收测试基线

每次做样机验收前，我建议先花半天时间把测试基线搭好，这一步能做到"一次配置，多次复用"。

测试基线至少包含以下内容：

• 样机清单：设备编号、硬件版本、固件版本、算法版本、测试日期。
• 环境参数：室温、湿度、供电方式（电池还是电源适配器）、网络状态（如果需要）。
• 测试脚本：自动化跑测脚本，覆盖功能用例、性能用例、压力用例。
• 数据记录规范：日志格式、指标采样间隔、存档路径。

我习惯把所有信息写在一个验收清单文件里，每一项测试完成后直接更新结果。这一步看起来繁琐，但到了出验收报告时，这份基线记录就是最有力的凭据。

4.2 功能正确性检查的实操路径

功能检查的第一步是搭建测试集。我的做法是：

1. 从开发阶段的测试集里抽出一份"验收子集"，保证样本量和覆盖度。
2. 录制一份"真实场景样本库"，包含目标场景中可能遇到的各种变体。
3. 把测试集整理成标准格式，便于自动化批量跑测。

第二步是把模型跑起来并收集输出。常规做法是写一个测试脚本，遍历测试集，把输入的推理结果保存为文件，然后和标注好的 ground truth 对比，计算精度指标。

第三步是逐层对比验证。如果模型经过了转换或量化，我建议在样机和 PC 仿真环境上各跑一遍相同输入，保存中间层输出，计算最大绝对误差或余弦相似度。这个环节能精确定位到底是哪个算子、哪一层在转换时出了问题。

实操中要特别关注量化敏感性。有些模型对 INT8 量化极其敏感，稍微一量化，精度就掉几个点。我遇到过一个人体姿态估计模型，量化后关键点误差平均增加了 1.2 像素，看上去还在指标范围内，但可视化之后发现，有些关键点直接漂到画面外了。原因是量化误差在小数值特征上被放大。这种问题在逐层对比中会非常明显，如果只看最终精度就很容易漏掉。

4.3 端到端延迟打点与性能预算表的落地

延迟分析的第一步是确定打点位置。我通常要求在代码里定义一个统一的计时器接口，然后在关键节点插入：

• 数据到达时刻：t0，比如音频帧从麦克风缓冲区取出。
• 预处理完成时刻：t1。
• 推理开始时刻：t2，也就是把输入数据交给 NPU 的时刻。
• 推理完成时刻：t3。
• 后处理完成时刻：t4。
• 业务响应完成时刻：t5。

这六个时刻分别记录到日志里，离线分析时就能算出每个阶段的耗时。比如推理耗时就是t3 - t2，端到端耗时就是t5 - t0。

第二步是生成性能预算表。假设一个实时语音交互场景的总体验收指标是"从用户说完话到设备响应不超过 200ms"，那我们就需要把 200ms 按比例分配到各个环节：

有了这个预算表，验收时就能直接对号入座：哪个环节超了就优化哪个环节。如果发现模型推理本身没问题，反而是音频采集缓存机制导致延迟超标，那就要去查驱动和缓存策略，而不是一味地去优化算法模型。

4.4 功耗与热测试的操作细节

功耗测试的实操关键是精确同步。我建议在测试脚本里同时记录两路数据：一路是功耗仪的电流/电压采样，一路是样机端的业务日志。这样离线分析时，可以把功耗曲线和业务事件对齐，精确判断某个业务动作消耗了多少电量。

测试步骤大致如下：

1. 将样机置于测试环境，连接功耗仪，确认基线电流稳定。
2. 记录 10 分钟待机功耗，确认待机状态没有异常活动。
3. 循环执行典型 AI 任务 30 分钟，记录平均功耗和峰值功耗。
4. 停止业务，继续记录 10 分钟，观察是否有关机后的电流回落。
5. 将数据导出，绘制功耗曲线图，标注业务事件。

热测试通常在功耗测试之后接着做。我的经验是让样机连续跑高负载任务 60 分钟以上，同时每 5 分钟通过温度节点记录一次结温，用热成像仪每 10 分钟拍一次表面温度分布。如果条件允许，最好还把样机放在不同环境温度下各测一轮，至少要在常温下测，如果产品有明确的户外使用场景，还要加一轮高温环境测试。

实操中我踩过一个坑：某次热测试时温度一直超标，反复检查算法和散热结构都没问题，最后发现是热成像仪的发射率设置错了，导致读取的温度虚高。所以做热测试时，一定要先校准热成像仪参数，或者用热电偶实测对比。

4.5 长稳测试脚本与异常监控的设计

稳定性测试的脚本设计，核心是模拟真实用户行为。以语音交互设备为例，我会写一个自动化脚本，循环执行这样的序列：

• 播放唤醒词 -> 等待设备唤醒 -> 播放正常指令 -> 等待响应 -> 播放另一个唤醒词。
• 随机插入半句话、静音、爆音、远场低音量语音。
• 随机插入打断操作，即在设备播报过程中再次唤醒。
• 随机切换不同的网络状态和电源状态（如果支持）。

这个脚本跑 48 小时以上，同时后台记下系统指标。遇到问题时的排查方式，我的建议是分三步走：

1. 先看系统日志，定位异常发生时最近的事件序列。
2. 再看资源曲线，确认异常发生前是否有资源单调递增的趋势。
3. 最后复现问题，用同样的脚本在小范围内跑，看是否能稳定复现。

这三步能应付 80% 以上的稳定性问题。剩下 20% 的偶发问题，需要靠长时间的测试和日志埋点去碰运气，但做好前两步，通常能大大缩小排查范围。

5. 常见问题与排查技巧实录

5.1 问题一：样机上模型精度和仿真精度差异很大

这类问题的排查顺序，我建议先从"模型转换"这一环找原因，因为绝大多数差异都出在这里。操作步骤：

1. 检查转换后的模型算子列表，看是否有不支持的算子被替换成了低精度实现。
2. 用固定输入跑一遍原始模型和转换后模型，逐层对比输出误差，定位误差最大的层。
3. 检查量化校准集是否具有代表性。如果校准集样本太少，或者分布和真实场景偏差大，量化后的模型精度就会明显劣化。
4. 尝试改用混合量化或者更高 bit 位宽，观察精度是否恢复。

补充一个容易被忽略的原因：输入预处理不一致。开发阶段可能在 PC 上用 PIL 做图像预处理，到了端侧换成了 OpenCV 或自研库，两个库在缩放算法、像素格式、归一化方式上存在细微差别，累积起来就会让模型输入分布漂移。这种问题用逐层对比同样能快速暴露。

5.2 问题二：端到端延迟偶发性飙高

延迟偶发飙高，通常不是因为模型推理本身慢，而是系统层面的干扰。我建议按下面的顺序排查：

1. 先确认飙高时刻和系统日志事件是否吻合，比如是否有 GC 触发、后台任务唤醒、网络同步操作。
2. 检查 CPU 调频策略。端侧设备经常用调频来省电，当 CPU 频率被临时调低时，预处理和后处理的耗时会被放大。
3. 检查内存带宽争用。如果同一时间有其他高带宽任务在跑，NPU 和 CPU 的数据搬运会变慢。
4. 检查锁竞争。多线程环境下，某个线程拿不到锁会阻塞整个链路。

还有一个非常隐蔽的原因：第一次推理的冷启动耗时。很多端侧平台在模型第一次加载时需要编译、初始化、申请内存，这个过程可能耗时几百毫秒甚至几秒。如果业务逻辑没有做预加载和预热，用户第一次触发任务时就会感受到明显卡顿。验机时我会专门测"冷启动场景"和"热启动场景"两种延迟。

5.3 问题三：待机功耗异常偏高

待机功耗异常，往往是"后台有事务没有真正停止"。排查路径：

1. 用功耗仪画出待机功耗曲线，看是否存在周期性脉冲。
2. 周期性脉冲意味着有定时任务在跑，去系统日志里查是哪个进程在周期性唤醒。
3. 检查模型的推理线程是否在空闲时进入了低功耗等待状态。
4. 检查传感器的持续供电和采样策略，有些项目里传感器即使在待机态也在高频采样。

我遇到过最离谱的案例是：某个语音方案的待机功耗比预期高了 300%，查了很久发现是音频服务在空闲状态仍然以 48kHz 的采样率持续工作，CPU 一直没法进入低功耗状态。最后把采样率降到 16kHz，同时加上事件触发机制，待机功耗才恢复正常。这类问题靠"短时间开着不耗电"是测不出来的，必须用仪器认真测待机曲线。

5.4 问题四：长时间运行后面临内存持续增长

内存持续增长，九成是内存泄漏，排查手段通常分两层：

第一层，用系统自带的进程内存统计命令，每隔一段时间记录一次内存占用，画出增长曲线，先确认增长速率和增长趋势。

第二层，用内存剖析工具检测分配记录，重点关注循环分配和释放不对称的地方。常见泄漏源包括：

• 图像帧或音频缓冲区分配后没有释放。
• 模型推理的输出张量每次新建，不再引用旧对象还占着内存。
• 回调函数里创建的临时对象没有被正确回收。
• NPU/GPU 侧的内存显式分配后没有释放。

实操中我还遇到过一种"伪泄漏"：内存曲线看起来在涨，但实际是系统缓存机制导致的。这种情况下要用malloc_stats或平台的内存统计接口确认到底是进程实际占用还是文件缓存。伪泄漏不需要恐慌，用工具确认进程物理内存没有增长后，就可以继续观察。

5.5 问题五：高温环境下性能明显下降

高温环境下性能下降，几乎都是因为芯片降频保护。排查思路：

1. 用温度节点记录结温，确认是否达到降频阈值。
2. 用 CPU/NPU 频率接口记录推理过程中的频率变化，确认降频是否发生在性能下降时段。
3. 对比散热优化前后的降频点，看是散热能力不足还是算法功耗过高。

针对这个问题的解决思路，通常有三个方向：

• 算法层面：降低单位时间内的推理次数，或者将推理任务分散到多个时间片。
• 硬件层面：增加散热片、导热硅脂、风道设计。
• 系统层面：通过 DVFS 调频策略，让芯片在高温前提前降频，从而避免瞬间性能悬崖。

我个人的建议是：在算法设计阶段就要评估功耗和热的预算，不要等到样机验收时才发现热设计不达标。比如一个实时视频检测方案，可以在算法里加入动态帧率调整，温度高时自动降到 15 FPS，温度低时恢复 30 FPS，这样用体验换取稳定性，往往比单纯堆散热方案更实用。

5.6 常见问题速查表

这张表是我每次验收时会打印出来放在手边的参考。它不是万能的，但覆盖了绝大多数端侧 AI 样机验收中会遇到的问题。

6. 验收报告的编写与经验总结

6.1 验收报告的结构设计

一份合格的验收报告，应该具备"结论先行、数据支撑、风险透明"三个特点。我习惯用这样的结构：

• 验收结论摘要：一页纸说清楚是否通过、哪些项不达标、风险等级。
• 测试环境说明：样机信息、固件版本、算法版本、环境条件。
• 各检查项结果：按五项工程检查分别列数据、图表和结论。
• 问题清单与整改建议：每个问题标注严重等级、发生频率、建议负责人。
• 附录：原始数据路径、日志存档位置、测试脚本版本。

如果验收不通过，报告里最重要的不是"不通过"三个字，而是让决策者知道为什么不通过、风险有多大、整改需要多久。比如内存泄漏问题，如果增长速率是每小时 2MB，那 7 天后设备就可能被系统杀掉，这个结论比单纯说"有泄漏"有说服力得多。

6.2 每一个验收数字，都要能追溯到当时的情景

我遇到过很多次这样的情况：验收报告写完三个月后，量产阶段出了问题，回头翻报告，发现当时的测试数据记录不完整，完全没法复现当初的测试条件。为了杜绝这种情况，我养成了一个习惯：每一项测试数据后面，都要附带测试开始时间、测试时长、样机编号、固件版本、环境温度。这些元信息看起来不起眼，但在问题回溯时价值巨大。

还有一个小技巧：测试过程中养成立即拍照和截图的习惯。功耗曲线、热成像图、系统日志异常段，统统截图存到验收目录里。这些图片比文字描述直观得多，也更容易让评审会上的非技术成员理解。

6.3 五项检查之间的综合判定逻辑

五项检查不是简单的"过/不过"投票，而是有综合判定逻辑的。我自己的判定习惯是：

• 功能正确性和端到端延迟属于一票否决项，不达标就不应该进入下一阶段。
• 资源占用和功耗热属于条件通过项，如果超标但超标幅度在 10% 以内，且整改计划明确，可以黄灯通过。
• 稳定性属于时间保证项，短期测试通过不算数，至少要有 48 小时连续测试的数据支撑。

这种判定逻辑的出发点很简单：像精度和延迟这类指标，一旦不达标，产品体验就直接受损，没有商量余地；而功耗、热量这类指标，留有裕量的话是可以边量产边优化的。所以验收评审会上的重点，往往不是争论"过没过"，而是对"不达标项的风险可接受度"达成共识。

6.4 一个建议：把验收标准前置到项目启动阶段

最后分享一个从项目管理和工程实践两个角度都很重要的经验。我在早期项目里吃过"验收标准后置"的亏：开发阶段只关注模型效果，完全没有定义端侧运行的性能、功耗、稳定性指标，到了样机验收时，大家对着测试结果各执一词，吵了整整一周才勉强达成一致。

后来我把方法改成了：项目启动阶段就把验收标准草案写好，哪怕一开始只是拍脑袋定的粗略数值，也先写到项目文档里。随着开发推进，再根据实测数据不断修正。到了样机验收时，大家已经对"什么算好"有了共识，验收会开得快，矛盾也少得多。

这个方法执行起来并不复杂，核心就一句话：把验收标准当成项目需求的一部分来管理，不要留到最后一刻才讨论。如果这篇分享能对你有一点实际的帮助，我的建议是从你的下一个端侧 AI 项目开始，先花一个下午把验收标准草案写出来，后面你会发现整个项目团队的沟通效率能提升一个明显的台阶。