1. 从三个人的分工说起电赛小组的组队逻辑电子设计竞赛这件事单打独斗基本走不远。四天三夜的赛程从方案论证、硬件搭建、软件调试到报告撰写工作量摆在那里一个人扛下来几乎不可能。刁政宇、朱铭昱、叶申源这个三人组从组队之初就面临一个很现实的问题三个人怎么分工才不至于互相拖后腿。我见过太多队伍在赛前一周还在纠结谁负责什么结果比赛一开始就乱套。这个组的做法值得参考——他们在赛前两个月就把角色定死了硬件主攻、软件主攻、系统整合与文档。听起来简单但真正执行到位需要每个人对自己的边界有清醒认知。1.1 硬件主攻的职责边界硬件主攻不是简单地画板子、焊元件。在电赛的语境下这个角色要负责的是器件选型、原理图设计、PCB布局布线、焊接调试、以及和软件主攻对接接口定义。刁政宇在这个组里承担的就是这个角色。关键点在于硬件主攻必须在赛题公布后的前两个小时内完成核心器件的选型决策。为什么是两小时因为电赛的器件清单是有限的很多队伍会同时抢同一款芯片。如果你拖到下午才去领器件很可能已经被别的组拿光了。这个组的一个经验是赛前就把可能用到的器件列一个优先级清单按照往年赛题的类型把必用可能用备选三档分好赛题一公布直接按清单去领不犹豫。注意器件选型不要追求最新最强而要追求最熟最稳。你在赛前用过的芯片哪怕性能不是最优也比临时上手的新片子靠谱得多。1.2 软件主攻的核心任务朱铭昱负责软件部分。电赛的软件工作量和硬件不相上下尤其是控制类题目PID调参、传感器融合、通信协议实现每一项都够喝一壶的。软件主攻最容易犯的错误是等硬件搭好再写代码。这个组的做法是硬件还在焊接的时候软件已经在开发板上跑通了核心逻辑。比如需要驱动某个传感器先用开发板单独调通等硬件板子回来直接移植省掉大量联调时间。这里有个实操细节软件主攻要提前准备好一套模块化的代码框架把常用的外设驱动GPIO、定时器、串口、I2C、SPI、ADC封装成独立函数比赛时直接调用。这个组在赛前就维护了一个自己的代码库每个模块都经过至少两次比赛的验证拿来就能用。1.3 系统整合与文档的角色定位叶申源承担的是系统整合和文档撰写。这个角色最容易被低估很多人觉得文档就是最后写写报告实际上系统整合的工作贯穿全程。系统整合要做的包括协调硬件和软件的接口定义、管理版本、在联调阶段快速定位问题出在硬件还是软件、以及最终的指标测试和报告撰写。这个角色需要同时对硬件和软件有基本理解不然联调时连问题都描述不清楚。这个组的一个好习惯是每天结束前开一个15分钟的短会三个人同步进度、确认第二天的任务、把当天遇到的问题记录下来。这个记录后来直接成了报告素材省了大量回忆和整理的时间。2. 四天三夜的时间线每个阶段该干什么电赛的时间管理是决定成败的隐形因素。很多队伍不是技术不行而是时间分配出了问题——前两天慢悠悠最后一天通宵赶工结果报告写得一塌糊涂测试指标也没调到位。这个组的时间线安排我梳理下来觉得比较合理值得拆开讲。2.1 第一天方案锁定与器件领取第一天上午赛题公布后前两个小时用来读题和讨论方案。这里的关键是不要过早陷入细节。很多队伍一看到题目就开始争论某个电路怎么设计结果三个小时过去了还没确定整体方案。这个组的做法是先用30分钟各自读题、独立思考然后花45分钟集中讨论列出两到三个可行方案对比优劣选定一个。选定之后就不再回头除非遇到根本性的技术障碍。下午的时间主要用于领取器件和搭建最小系统。最小系统指的是能让主控芯片跑起来的最简电路——电源、晶振、复位、下载接口。这个东西必须在第一天搞定不然后面所有工作都无法开展。提示第一天晚上一定要让最小系统跑通一个最简单的程序比如点灯确认整个工具链没有问题。我见过太多队伍第二天才发现下载器驱动没装好白白浪费半天。2.2 第二天硬件搭建与软件框架第二天是工作量最大的一天。硬件方面要完成核心电路的焊接和初步调试软件方面要完成主要功能模块的编写和单元测试。这个组在这一天的分工是硬件主攻集中精力焊板子和调试模拟电路部分软件主攻在开发板上验证数字部分和算法系统整合角色负责搭建测试环境、准备测试仪器、同时开始整理报告框架。这里有个经验硬件调试要分模块进行不要一次性焊完再上电。电源部分先焊、先测确认电压正常再焊主控主控跑通再焊外设。这样出问题的时候排查范围小定位快。2.3 第三天联调与指标优化第三天是联调日也是问题集中爆发的一天。硬件和软件第一次真正合在一起跑各种意想不到的问题都会冒出来。这个组在联调阶段的做法是先跑通基本功能再优化指标。比如一个控制系统先把开环跑通确认信号链路没问题再闭合环路调参数。不要一上来就追求完美指标那样很容易卡在一个小问题上出不来。联调阶段最常见的问题是信号不对这时候需要快速判断问题出在硬件还是软件。一个实用的方法是用示波器逐级测量信号从输入端开始一级一级往后查看信号在哪一级出了问题。这个组的系统整合角色在这方面发挥了关键作用因为他同时对硬件和软件有理解能快速判断问题归属。2.4 第四天测试、报告与提交最后一天上午用来做最终测试和指标确认下午用来完成报告和提交。这里要强调的是报告不要留到最后一天才写。这个组从第一天就开始整理报告框架每天往里填内容最后一天只需要补充测试数据和结论。报告撰写的几个要点方案论证要有对比、理论计算要有过程、测试数据要有表格、电路图要清晰、代码要有关键部分注释。评审老师看报告的时间有限排版清晰、重点突出比文采重要得多。3. 那些只有踩过才知道的坑电赛的坑有些是技术层面的有些是流程层面的。技术坑可以靠知识弥补流程坑往往更致命因为它浪费的是时间。这个组在比赛过程中遇到的几个问题我觉得很有代表性。3.1 器件选型的性能陷阱刁政宇在选型时曾经纠结过一款性能更好的芯片但最终放弃选了一款自己用过的。这个决策后来被证明是正确的——那款更好的芯片需要额外的配置流程在比赛的时间压力下任何额外的学习成本都是风险。注意电赛的评分标准是完成度优先不是技术先进性优先。一个用成熟方案稳定完成所有指标的作品得分远高于一个用前沿方案但只完成一半的作品。3.2 软件版本的混乱朱铭昱在联调阶段遇到过一个典型问题硬件改了接口定义但软件没有同步更新导致通信一直失败。排查了两个小时才发现是版本不一致。这个问题的解决方案是建立一个简单的版本记录每次硬件或软件有改动在共享文档里记一笔注明改了什么、影响什么。这个习惯看起来麻烦但省下的排查时间远超记录时间。3.3 测试环境的准备不足叶申源在最后测试阶段发现实验室的某些仪器被其他组占用了导致测试排队等了很久。这个问题其实可以避免——提前确认所需仪器能预约的预约能自带的自带。这个组的教训是赛前就要列一个测试仪器清单包括示波器、万用表、信号发生器、直流电源等确认比赛场地能提供哪些自己需要带哪些。不要假设到时候肯定有。4. 组队与协作三个人如何不内耗电赛是团队比赛但团队本身也可能成为问题来源。三个人意见不合、分工不清、进度不同步这些都会消耗大量精力。这个组在协作方面的一些做法我觉得比技术细节更值得分享。4.1 决策机制谁负责什么就听谁的这个组有一个明确的决策原则在自己负责的领域内主攻手有最终决定权。硬件怎么布局刁政宇说了算软件用什么算法朱铭昱说了算系统怎么整合、报告怎么写叶申源说了算。其他人可以提建议但不强行干预。这个机制的好处是避免了无休止的争论。电赛时间紧张最怕的就是三个人在一个问题上僵持不下。有了明确的决策权归属效率会高很多。4.2 沟通节奏固定短会与即时同步前面提到每天结束前的15分钟短会这个习惯贯穿了整个比赛过程。短会的内容很固定今天完成了什么、遇到了什么问题、明天计划做什么、需要谁配合。除了固定短会他们还建立了一个即时同步的机制——任何一个人遇到阻塞性问题立刻在群里说不要自己闷头搞。这个组的经验是很多问题在别人看来只是一句话的事但自己钻牛角尖可能浪费几个小时。4.3 情绪管理允许犯错但不允许重复犯错比赛压力大的时候情绪容易失控。这个组的一个默契是出了问题先解决不追责。硬件烧了、软件跑飞了先想办法补救等事情过去了再复盘原因。但有一条底线同样的错误不能犯第二次。第一次是意外第二次就是态度问题。这个原则让团队既有容错空间又不至于反复踩同一个坑。5. 赛后复盘哪些做法值得延续比赛结束后这个组做了一次复盘把做得好的和做得不好的都列了出来。我觉得这种复盘习惯本身就值得学习因为电赛的经验只有经过整理才能变成自己的能力。5.1 值得延续的做法赛前建立代码库和器件清单这个准备工作的回报率极高直接节省了比赛中的决策时间。每天固定短会保证了信息同步避免了重复劳动和方向偏差。报告框架提前搭建最后一天不慌报告质量有保障。决策权明确减少了内耗提高了执行效率。5.2 需要改进的地方测试仪器的准备不够充分应该赛前就确认场地仪器情况做好预案。版本管理太随意虽然最后问题解决了但过程中浪费了时间应该用更规范的记录方式。联调阶段的时间预留不足实际联调遇到的问题比预期多应该把第三天的时间安排得更宽松一些。5.3 给后来者的建议如果你正在准备电赛或者即将组队参赛我的建议是把至少30%的精力放在非技术的准备上。器件清单、代码库、分工方案、沟通机制、报告模板这些东西看起来不硬核但它们决定了你的技术能力能不能在四天三夜里充分发挥出来。技术可以临时学但流程和协作的问题一旦在比赛中暴露往往没有时间补救。刁政宇、朱铭昱、叶申源这个组的经验核心不在于他们用了什么芯片、写了什么算法而在于他们把怎么合作这件事想在了前面。我在实际带队伍的过程中发现那些赛前把分工和流程理清楚的组比赛时的状态明显更从容。他们不是没有遇到问题而是遇到问题时知道该找谁、该怎么解决。这种从容本身就是竞争力。