1. 竞赛调试的心法：先想明白再动手
1.1 调试不是改代码，是收集信息
在技术竞赛现场，我见过太多队伍把大把时间浪费在“瞎试”上。现象一出现，第一反应就是打开代码开始改，改一次编译一次烧录一次，现象不变就再改。这种行为模式在竞赛里基本是致命的，因为比赛时间有限，越急越乱，最后整个下午都搭进去，问题还没定位到。
我自己在带竞赛队伍时，反复给队员们强调一句话：调试的本质是收集信息，不是修改代码。你得先搞清楚系统当前到底处于什么状态、哪个模块的行为和预期不符、数据是在哪一步开始变错的，然后再动手。这个顺序一旦反过来，调试就变成了碰运气。
具体来说，一次完整的调试循环应该是这样的：复现现象、观察输出、提出假设、设计验证方案、验证假设、定位根因、修复验证。每一步之间都有明确的产出物，比如“我从串口日志里看到了X值异常，我猜是传感器初始化顺序问题，所以我加了一行打印来验证”。有了这套流程，调试就不是东一榔头西一棒槌，而是一条清晰的主线。
还有个容易被忽略的点：问题复现的稳定度。竞赛环境里很多BUG是间歇性的，或者只在特定条件下出现。遇到这种问题，第一件事不是分析代码，而是把复现条件记录下来——什么操作序列、什么数据包、什么温度环境下出现的。如果连稳定的复现手段都没有，后面的所有分析都是空中楼阁。我会要求队员准备一个“复现记录本”，专门记这些条件，这个习惯在长时间比赛中尤其管用。
1.2 二分定位法：快速缩小故障范围
面对一个大型系统里的BUG，最忌讳的就是从头到尾逐行看代码。我常用的套路是二分定位法，核心思想特别简单：把系统按数据处理链路切成两半，先判断故障在前半段还是后半段，然后继续对有问题的那一半再切一刀，直到定位到具体模块。
举个例子。之前带学生做CAN总线通信的项目，现象是上位机收不到设备回复。我没有让他们先翻通信协议栈代码，而是让他们分三步排查：第一步，在设备端确认CAN控制器是否进入发送状态；第二步，在总线上用示波器或CAN分析仪看有没有报文波形；第三步，在上位机软件里确认接收缓冲区有没有数据。实际测试发现第二步完全没波形，问题直接锁定在设备端发送链路，范围从“整个通信系统”缩小到“发送方向”。再往下一步步定位，最后发现是发送邮箱配置错误，中断标志位没清干净。
这个方法对软件问题同样适用。程序崩溃了，先用print或调试器确定崩溃发生在哪个函数，然后看是输入数据问题还是逻辑分支问题，再用更细的日志确认具体是哪个变量引发了异常。每次排查都让范围缩小一半，最多七八步就能把问题锁死在几十行代码之内。
二分法的前提是你对系统架构有整体认知。所以竞赛准备阶段，我会让每个队员把自己负责模块的数据流图画一遍——输入是什么、输出是什么、依赖哪些外部资源、通过什么接口和上下游交互。这张图平时看起来没用，真出问题的时候它就是你的排查地图。
1.3 一次只改一个变量的纪律
”一次只改一个变量“，这句话听起来像废话，但竞赛现场真正能做到的队伍少之又少。原因很简单：紧张。怕改不完，怕时间不够，所以总想着“顺便把另一个隐患也修了”“反正这行代码我也觉得不太对，一起改掉吧”。结果就是，问题确实没了，但你不确定是哪个改动起了作用；或者问题更严重了，但你根本不知道是哪个改动引入了新问题。
我见过最典型的一次翻车：嵌入式小车比赛，电机转速不稳定，队员先调整了PID参数，又改了PWM输出引脚的复用配置，还换了一个定时器的分频值，三个改动一次性烧录进去。结果小车直接不转了。三个人围着板子查了两个小时，最后只能逐个还原改动，才定位到是引脚复用配置和电机驱动库冲突。如果当初只改PID参数，即使没解决，至少能确认PID方向是否正确，后面的排查会快得多。
在多人协作的竞赛环境里，“一次只改一个变量”还要求团队有严格的改动记录机制。我习惯让队伍用版本管理工具，每次改动提交时写好说明，保证任何时间点都能回退到上一个稳定版本。现场调试时，物理上隔离改动：一个人调硬件，另一个人改软件，不要两个人在同一块板子上同时动手。等一个人验证完，另一个人再开始。
2. 日志体系：调试信息的采集与组织
2.1 日志分级的正确姿势
很多初学者写日志，只有一种方式：觉得哪里不对就加一行printf，内容随意到什么程度呢？“here1”“here2”“test123”。这种日志在竞赛调试里基本等于没有，因为一旦程序复杂起来，你根本不知道这条信息是在哪个模块、哪个状态下打印的，串口一刷屏，整个人都是懵的。
竞赛级的日志体系，至少要分四个级别：错误（ERROR）、警告（WARN）、信息（INFO）、调试（DEBUG）。ERROR只记录会导致功能失败的事件，比如传感器初始化失败、内存分配返回空指针；WARN记录异常但不影响主流程的情况，比如数据校验和错误后重传；INFO记录关键流程节点，比如任务启动、通信握手成功、状态机切换；DEBUG记录详细数据，比如每个采样周期的原始值、每次协议的收发帧内容。
级别划分不是为了让代码显得专业，而是为了在调试时能快速过滤信息。竞赛现场串口带宽有限，全量日志一秒钟就能刷几千行，真正有用的信息反而被淹没了。我的做法是：平时跑系统只开INFO级别，需要排查某个模块时再临时打开这个模块的DEBUG输出，其他模块保持原样。这样日志量可控，重点信息也足够突出。
实现上，我习惯用一个简单的日志宏封装，让每条日志自动带上时间戳、模块名、函数名和行号。格式类似[12:34:56.789][MOTOR][ERROR] motor init failed, err=3。这样即使日志刷屏，也能一眼看出问题出在哪个模块、什么时间点。时间戳尤其重要，后续做多模块关联分析时，它是唯一的对齐依据。
2.2 串口日志的坑与输出方式
嵌入式竞赛里，串口是使用频率最高的调试输出通道，没有之一。大部分MCU开发板默认都支持串口打印，接一个USB转TTL模块就能在电脑上看到日志。但串口调试有几个非常典型的坑，我在竞赛现场见过无数次。
第一个坑是printf重定向不完整。很多工程模板里printf能用，但底层没有真正实现重定向到串口，或者重定向了但初始化顺序不对，导致程序启动早期（比如时钟配置阶段）的日志丢失。解决办法是确认你的printf最终调用了哪个底层发送函数，是fputc还是_write，确保它在所有需要打印的模块之前就已经初始化完成。如果日志在启动早期就丢失，你会在后面排查时完全摸不着头脑，因为问题恰恰可能就出在早期初始化。
第二个坑是串口发送阻塞。早期的串口打印通常是阻塞式——每次发送一个字节都要等待发送完成标志，波特率9600时一个字节就要约1毫秒，如果你在中断里打印或者在高频循环里打印，整个系统实时性都会完蛋。我在PID控制环路里见过有人每毫秒打印一串调试信息，结果控制周期被拉长了十倍。正确的做法是：低频打印，或者用DMA方式发送，把要打印的内容丢给DMA后程序继续往下跑，CPU不用等。
第三个坑是缓冲区溢出。如果日志通过中断发送，发送缓冲区开得太小，日志量大时新数据会直接丢。你会看到几百条连续的日志中间突然断掉一段，后面的内容和前面对不上。排查间歇性问题时，这种丢日志造成的假象特别容易误导人。我建议把串口发送缓冲区至少开到1KB以上，同时加上丢帧计数，这样日志断掉时至少能知道丢了数据，而不是以为系统真的卡死了。
2.3 日志记录与回放：竞赛里的“复盘神器”
竞赛调试和平时做项目有一个最大的区别：现场时间压力大，错过了就真的错过了。平时你在工位上可以慢慢复现问题，竞赛里可能一个复现窗口就只有几分钟，下次触发条件可能再也凑不齐。所以我特别强调日志的记录和回放能力。
具体做法很简单：给系统做一个“日志记录模式”，把串口输出同时写到调试终端和SD卡（或者通过模块转发到上位机文件）。如果条件允许，直接用带日志保存功能的调试软件，很多串口助手都支持记录原始数据。跑完一次完整流程后，把日志文件留档，后续可以反复看、慢慢分析，不用一边跑现场一边记笔记。
多模块系统的日志关联分析特别依赖记录与回放。举个例子，之前做飞控竞赛，现象是飞行中偶发姿态解算异常。单看飞控串口日志，只看到某个时刻解算输出跳变，但找不到原因。后来把传感器原始数据、遥控指令、电机PWM输出等所有模块的日志都加上统一时间戳，存在一起。回放时把几条日志按时间轴对齐，发现异常总是发生在遥控器发送特定指令之后约20毫秒，问题一下子定位到了指令解析模块的缓冲区处理逻辑。
我在竞赛前会做一个很基础但极有用的准备工作：提前写好日志回放脚本。不需要多高级，用Python写个程序，读取日志文件，按时间戳过滤、排序、画波形图，分析起来效率高得多。很多看起来无解的偶发问题，用这种方法回放两三遍就能找到规律。
3. 工具链实操：调试装备的调度艺术
3.1 GDB：命令行调试的基本功
不管做什么方向的竞赛，只要涉及代码，GDB这套命令行调试思路你迟早要掌握。图形化IDE的调试器虽然好用，但在比赛现场会遇到各种状况——IDE卡死、远程没有图形界面、目标板只能通过命令行访问，这时候GDB就是你唯一能依赖的调试工具。我常说，会GDB的队员在竞赛里多一条命。
GDB的核心操作其实没几个：break（打断点）、run（运行）、next（单步跳过）、step（单步进入）、print（查看变量）、backtrace（查看调用栈）、continue（继续运行）。用的时候记住一个原则：优先用backtrace和print，不要死磕单步。单步执行速度慢，而且容易把你带进无关的库函数细节里。程序崩溃时第一件事永远是backtrace，看调用栈就知道崩在哪个函数、由哪条调用链进来的。
实际竞赛中还有一个高频操作：条件断点。比如你怀疑某个循环在特定数据值时出错，但正常断点会频繁触发，你根本来不及看。这时用条件断点，格式是break 行号 if 变量==特定值，只有满足条件时才停下。这种操作在GDB里一条命令就能搞定，但在图形化IDE里配置反而麻烦。另一个有用的技巧是watch，监视某个变量，一旦值改变就暂停，用来排查变量被不明修改的“幽灵问题”非常有效。
命令行调试还有个硬核优势：可以写脚本。提前把常用调试命令写进.gdbinit文件里，或者用GDB的脚本语言做自动化，批量执行断点设置、变量打印、日志采集。竞赛现场时间宝贵，按一下脚本就自动配好环境，绝对是效率利器。
3.2 串口调试助手的正确用法
串口调试助手是嵌入式竞赛里人手一个的软件，SSCOM、友善串口调试助手这些大家都熟。但坦白讲，大部分人对串口助手的理解停留在“打开串口→收发数据”的层面，很多高级功能没用到，反而用得不对还踩坑。
第一个要说的坑是波特率。看起来是最基本的参数，但竞赛现场经常因为波特率不匹配导致日志全是乱码。设备端实际波特率要查代码确认，不能想当然认为“默认115200”。遇到乱码时，第一反应应该是用几个常见波特率（9600、19200、38400、57600、115200）逐个试，同时也检查一下串口助手的“DTR/RTS”标志位设置，有些开发板的自动下载电路会在这两个引脚上做手脚，导致数据受影响。
第二个要说的功能是HEX模式与文本模式的切换。大部分嵌入式协议都是二进制帧格式，文本模式根本看不出来结构，你需要切换到HEX模式，按字节查看收发的数据。用HEX模式调试的典型场景是排查串口接收中断里缓冲区数据是否完整：直接把收到的原始字节贴出来对比协议帧定义，比看变量抽象值直观得多。
第三个说的是定时发送和自动回复。调试下位机时，经常需要周期性发送一个指令来观察响应，比如传感器数据采集指令。串口助手的定时发送功能可以直接设置间隔，自动循环发；下位机收到后返回的数据还能配自动保存，方便后续分析。有些成熟竞赛队伍还会用脚本化的网络调试工具做上位机模拟，先在下位机还没写完上位机的时候，用工具模拟协议交互，验证下位机行为是否正确。
第四个经验是关于显示与日志记录的配合。现场调试时，串口日志刷新极快，肉眼根本来不及看。我建议开启串口助手的“保存到文件”功能，一边实时看，一边存文件，之后用脚本做关键词过滤和统计。比如搜索“ERROR”出现的次数和时间点，定位异常分布规律，比人肉盯屏靠谱得多。
3.3 网络调试与协议分析
现在很多竞赛项目涉及网络通信，比如物联网赛项、上位机与下位机的TCP/UDP通信、分布式节点通信。这类项目调试，网络调试助手是必须掌握的武器。但要真正高效，我建议把“回环测试”和“协议分析”两个思路贯穿始终。
回环测试的做法是：先抛开对方的设备，用网络调试助手模拟对端的行为，验证本端逻辑是否正确。比如你在做上位机，下位机还没完成。上位机发送的指令预期会收到特定回复，那你就可以用网络调试助手启动一个本地监听端口，收到数据后手动填一个模拟响应发回去。这样上位机的协议解析逻辑可以先被完整验证，等真硬件接入时，联调问题只剩下时序和细节。
协议分析层面，我的建议是：不管用什么工具，一定要能看原始报文。看清TCP/UDP包的十六进制内容、源目端口、时间戳，很多看似诡异的问题其实都是协议字段对不上。有一年比赛，两个模块之间用自定义UDP协议通信，总是偶发丢包。用网络调试助手抓了完整报文后，发现是发送端在特定场景下会发送一个超长包，超过了对端接收缓冲区的上限，数据被截断后协议解析出错。这类问题如果只看应用层日志，可能永远找不到根因。
对于CAN总线这类现场总线，CANoe是行业标准工具，功能非常强大。竞赛中未必有完整版，但核心的报文中断断点、信号追踪、日志记录功能一定要会用。遇到CAN通信问题，第一件事就是用CANoe（或类似的CAN分析仪）记录总线上的所有报文，按时间回放。哪条报文没发出去、哪条报文内容不对、仲裁失败发生在什么时候，一目了然。
3.4 可视化调试：从PID调参到逻辑分析
嵌入式控制类比赛的调试，只靠printf打印数值效率太低了。你想观察电机转速曲线、PID输出波形、传感器数据变化趋势，打印一堆数字根本看不出动态特性。可视化工具的价值这时候就体现出来了。
我常用的方案是VOFA+这个上位机，它支持把串口数据直接绘制成实时波形，协议简单，方式灵活。用法是：下位机按固定格式把数据通过串口发出来，例如ch0:100,ch1:200,ch2:300，上位机就能把三个通道的曲线画出来。调PID的时候，把目标值、当前值、输出值三个通道一起发上来，整条控制曲线动态呈现，超调量、调节时间、稳态误差一眼就能看清。很多队伍PID调到天荒地老还调不好，就是因为只看打印的数值，根本看不到曲线趋势。有了波形图，调参效率能提升十倍。
对于更底层的调试，逻辑分析仪是排查时序问题的利器。我之前带学生做FPGA相关的题目，有次链路一直无法同步，排除了无数软件配置问题后，最后用逻辑分析仪去抓引脚波形，发现一个信号的上电时序和芯片手册要求差了那么几百微秒。这种问题，你根本没法靠打日志发现，必须看物理信号。逻辑分析仪的典型应用场景包括：SPI/I2C/UART总线的数据抓取和协议解析、多路信号间的时序关系验证、外部中断触发是否正常。
还有一个高频坑值得单独提一下：调试软件里“找不到信号”的问题。竞赛里用逻辑分析仪或调试器找信号时，经常列表里空空的，什么都搜不到。排查这个，优先确认三件事：一是信号名称是否正确（有些工具要求精确匹配网络名）；二是引脚分配是否真的编译生效，改完引脚后要重新综合、布局布线；三是探针连接是否可靠，差分信号要按对应方式连接。这三个都排除了还是找不到，再考虑是不是工具版本对器件支持不完整，换一个版本试试。
4. 场景化复盘：从硬件链路到软件死锁
4.1 经典故障：串口为何收不到数据
串口收不到数据，这是嵌入式竞赛里出现频率最高的BUG之一，几乎每场比赛都能见到队伍在这上面卡上几个小时。我把这类问题做过一个梳理，按出现概率排序，基本就是几个原因：硬件连接问题、引脚复用配置错误、波特率不匹配、中断未开启或优先级配置问题、代码逻辑问题。
硬件连接问题看起来很基础，但竞赛现场环境乱，杜邦线松动、接触不良都是常事。我遇到过折腾半天，最后发现是USB转TTL模块的地线没和设备共地。串口通信的参考电压是相对的，不共地时逻辑电平参考点不一致，数据就是乱码或者完全收不到。排查时先量一下电压、确认接线，比查代码快得多。
引脚复用配置是另一个高频雷区。很多MCU的某个引脚默认不是UART功能，需要在初始化代码里显式配置为复用功能。看起来不起眼，但配置错了或者漏了，数据就永远进不来。我建议排查顺序是：先确认初始化代码里引脚复用配置和串口外设初始化都执行了，再确认代码里接收中断确实开启，最后用调试器查看外设寄存器里有没有数据到达标志。
中断相关问题也经常引起“收不到数据”的假象。比如串口接收中断优先级设置得太低，被其他高频中断抢占，数据来了但没来得及处理，接收寄存器被新数据覆盖。此时的现象是偶发丢失，不是完全收不到。排查方法是在接收中断里加一个计数，对比实际收到的数据量和预期数量，判断是不是中断处理不及时导致的丢包。
4.2 芯片连接失败：复位时序与连接技巧
比赛现场另一个高频问题，是调试器和目标芯片连不上，在调试软件里点击“连接”按钮一直失败。这类问题出现最多的场景，是芯片内部程序锁死了调试接口，或者上电时序让芯片进入了异常状态。
我常用的处理办法，就是热词里提到的那句“先按住芯片复位键，在调试软件里点连接。连接成功后松开复位键，然后擦除”。这个操作的本质是：让芯片在上电或复位后的极早期阶段被调试器接管，在用户程序还没跑起来（或者说还没来得及把调试接口锁死）之前，先把连接建立起来。一旦连接成功，立刻擦除Flash里的程序，芯片就回到可调试状态了。
这个技巧在STM32、GD32这类Cortex-M系列芯片上配合ST-Link/J-Link使用时非常有效。具体操作是：打开调试软件选择好目标芯片型号，按住板子上的复位键不放，点击连接，软件开始尝试同步芯片时，松开复位键。时机要稍微配合一下：先按复位，再点连接，然后保持一小段时间后松开复位。多试几次就能找到节奏。连接成功后第一件事就是擦除，防止下次上电又被锁。
另外，有些情况连接失败是因为调试器固件版本太旧、不支持当前芯片型号。这类问题的处理方式就是升级调试器固件、更新调试软件版本。在比赛前，队伍应该提前把工具链全部装好、连通，到一个新环境后优先检查驱动识别是否正常。现场才开始装驱动和找版本兼容问题，时间成本太高了。
4.3 死锁与软锁死：系统“卡住”的真正原因
Linux/嵌入式Linux平台上，有个让人头疼的报错长这样：kernel: watchdog: bug: soft lockup - cpu#2 stuck for 23s! [kworker/u32:3:2196]。很多同学第一次看到这个信息直接懵了，以为是系统崩溃了。实际上，soft lockup的意思是：某个CPU核心在一个上下文里长时间没有调度切换，导致内核看门狗判断系统卡死。
出现soft lockup，最常见的原因是某个中断处理函数或者内核线程里出现了无限循环，或者持锁时间过长。比如设备驱动的中断处理里有耗时的等待、自旋锁被长时间占用、硬件状态寄存器一直不满足预期导致循环等待。排查手段主要是：用内核日志确认卡死时正在执行的函数，用/proc/下的接口查看各任务状态，必要时用perf等工具获取调用栈。
在竞赛场景里，如果是自己写的驱动程序出现soft lockup，大概率是硬件交互时序处理得不对。比如等一个硬件状态位变成某个值，但硬件本身初始化失败了，状态位永远不会变，于是代码一直循环等下去。解决办法是给循环等待加超时，超过时间就返回错误，而不是死等。我在框架代码里一贯强调：所有while等待硬件状态的循环，必须搭配超时计数。
4.4 编码与格式：看不见的字符杀手
排查“乱码”和“解析失败”这类问题时，编码问题是最容易被忽略的隐形杀手。竞赛作品跨平台协作时，Windows、Linux、macOS对文本文件的默认编码不一样，中文内容在某个环境下存成GBK，另一个环境下用UTF-8打开，就出现乱码。之前在Visual Studio Code里调试Python脚本，控制台输出乱码，排查了半天，最后是控制台编码和源文件编码不匹配导致的。
遇到乱码问题，处理思路是：先确认源文件的编码格式，再确认控制台/终端当前的编码设置，然后统一成UTF-8。具体操作上，在VS Code里可以通过右下角的编码按钮查看和切换文件编码；控制台方面，Windows环境可以用chcp 65001把代码页切换到UTF-8。Python代码里可以在脚本开头设置标准输出的编码，sys.stdout.reconfigure(encoding='utf-8')。
还有一类格式问题来自协议解析时的字段对齐。比如用结构体指针直接强转字节数组，不同编译器的结构体内存对齐规则不一样，字段偏移就不一致，解析出来全是错的。这种问题最典型的表现是：同一个数据包，在一个开发环境里解析正常，换了开发板或者换了编译器，突然就乱套了。解决办法是不要依赖编译器对齐规则，手动用字节偏移来解析，或者显式使用#pragma pack(1)禁用对齐。
4.5 第三方库和系统自身的问题
竞赛中遇到的问题，有一部分其实不是你的代码问题，而是第三方库或系统自身的BUG。比如热词里提到的npm optional dependencies相关的报错cannot find native binding，这类问题在软件类竞赛中非常常见。遇到第三方依赖出错，我的原则是：先确认问题能否通过升级或降级依赖版本来解决，不要急着修改库本身。因为依赖是共享的，旁边队友的代码也依赖它，你乱改只会让情况更糟。
操作上，排查npm依赖问题可以试试清理缓存、重新安装依赖、删除node_modules和lock文件后重新安装。如果还不行，去开源社区或搜索引擎找已知问题记录。在竞赛时间有限的情况下，如果第三方库的BUG绕不过去，果断切换到备选库或自己实现替代功能，不要硬刚。竞赛考察的是你解决问题的能力，不是你修复开源软件的能力。
还有一类系统级问题，比如热词里出现的mscorlib recursive resource lookup bug，这类运行时错误往往和资源文件缺失或版本不匹配相关。处理方式通常是检查资源文件是否部署完整、运行时环境版本是否匹配、是否有配置文件隔离异常。这类问题对新手很不友好，因为报错信息完全看不懂。我的建议是：遇到看不懂的底层报错，先搜，再分析调用栈，最后才是怀疑自己的代码。搜索时带上完整报错语句，通常能找到前人总结的解决方案。
5. 竞赛中BUG的应急流程与团队协作
5.1 时间有限时，如何决定修还是不修
竞赛和平时开发最大的不同在于：时间窗口是确定的，而且非常短。所以面对一个BUG，第一反应不应该是“马上开始修”，而是“评估这个问题值不值得修”。这个思路，很多参赛队完全没有。
我一般把BUG按影响范围和修复成本分成四类。第一类是必现且影响核心功能的，比如主控通信断开、显示全黑，这种必须立刻投入全部精力。第二类是必现但影响次要功能的，比如某个指示灯状态不对，可以考虑先绕过，把资源留给核心问题。第三类是间歇性出现且难以复现的，这类问题最费时间，如果是比赛后半段，尽量不要深入，先记录现象和后现场条件，保证主线功能优先。第四类是修复成本很高但影响很小的，比如某个边缘功能在特殊输入下会闪退，直接禁用该功能都比调试划算。
做出判断之后，还有一个“绕过方案”技能需要掌握。同功能的实现路径往往不止一条，比如I2C通信不稳定，可以在重试机制上下工夫，也可以换个通信速率，还可以切换到软件模拟I2C。有些时候绕过方案比修复根因快得多，而竞赛最终看的是整体功能表现，不是代码完美度。我带的队伍里，我明确说过：比赛是拿分，不是做科研，能用简单路径实现的绝不过度工程化。
5.2 Bug修复赛题：从读题到提交的标准化流程
近些年不少赛事直接出了“BUG修复赛题”，比如操作系统类赛题、应用开发类赛题，会在代码库里故意埋漏洞，让参赛者修复。这类赛题看似简单，其实是拿分关键，因为读题方式和普通功能开发完全不同。
拿到赛题后，第一步是通读题目描述，列出所有要求修复的问题点。第二步是建立可编译、可运行的基线环境，确保在修改之前，工程能正常构建和运行。这一点很重要，如果动手前连基线都跑不起来，后面很难判断是修改导致的还是环境本来就有问题。第三步是针对每个问题点定位代码位置，先理解代码意图，再对照题目要求看哪里不一致。
修复过程中的关键，是保持修改最小化。只改动和问题直接相关的代码，不要顺手做“代码优化”。因为比赛评判用的是隐藏用例，优化时很容易引入新的行为变化，导致用例失败。另外，修完一个点后要立即跑相关测试用例，确认通过后再修下一个，不要攒着一起验证。如果中途发现问题越来越多，大概率是理解错了题意，回去重新读题，而不是继续硬改。
提交前，最后做一遍全量回归：把所有已有测试用例都跑一遍，确认没有引入新问题。同时检查代码风格和必要的头文件、依赖关系，有些评分体系对编译警告也扣分。这个标准化流程看着繁琐，但正是这些细节，决定了你在这类赛题里能不能稳定拿分。
5.3 团队协作中的调试分工
多人一起调试同一个BUG时，最怕的是所有人围着同一块屏幕出主意，七嘴八舌，效率极低。我建议的协作方式很明确：指定一个“主调试人”，负责观察现象、提出假设、指导验证；其他队员负责在旁边提供资源支持——查手册、看代码、准备测试数据，但不要直接上手改。一个人改，一个人查，相互之间通过语言交流，而不是通过“抢键盘”。
另一个常见问题是修改冲突。两个人同时改同一个模块的不同部分，编译时各种错误，合并时各种冲突。竞赛时间这么宝贵，绝不能在合并代码上浪费。解决办法是提前约定模块所有权：每个队员负责不同的模块，接口通过约定好的数据结构交互，不要随意改动别人的文件。如果确实需要改动接口，先在白板上画出调用关系，说清楚再动手。
还要建立“问题同步白板”。把当前遇到的问题、已经尝试的方案、尝试结果、下一步计划写在随时可见的地方（白板、共享文档都可以）。这个习惯对长时间竞赛尤其重要，因为人的短期记忆在高压下很容易断片，前一小时试过什么可能转头就忘。白板上的记录能让你在迷茫时快速回到主线，不至于反复做无用功。
5.4 AI辅助调试的正确用法
AI辅助调试现在越来越普及，但很多人用不好。热词里有一条特别形象：“AI修改一个小bug用时很久，一直在分析，怎么精简。”这个体验我太熟了。AI工具并不是改不了这个BUG，而是因为你给它的上下文不够精准，它只能在宽泛的范围里反复猜测。
要让AI辅助调试发挥效率，我给三条建议。第一，提供最小复现信息：把问题现象、相关代码片段、日志中关键输出、已经排除的方向一次性告诉它，而不是只丢一句“这个程序报错了”。第二，给AI设定角色和范围：比如“你是嵌入式调试专家，请分析这段UART初始化代码和中断处理逻辑，找出可能导致接收丢失的原因”。把范围圈小，AI的答案才更有针对性。第三，把AI当结对编程的队友，而不是文档生成器：让它解释某段代码的行为、生成测试用例、帮你对比几种方案的优劣，而不是直接贴一个完整文件让你覆盖。
我自己经验里，AI在调试中最大的价值，是帮你快速排除“已知的未知”——常见框架用法、API参数含义、某类报错的通用原因。它不擅长的是需要结合硬件时序、现场环境、历史改动记录的综合分析。所以我的用法是：快速用AI确认基础问题排除掉的备选项，再自己花精力做需要深入理解和实验的部分。按照这个思路，AI辅助调试的效率会非常明显。
在竞赛最后一个小时，时间极紧张，AI还能帮你做代码审查。把每个模块的关键代码贴给AI，让它找边界条件、未初始化变量、数组越界这些容易踩的坑，经常会发现人眼漏掉的问题。这类问题往往就是赛题里的送分陷阱，用AI跑一遍代码体检，性价比极高。
最后再分享一个我自己踩过多次坑后总结出来的习惯：每次比赛结束，无论成绩如何，我都会把整个调试过程中遇到的每个问题和最终原因整理成一份“BUG单”。第一行写现象，第二行写根因，第三行写排查手段，第四行写为什么一开始没发现。技术竞赛的调试能力，本质上就是见过多少种类型的坑、能多快从环境噪音里锁定根因。这份“BUG单”就是下一个项目最宝贵的起点。
