2026年FPGA大赛用国产高云GW2A做「实时视频去雾+目标检测」，评委问创新点是不是「把两个模块拼一起」，该怎么答才站得住？

先说结论：别把答辩往「我做了两个模块」上带，往「我让去雾为检测服务」上带。评委问拼接，本质是在问你有没有系统级的设计决策。你可以这样答：去雾不是独立美化，它的参数和输出去向是围绕检测器调的——比如去雾强度过大，暗部噪声会被放大，反而让 YOLO 的误检上升，所以我们做的是带约束的去雾，目标是检测 mAP 而不是主观清晰度。量化上给出三组对比：原图直检、去雾后直检、去雾后检测但去雾参数针对检测调优，看 mAP 和漏检率的变化。资源上提一句共用行缓存或 BRAM 的复用，说明两模块不是各占一块内存。时延上给端到端帧率，对比单独跑两个工程的简单叠加。这样评委听到的是「耦合」，不是「拼接」。你们现在有做过去雾参数与检测精度的联合调优实验吗？

你这个问题其实核心就一句话：别让评委觉得你在讲两个模块，要让他们觉得你在讲一个系统。答辩时你可以先承认去雾和检测各自都有开源参考，然后话锋一转，说我们的工作量不在于重新发明去雾或YOLO，而在于让去雾的输出真正服务于检测的输入分布。比如去雾强度不是拍脑袋定的，而是拿检测mAP当指标反推出来的——过强去雾会放大暗部噪声，反而让轻量YOLO误检变多，所以我们做的是一组面向检测的去雾参数约束。资源上提一句两者共用行缓存或BRAM，说明不是各占一块内存各跑各的。时延上给端到端帧率，和单独跑两个工程再串起来的朴素做法对比。评委听到的是耦合和取舍，自然就不说你是缝合了。你们现在有没有做过不同去雾强度下mAP的对比表？

先说结论：评委问「是不是拼一起」，你千万别去解释「我们两个模块都跑了」，要解释「我们让去雾的输出分布去迁就轻量检测器的输入分布」。这是系统级设计决策，不是两个工程各跑各的。举个例子，你可以说去雾强度不是按肉眼好看调的，而是拿检测mAP当反馈指标扫出来的：去雾太狠，暗部噪声被放大，轻量YOLO误检反而涨；去雾太弱，雾天漏检又压不下去。所以我们的去雾参数是面向检测精度约束的，目标是mAP而不是主观清晰度。量化上给三组就够了：原图直检、去雾后直检、去雾参数针对检测调优后直检，看mAP和漏检率怎么变。资源上补一句两模块共用行缓存或BRAM，时延上给端到端帧率，跟单独跑两个工程再串起来的朴素做法对比。评委听到的是耦合和取舍，就不会再说你是缝合了。你们现在扫过几组去雾强度？

我换个角度讲，答辩站不站得住，很多时候不取决于你做了多少，而取决于你能不能说出「为什么必须这么做」。GW2A这块板子资源本来就紧，你如果老老实实说「去雾一个模块、YOLO一个模块」，评委第一反应就是那我分别跑两个demo再串起来不也一样。所以你要把话头引到「单独部署做不到什么」上。比如：单独部署时去雾模块要占一份帧缓存，检测又要占一份，GW2A的BRAM根本不够同时开双缓冲，帧率直接掉下来；而我们把行缓存复用之后，两级的中间帧不用落DDR，端到端时延从多少降到多少。这就是硬件层面的耦合，不是软件调API能糊过去的。

风险也提醒一句：别把创新点全押在「精度提升」上。如果你的检测模型本身就很弱，去雾带来的mAP提升可能被噪声吃掉，甚至出现负提升，答辩时被追问就很难看。稳妥的做法是两条腿：一条是精度维度的联合调参实验，一条是资源/时延维度的复用率数据，哪条数据好看就以哪条为主讲，另一条作为佐证。替代做法也可以提一句，比如你试过先检测后去雾，发现对小目标没意义，所以最终选了去雾在前——这种被否掉的方案本身就是工作量。你们板子上BRAM现在还剩多少余量？

这个问题我想往深里说一层，因为「缝合」这个质疑背后其实是评委在考你有没有系统级的判断力，而不是考你会不会调开源代码。

先讲因果链。为什么去雾和检测放一起会有创新空间？因为去雾本质是一个图像增强算子，它改变了图像的亮度分布、对比度和噪声结构，而检测网络的训练分布是固定的。你把一张去雾后的图喂给一个在清晰图上训出来的轻量YOLO，分布已经漂了，精度未必涨。所以真正的工作量在于：让去雾的输出去适配检测器的输入，而不是让去雾自己好看。具体手段可以是去雾强度约束、可以是去雾后加一个很小的归一化层、也可以是训练时用去雾后的图做微调。这些都不是「两个开源工程拼起来」能自动得到的。

再讲工程取舍。GW2A资源有限，你不可能给去雾和检测各开一套独立缓存。常见做法是让两级共用行缓存，去雾按行输出、检测按行消费，中间不落DDR。这么做的代价是流水线耦合变紧，去雾的延迟会直接顶到检测的节拍上，任何一级卡顿都会拖垮端到端帧率。所以你要在答辩里主动说出这个代价，再说你怎么权衡的，比如牺牲一点去雾窗口大小换取流水线对齐。评委听到「我知道代价在哪、我做了取舍」，基本就不会再纠结拼接的问题。

最后讲学习路径。如果你还在准备阶段，建议先别急着堆模块，先把「去雾强度—mAP」这条曲线扫出来，哪怕只有五六个点，也比空谈耦合有说服力。资源复用率、端到端时延这些数据，等曲线出来再补，因为它们是支撑，不是主角。答辩时顺序也建议这么排：先讲问题（雾天检测掉点），再讲朴素做法为什么不行，最后讲你的耦合方案。你们现在是打算在检测前加归一化，还是直接拿去雾后的图微调检测网络？

先别急着把「耦合」当成答辩话术背下来，评委其实一眼能看出你是不是真做过。我建议你把问题反过来想：如果这两个模块真的只是拼一起，会发生什么？你先把这个「反面情形」写出来，再拿你的实测数据去逐条打脸，创新点自然就立住了。

反面情形大概长这样：去雾模块自己占一份帧缓存做双缓冲，检测模块再占一份，GW2A的BRAM根本不够，只能降分辨率或者跳帧；去雾输出落一次DDR，检测再读回来，端到端时延被DDR带宽拖住；去雾参数是照肉眼调好看的，检测精度不升反降。这三条只要有一两条你能给出对比数据，答辩就稳了。

具体怎么量化，给你一个可落地的实验设计。第一组，原图直接进检测，记mAP和漏检率；第二组，去雾后进检测，但去雾参数是主观调优的；第三组，去雾参数以检测mAP为反馈扫出来的一组约束值。三组一摆，你能说清「去雾不是为好看，是为检测服务」。资源维度补一句行缓存复用：去雾按行输出、检测按行消费，中间帧不落DDR，给出BRAM占用率的前后对比。时延维度给端到端帧率，跟「两个工程各跑各的再串」的朴素做法比。

风险也提醒一下：别把宝全押在精度提升上。轻量YOLO本身弱，去雾带来的mAP增益可能被噪声吃掉，甚至负提升。所以精度这条腿不稳时，资源复用和时延这条腿要能单独撑住。另外评委可能追问去雾强度怎么扫的、扫了多少组，你要是只扫了三五组，最好老实说范围有限，别硬吹。

你们现在去雾参数是固定值还是分场景自适应的？这个点会直接影响后面怎么答。