芯耀
与非AI
245
01 前言
大家好，今年带学生参加了全国大学生电子设计竞赛，比赛一共四天三夜。现在比赛已经结束，学生们也陆续回到正常的学习生活中，但这几天的过程还是值得复盘一下。
在只有四天三夜的情况下，一支队伍到底需要具备什么能力，才能把一个临时拿到的题目，变成一个可以测试、可以演示的作品？
02 四天三夜，留给你试错的机会并不多
很多没有参加过电赛的同学，可能会觉得四天时间已经不少了。
但真正进入比赛以后，时间会过得非常快。
拿到题目之后，需要先读题，理解指标，确定方案，然后开始准备硬件、编程、焊接、机械结构和调试。中间只要有一个环节出问题，后面的进度就会一起往后推。
更麻烦的是，方案不能无限迭代。
平时做项目，如果发现思路不合适，可以推倒重来，重新画板、重新买器件，甚至换一个方向。但是电赛只有四天三夜，很多时候你刚刚发现方案存在问题，时间已经不允许你重新开始了。
所以电赛不是看谁能想出最复杂的方案，而是看谁能在有限时间里，判断出什么能做，什么不能做，哪些功能必须先完成，哪些功能可以暂时放一放。
这个判断能力，其实比单纯的技术能力更重要。
有些方案理论上非常漂亮，但是实现周期太长，最后可能连基本功能都没有完成；有些方案看起来没有那么复杂，但是每个环节都比较稳，最后反而更容易把指标做出来。
这也是我带队过程中比较强调的一点：
电赛首先是一个工程问题，然后才是一个技术问题。
03 AI编程，为什么很难成为电赛的捷径
这次比赛前后，也有同学问过我，现在不是有很多AI工具吗？能不能让AI帮忙写代码，这样是不是可以节省很多时间？
我的看法比较明确：AI可以辅助，但想靠AI完成电赛编程，现实中并没有那么简单。
首先，AI不知道你的硬件到底是什么状态。
它可以根据你的描述，给你写一段GPIO、定时器、ADC或者通信代码，但代码能不能直接运行，取决于芯片型号、寄存器配置、时钟树、引脚复用、外设连接方式以及工程本身的框架。
这些东西只要有一个地方不一致，代码就可能无法运行。
其次，电赛里最花时间的往往不是把代码写出来，而是定位代码为什么没有按照预期运行。
屏幕没有显示，可能是程序问题，也可能是供电问题、焊接问题、引脚问题、时序问题，甚至可能是硬件已经损坏。AI可以给出很多可能性，但它无法直接拿着示波器去测你的板子，也不能替你判断某个焊点到底有没有虚焊。
再往后，真正影响比赛进度的通常是软硬件之间的配合。
你需要根据实际波形修改采样方式，根据传感器的安装位置调整算法，根据机械结构的响应修改控制参数。这些工作需要不断观察、测试和判断，不是把一段代码复制进去就结束了。
所以我并不是说AI没有用。
查资料、理解陌生代码、解释函数、整理思路、协助检查一些简单逻辑，这些事情AI确实可以帮忙。
但是，想在四天三夜里临时依靠AI建立起完整的编程能力，基本是不现实的。特别是当你对芯片、外设和工程框架都不熟悉时，AI生成的代码即使看起来很专业，也不代表它适合你的实际系统。
最终还是要回到一个比较传统的能力：
你自己能不能读懂代码，能不能定位问题，能不能根据现象修改代码。
这个能力没有办法完全外包给工具。
04 编程能力，决定了你能不能把想法变成作品
电赛中，很多同学并不是没有想法，而是想法和实现之间隔着一段距离。
题目刚出来的时候，大家都能提出很多方案，甚至可以把系统框图画得很完整。但是一旦开始编程，就会发现每一个模块都需要实际落地。
传感器怎么采集？数据怎么处理？控制周期是多少？不同模块之间怎么配合？出现异常时程序应该怎么处理？
如果编程基础不够，前面想得越多，后面越容易卡住。
这里的编程能力，也不只是会不会写C语言语法。它还包括几个方面：
- 能不能快速看懂一个陌生工程；能不能根据芯片手册配置外设；能不能把一个大功能拆成几个小模块；能不能写出方便测试和修改的代码；能不能通过串口、示波器和日志判断程序运行到了哪一步。
平时如果只会调用现成库函数，遇到熟悉的开发板可能还能够完成任务。但电赛的硬件和要求每年都会变化，真正到了现场，很多东西都需要自己判断。
因此，编程能力不是比赛前临时补几天就能解决的。平时做项目时，就应该有意识地让自己离开一键配置和现成例程，多理解一下底层运行过程。
这件事可能比较慢，但确实没有太好的捷径。
05 焊接能力，往往决定了你有没有机会调程序
焊接这个事情，平时很容易被低估。
很多同学觉得，焊接只是把元器件焊到板子上，应该不算什么特别困难的能力。但到了比赛现场，焊接质量会直接影响后面的调试进度。
一个焊点虚焊，可能导致系统时好时坏；一个电源短路，可能让整块板子无法工作；一个接口方向接错，后面排查起来会非常麻烦。
更难受的是，有些焊接问题并不是一眼就能看出来的。
程序第一次运行正常，换一个角度或者碰一下线材就不正常，这时候很多人会先怀疑代码，反复修改软件，最后才发现根本原因在硬件连接上。
所以，焊接能力不只是“能焊上去”，还包括焊完之后的检查能力。
供电是否正常，电源和地有没有短路，关键引脚之间有没有连错，器件方向是否正确，接口信号是否符合预期，这些都应该形成基本习惯。
如果没有经过足够的训练，比赛时就容易出现一种情况：程序还没有开始调，硬件已经先给你制造了很多问题。
06 机械设计能力，不能等到比赛现场再补
这次涉及E题和H题，也让我再次感觉到，很多电子类学生在机械设计方面准备得不够。
大家对单片机、传感器、通信和算法比较熟悉，但当作品需要稳定运动、准确定位或者保持结构一致时，机械部分就会直接影响最终效果。
机械结构不是外观问题。
结构是否牢固，零件是否容易加工，传感器安装位置是否合理，重心是否合适，运动过程中有没有干涉，这些都会影响程序调试。
如果机械结构一直变化，软件参数就很难稳定下来。今天调好的参数，明天换了一个安装位置，可能就全部失效。
特别是控制类题目，机械系统的响应特性和软件控制参数是连在一起的。结构有间隙、摩擦力变化、重心不合适，都会反映到控制效果上。
因此，机械设计能力并不是机械专业学生才需要掌握的东西。对于参加电赛的队伍来说，至少应该具备基本的结构设计、尺寸测量、加工装配和快速修改能力。
如果比赛前从来没有做过实物结构，到了现场再临时设计，时间压力会非常大。
07 赛后复盘，不能只看最后有没有完成
比赛结束以后，大家最容易关注的是结果。
但对于带队老师来说，我觉得还应该再往前看一步：这个作品是怎么完成的？哪些能力真正发挥了作用？哪些问题如果不解决，下一次还会继续出现？
比如方案迭代次数为什么比较少，是因为判断准确，还是因为前期准备不足，没有时间重新来？
程序没有完全按照预期运行，是编程能力问题，还是调试方法问题？
焊接出现问题，是操作不熟练，还是赛前没有形成检查流程？
机械结构调试困难，是设计本身复杂，还是平时没有做过类似的实物？
这些问题比“最后完成了多少功能”更值得记录下来。
因为结果只属于这一次比赛，但过程中的问题，很可能会出现在下一次比赛里。
我比较建议学生在赛后把整个过程重新梳理一遍，不一定要写成很正式的总结，哪怕只是把关键节点、遇到的问题和最后的解决方法记录下来，也会有帮助。
尤其是那些当时花了很长时间才解决的问题，过一段时间以后很容易忘记。如果不记录，下次遇到类似情况，可能还要重新走一遍弯路。
08 下一次备赛，应该提前准备什么
如果下一次还要参加电赛，我认为准备工作不能只放在比赛前几周。
首先，应该提前训练完整的开发流程，而不是只练某一个单独模块。拿到一个简单任务后，从读题、确定方案、准备硬件、编程、焊接到调试，尽量完整地走一遍。
其次，要有意识地训练在不确定条件下解决问题的能力。比赛现场不可能所有器件、资料和环境都完全熟悉，遇到陌生芯片或者新的外设时，能不能快速找到手册、理解关键部分并完成验证，这很重要。
然后是机械和焊接。
这两部分不应该等到确定题目之后才开始接触。平时做一些小型的结构设计、简单加工和电路焊接，哪怕项目并不复杂，也是在为比赛积累经验。
最后，队伍成员之间的分工需要提前磨合。
一个队伍里不一定每个人都要什么都会，但至少要知道谁更擅长硬件，谁更擅长编程，谁更擅长机械和调试。比赛过程中遇到问题时，能够快速判断应该由谁来处理，而不是所有人一起围着同一个问题反复讨论。
这也是为什么我认为，电赛准备的重点不只是学习更多知识，而是尽量多做完整项目。
09 最后
这次带学生参加电赛，对我来说最大的感受还是：四天三夜确实很短，很多事情没有办法做到完美。
方案不能反复试太多次，代码不可能临时全部补齐，焊接和机械结构也不可能在比赛现场突然变得非常熟练。
但比赛的意义，也不在于每一个细节都完美。
它更像是在有限时间里，让大家真实地经历一次工程项目。从题目要求开始，到最后把作品做出来，中间会遇到很多平时在课堂上不容易遇到的问题。
AI工具以后肯定还会继续发展，也会在资料查找、代码理解和开发辅助方面发挥更大的作用。但对于电赛这种需要软硬件结合、现场调试和快速判断的比赛来说，学生自身的编程、焊接和机械设计能力，仍然是基础。
这些能力可能不够新，也不够“智能”，但在真正需要把作品做出来的时候，还是非常实际。
以上仅仅是我一些个人感受，具体情况也会因队伍、题目和准备程度不同而有所差异。如果大家在备赛过程中还有其他问题，也欢迎一起交流。
