51单片机校车安全检测系统：气体传感器+WiFi+舵机联动调试

这两年陆续帮好几个学弟学妹调过校车安全检测方向的单片机项目，踩过的坑比想象中多。很多人照着网上的教程把模块买齐、代码烧进去，就觉得万事大吉，结果一联调就露馅：ADC读数上下乱飘、ESP8266发AT指令没反应、舵机一动作整个板子直接重启。这篇文章把基于51单片机的校车安全检测系统中，可燃气体检测、WiFi传输、舵机联动、声光报警这几个模块的选型逻辑、硬件接线、程序结构和实测调试经验从头到尾复盘一遍，适合正在做毕设课设、或者想用51单片机组一套环境监测远程预警系统的读者参考。

1. 校车安全检测系统的需求拆解：为什么是“气体检测+WiFi+舵机声光”这套组合

1.1 校车环境里真正需要防的是什么气体风险

校车不是普通轿车，它的载客对象是儿童，应对突发情况的能力本来就弱。我接过这类项目后重新梳理过一遍现场场景：校车在接送点长时间停靠、发动机不熄火等待时，如果附近有液化气槽罐车泄漏、地下燃气管网泄漏，或者车内加装的采暖设备用的是天然气，气体很可能顺着空调进风口、车门缝隙慢慢渗入车厢。校车内部又是一个相对密闭的空间，可燃气体浓度一旦在短时间内上升，接近爆炸下限（LEL），任何一个微小电火花都可能引发严重后果。

另外还有一个很现实的隐患——儿童随身携带的物品。低年级孩子对打火机、酒精喷雾这类东西没有概念，落在座位上、塞在书包里，高温暴晒下挥发出的可燃气体同样存在风险。这类风险的特点是“看不见、摸不着、闻不到”，所以需要一套自动检测的电子系统代替人的鼻子。这里选择可燃气体传感器而不是烟雾传感器，是因为可燃气体传感器对甲烷、液化石油气、丁烷这类气体更敏感，覆盖面刚好匹配校车的主要风险来源。

1.2 检测到异常之后，为什么还一定要做WiFi传输

很多没接触过物联网项目的同学会问：车上有司机、有老师，报警器和舵机都在现场，还费劲搞WiFi干嘛？

这个问题的答案要从实际使用场景里找。校车熄火停在停车场时，驾驶位上是没有人的；校车在接送点停靠时，老师可能会下车组织孩子排队，车内短暂无人。如果气体泄漏发生在这些时间段，现场声光报警根本没人看得见。WiFi传输的价值在于把检测数据送到“有人看的地方”——车队管理后台、门卫监控屏或者负责人的手机端。这样管理人员不用上车就能判断这辆车此刻是不是处于危险状态。

WiFi传输还有一个容易被忽视的作用：历史数据留痕。系统可以持续把气体浓度数据、报警状态、舵机动作记录上传，一旦事后需要复盘某次事件发生的过程，直接翻后台记录就行。对于校车这类公共安全场景，“有记录”和“没记录”是完全不同的责任边界。所以WiFi不是锦上添花，它承担的是“远程感知”和“可追溯”这两项核心任务。

1.3 舵机和声光报警在系统里各自的角色

这套系统的执行端分两路：一路是提醒人，一路是处置事。

声光报警是提醒人的——蜂鸣器发出区别于环境噪音的急促声音，红色LED快速闪烁，让周围人第一时间注意到异常。校车运营方通常有一整套应急处置预案，声光报警的作用就是触发预案的信号。

舵机是做机械动作的——这是很多课设项目里做得最敷衍的部分。有人随手接了个舵机让它转90度，但没想清楚它在真实场景里到底执行什么动作。在一个完整方案里，舵机的典型任务是带动联动机构关闭燃气瓶阀门，或者打开应急排风窗的锁扣，甚至在更复杂的方案里切断危险设备的供电开关。舵机的优势在于它能输出连续角度控制，实现继电器的“通/断”做不到的机械行程。项目为了演示方便，一般会把舵机装在一个模拟阀门或挡板上，但程序逻辑必须按真实场景去写，这样答辩和实际部署时才站得住脚。

2. 硬件选型与电气连接：从51单片机到传感器、WiFi和舵机的接线关系

2.1 经典51系列为什么在2025年依然值得选

现在说单片机选型，很多人第一反应是STM32、ESP32。但我仍然建议把51系列放在考虑范围里，尤其是STC89C52、AT89S52这类芯片。

理由很实在：第一，51单片机足够简单，所有IO口的使用逻辑一目了然，对掌握“传感器怎么接、数据怎么采、外设怎么驱动”这套底层知识非常合适。第二，51的配套资料极其丰富，几乎每个模块都有现成的驱动例程，课设和毕设节奏紧张，用51能省下大量查手册的时间。第三，也是最关键的——这套校车安全检测系统的实时性要求并不苛刻，气体浓度变化是秒级过程，WiFi透传是毫秒级指令交互，51的12MHz或11.0592MHz主频完全跑得动。

功耗、性能这些维度确实不是51的强项，但在这个项目里没有一样是瓶颈。我用过STC89C52RC和STC12C5A60S2两个型号，前者适合入门，后者多了一路内置ADC和更多定时器，如果不想外接ADC芯片，直接选它会更省事。具体的采集方案下面会展开讲。

2.2 可燃气体传感器：MQ-2、MQ-4、MQ-5怎么挑

可燃气体传感器系列里最常被拿出来对比的是MQ-2、MQ-4和MQ-5。这三者外观几乎一样，但气体敏感侧重点完全不同。我做了个表，方便直接对照：

校车场景里最有可能出现的可燃气体包括液化石油气、天然气（主要成分甲烷）、以及打火机里的丁烷类气体。MQ-2覆盖范围最宽，能把液化气和丁烷都管起来，所以我最终选的是MQ-2作为主传感器。如果项目的题目里明确强调了“天然气”相关，那MQ-4更精准；如果强调“液化气”，MQ-5更对口。这里没有绝对标准，关键是弄清楚题目要检测的对象。

2.3 信号采集方案：内置ADC还是外置ADC0832

MQ系列传感器输出的是模拟电压信号，而单片机只能处理数字量，所以中间必须有个模数转换环节。

STC89C52RC本身没有内置ADC，需要外接ADC芯片。最常用的选择是ADC0832，8位双通道串行ADC，接线简单，只需要CLK、DO、DI和CS四根线，对51这种IO资源紧张的平台很友好。如果选用STC12C5A60S2这类带10位ADC的芯片，可以省掉外置芯片，但程序配置要稍复杂一些。

从整个系统的精度需求看，8位ADC其实够用。ADC0832的输出范围是0-255，对应0-5V电压，在我们这个项目里并不需要把气体浓度精确到个位数ppm，分辨到“正常、预警、报警”三个状态就足够了。而且单片机本身抗干扰能力有限，外界电磁干扰下10位ADC的低两位经常是跳变的，还不如8位稳定。所以不必一味追求ADC位数，稳定比精度重要。

2.4 ESP8266-01的接入和电平匹配细节

WiFi模块选用ESP8266-01，这是国内做物联网课设最流行的方案。它负责把单片机串口出来的数据通过WiFi送到局域网内的服务器或云平台。51单片机工作在5V电平，ESP8266工作在3.3V电平，两者直接连串口会导致模块烧坏或者收不到数据。处理方法是把单片机发送到ESP8266 RXD的信号线上串一个1kΩ电阻限流，ESP8266 TXD到单片机RXD方向的信号是3.3V，对51来说已经能可靠识别，可以直接相连，更稳妥的做法是再加一个分压电阻网络。

供电上要特别注意，ESP8266-01的峰值电流能到300mA甚至更高，如果用开发板上的AMS1117-3.3直接喂，很容易掉电压导致模块启动失败。我后面实测部分会详细讲这个坑，这里先记住一个原则：给ESP8266单独用一个低压差稳压芯片或者靠谱的3.3V电源，不要和单片机共用一个小稳压器。

2.5 舵机、蜂鸣器和LED的驱动细节

舵机选用SG90模拟舵机，扭矩不大，但用来带动一个小型模拟阀门机构绰绰有余。SG90的信号线接单片机任意一个IO口，电源用独立5V，地线必须和单片机共地。强烈建议在舵机电源两端并一个1000μF左右的电解电容，舵机启动瞬间电流是正常工作的好几倍，不加电容很容易把系统电压拉低。

蜂鸣器分有源和无源两种。有源蜂鸣器只要给高电平就响，程序最简单；无源蜂鸣器需要给一定频率的方波才能发声，可以实现“滴—滴—”的节奏控制，更灵活。考虑到声光报警里需要区分预警和报警两种状态，我推荐用无源蜂鸣器，通过定时器输出不同频率的方波，配合LED的闪烁节奏形成明显的状态区分。LED驱动要串联限流电阻，一般是220Ω到1kΩ，具体根据供电电压和LED额定电流算。

2.6 这套系统的完整接线汇总

我把整个系统的硬件连接整理成一个总表，方便搭板子的时候直接对照：

实际接线的时候我建议分区域布线：信号类线束（ADC、串口、传感器）走一边，功率类线束（舵机、蜂鸣器电源线）走另一边，减少干扰耦合。

3. 可燃气体检测链路的工程细节：从传感器电阻变化到稳定阈值

3.1 MQ传感器比想象中简单，也比想象中“娇气”

MQ-2这类传感器的核心是表面涂覆了二氧化锡气敏材料的陶瓷管，内部同时有一个加热电阻。工作时加热电阻把材料加热到几百摄氏度，二氧化锡在空气中会吸附氧分子，形成表面势垒，电阻处于一个比较高的稳定值。当还原性气体（可燃气体都属于还原性气体）出现时，气体分子与表面吸附氧发生反应，释放电子，材料电导率上升，也就是等效电阻下降。

简单理解：传感器内部是一个“看气体浓度变化而改变阻值”的可变电阻。气体浓度越高，阻值越低。这个阻值变化通过配合一个固定负载电阻形成分压，就能变成单片机可读的电压信号。但“娇气”的地方在于，它受温度和湿度影响很大，环境温度变了基线会漂移；刚通电的几分钟内，加热丝还没达到稳定工作温度，输出也不可靠。所以系统设计里必须留预热时间和软件滤波环节。

3.2 分压采集电路与RL取值逻辑

MQ系列模块一般有两种输出方式：数字量输出（经过比较器）和模拟量输出。校车安全检测需要对浓度做分级报警，所以必须用模拟量输出，也就是把传感器串接一个负载电阻RL，取RL两端的电压送给ADC。

RL的取值决定了检测灵敏度。以MQ-2为例，官方建议的RL范围是10kΩ到20kΩ，负载电阻越大，在相同气体浓度下分压变化越明显，灵敏度越高。我用的是模块自带的可调电位器，先调到中间位置，然后用标准气体源（这里用打火机气体）实测采集值来反推合适的灵敏度点。这个思路其实不复杂：灵敏度太高会在空气中误报，太低则漏报，关键是找到适合校车车厢这个中等密闭空间的工作点。

3.3 从ADC值到电压和浓度的换算

ADC0832是8位分辨率，当基准电压是5V时，采集值ADC_Val对应的电压为：

V = (ADC_Val / 255) × 5

比如说单片机读到ADC值128，那传感器输出电压大概是2.51V。这个电压值本身没有绝对意义，还要结合标定曲线才能换算出浓度。MQ系列官方手册里会画一条灵敏度特性曲线，横坐标是气体浓度，纵坐标是Rs/R0的比值。正规一点的系统会用多点标定来拟合这条曲线，但课设和一般工程应用中，更务实的做法是直接用ADC值设立阈值，不纠结准确的ppm数值。

原因很现实：传感器个体差异大，同一个型号的不同模块，在同样气体浓度下的输出可能差20%以上。与其追求理论标定精度，不如把它当成一个“相对浓度检测器”，标定出一个可靠的分级阈值。

3.4 标定阈值：用数据说话，不要拍脑袋写死数

我最怕看到的代码就是“if(adc_value > 100) 报警”，这个100是怎么来的？完全没有依据。正确的标定步骤是这样的：

上电后先让系统预热5分钟，让传感器加热丝稳定工作，然后记录新鲜空气环境下的ADC基线值。我实测过，常温干净空气下，ADC值一般在20到40之间波动。接下来找一个安全的气体源——注意是打火机里的丁烷气体，不是明火——在通风良好的环境下，把没有点燃的打火机凑近传感器3到10厘米处，轻轻按压释放气体，观察ADC值的响应范围。

按我的实测数据：气体靠近10厘米时，ADC值能到120到170；气体直接凑近3厘米时，ADC值可以冲到180到230以上。于是我把预警阈值定在90，报警阈值定在150，基线在40以下，中间留了足够的缓冲。这样既不会因为基线漂移误报，又能比正常基线提前约两倍数值就给出预警。

需要提醒的是，这套阈值只对我这块板子和这个环境点是有效的。每块开发板换了模块、每换一个教室环境，都要重新跑一遍标定流程。强行套用别人的阈值，是联调阶段误报的一大来源。

3.5 软件滤波与报警确认机制

传感器输出说到底是模拟信号，噪声抖动的幅度在几个ADC位上非常正常。所以软件上必须做两层处理：第一层是采样滤波，第二层是报警确认。

采样滤波我用的是“去极值滑动平均”：连续采样10次，去掉最大值和最小值，把剩下8个值取平均。这个滤波方法对抑制突发毛刺很有效，同时比单纯套一阶低通滤波更容易理解和调试。代码实现起来也就几十行。

报警确认机制更关键，它的作用是防止“一有尖峰就报警”的尴尬。我在主循环里加了一个连续采样计数器：只有当连续3次采样都超过阈值时，才真正触发预警或报警状态。这样做相当于做了一次时间维度的去抖，短促的干扰脉冲就不会触发误报了。实测中，这个机制把误报率从肉眼可见的频繁触发降到了几乎没有。

4. WiFi传输的对接细节：ESP8266与51单片机如何稳定“对话”

4.1 51单片机、串口和AT指令的基础配合

ESP8266的一大特点是它内置了完整的TCP/IP协议栈，单片机完全不需要处理复杂的网络协议，只要通过串口发送AT指令，模块就会自动完成连接AP、建立TCP连接、透传数据这些工作。

初始化流程是一组固定的AT指令序列：

AT AT+CWMODE=1 AT+CWJAP="你的WiFi名称","WiFi密码" AT+CIPSTART="TCP","192.168.1.100",8080 AT+CIPMODE=1 AT+CIPSEND

这段序列的意思是：测试模块是否响应、切换到STA模式、连接路由器、建立TCP连接到服务器、进入透传模式、开始发送数据。进入透传模式后再发给串口的所有内容都会被直接打包成TCP数据发出，省去了每条数据前面加长度的麻烦。

4.2 电平匹配、波特率和串口资源分配

51单片机只有一个硬件串口，平时烧录程序要占用它，和ESP8266通讯也要占用它。我的处理方式是把烧录用的下载器和ESP8266通过一个拨码开关或者跳线帽切换：调程序时切到下载器，跑系统时切到WiFi模块。如果调试阶段还需要从串口打印传感器数据，干脆临时把ESP8266拔掉，用USB转TTL直接看打印信息，调好了再装回去。

波特率方面，ESP8266默认是115200，但51单片机在11.0592MHz晶振下，115200的波特率误差偏大，无线通讯一旦有误码，AT指令就经常不识别。我的做法是先把模块固件波特率改成9600，用指令“AT+UART_DEF=9600,8,1,0,0”设置，并让它保存到Flash。这样51的波特率在9600下几乎没有误差，通讯稳定得多。

4.3 一种适合51环境的数据帧格式

数据帧的设计很多人不在意，觉得“能发出去就行”，但联调时就会发现，接收端判断不了一帧数据从哪开始在哪结束。这里我推荐用固定的十六进制帧格式，长度短、解析简单：

帧头0xAA用来同步，设备地址方便以后接多辆车，浓度值拆成高低两个字节，状态码定义了0x00正常、0x01预警、0x02报警，校验字节是前面所有字节的累加和。接收端先判断帧头，再解析数据，最后累加校验，对不上就丢弃整帧。这套帧结构虽然简单，但已经能应对绝大多数单向传输场景。

4.4 心跳包、掉线检测与自动重连

WiFi传输最大的隐患是“看着连上了，其实早就断了”。ESP8266在待机状态下不会主动告诉单片机连接已经断开，如果程序傻等，数据就永远卡在串口里发不出去。我的方案是双保险：

第一，单片机每隔10秒主动发送一条状态心跳帧，里面带着当前的正常/预警/报警状态和传感器数值。这样接收端只需要监控心跳是否超时，就能判断设备是否在线。第二，单片机每次发送状态帧前，先发一条查询指令“AT+CIPSTATUS”，根据返回值判断连接是否还活着。返回值里有“CONNECTED”字样说明正常，否则进入重连流程，重新执行AP连接和TCP建立的AT指令序列。

实测下来，从检测到掉线到重连成功，一般能控制在20秒以内，对于气体检测这种秒级变化的应用场景，这个恢复速度是够用的。

5. 舵机联动与声光报警的响应逻辑：报警不只是响一声

5.1 舵机在这里承担的机械动作

舵机的联动动作，我把它拆成两步来设计：第一步是响应逻辑，第二步才是具体的传动机构。

响应逻辑上，当系统进入报警状态时，舵机从初始角度转动到预设动作角度。如果是模拟关断燃气阀门，初始角度固定为0°，报警状态下转动到90°，表示阀门处于关闭位置。这个逻辑放在程序里就是判断状态码后更新PWM的占空比。

传动机构的细节在课设里面可以用3D打印的小零件来模拟，不必真的去接燃气管道。但要让评委和读者看懂这个舵机在干什么，最好的办法是把舵机臂连到一个带示意的阀门模型上，舵机臂旋转90度时恰好带动阀门旋钮转动。项目演示时，这个动作的直观性远胜于一个在纯空中转动的舵机臂。

5.2 用定时器模拟PWM来驱动SG90

51单片机本身没有硬件PWM输出，但用定时器模拟很容易。SG90的PWM控制信号是周期20毫秒的方波，其中高电平时间对应角度：

我用定时器0设置了一个100微秒的定时中断，20毫秒的周期等于200个中断计数，0.5毫秒等于5个计数，2.5毫秒等于25个计数。中断服务程序里维护一个计数器，在一个周期开始时把信号线拉高，计数到预设的占空比计数值时拉低，循环往复。

// 定时器0初始化：100us进入一次中断 // 20ms = 200个计数，角度占空比存于duty_cnt // 0° -> duty_cnt = 5，90° -> duty_cnt = 15，180° -> duty_cnt = 25 unsigned char pwm_cnt = 0; unsigned char duty_cnt = 15; // 默认90° void timer0_int(void) interrupt 1 { TH0 = 0xFF; // 重装初值 TL0 = 0x33; // 100us对应11.0592MHz晶振 pwm_cnt++; if(pwm_cnt >= 200) // 一个完整周期结束 { pwm_cnt = 0; P2_0 = 1; // 周期起点拉高 } if(pwm_cnt == duty_cnt) { P2_0 = 0; // 到达占空比后拉低 } }

需要注意一点，舵机和单片机共用电源时，舵机转动瞬间的大电流会拉低系统电压，可能导致单片机复位。我在这里的解决方案是分两路供电：单片机用USB的5V，舵机单独用另一路5V电源，两路电源的地线连在一起。这个“独立供电、公共地线”的做法，可以避免绝大多数负载突变引起的系统崩溃。

5.3 声光报警的驱动电路和程序组织

声光报警电路我用一个三极管驱动无源蜂鸣器，用两个LED（红灯、黄灯）配合一个绿灯表示状态。绿灯常亮表示正常；黄灯和蜂鸣器以慢节奏蜂鸣表示预警；红灯快速闪烁加持续蜂鸣表示报警。LED都得串限流电阻，蜂鸣器接在集电极回路里，单片机IO口输出高电平让三极管导通，蜂鸣器通过电流发声。

程序上我把声光报警独立成一个小状态机，主循环里只负责更新alarm_level，而LED和蜂鸣器的闪烁节奏由定时中断统一驱动。这样不会因为主循环里还有WiFi发送、ADC采集这些耗时操作而导致闪烁不均匀。闪烁节奏其实就是定时器里对某个计数器取模，比如预警是“亮200ms、灭800ms”，报警是“亮200ms、灭200ms”，区别非常直观。

5.4 三级响应策略与完整联动时序

最终联动逻辑，我归纳成了三级：

这里有一个工程细节：舵机只在状态发生变化的那一瞬执行一次动作，而不是在报警状态下反复执行。否则舵机一直在转，供电压力大不说，还会把机械结构磨损。报警后系统继续监测气体浓度，如果浓度回落到正常并持续一段时间，舵机会自动复位到“开启阀门”的角度，但WiFi上报会保留一条历史报警记录，方便事后查看。

6. 联调实测记录：常见坑、现场数据与稳定性改进

6.1 电源噪声让ADC读数乱跳，这是第一个遇到的硬骨头

第一次完整联调时，我碰到一个非常典型的故障：不接舵机，ADC读数很稳定；一接上舵机，气体浓度数值就开始在上下几十个ADC位之间乱跳，严重时甚至出现“新鲜空气里直接报警”。

定位过程花了大半天。先怀疑是传感器问题，换了模块没用；再怀疑是ADC时序问题，把时钟频率降了一半也没解决；最后用示波器量舵机运行时5V电源线上的纹波，才发现舵机一转动，电源电压就有明显的尖峰毛刺，而我的ADC基准电压正好也取自这路电源。基准电压一波动，采集结果自然跟着飘。

解决办法就是我前面提到的分路供电：舵机和蜂鸣器走独立电源，传感器、ADC、单片机走另一路，两路共地。同时在舵机电源两端并联一个1000μF电解电容吸收启动电流，再在ADC的Vref引脚附近加一个0.1μF陶瓷电容滤高频噪声。改完之后，ADC读数重新恢复到±3个位以内的波动，问题彻底消失。

6.2 ESP8266上电不启动、AT指令无应答的供电与复位问题

第二个让我折腾很久的坑是ESP8266不启动。现象是上电后串口发AT没有任何回应，用万用表量模块的VCC和GND，电压只有2.8V左右，明显不正常。

原因出在供电链路：开发板上的稳压芯片本身压差大，再加上我接了WiFi模块、传感器、几个LED，电流一多，电压直接被拉垮。ESP8266在连接WiFi的瞬间电流需求很高，稳压器输出达不到电流要求时电压就会塌陷，模块自然无法完成启动。位置换了两次之后，解决办法是给ESP8266单独配了一块低压差稳压模块，输入5V输出3.3V，峰值输出电流能吃住模块的瞬时需求。另外确认了EN引脚给高电平、GPIO0在复位时悬空（进入正常运行模式而不是刷写模式），模块启动一次成功。

这里也想多提醒一句：很多ESP8266的“间歇性故障”都是供电导致的。先修供电再查程序，能省掉一大半调试时间。

6.3 气体传感器的冷启动和温漂问题

MQ系列传感器的加热丝需要时间达到工作温度，冷启动时输出不稳定。刚开始测试时我没有预热直接读ADC值，发现数值从30一路慢慢爬高，差不多三四分钟后才稳定下来。后来把标定流程固定为“上电后预热5分钟再进入正常检测主循环”，数据才可靠。

温度漂移则是另一个长期现象。教室没开空调和开了空调两种环境下，基线值能差出十几个ADC位。虽然这个幅度还不至于突破预警阈值，但如果阈值本身定得太贴近基线，就很容易在中午气温升高时触发假预警。我的应对策略是基线动态校正：系统每隔30秒记录一次基线值，只有当当前读数比基线高出合理倍数时才进入预警判断。这样环境缓变引起的漂移就被系统自动吸收掉了。

6.4 实测数据：这套系统的真实表现

我把调整后的系统跑了一整天，记录了几个关键场景下的数据：

这套数据显示，系统在响应速度和可靠性之间取得了平衡。气体从释放到触发报警，最快一次约0.8秒，最慢也就2秒，符合校车安全检测的应用预期。

6.5 三个能显著提升稳定性的细节改动

整个联调过程中，我最后归纳出三个性价比极高的改动，强烈建议照做：

第一个是用独立的稳压电源模块给WiFi和舵机分别供电，永远不要把所有大电流外设压在一个5V稳压器上。第二个是给舵机电源两端并联大容量电解电容，启动尖峰是主要的干扰源，吸收掉它ADC的稳定性立刻上了一个台阶。第三个是主循环里不要让WiFi发送、ADC采样和舵机控制挤在一起，用定时中断给执行机构做PWM和报警节奏，主循环只管慢慢轮询传感器、更新状态和发送网络数据，层次清晰以后排查问题会轻松很多。

这些改动加起来成本不超过十几块钱，但效果立竿见影，整套系统的可靠性和演示效果跟改之前完全两回事。

最后再分享一个小技巧：如果做的是课设或毕业设计，不妨把整个标定过程和实测数据完整写进项目文档里。很多人只写了功能实现，却拿不出一份像样的测试记录，答辩时很容易被“你这个阈值为什么是这个值”“误报率是多少”这类问题问住。我在实际指导中都会要求先把标定数据和实测记录补齐，这套东西不仅能证明你的系统真正经过调试，还能让整篇文章从“能跑”变成“可信”，价值远大于一行代码。