2026年电赛FPGA赛题公布后，队伍怎么在48小时内把系统框图砍到能落地的规模？

先别急着画框图，拿到题目第一件事是把评分表抄一遍，逐条圈出哪些是硬指标、哪些是主观印象分。这一步做完，你会发现所谓「实时控制+AI推理」真正卡人的往往只有两三个数字：控制周期多少微秒、推理帧率多少、误差带多宽。把这些数字写在大白板上，剩下的讨论就有了裁判。

接下来按采集-处理-输出切三段，每段只认一个最小闭环。采集端先问：评委怎么给我喂信号，模拟还是数字，带宽多大，我能不能用最笨的ADC加DMA先跑通？处理端只留一条算法主干，AI推理和控制律哪个是评分核心就保哪个，另一个要么降级成查表要么直接砍。输出端先保执行器能按指令动、波形能对上，人机界面、上位机曲线、炫酷灯效全部进「砍」清单。

真正难的不是砍，是砍完之后队友不服。我的经验是给每个砍掉的模块标注代价：砍了它，哪个指标会掉多少分。这样讨论就从「我想做」变成「值不值」。第一天结束时必须产出一张只有五六个框的图，每个框旁边写清楚验证方法——用信号源、用示波器、还是用串口打印。跑不通的框当天就暴露，比第三天崩盘强太多。

还有一点容易被忽略：留出接口冻结的时间点。一般第一晚就要把引脚、时钟、数据格式定死，后面谁改接口谁请全队吃饭，否则联调时全是扯皮。你们现在手上有开发板型号和赛题原文吗？这决定了ADC和推理方案能压到多小。

我更想聊的是「倒推」这件事怎么落地。很多人说先锁输入输出再倒推算法，但真到白板前还是从算法开始画，因为算法最有成就感。我的做法是反过来，先写一个假的顶层：输入接口固定、输出接口固定，中间就放一个黑盒，黑盒的输入输出时序先定死。这时候你会发现黑盒能不能实时其实已经被接口约束住了，比如采样率一高，浮点推理基本没戏，方案自然往定点或者降采样走。

框图画完先别分配任务，先让每个人认领一个框的验证方案。谁负责采集，就要说清楚用什么信号源验证；谁负责推理，就要说清楚拿什么数据跑、精度掉多少能接受。验证方案写不出来的框，大概率是锦上添花，直接砍。

砍的顺序我一般按三档：影响核心指标的一档，保；影响演示效果但不影响评分的一档，看时间；纯好看的一档，删。别心疼，48小时里能跑通一条闭环已经赢一半队伍了。

先讲一个很多人不愿意承认的事实：48小时里真正决定成败的不是框图本身，而是「验证方案能不能在第一天晚上写出来」。所以我的裁剪主线只有一条——按可验证性排序，而不是按功能重要性排序。

拿到题目先把评分表逐条抄到白板上，圈出硬指标数字：控制周期多少微秒、推理帧率多少、误差带多宽。这些数字是后面所有争论的裁判，没有它们，队友之间就是纯吵架。

然后拆采集-处理-输出三段，每段只留一个最小闭环。但关键动作在下一步：让每个框的负责人当场说出验证方案——用什么信号源、拿什么数据、精度掉多少能接受。写不出验证方案的框，不管看起来多重要，先放进候选砍单。这一步能筛掉一大半「想做但做不完」的模块。

砍的顺序我习惯分三档：影响核心指标的一档必保；影响演示效果但不影响评分的一档看剩余时间；纯好看的直接删。显示、联网、上位机美化基本都在第三档。

真正难的是砍完队友不服。我的做法是给每个砍掉的模块标代价：砍了它，哪个指标掉多少分。讨论就从「我想做」变成「划不划算」，情绪问题变成算术问题。

还有一点常被忽略：倒推接口时要把时序约束写死。采样率一高，浮点推理基本没戏，方案会自然往定点或降采样走。接口定了，算法空间其实已经被压缩了一大半。

48小时能跑通一条闭环，比堆五个半成品强得多。你们队现在框图里，有几个框是写不出验证方案的？

我一般建议第一天上午只做一件事：把赛题里所有带数字的要求抄下来，然后按「不满足就零分」和「满足了加分」分成两列。这个动作看着笨，但它能立刻把队伍从「功能清单」拉回「指标清单」。很多队框图越画越大，就是因为把加分项当成了必做项。

分完之后按采集-处理-输出切三段，每段只认一个最小闭环。采集端先问评委怎么喂信号、带宽多大，用最笨的ADC加DMA先跑通；处理端只留一条算法主干，AI推理和控制律哪个是评分核心就保哪个；输出端先保执行器能动、波形能对上。

剩下的显示、联网、灯效、上位机曲线，全部进砍单。不是它们不好，是48小时里它们换不来分。

砍完之后给每个被砍的模块标一句「代价」，比如砍了它哪个指标掉多少。这样队友的抵触会小很多，讨论也更容易收敛。你们现在的框图里，哪几个框是纯粹为了好看加的？

先说一个容易被忽略的前提：48小时里真正稀缺的不是人手，是「判断力」。四个人画框图画到凌晨两点，往往不是不会做，而是没人敢拍板砍。所以我的建议是，拿到题的第一次队内会议不要讨论技术，只干一件事——把评分表变成一张「否决清单」。

具体做法：把赛题里所有带数字的表述单独拎出来，比如控制周期、响应延迟、识别准确率、通道数、功耗上限。这些数字构成了一条及格线，凡是和这条线无关的模块，默认状态就是「不做」，而不是「看时间再说」。这个默认值很重要。很多人砍不干净，是因为把锦上添花的东西默认成「做」，然后再去论证该不该砍，结果永远砍不掉。反过来，让所有非核心模块默认出局，谁想加回来，谁负责举证它怎么帮到硬指标。

举证不了，就出局。

接下来才是框图本身。我习惯先只画接口，不画算法：输入是什么物理量、什么电平、什么速率，输出要驱动什么、精度多少、时序卡在哪。接口定死之后，中间那一大块其实是被约束出来的，不是被设计出来的。举个例子，如果采样率要求到几十兆，那浮点推理基本就别想了，方案会自然滑向定点或者降采样加流水线；如果控制周期是微秒级，那上位机显示、串口打印这些调试手段本身就会成为负担，得换成片上逻辑分析或者LED打点。你看，很多「砍」不是主观取舍，是接口逼出来的。

然后按采集、处理、输出切三段，每段只留一个能独立验证的最小闭环。注意是「能独立验证」，不是「能跑」。采集端至少要能用信号源或者自己搭的激励把数据灌进去，处理端至少要能用固定测试向量跑出可复现的结果，输出端至少要能用示波器或者逻辑分析仪看到波形。任何一段如果验证方案都写不出来，那这个模块大概率是想象出来的，先放候选砍单。

真正难的是砍完之后怎么服众。我的经验是给每个被砍的模块标一句代价，比如「砍了无线回传，实时性指标不受影响，但演示时评委看不到曲线」，把代价摆出来，讨论就从情绪变成账本。很多时候队友不是舍不得功能，是舍不得那份「我做了东西」的成就感，你能把代价讲清楚，他反而会松口。

最后提醒一句：第一天的框图不要追求完整，要追求「每一根线都有人能解释为什么存在」。解释不了的线，就是第二天会烧掉你六个小时的坑。你们队现在卡在砍不动，还是卡在砍完不知道先做哪段？