2026年了，FPGA大赛拿奖后简历怎么写才能让面试官一眼记住？项目描述侧重算法还是工程？

别把获奖当结论写，要把获奖当证据链写。你现在的描述是「拿了省一」，面试官读到的是「这人会调板子」，但省一每年几百个，他记不住。真正让他抬头的是「我在集创赛里负责AXI DMA的带宽优化，把DDR读写效率从62%压到89%，代价是LUT多吃了7%，最后靠调整burst长度和预取深度把时序收敛到150MHz」。你看，这中间有指标、有取舍、有代价，比「实现了高速数据传输」有画面感得多。算法和工程的比例，我的建议是七三开偏工程——除非你投的是算法岗，否则面试官默认你会写RTL，但他不确定你能不能在上板三天前把时序救回来。具体写法上，别用STAR那种死板格式，可以按「背景一句话、我的模块两句话、关键指标一句话、踩坑一句话」来组织。比如：比赛要求实时处理4K视频流，我负责ISP管线里的降噪模块，用中值滤波换双边滤波，PSNR掉了0.8dB但LUT省了35%，最后整条流水线在100MHz下跑通，没丢帧。最后补一句当时怎么定位到是带宽瓶颈而不是逻辑延迟的——这种debug过程才是面试官最想听的。关键词上，多写「时序收敛、资源占用、吞吐率、握手协议、跨时钟域」，少写「精通、熟练、实现了」。另外，别只写一次获奖，把两次比赛串成一条成长线，比如电赛是入门，集创赛是深入，这样显得有规划。你现在的简历，是把奖状贴在脸上，还是把问题解决过程摊开给人看，差别很大。对了，你投的岗位是偏验证还是偏设计？这会影响我把算法细节写到多深。

你这个问题背后其实藏着两个更深的困惑：一是不知道面试官在简历上到底找什么，二是怕自己写出来的东西在别人眼里不值钱。我先说第一个。面试官筛简历，本质是在做风险控制——他要找一个来了能干活、出问题能自己扛的人。获奖本身只证明你比同龄人多花了时间，但证明不了你解决问题的能力。所以他真正在找的是「证据」，证明你有过完整的闭环：从需求到方案，从方案到实现，从实现到调试，从调试到复盘。你现在的描述缺的就是这个闭环。第二个困惑，算法和工程怎么选，我的建议是别选，要写它们的交叉点。纯算法写「提出了一种改进的量化方案」很虚，因为面试官不知道你的改进在硬件上意味着什么；纯工程写「完成了时序收敛」也很虚，因为收敛是基本功。真正有冲击力的是把两者绑在一起：比如「为了在资源受限的FPGA上跑通YOLOv5s，我把权重从FP32量化到INT8，mAP掉了1.2%，但DSP48占用从98%降到61%，最后在ZYNQ上做到30fps」。你看，这里算法决策（量化）直接导致了工程结果（资源下降），面试官一眼就能看出你有全局观。具体到写法，我建议你给每个项目写三句话：第一句说清楚你负责的模块和它在整个系统里的位置；第二句写你做了什么关键决策，以及这个决策带来的可量化变化；第三句写你踩了什么坑、怎么定位的、最后怎么解决的。不用写什么STAR，那太僵了，就按这个逻辑自然写。另外提醒一句，别把队友的功劳写进来，面试官追问细节时你答不上来，比不写更糟。你最好现在就把两个比赛的代码翻出来，回忆一下每个模块的时序约束文件里你改过什么，带宽瓶颈是怎么用ILA抓出来的——这些细节才是你面试时的底气。最后问一句，你这两次比赛，哪一次是你个人主导的模块更多？那一次应该作为简历的主项目。

先说结论：面试官记不住奖项，只记得住你解决过什么具体问题。省一、国一每年都有，但「我在集创赛里负责把AXI DMA的读带宽从62%提到89%，代价是LUT多吃7%，最后靠调burst长度和预取深度把时序压回150MHz」这句话，他大概率会抬头看你一眼。所以写法上别堆名词，也别写成流水账，就用最朴素的STAR变形：背景一句话（比赛要求实时处理4K视频流）、你负责的模块两句话（ISP管线里的降噪，用中值滤波换掉双边滤波）、关键指标一句话（PSNR掉了0.3dB但LUT省了40%）、踩坑一句话（最初缓存没对齐导致DMA频繁断流，后来改成64B对齐才解决）。算法和工程的比例，除非你投算法岗，否则我建议七三开偏工程，因为面试官默认你会写RTL，但他不确定你能不能在上板前把时序救回来。另外有个容易被忽略的点：别只写成功，写一个你主动放弃的方案。比如「试过将权重从FP32量化到INT8，发现检测精度掉太多，改成混合量化，只对前两层用INT8」，这种取舍比「完成了量化」可信得多，也天然是面试追问的引子。最后提醒一句，简历上的每个数字都要能当场解释怎么测出来的，不然就是给自己挖坑。你现在用的赛题是哪个方向的？集创赛的话，作品是偏SoC还是纯FPGA？这会影响描述里该突出总线还是时序。

我建议你换个思路：别问「写算法还是写工程」，先问「面试官看见这段描述时，脑子里会不会冒出一个追问」。如果会，这段就写对了。比如你写「完成了时序收敛」，他可能问「收敛到多少？瓶颈在组合逻辑还是布线？」；但如果你写「把三段式状态机改成单段式，关键路径LUT级数从9级压到6级，代价是代码可读性变差，后来加了注释才敢提交」，他大概率会追问「为什么单段式能压级数？你测过复位同步吗？」——这才是你想要的对话。回到比例问题，我的经验是：除非投算法岗，否则工程细节永远比算法名词重要。因为算法创新在竞赛里多半是调参或套现成论文里的成熟结构，面试官心里有数；但工程能力是实打实的，比如你DDR读写效率低，是burst长度没调好还是bank冲突？你时序不收敛，是组合逻辑太深还是扇出太大？这些细节写出来，比「提出了一种改进的量化方案」有分量得多。具体组织上，别用STAR那种死板格式，按「背景一句话、我的模块两句话、关键指标一句话、踩坑一句话」来，像讲故事但每句都有信息量。另外有个常见误区：把团队成果写成个人成果。面试官一问「这个AXI DMA是你一个人写的？」你就露馅。正确做法是写清楚「我负责DMA读写调度，队友负责图像算法」，然后你的部分给出独立指标。最后给你个替代做法：如果实在没得写，就把你调试过程中最痛苦的那个bug写上去，比如「花了两天发现是跨时钟域握手信号没做同步」，这比「完成了模块设计」更能证明你会debug。你目前写的是哪类赛题？如果是集创赛，作品是偏SoC还是纯逻辑？这会影响描述里该突出总线协议还是时序约束，你可以把当前草稿发一段上来，我帮你看看哪里能改出追问点。