企业官网建设流程全解析

样机从产线上拿到手，第一件事就是接上电源跑一个 demo。画面流畅、识别准确、功耗看着也正常，大家都很满意，项目似乎可以结了。但真正进了小批量验证阶段，问题一个接一个往外冒：帧率掉了一半、偶发卡顿、连续跑几个小时之后内存暴涨、换个光照环境识别率直接崩盘。这种事我见过太多次了，根源只有一个：样机验收的时候只看了“功能对不对”，没有做“工程能不能扛”。

端侧 AI 样机验收，核心不是验证算法效果有多好，而是验证这套软硬件组合在实际交付条件下能不能稳定、可靠、持续地工作。我所在的超维方程团队，这几年一直在做端侧 AI 设备的交付验收，总结下来就是五项工程检查。这套方法不挑具体芯片平台、不挑算法类型，从图像识别到语音唤醒、从手势控制到异常检测都能用。这篇文章把完整思路和实操细节都摊开讲，如果你是 AI 应用工程师、嵌入式开发、或者负责项目验收的人，按这个框架走一遍，能少踩很多坑。

1. 样机验收为什么容易翻车：核心矛盾与验收边界

1.1 “能在开发板上跑通”不等于“能交付”

先说一个最常见的认知偏差。很多团队做端侧 AI 样机，前期的算法验证是在开发板上完成的。开发板的供电余量足、散热条件好、系统环境干净，模型跑起来顺畅得很。但交付样机往往是另一套硬件设计，传感器型号可能换了、内存带宽打了折扣、散热片缩小了、系统里还塞了业务程序和其他后台服务。这些差异组合在一起，算法表现就会明显劣化。

更隐蔽的问题是，开发时用的推理框架、算子库版本与量产固件不一致，导致同样的模型文件在两端产出的数值结果都有细微差异。这个差异平时不影响单张图片的识别，但累计起来就可能造成偶发的误判。验收的目的，就是把“开发环境里能用”和“交付环境里可靠”这两件事之间的差距量化出来，而不是靠感觉来拍板。

1.2 验收前必须先划清三条边界

不划清边界的验收就是耍流氓。我见过不少验收争议，最后复盘发现是甲方乙方对“验收范围”的理解根本不一致。这三条边界必须在验收启动前书面确认。

第一条是场景边界。这台样机承诺在什么样的条件下工作？室内固定光照、户外变化光照、夜间补光，还是全黑环境？视野范围内最多允许多少个目标、目标最小尺寸多大、最大运动速度多快？对这些参数不能只写“复杂场景”，必须量化，否则后面任何测试结果都可能被拿出来吵。

第二条是机型边界。样机可能只有一台，但交付的量产版本可能有多个配置。验收结论只对送检的硬件配置有效，不能拿低配版的结果去覆盖高配版。需要把 CPU 型号、内存大小、算力芯片型号、摄像头模组型号、系统版本、推理框架版本全部登记在案。

第三条是样本边界。用什么数据集来测试、数据是什么样的分布、来源是什么，都要固定下来。如果验收时用的测试集是网上找的通用数据集，到现场才发现真实场景的数据分布完全不一样，那验收就失去意义了。最稳妥的做法是，验收测试集中至少包含一部分从目标现场采集或模拟现场条件生成的数据。

这三条边界定完，验收方案才有讨论的基础。否则你测出来的所有数字，都可能被一句话噎回来：“那不是我们承诺的场景。”

2. 超维方程五项检查的逻辑：从跑通到扛住

2.1 五项检查分别解决什么问题

“端侧 AI 样机”最终要做的事情可以拆成一个链路：输入信号进设备 → 预处理 → 模型推理 → 后处理 → 业务系统响应。这个链路要能连续、稳定、准确、不掉链子地运行，等价于五个层面的能力同时达标。

我先把五项检查的整体逻辑列出来，后面逐个展开讲操作细节：

五个检查之间有递进关系：检查一解决“模型能不能在这个硬件上跑”的问题；检查二解决“跑出来的结果准不准”的问题；检查三解决“跑得快不快、资源占得多不多”的问题；检查四解决“跑久了会不会出问题”的问题；检查五解决“换了个环境还灵不灵”的问题。前两项过了，说明样机“基本能用”；后三项过了，说明样机“扛得住真实使用”。

2.2 软硬件基线登记：验收的前提动作

这个动作特别容易被忽略，但它是验收报告能不能成立的地基。曾经因为框架版本升级，同一份模型输出结果批量偏了几个像素，害得整个验收重测了一轮。所以正式开测之前，一定要先做基线登记。

需要登记的内容至少包括：样机硬件版本号、芯片序列号或批次、SoC 型号、内存容量、存储介质与剩余空间、操作系统版本、内核版本、推理框架版本、各依赖库版本、模型文件 hash 值、权重量化方式、测试固件版本，以及测试工具自身的版本。每一项都用文档记录，不允许“好像是”“大概”这类描述。

基线登记表还要留一个“变更记录”区域。验收期间如果更新了固件或模型，必须记录更新后的版本和刷新时间，同时标注“本次更新影响哪些测试项需要重跑”。没有这个意识，后面出了问题连复现都无从下手。

3. 检查一：编译链路与算子兼容性检查

3.1 模型转换这一步最容易埋雷

把训练好的模型从标准框架转到端侧推理框架，这是整个端侧 AI 交付里最容易被低估风险的一步。很多团队验收时直接跳过转换过程，只拿转换后的模型跑一遍 demo，看着能出结果就觉得万事大吉。但“能出结果”和“所有算子都被高效执行”完全是两码事。

以图像分类模型为例，模型里可能有几十上百个算子。端侧推理框架对常见算子（卷积、池化、全连接、激活函数）有深度优化，但对那些冷门的、自定义的、或者特殊组合的算子，支持程度可能很差。我曾经遇到过一个模型，98% 的算子都正常跑在 NPU 上，就剩一个在 PyTorch 里特别方便的算子，目标平台上不支持，整套推理被踢回了 CPU。CPU 上跑全模型，帧率从 30 掉到 7，业务根本没法用。

所以编译链路检查的第一步，是获取模型转换时产生的算子映射报告。不同推理框架叫法不同，比如有的叫 profiling 日志，有的叫 IR 转换报告，核心内容就是：模型里每个算子对应的执行单元、每层的数据类型、以及是否存在算子拆分或替换。拿到报告后重点筛查：哪些算子走了通用回退路径？哪些算子用了模拟支持（即框架表示支持，实际上是模拟计算）？哪些算子的输入要求被悄悄改写了？

3.2 如何梳理算子支持矩阵与回退策略

实操中，我会做一张算子清单表，把模型里出现的算子逐一列出，对应标注目标推理框架的支持情况。这张表不要求覆盖框架所有算子，但要求完全覆盖当前模型的算子集合。检查顺序如下：

先看是否存在完全不支持的算子。存在的话必须确认替代方案，比如用多个基础算子组合代替，或者修改模型结构避开这个算子。出现这种情况，模型可能必须重训或微调，绝不能硬上。

再看是否存在部分支持或性能丢失的算子。有些框架报告“支持”，但底层是把算子在 CPU 和 NPU 之间来回搬运数据，或者用低效方式模拟。要特别留意那些报告中标记了“fallback”“refactor”“rebuild”之类的字段，一个都不能漏。把这些算子抓出来，跑一个单独的性能基线，看看它消耗了多少毫秒。如果在整条链路里的占比超过了全模型耗时的 10%，就要考虑修改模型结构了。

最后做一次整个模型的端到端编译验证。编译成功的标志不是“没报错”，而是把推理框架的调度日志打印出来，确认整张推理图的执行计划符合预期。比如所有卷积层都在目标加速器上执行，没有任何 subgraph 跑到 CPU 上去。这一步看起来繁琐，但它能提前暴露绝大多数“为什么上线后这么慢”的问题。

3.3 检查一容易漏掉的细节

上述流程之外还有几个细节，踩坑概率极高，单独提出来：

第一，模型的动态维度问题。如果模型支持动态输入（比如检测模型允许不同分辨率），转换到端侧框架后可能要静态化处理。检查时要确认输入尺寸在运行时是否被强制 resize，resize 算法与训练时是否一致。做过图像处理的人都知道，从 bilinear 换成 nearest 会让边界检测的精度有明显变化。

第二，多线程与内存分配策略。有些框架在模型转换时会生成包含线程数、内存池大小等参数。若不做配置就直接跑默认值，在资源紧张的设备上可能导致推理时延严重波动。检查时要记录实际生效的线程配置，并确认它和开发环境一致。

第三，后处理算子的归属。非极大值抑制、阈值过滤这类后处理有时在 GPU/CPU 上执行，有时可以直接挂在推理框架内部。后处理的实现位点直接影响端到端时延，检查编译报告时不能只看推理部分，还得看整条业务链路。

4. 检查二：端侧输出精度对比检查

4.1 参考基准怎么定

部署在端侧之后，模型的数值输出几乎不可能和训练阶段完完全全一致。原因有几个：权重从 FP32 转成了 FP16 或 INT8；算子在不同硬件上的实现细节有差异（比如卷积的累加顺序不一样）；激活函数可能用的近似实现。所以验收时不能要求“输出一模一样”，要定义一个“可接受的偏差范围”。

参考基准的选择，我建议在目标平台支持的最高精度模式下跑一组标准测试样本，作为该平台下的“准参考”。如果目标平台本身不支持高精度模式，那就用训练框架在 PC 上跑同一批样本，作为外部参考。两个参考都保留，因为它能帮你区分偏差到底是“平台差异”还是“精度损失”。

获取端侧输出之后，逐层对比或者最终输出对比都要做。这里引入一个“最大绝对误差”的概念：逐层统计推理结果的数值差距，记录所有层里的最大绝对误差及其所在层。这个指标比平均误差更能反映问题的严重程度，因为某个层的误差一旦偏大，后面网络的输出就可能被带偏。

4.2 误差度量的三个层次

只计算“模型输出的数值误差”是不够的，需要分三个层次来度量。

层次一：中间张量偏差。选定若干个代表性中间层，将端侧输出和参考输出的张量逐元素做差，统计绝对差分布。如果差值呈均匀分布且幅度很小，问题不大；如果差值集中在少数通道或特定空间位置，说明某些层对量化误差特别敏感，需要进一步排查。

层次二：任务级指标偏差。根据业务任务的评估指标来对比，比如分类任务的 Top-1/Top-5 准确率、检测任务的 mAP、分割任务的 mIoU。端侧指标相对参考指标的下滑幅度应该有一个明确的验收阈值，比如“mAP 下跌不超过 1 个百分点”。注意，这个阈值必须事前定义，不能等测完再拍脑袋决定，否则验收就失去客观性了。

层次三：业务语义验证。这一步是把端侧输出的结构化结果映射回真实业务场景，人工判断是否合理。有时候数值指标都过线，但仔细看错例，发现样例全部集中在某种“业务上不可接受”的情况，比如把背景误检为目标且置信度很高。业务语义验证不能少，它是站在用户视角对模型结果的最终把关。

4.3 定位精度劣化的排查手段

如果端侧输出和参考输出差距偏大，怎么定位？这里分享一个逐步缩小范围的排查思路：

先检查输入数据预处理是否一致。读图方式和归一化方式是最常出错的环节。比如读图时颜色通道排列差异（RGB 还是 BGR），归一化时用的均值方差与训练时是否一致，图像缩放时插值算法的差异，这些都会导致模型输入分布偏移，进而引起输出偏差。尤其要注意端侧摄像头上来的原始数据往往是 NV21/YUV 格式，转成 RGB 后再归一化，比 PC 上直接读 JPG 多了一道转换，转换参数不一致就会引入固定偏差。

再检查量化校准集与真实数据分布是否对齐。INT8 量化的校准过程需要一批有代表性的统计数据，如果校准集和真实业务场景分布不一致（比如校准集里都是白天室内，实际场景却是夜晚户外），量化参数就会在特定区间内产生较大误差。这种情况表现为“整体偏差不大，某些特定样本类别误差突出”。

最后用逐层输出对比来锁定误差源头。在推理框架里开 debug 模式，逐层输出端侧中间张量，与参考框架同层张量对比。误差从某一层开始突然变大，那问题就锁定在那附近。最常见的原因包括：该层对数值范围极度敏感、该层的量化 scale 设置不合理、该层之前的某个层在端侧实现中做了数值截断。

5. 检查三：端到端时延与资源水位检查

5.1 延迟分析要拆开 Pipeline 来看

很多团队验收时只看“端到端时延”——从摄像头捕捉到一帧到业务拿到结果的耗时，这个数字有意义，但对于定位问题远远不够。端侧 AI 的完整链路通常包括图像采集、预处理、推理、后处理、业务逻辑多个环节，每个环节都可能成为瓶颈。为了准确定位，必须把整条 Pipeline 打点，分段计时。

打点的方法很简单：在每个环节的入口和出口记录时间戳，用微秒级别的计时函数，把每段耗时输出到日志或内存环形缓冲区。测试跑完后，把分段耗时数据拉出来，统计每一段的 P50、P90、P95、P99 耗时。注意 P99 比均值重要得多，均值好看不代表系统流畅，真正影响体验的是极端情况下的卡顿。

典型的问题模式我在项目里遇到过好几种。推理耗时只占 30%，剩下 70% 全在图像采集和格式转换上，说明采样链路的驱动程序或缓冲区设计有问题；预处理耗时随分辨率变化剧烈，说明算法复杂度对输入尺寸太敏感；后处理在 CPU 上执行且不时和其他任务抢资源，导致 P99 远高于 P50。

5.2 CPU、内存、功耗的联动记录

时延只是表象，资源水位才是根因。每跑一轮压力测试，应该同步记录 CPU 占用率、内存占用、功耗/电流这几个指标，并保证时间戳对齐。

CPU 占用率重点关注两类情况：一是推理时单核/多核是否被跑满，是否存在某个核始终 100% 而其他核空闲，说明任务调度不平衡；二是 CPU 占用率的波动曲线是否存在周期性尖峰，这种尖峰往往是后台服务定期唤醒导致的，会影响 AI 推理的实时性。

内存占用重点关注两项：常驻内存的绝对值（RSS）和它的增长率。如果 RSS 在启动后慢慢爬升，且不随测试时长收敛，那基本可以断定有内存泄漏。另一种情况是内存池碎片化严重，表现为 RSS 不涨但推理时延越来越不稳定，因为每次分配都要花更多时间找合适的内存块。

功耗和温度要一起看。端侧设备散热有限，持续高负载运行会让芯片温度升高到阈值，然后触发降频，表现为“前 10 分钟性能正常、之后明显变慢”。这时需要在日志里加入温度采样点：什么时候升温、什么时候降频、降频之后性能恢复曲线如何。这些数据对硬件散热设计的最终确认非常有价值。

5.3 吞吐与多路并发场景

除了单帧时延，还要测连续运行情况下的吞吐能力。简单说有两点：帧率是否稳定，以及处理队列是否堆积。

连续跑 1000 帧，统计每帧耗时，画出耗时分布。如果分布集中在均值附近，说明系统稳定；如果出现大量拖尾，说明存在间歇性阻塞。阻塞的来源可能是内存分配、缓存未命中、调度延迟，也可能是 DMA 传输和其他任务冲突。

多路并发的场景也要测：多个摄像头输入、多路推理请求并行这些情况，其实就是把单路时延之外的资源竞争充分暴露出来。曾经有个智能终端项目，单路推理时延只有 15ms，四路并发后时延直接飙到 80ms 以上，原因是多个推理实例同时申请大块内存时触发了锁竞争。这类问题不实际压测，看代码是发现不了的。

6. 检查四：长稳与压力测试

6.1 热极限测试：把设备跑到“不想跑”为止

长稳测试是很多团队验收时最敷衍的一项，经常是开机放那跑一晚上，第二天看没死机就当过了。这个做法不行，因为**“没死机”和“性能没劣化”是两回事**。设备可能没崩溃，但推理时延涨了三倍，用户感受上就是越来越卡。

真正有效的方法是做热极限测试：让设备在最大负载下持续运行至少 4 小时，同时监控芯片温度、推理时延、CPU 频率。观察三个关键曲线拐点：

第一，温度是否达到散热设计极限并稳定下来。如果温度持续上升不收敛，硬件散热存在缺陷，长期运行寿命堪忧。

第二，频率是否出现明显下降。一旦温升触发降频，CPU/GPU 频率会维持在一个较低档位。要把降频前后的时延数据分别统计，确认降频后的时延是否仍满足业务指标。如果降频后时延超标，那就要和硬件团队讨论加强散热或调整负载策略。

第三，从高温恢复常态的过程中，性能能否回到初始水平。理想情况是设备在负载降低后能逐步降温，频率恢复到高位，时延回落，形成一个良性的回环。如果降温后性能也回不去了，说明设备进入了某种锁死状态，后续必须查电源管理策略。

6.2 内存泄漏、句柄泄漏与资源回收观察

内存泄漏在端侧设备上的隐蔽性比 PC 上高得多。PC 环境内存大，泄漏个几十 MB 看不出来；端侧内存小，泄漏几百 KB 连续叠加就能把系统拖垮。常用的观察手段是每隔固定间隔采样一次进程的 VmRSS 和 VmSize，画成时间序列曲线。曲线斜率长期为正且不趋稳，就存在泄漏。

除了内存，还要盯文件描述符和匿名 mmap 数量。很多端侧 AI 框架会在每次推理时创建新的临时文件或映射区域，如果释放逻辑写错，句柄就会持续累积。句柄耗尽的表现很隐蔽，系统不会立刻崩溃，但会出现越来越频繁的 IO 异常、偶发的卡顿、甚至摄像头突然掉线。

另外别忘了显存或专用内存的回收情况。有些框架把所有推理中间结果都缓存在专用内存里，长期运行后缓存膨胀，导致后续推理申请大块内存失败。观察专用内存的使用率和碎片情况，比单看系统内存更能反映深度模型的资源行为。

长稳测试之后再加一项清理恢复测试：手动触发业务停止、进程重启、系统休眠唤醒，观察所有资源是否回到初始水位。设备重启恢复不到初始状态，说明有常驻泄漏。

6.3 异常掉电与断电重启

长稳测试里必须有异常掉电的环节。端侧设备经常出现在野外、车端、工控环境，电源质量远不如实验室，异常断电几乎是必然会发生的事件。

掉电测试分两种。一种是软件层掉电：业务系统还在运行时，模拟系统突然掉电，然后重新上电，观察设备能否正常启动、AI 推理服务能否自动拉起、缓存的数据是否需要人工清理。另一种是硬件层掉电：直接在电源输入口切断供电，然后恢复，观察存储介质上的数据是否损坏、文件系统能否正常挂载。

这项测试的重灾区是数据一致性问题。模型文件如果因为断电损坏，可能导致推理框架加载失败；业务日志如果写了一半，可能导致恢复后逻辑错乱。还有一些设备用临时文件保存模型映射表，断电后这张表不完整，启动时会反复重建索引，表现为启动时间异常拉长。

掉电测试一定要记录恢复时间，定一个“异常掉电恢复时长上限”，比如 30 秒。超过这个时间，用户端体验就是“设备死机了”。如果每次断电压根无法正常恢复，这个样机是绝不能放行的。

7. 检查五：场景鲁棒性与对抗样本测试

7.1 现场样本采集比什么数据集都重要

到最后一项检查，前面四项都过了，说明样机“在测试环境里很稳”。但真正交付后，测试环境里跑不到的那些真实场景会给你上一课。所以第五项检查的本质是：让样机面对真实世界的混乱。

采集现场样本是整个鲁棒性检查的起点。如果项目能接触到目标使用场景（工厂车间、户外公园、商场过道、车内空间都行），尽量在真实场景里采集一批数据。采集时有意识地覆盖几个维度：一天中的不同时间段、天气变化（对应光照变化）、目标物不同的状态（比如不同姿态、不同遮挡程度）、背景的复杂度变化。

如果接触不到真实场景，也要按真实场景的特点来构造模拟数据。比如用不同色温的灯光模拟早晨和傍晚，用高斯模糊模拟镜头脏污，用随机裁剪模拟遮挡。模拟数据永远没有真实场景那么“野”，但至少能提前暴露模型对光照和遮挡的基本敏感度。

7.2 光照、遮挡、相似物这三类大坑

从我经手的项目来看，端侧 AI 效果现场翻车主要集中在三个方面，鲁棒性检查也要围绕它们做细。

光照变化是最常见的问题源。很多模型在标准光照环境中表现良好，但一遇到逆光、强侧光或突然的灯光切换，准确率就会大幅下跌。针对光照，测试时至少覆盖低照度、高照度、逆光、混合光源这几个条件，并记录样机能否自动调节曝光。还要注意自动曝光算法和模型推理是串行关系时，画面亮度变化会导致推理时延波动或结果跳动。

遮挡问题在目标检测和识别类任务中极其突出。现实中目标物体很少完整地呈现在画面中央，往往会有部分遮挡、和其他物体重叠、或者目标本身只露出极小的一部分。测试样本里要专门构造遮挡比例梯度：10%、30%、50%、70% 的遮挡，分别看模型能否正确识别。关键不是看“几十个点掉多少个”，而是看遮挡到什么程度开始出现系统性误判，这个临界点要记录，写进产品说明书里作为能力边界。

相似物混淆是指那些外观高度相似但属于不同类别的物体。比如饮料瓶和洗衣液瓶、不同品种的宠物、不同款式的同类型工业零件。模型在测试集上分类清楚不代表在现场也分得清，因为生产环境的物体颜色、纹理、包装都会和训练集有差别。测试时把可能混淆的物体配对组合，让模型反复分类，观察是否存在系统性偏向——比如某个类别总是被识别成另一个类别。

7.3 回归集与增量集的分工

最后说一下鲁棒性测试的数据集管理。我建议把测试数据分成两个集合，职责不同，缺一不可。

回归集是冻结的，内容不再变化，每次改模型、改固件之后，重新跑一遍回归集，确认原有能力没有退化。回归集里主要是各类典型场景的代表样本，覆盖各光照条件和部分遮挡情况，数量不一定多，但要有代表性。团队里应该规定，任何模型更新如果回归集指标下跌超过预设阈值，该版本不允许发布。

增量集是持续更新的，每次现场发现新问题，就把出问题的样本加入增量集。它的作用是防止“修了这个坑、漏了那个坑”的情况。增量集扩大后，隔一段时间把增量集合并进回归集，让回归集逐步逼近真实场景的复杂程度。

这两套数据集分开管理还有一个好处：验收结论里的指标都只在回归集上报告，不会因为增量集的频繁变动导致验收指标“漂移”，后面对比不同版本也有了一个稳定的标尺。

8. 验收结论怎么下：问题分级、报告结构与最终判定

8.1 问题分级不能含糊

五项检查全部执行完，一定会收集到一堆问题。怎么判断这些问题是否影响放行？我建议把所有问题分为三个级别：

P0 级：阻断性问题。样机无法满足最基本的业务承诺，比如模型在某些核心算子路径上完全不可用、端到端时延严重超标、长时间运行后设备死机、核心精度指标跌破验收红线。出现任何一项 P0，验收结论都是“退回”，没有商量余地。修完必须重新执行全量回归测试。

P1 级：重要问题。影响主要使用场景或主要用户体验，比如 P90 时延超标但 P50 合格、在特定光照条件下识别率明显下跌、内存泄漏但泄漏速度较慢（需要连续跑 24 小时才出问题）。这类问题的处理方式是“有条件放行”：样机可以进入下一阶段，但必须给出明确的修复计划和时间点，修复后重新跑相关子项测试。

P2 级：一般问题。不影响当前主流程但有潜在风险，比如日志信息不全导致后期运维诊断困难、某类罕见样本下精度轻微下降、资源回收不够及时但未造成明显影响。这类问题记录在案，后续版本优化即可，不影响当前放行。

这个分级体系并不复杂，但很多团队从来没有事先定义。结果就是验收现场发现一堆问题，每个人对严重程度的判断都不一样，吵到最后只好拍脑袋决定。先定义分级再执行测试，结论出来之后大家按规则对照，没有争议空间。

8.2 验收报告的“五段式”写法

验收结束之后，报告要能扛得住别人追问细节。我见过太多验收报告写得像广告文案，满篇“运行正常”“表现优异”，连最基本的测试条件都没交代清楚。一个合格的验收报告，我建议包含五个固定部分：

第一部分是测试环境与基线信息，把送检样机型号、硬件版本、固件版本、模型版本、测试工具版本、数据集版本全部列清楚。这部分的目的是让任何人按图索骥，可以完整复现测试条件。

第二部分是测试方法与用例说明，写明五项检查各自的测试步骤、测试参数、样本数量、统计方法。比如“端到端时延测试中，连续运行 1000 帧，统计每帧从采集到业务回调的耗时，取 P50/P90/P95/P99”。这个描述比“测了帧率”精确得多。

第三部分是测试数据与结果汇总，用表格列出每一项检查的数据结果、参考阈值、判定结论。这里只放数据，不做主观评价。

第四部分是问题清单与分级，把所有发现的问题按 P0/P1/P2 列出，附上问题的发现场景、影响范围、初步定位结果、建议处理方案。问题没有正确归属，后面无法闭环。

第五部分是验收结论与放行条件，写明最终结论属于“通过”“有条件放行”还是“退回”，并列出所有放行条件。条件回到第四部分的问题清单，每条对应一个编号，做到责任可追溯。

8.3 谁验收，谁负责

最后说一个不太技术但特别重要的事：验收结论要有明确的负责人。样机验收不是一个仪式，它本质上是对“产品是否满足交付要求”做出的一次技术背书。负责签署验收意见的人，要能对自己的结论负责。如果验收时放过了 P1 问题，结果设备批量部署后出了问题，这个责任不能推给“大家”。

落实到操作层面，验收启动前应该指定一名验收负责人，所有结论由他汇总和签署。他可以征求团队里所有人的意见，但最终签字只有一个声音。这样做的好处是不但决策效率高，而且倒逼验收负责人认真把关，而不是敷衍了事。

写在最后

我从超维方程这个团队的实践里总结出一个看法：端侧 AI 样机验收，本质上不是在给产品找茬，而是在给产品划定“安全飞行包线”。五项检查全部做下来，你能清楚地知道这台机器什么条件下能全力运转、什么条件下会明显劣化、什么条件下会直接罢工。带着这份认知去做量产决策、去写产品说明、去做交付承诺，每一句话都有测试数据托底。

最后一件事，简单但重要：把验收用的所有脚本、参数、数据集、日志归档保存，别等验收完就丢一边。版本更迭是必然的，下一轮验收还会回来找这些东西。