2026年秋招想投FPGA岗，简历里项目只有「跑通正点原子例程」，面试官一眼能看出来吗？

先说结论：能写，但别按『我完成了串口通信/OV5640图像显示』这种写法往上放，面试官一眼就能看出来是例程。判断维度其实就一个——你能不能对里面每一处改动说出『为什么』。比如OV5640那个工程，你改过分辨率吗？改了之后帧率掉了多少、SDRAM带宽够不够、FIFO深度怎么定的？如果这些你答不上来，那这段经历在简历上就是负资产，一问就崩。

比较稳的做法是把它降级处理：不单独占一个『项目经历』，而是塞进技能或课程实践里一笔带过，把简历版面留给一个你自己从零搭的小东西。举个例子，同样是OV5640，你可以砍掉显示部分，只做采集加SDRAM缓存加一个简单的帧差检测，用LED或串口输出结果，然后老老实实记下资源占用和最高能跑到多少帧。这东西不大，但面试官问起来你能一路讲到时序约束和跨时钟域，含金量完全不一样。

另外提个风险：双非本科FPGA岗筛简历确实狠，但狠在『看不出动手能力』，不是狠在项目小。你与其纠结写不写，不如花两周把例程里一个bug的定位过程整理成能讲三分钟的故事。你现在手头这块板子是哪家的、有没有逻辑分析仪或者ILA能抓波形？这个决定了你能不能把调试过程讲实。

例程当然能写，但关键看你怎么写。你现在的两个项目，串口收发和 OV5640 显示，都属于典型的教程工程，面试官看到这种描述基本会默认你只是跟着敲了一遍代码。那要不要写？我的建议是写，但要降级处理，不要单独占一个项目经历的位置，而是放在技能或课程实践里一笔带过，把简历版面留给一个你自己从零改出来的小东西。比如 OV5640 那个，你可以砍掉显示部分，只做采集加 SDRAM 缓存加一个简单的帧差检测，用串口或 LED 输出结果，然后老老实实记下资源占用和最高帧率。这东西不大，但面试官问起来你能一路讲到跨时钟域、时序约束和带宽估算，含金量完全不一样。另一个风险是，如果你把例程包装成项目经历，面试官一问「你改过哪里、遇到什么 bug、怎么定位的」，答不上来就是负资产，一问就崩。所以判断维度其实就一个：你能不能对里面每一处改动说出为什么。能说清楚，例程也能写；说不清楚，越包装越危险。你目前对 OV5640 那条链路里哪一块最熟，是摄像头配置、SDRAM 时序还是显示时序？

能写，但得换个写法。你现在这两个东西，问题不在于是不是例程，而在于描述里全是「实现了什么功能」，没有一个数字。面试官扫简历的时候其实是在找两类信号：这人有没有自己踩过坑，以及他对自己做的东西有没有量化的概念。串口收发和OV5640显示，如果只写功能，跟一百份简历长得一模一样，筛的时候自然排后面。 我的建议是保留一个、改造一个。串口那个太薄，放到技能栏里一句带过就行，比如熟悉UART协议、能独立完成收发模块与上位机联调。OV5640那个别急着扔，它其实有改造空间：把显示砍掉，只留采集加SDRAM缓存，再加个简单的帧差或者阈值判断，结果从串口打印或者点个LED。听起来是减法，但你这么一改，立刻多出一堆能讲的东西——像素时钟和SDRAM时钟不是一个域，跨时钟域怎么处理；一帧的带宽算下来是多少，SDRAM扛不扛得住；FIFO深度是按什么定的，深了浅了各会出什么问题。这些都是面试官爱追问的点。 描述的时候按「做了什么改动、为什么这么改、结果如何」来写，末尾挂上资源占用和帧率，比如LUT用了多少、BRAM几个、稳定跑到多少帧。哪怕数字不好看也没关系，真实比漂亮重要。 有个风险得提醒你：别把例程包装成独立项目。面试官一句「这块代码原来是什么样、你动了哪几行」就能验出来，答不上来这段经历就是负资产。所以判断标准很简单——你能不能对着这个工程讲二十分钟不卡壳。讲不了，就先花两周把它改到能讲。 你现在手上有板子能重新烧吗，还是得等开学回实验室？

别纠结能不能被看出来，先想清楚面试官看简历时在找什么。他一天翻几十上百份，眼睛扫的是数字和动词：多少帧、多少兆、几个周期、占了多少LUT、跑在多少兆时钟下。你写「基于FPGA实现OV5640图像采集与显示」，他脑子里立刻归档成教程工程，因为这句话没有提供任何他自己的判断。所以你真正要解决的不是写不写，而是让这段经历里出现只有亲手做过的人才知道的东西。具体做法：把OV5640那个工程当成原材料，做一次减法加一次加法。减法是砍掉显示，只保留采集加SDRAM缓存；加法是在这条链路上加一个你自己想出来的小功能，比如帧差、亮度阈值或者简单边缘检测，结果通过串口打出来。然后老老实实记录三组数据：不同分辨率下的实际帧率、SDRAM读写带宽的估算和实测、综合后的资源占用。这三组数字一写上去，性质就变了，因为它逼着你回答像素时钟和SDRAM时钟不同域怎么处理、FIFO深度凭什么定成这个值、带宽够不够。串口那个就别单列了，塞进技能栏一句话带过。简历版面有限，一个能讲透的小项目远胜三个跑通的例程。你目前是打算继续在OV5640上改造，还是想换一个更贴近目标岗位方向的小题目？

我换个角度说，你现在最该做的其实是一次自我审计：把OV5640那个工程打开，逐条问自己每个模块的参数为什么是那个值。像素时钟多少兆、SDRAM控制器跑多快、异步FIFO深度怎么来的、如果分辨率翻倍哪一级先撑不住。能答上七成，这段经历就值得写，只是描述方式要改；答不上三成，先别急着改简历，花两周把这条链路吃透，比再堆一个例程有用得多。描述上的技巧是把功能句换成约束句，比如不写「实现了图像显示」，写「在XX兆像素时钟下完成采集与SDRAM缓存，实测稳定帧率XX，占用XX个LUT」。约束句天然带着你的判断，面试官顺着问下去也是你准备好的方向。另外提醒一句，秋招时间紧，改造项目要设上限，别陷进去出不来。你目标岗位偏图像处理还是偏接口与逻辑设计？方向不同，这个项目往哪边深挖也不一样。

先说个可能不太中听但有用的判断：面试官能不能一眼看出来，其实不取决于你写的是不是例程，而取决于你简历上有没有出现「只有亲手做过才会知道的细节」。正点原子那套 OV5640 工程，全国每年跑通的人没有一万也有几千，所以「跑通」这两个字本身不构成任何区分度。但反过来想，这套工程是一条完整的链路：摄像头配置、像素时钟域、SDRAM 控制器、读写 FIFO、显示时序，每一级都有可以深挖的地方。你照教程改参数没关系，问题是你改完之后有没有产生过「为什么是这个值」的疑问，以及有没有真的去查过答案。

我建议你走一条比较务实的路线：不要重做一个新项目，就在这个工程上做一次「降维加改造」。降维是把显示砍掉，只保留采集加 SDRAM 缓存，这样链路变短，你能把每一级的时序和带宽算清楚；改造是在这条短链路上加一个你自己定义的小功能，比如对采集到的帧做阈值判断或者帧间差分，结果从串口输出。这个改造的技术含量不高，但它逼着你回答几个真问题：像素时钟和 SDRAM 时钟不同源怎么处理、一帧的数据量除以可用带宽够不够跑目标帧率、FIFO 深度按什么最坏情况定的。这些问题你答得出来，简历上就可以写「在 XX 兆像素时钟下完成采集与缓存，实测稳定帧率 XX，占用 LUT XX%」，约束句一出来，性质就变了。

至于时间安排，大三下开始学 FPGA，到 2026 秋招还有一年出头，这个窗口不算紧但也不宽裕。我的建议是给这个改造设一个硬上限，比如六到八周，做完就停，把剩下的时间分给八股、手撕代码和一到两个更小但更干净的模块练习。别在一个例程上无限打磨，秋招看的是整体匹配度，不是单个项目的深度。最后问一句：你目前用的开发工具链是 Quartus 还是 Vivado，板子上 SDRAM 的位宽和容量大概是什么规格？这两个信息会直接影响你带宽估算怎么写。

个人感觉这事儿的核心不是写不写，而是你有没有一个能撑住十五分钟追问的点。串口收发这种，放技能栏里一句「熟悉 UART 协议与收发模块设计」就够了，别占项目位置。OV5640 那个倒是可以留，但你得想清楚面试官会从哪儿切进来——大概率是问你帧率和带宽的关系，或者问你跨时钟域怎么处理的。这两个问题你要是现在答不上来，就先别急着改简历，花两三周把工程里的时钟树和数据流画一遍，画完你自然知道该写什么。

另外一个容易被忽略的点：简历上写例程不丢人，丢人的是被问「你改过哪里」的时候说「就改了个分辨率参数」。哪怕你只是把 FIFO 深度从默认值改成自己算出来的值，只要能说清楚按什么最坏情况算的，这就是你的东西了。所以与其纠结要不要写，不如先去做一次最小改造，哪怕只加一个 LED 指示帧同步信号，也比原封不动强。你板子上现在跑的最高分辨率是多少，掉帧情况明显吗？

能写，但别单独占项目位。串口那句放技能栏，OV5640 留着，重点写你动过哪、为什么动。面试官扫一眼就知道是不是例程，他要看的是你被追问三层还站不站得住。你现在能讲清像素时钟和 SDRAM 带宽的关系吗？

写，但别单独占项目栏。串口那句塞进技能里，OV5640 留着，描述里必须出现「你改了什么、踩了什么坑」。面试官不怕你跑的是例程，怕的是问三层你就没词了。你现在能说清像素时钟和 SDRAM 带宽怎么算吗？说不清就先别动简历，回去把链路捋一遍。

我理解你现在的焦虑，但先别急着删项目，换个思路：例程本身不丢人，丢人的是简历上只有「跑通」两个字。你手上这两个东西，串口那个确实太薄，放技能栏一句带过，比如熟悉 UART 收发模块设计与上位机联调，别占版面。OV5640 那个值得留，但描述方式得改，把功能句换成约束句——不写「实现了图像采集与显示」，写「在多少兆像素时钟下完成采集与 SDRAM 缓存，实测稳定帧率多少，综合占用多少 LUT」。数字一出来，性质就变了，面试官顺着问下去也是你准备好的方向。

更关键的是补一个带指标的小项目。不用从零造轮子，就在这个工程上做减法加加法：砍掉显示，只留采集加缓存，再加个帧差或者亮度阈值判断，结果从串口打出来。然后老老实实记三组数据：不同分辨率下的实际帧率、SDRAM 读写带宽的估算和实测、资源占用。这东西不大，但你能一路讲到跨时钟域、时序约束和带宽估算，比堆三个例程有说服力得多。

时间上设个上限，秋招节奏紧，别陷进去出不来。你板子上现在跑的是哪个分辨率的配置？