2026年电赛FPGA赛道想拿国奖，队伍在「指标堆满」和「故事讲圆」之间该怎么取舍？

先别急着删功能，先给整套系统找一个能一句话说清的工程问题。你们做多路采集加实时处理，适合往「多通道之间的同步误差到底卡在哪个环节」上收：是 ADC 采样时刻对齐、跨时钟域搬运、还是处理链路的固定延迟。把这个问题量化，比如八个通道峰峰值偏差要压到某个范围内、端到端延迟要稳定在某微秒级。之后每个模块都要能回答它对这个指标做了什么。答辩就按问题、约束、方案、实测对比四段讲，指标只当证据，别当目录念。备赛时每周留一次「十分钟讲给外行听」的演练，讲不顺就说明故事线还没成型。你们现在最想保住的核心指标是哪一个？

先对齐一个现实：评委不是没见过堆模块的作品，他们见过太多。你们硬件指标满，说明执行力和调试能力都在线，这是底子。真正缺的是把『我们做了什么』翻译成『我们解决了什么』。做法可以很土但有效：备赛早期就定一个能一句话说清的工程命题，比如『八路采集在强干扰下如何保证通道间同步误差稳定在某个范围』，然后倒推每个模块存在的理由——ADC 配置是为了对齐采样时刻，FIFO 和跨时钟域设计是为了不引入额外抖动，处理链路是为了把端到端延迟压住。答辩时按问题、约束、方案、实测对比讲，指标只是证据不是目录。功能可以砍，故事线不能散。你们现在最舍不得砍的是哪个模块？

这个问题我拆成两层来说，因为『指标堆满』和『故事讲圆』其实不冲突，冲突的是你们还没确定故事的锚点。

第一层是备赛阶段怎么定锚。很多人一上来就列功能清单，采集多少路、带宽多大、能不能跑算法，列完发现每个模块都挺厉害，但合起来没有指向。正确顺序应该反过来：先找工程痛点，再决定堆什么指标。你这个高云 GW2A 的平台，比较适合往『多通道同步』或『实时链路延迟确定性』这两个方向收。原因是它们天然要求你把 ADC 时序、跨时钟域、缓存深度、处理流水线全部串成一条因果链，评委一听就知道你不是在罗列模块，而是在解一道有约束的题。定完命题后要量化，比如通道间偏差压到多少、端到端延迟抖动控制在多少微秒，这个数字就是你们后面所有取舍的依据。哪个模块对这个指标贡献小，就敢砍。

第二层是答辩怎么讲。常见误区是把它讲成技术汇报，从系统框图开始一页页念，评委听到一半就失去耐心。更稳的结构是四段：问题是什么、约束在哪里、方案怎么选、实测对比如何。注意最后一段一定要有对比，比如优化前后同步误差从多少降到多少，或者两种跨时钟域方案在延迟上的差异。指标在这四段里是证据，不是主角。

还有一个容易被忽略的点：故事线要在备赛中期就成型，不能等到答辩前一周才拼。建议每周安排一次十分钟的对外讲解演练，讲给不懂 FPGA 的同学听，如果对方能复述出你们解决的核心问题，说明故事立住了；如果对方只记住了一堆参数，那还得改。

至于取舍本身，我的经验是宁可少两个功能，也要保住那条因果链的完整。评委对『闭环漂亮』的容忍度远高于对『功能数量』的容忍度。你们目前这条链路里，哪个环节的实测数据最拿得出手？

换个角度说个风险：很多队伍不是不会讲故事，而是故事和实物对不上，答辩时被追问两句就露馅。所以『故事讲圆』的前提是你们真的围绕那个问题做过取舍，而不是事后编一个说法。

举个具体例子。假设你们选的核心问题是多路采集的同步误差，那至少要能回答：误差主要来自哪几个环节，你们怎么定位的，改动前后数据差多少。如果只是嘴上说同步做得好，但示波器一测通道间还有明显偏斜，评委一问就崩。反过来，如果某个花哨的算法模块跟这个问题无关，砍掉它反而让故事更干净。

还有个替代做法：如果实在找不到单一痛点，可以退一步用『约束下的权衡』当主线，比如在资源受限的 GW2A 上如何同时满足通道数和实时性，讲清楚你们放弃了什么、换来了什么。这种叙事同样成立，而且更贴近工程真实状态。个人感觉，评委更在意你有没有清楚的判断依据，而不是功能表有多长。你们板子上的资源余量大概还剩多少？

先对齐一下你们的处境：你说『指标堆得挺满』，这句话本身其实已经暴露了问题。指标是别人（评委、往届题目、参考设计）定义的好，而工程命题是你们自己定义的。堆指标谁都会，选一个值得解的题才是分水岭。

我建议你们从『痛点倒推』而不是『模块正推』。具体做法：把你们现在所有做出来的功能列一张表，然后问自己一个问题——如果只允许保留一个功能，哪个功能砍掉之后整个系统就不成立了？那个功能背后一定藏着一个工程难点，比如多路采集里 ADC 采样时刻对齐、跨时钟域搬运带来的抖动、处理链路里固定延迟和吞吐的矛盾。把这个难点写成一句话，加上一个可测量的数字，就得到了你们的命题，比如『八通道同步误差峰峰值压到某个范围内，同时端到端延迟稳定在某微秒级』。

为什么必须先有数字？因为数字是取舍的唯一裁判。没有数字，每个模块都『看起来有用』，你永远砍不掉东西；有了数字，你可以理直气壮地说：这个花哨的算法模块对同步误差贡献几乎为零，砍掉它，把资源让给时序约束更紧的那条路径。评委真正想听的，恰恰是这种『我为什么不要它』，而不是『我又加了什么』。

接下来是故事的骨架。答辩不要按系统框图讲，那是目录思维。按『问题—约束—方案—实测对比』四段走：先说清楚工程问题和量化目标，再说你们面对的硬约束（器件资源、时钟频率、功耗、开发周期），然后讲为了满足约束做了哪些关键取舍，最后拿实测数据证明取舍是对的。指标只在第四段出现，作为证据，不作为开场白。

有个小技巧：备赛中期就开始做『十分钟外行测试』——找一个不懂 FPGA 的同学，你讲十分钟，如果他能复述出你们解决的核心问题，故事线就成了；如果他只记住了一堆模块名，说明你还在罗列。

最后提醒一个常见翻车点：故事和实物必须对得上。如果你们宣称同步做得好，但实测通道间还有明显偏斜，评委追问两句就露馅。宁可把命题定得小一点、数字保守一点，也不要讲一个自己数据撑不住的故事。

你们现在最舍不得砍的那个模块，是它真的对核心指标有贡献，还是只是调试花了很多时间不舍得？