AI时代嵌入式面试还能问出真水平吗？

以前做嵌入式面试，其实有一套比较直接的办法。问项目做过什么。问某个模块是不是你负责的。问任务怎么划分，队列怎么用，中断里做了什么。再往下问一点，指针、内存、volatile、栈溢出、RTOS 调度、串口丢包、I2C 异常、DMA 这些细节，基本就能看出一个人到底有没有做过。会就是会。不会也能临时说几句，但很快就会露出来。因为嵌入式很多东西不是背几个概念就能装出来的。你有没有在板子前面熬过，有没有被一个偶发 bug 折磨过，有没有看过寄存器、波形、日志、map 文件，问深一点，感觉是不一样的。但现在 AI 出来以后，这件事变得有点微妙。简历可以让 AI 润色。项目经历可以让 AI 帮你整理。面试题可以让 AI 帮你准备。不会的概念，可以让 AI 用很漂亮的话解释。甚至一个学生没有完整做过项目，也能让 AI 帮他把课程设计、毕业设计包装成一套看起来很完整的技术叙述。那以后嵌入式面试还怎么问？是不是问基础，别人说是 AI 帮我学的；问项目，别人说是 AI 辅助开发的；问代码，别人说 AI 写了第一版，我调了一下。这个问题对面试者是挑战，对公司也是挑战。

1、以前面试，很多问题能问出经历

我自己以前理解嵌入式面试，核心不是把人考倒，而是确认几件事。第一，他到底有没有接触过真实工程。有些人简历上写了很多项目，但一问供电、通信、任务划分、资源限制，就讲得很空。真实做过的人，通常会记得一些很具体的东西，比如某个任务栈开小了，某个外设初始化顺序不对，某个串口在高负载下丢数据，某个驱动在中断里处理太多导致系统抖动。这些细节不是标准答案。它们更像项目留下来的伤口。第二，他基础是不是能支撑他继续成长。嵌入式绕不开 C 语言。指针、数组、结构体、内存布局、编译链接、static、const、volatile，这些东西平时看着老生常谈，但真正出了问题，经常就卡在这里。比如一个变量在主循环和中断里同时用，为什么要考虑volatile，为什么只加volatile还不一定够。比如一个局部数组开大了，为什么系统会跑飞。比如一个函数指针表写错了，为什么看起来像随机跳转。这些问题过去很好问。因为你要么真理解，要么就是背了几句定义。再加几个追问，很容易看出来。第三，他遇到问题时是不是有排查路径。嵌入式开发不是只写代码。更多时候是在和不确定性打交道。程序不进中断，先看 NVIC 还是看引脚复用？I2C 偶发 NACK，先怀疑上拉、电平、时序，还是驱动状态机？低功耗电流下不来，先看外设时钟，还是 IO 状态？这些东西没有唯一答案，但能看出一个人的工程感觉。

2、AI 把很多表面差距抹平了

现在的问题是，AI 把很多表面差距抹平了。一个大学生基础不扎实，但他可以让 AI 帮他补基础题。不知道volatile，AI 可以给出定义、例子、常见误区。不知道 RTOS 死锁，AI 可以讲互斥锁、优先级反转、资源竞争。不知道项目怎么介绍，AI 可以帮他把“我做了个温湿度采集系统”包装成“基于 FreeRTOS 的多任务传感器采集与通信系统”。如果只是看简历和听前两分钟介绍，确实很难分辨。尤其是大学生。现在很多课程设计、实验报告、毕业论文，都可以被 AI 加工得非常完整。以前一个学生有没有真的把代码跑起来，报告里多少能看出痕迹。现在报告可能写得比真实经历还顺。这就会带来一个很现实的问题：面试官问基础知识，候选人可以背 AI 帮他整理的答案；问项目经历，候选人也可以背 AI 帮他梳理的项目话术。如果面试还是停留在“请你讲一下什么是指针”“请你介绍一下你的项目”，确实会越来越难筛人。但我不觉得基础题就不能问了。问题不是基础题没用了，而是基础题不能再孤立地问。

3、以后基础题要放进场景里问

比如问volatile，以前可以直接问：volatile有什么作用？现在这样问，候选人很容易背出一套答案。什么防止编译器优化，什么内存可见性，什么硬件寄存器和中断共享变量。这些话都对，但不够。更好的问法可能是：

volatile uint8_t rx_done = 0;
void USART_IRQHandler(void)
{
    rx_done = 1;
}
int wait_rx_done(void)
{
    int timeout = 100000;
    while (!rx_done && timeout--) {
    }
    return rx_done ? 0 : -1;
}

然后问：这段代码能不能工作？有什么风险？如果rx_done不是 8 位，而是一个 32 位计数器，会有什么不同？如果这个变量在多个任务之间共享，光加volatile够不够？如果面试者真的理解，他会讲到编译优化、中断共享、超时设计、原子性、任务同步，甚至会说这里更好的方式可能是信号量、事件标志或者环形缓冲。如果只是背 AI 答案，很容易停在第一层。再比如问指针，也不要只问“指针是什么”。可以给一段真实一点的代码：

void parse_frame(uint8_t *buf, uint16_t len)
{
    uint16_t payload_len = buf[2] << 8 | buf[3];
    uint8_t *payload = &buf[4];
    for (uint16_t i = 0; i < payload_len; i++) {
        handle_byte(payload[i]);
    }
}

然后问：这里可能有什么问题？如果len小于 4 会怎样？如果payload_len比实际缓冲区长会怎样？如果这个函数处理的是串口 DMA 接收缓冲区，还要考虑什么？这种问题仍然是基础，但它不是背概念，而是看一个人能不能把基础放回工程现场。

4、项目经历也不能只听介绍

很多公司现在更喜欢问项目经历，这个方向是对的，但只听候选人讲项目，也会被 AI 影响。因为项目介绍非常容易被包装。一个普通的课程设计，AI 可以帮你扩写成架构清晰、模块完整、术语准确的项目描述。比如传感器采集、通信协议、上位机显示、数据存储、异常处理，听起来都很像那么回事。所以以后问项目，不能只问“你做了什么”，而要问“你怎么做的，为什么这么做，中间错过什么”。比如一个人说自己做过基于 RTOS 的数据采集项目，可以继续问：当时为什么要上 RTOS，而不是裸机轮询？任务优先级怎么分的？队列长度怎么定的？有没有遇到过队列满、数据丢失、任务卡死？某个任务的栈大小怎么估算？如果采样频率翻倍，系统瓶颈会在哪里？项目里哪个 bug 让你印象最深？这些问题不一定要求候选人回答得完美，但能看出他是不是经历过真实取舍。真实项目里一定会有不顺。如果一个人把项目讲得过于完整、过于正确、没有任何波折，反而要警惕。工程不是 PPT，尤其是嵌入式项目，不可能从头到尾都像文档写得那么顺。

5、面试不该排斥 AI，但要问清 AI 的边界

我不认为以后面试应该简单地问一句：这个项目是不是 AI 写的？这个问题意义不大。现在工作里用 AI 已经很正常。写脚本、查资料、解释代码、生成测试用例、整理文档，这些都可以用。一个候选人会用 AI，本身不应该扣分。真正该问的是：AI 帮了你哪一部分？你自己改了哪一部分？AI 给过哪些不靠谱的建议？你是怎么验证生成代码的？最后出了问题，你怎么定位？如果候选人能坦诚说明 AI 的使用边界，并且能讲清楚自己负责的判断和验证，我反而觉得这是加分项。因为这说明他不是把 AI 当代写工具，而是当工程助手。相反，如果一个人所有细节都说不清，只会说“这是 AI 生成的，我调了一下”，那就很危险。公司招人不是招一个会复制 AI 答案的人，而是招一个能对结果负责的人。

6、大学生会更难，也会更容易露出来

AI 对大学生面试的影响会更明显。一方面，大学生可以借助 AI 更快做出东西。以前大一、大二基础不够，很难做一个完整项目。现在只要会提问，会跟着 AI 调整，做出一个能演示的系统并不难。这对学生是好事。至少它降低了实践门槛。很多人以前卡在环境配置、语法错误、资料查找上，现在可以更快进入项目。另一方面，也更容易形成一种虚假的熟练感。项目是跑起来了，但不知道为什么这样设计。代码是能用了，但不知道边界在哪里。报告是写完了，但不知道实验现象是否真实。简历是好看了，但一问调试细节就空了。所以大学生面试以后可能会出现一个很大的分化。会用 AI 学习的人，会成长得更快。他能让 AI 解释代码，但自己会复盘；能让 AI 生成第一版，但自己会改；能让 AI 准备面试题，但自己会把题放到项目里理解。只用 AI 包装的人，短期看起来也不错，但面试一深入就会露出来。尤其是嵌入式岗位，只要问到具体代码、具体硬件、具体异常、具体调试过程，空心项目很难撑太久。

7、公司也不能再用老办法筛人

这件事不只是候选人的问题。公司如果还完全按以前的面试方式来，也会吃亏。只看简历关键词，会被 AI 润色影响。只问概念题，会被 AI 标准答案影响。只让候选人讲项目，会被 AI 话术影响。只做笔试题，也可能筛掉一些真实工程能力不错但不擅长刷题的人。嵌入式岗位更适合增加一些现场判断类问题。比如给一段有问题的 C 代码，让候选人读出来风险。比如给一个串口丢包的现象，让候选人说排查顺序。比如给一个 HardFault 的寄存器现场，让候选人说可能方向。比如给一个 RTOS 任务卡死的描述，让候选人分析是死锁、优先级、栈溢出还是中断占用太久。比如给一个外设初始化失败的场景，让候选人说先看时钟、引脚复用、复位、供电还是手册限制。这些题不一定要有唯一标准答案。面试官要看的，是候选人的推理过程。他会不会先确认事实？会不会区分现象和猜测？会不会提出可验证的下一步？会不会承认不确定，而不是硬编？这些东西比背答案更接近真实工作。

8、我觉得更合适的面试方式

如果让我设计一个 AI 时代的嵌入式面试，我可能会分成几块。第一块，基础概念，但必须结合代码。不要只问定义。给短代码，让候选人看风险。比如数组越界、指针生命周期、volatile、中断共享变量、内存对齐、大小端、环形缓冲、错误码处理。第二块，项目经历，但必须追到现场。不问泛泛的“项目介绍”，而问模块边界、资源约束、失败经历、调试路径、版本变化。真实做过的人不一定讲得华丽，但会有细节。第三块，调试题，看思路。给一个现象，不要求马上说出答案，而是要求给排查步骤。嵌入式工程里，很多问题本来就不是一眼能判断的。能不能合理缩小范围，比能不能猜中答案更重要。第四块，AI 使用边界。直接问候选人平时怎么用 AI。让他讲一个 AI 帮上忙的例子，也讲一个 AI 误导他的例子。这个问题很有价值，因为以后工作里大家都会用 AI，关键是看他有没有验证意识。第五块，小任务。如果条件允许，可以给一个很小的代码修改任务。比如修一个环形缓冲区问题，补一个超时处理，改一个状态机边界。时间不用长，十几分钟就能看出很多东西。

AI 之后，嵌入式面试不会变简单。它会变得更难。以前问几个基础题、追几个项目细节，大概就能判断一个人。以后这些表层内容都会被 AI 打磨，面试官需要更会问，候选人也需要更真实地证明自己。但我不觉得这是坏事。因为嵌入式本来就不是只靠背答案能做好的行业。你可以让 AI 帮你解释指针，但指针越界导致系统跑飞时，你还是要能定位。你可以让 AI 帮你写驱动框架，但外设不工作时，你还是要看手册、看时钟、看波形。你可以让 AI 帮你准备项目介绍，但面试官问到某个 bug 怎么来的、怎么复现、怎么修掉时，真实经历是藏不住的。以后真正有价值的面试，不是问候选人有没有用 AI，而是看他有没有在 AI 之外长出自己的判断。对面试者来说，AI 可以帮你跑得更快，但不能替你长出经验。对公司来说，AI 会让包装变得更容易，也会让真正会思考的人更值得被识别出来。嵌入式面试最终要找的，还是那种能把问题带回现场的人。看到现象，能拆。看到代码，能读。看到 AI 的答案，能判断。出了问题，能负责。