AI杂谈：面试AI Coding，我只看你是不是驾驶员

这两年面试，AI相关的问题越来越多。当然了，这里说的不是AI算法岗的面试，而是大模型应用开发，或者传统后端开发中的面试。有没有同学会想，面试官到底想考你什么？

我发现一个很有意思的现象：

很多同学聊AI的时候，像是在聊新闻联播。

DeepSeek、Agent、上下文窗口、推理模型、多模态、MCP，一个词接一个词往外蹦，听起来都知道。但一问到自己平时怎么用AI写代码，怎么判断AI写得对不对，怎么处理上下文太长、响应太慢、代码跑偏这些问题，马上就开始虚了。

我发现公司同事在面试的时候，基本不太喜欢问"你知道某某模型吗"，也不太喜欢问"你了解Agent吗"。这些问题太容易背，也太容易把面试变成概念互殴。

其实面试官更关心的是一件事是：

你到底是在用AI，还是在被AI用。

这场面试到底在看什么

如果我是面试官，我不会一上来就把AI问题问成八股文。

这类面试更像一条线：先用一个轻问题开场，看候选人有没有关注和体感；然后进入主线，让他讲自己真实怎么用AI Coding；最后根据他的回答，选几条支线往下挖。

整个过程大概20分钟就够了：

阶段	时间	面试官想看什么
引子开场	2-3分钟	对AI有没有关注，能不能把事件转成行动
AI Coding主线	8分钟	拿到需求到代码提交，中间怎么用AI
支线一：答不对怎么办	4分钟	能不能归因，而不是只会换模型
支线二：AI替代边界	4分钟	是否知道哪些事必须人来拍板
支线三：响应速度	4分钟	能不能从工程角度拆慢在哪里

这里最核心的判断标准，其实就一句话：

回答里是否自然出现"我先想，让AI跑，我检查/判断"的节奏。

比如同样是觉得模型慢。

观众的回答是：模型慢了？换个快的。

驾驶员的回答是：慢在读上下文，还是慢在推理，还是慢在输出？如果是prefill慢，就精简上下文；如果是推理慢，就关推理或者限制思考；如果是decode慢，就限制输出；如果任务本来简单，就换小模型。

这就是差距。

一个人懂不懂AI，不是看他能不能说出多少模型名字，而是看他能不能把AI纳入自己的工程流程。

引子不是闲聊，是看认知能不能落地

面试一开始，我一般会问一个很轻的问题：

最近一两年，AI领域有没有什么事让你觉得"原来还能这样"，或者让你对AI的理解发生了变化？

这个问题看起来是在问关注度，实际上不是考你记没记住哪个模型哪天发布，也不是考你能不能说出一堆时间线。

它真正想看的，是你能不能把一个行业事件转成自己的行动。

所以这个引子有两个原则。

第一，不要直接问"你知道DeepSeek吗""你知道Agent吗"。这样很容易变成知识考试，候选人也很容易开始背稿。

第二，关注度只是加分项，不是门槛。一个候选人主线和支线答得很好，但开场说不出什么AI大新闻，不应该直接淘汰；反过来，一个人开场讲得头头是道，但后面讲不出真实使用例子，这才是问题。

说白了，认知能不能转化为行动，执行力优先于好奇心。

引子后面可以怎么追？

方向	适合追问什么
DeepSeek	DeepSeek出来后，你用AI的方式有变化吗？换模型了吗？为什么换或者不换？
Agent	用过自动搜索、写文件、跑代码这类Agent功能吗？跟普通对话有什么区别？
上下文和记忆	跟AI聊久了它会不会忘事？给太多信息反而答得更差吗？你怎么处理？
基模原理	大模型为什么会一本正经地胡说八道？它的聪明和人的聪明有什么区别？

比如候选人说DeepSeek很火，这本身没什么信息量。如果只停留在"国产模型很强""价格很便宜"，那就是观众视角。

更好的回答应该是：

DeepSeek出来之后，我开始把不同任务拆开用模型。比如简单解释代码、生成单测这种任务，不一定要用最贵的模型；涉及公司内部代码或者敏感数据的场景，我会优先考虑本地部署或者私有化模型。它对我的影响不是"我知道了一个新闻"，而是让我意识到模型选择可以变成工程策略。

这就不一样了。

面试官听到这里，会知道你不是在背热点，而是在把热点落到开发流程、成本、数据安全、模型路由这些东西上。

再比如有人聊Agent。如果只是说"Agent就是多个AI一起干活"，这个回答基本没什么营养。

好一点的回答是：

普通对话是我问一句，它答一句；Agent更像是我给一个目标，它自己拆步骤、读文件、写代码、跑测试。但Agent也会跑偏，所以我不会一上来就让它全自动改一大坨代码，而是会先限制范围，比如只读哪些文件、只改哪个模块、改完必须给出验证方式。

这就是我想听到的东西：有使用场景，有踩坑经验，有边界意识。

如果候选人聊上下文，也可以继续追：

为什么上下文不能越大越好？KV Cache压缩、可生长记忆这些东西出来之后，是不是以后就不用管上下文管理了？

好的回答应该能落到：突破的意义是降低成本、扩大能力边界，但"该记什么、该忘什么"的判断并不会消失。就像机器内存从4G变成64G之后，操作系统也不可能从此不要内存管理。

至于大模型为什么会胡说八道，不要只回答"训练数据有截止日期"。这句话对，但太浅。

更接近本质的回答是：大模型是在生成最像答案的文本，不是在查数据库。它的优化目标是"像"，不天然是"对"。所以当数据覆盖不够、上下文不完整、问题边界模糊时，它就会编一个看起来合理的东西。

这就是面试官喜欢听的回答。

不是概念，而是机制；不是机制，而是"所以我怎么用"。

主菜永远是AI Coding全流程

真正的核心问题其实很简单：

拿到需求到代码提交，中间你怎么用AI？讲一个最近真实发生的例子。

这个问题非常好用，因为它几乎没法靠背来糊弄。

接下来可以顺着问：

层级	问题
1-2年	拿到需求到代码提交，中间怎么用AI？讲个最近真实例子
追问	AI到底帮你省了哪一步？
全级	AI生成的代码，你怎么判断它是对的？被坑过吗？
3-5年	哪一步AI帮不了你，或者帮倒忙？后来怎么处理的？
3-5年	token消耗大吗？你怎么控制给AI的上下文？给多给少分别会怎样？
5年以上	上下文装不下的复杂任务，怎么让AI跟你跑完全程？
5年以上加分	团队要做到偏AI Coding，需要建设哪些能力？哪些环节人不可替代？

如果候选人真的用过AI Coding，他的回答里一定会自然出现一个节奏：

1. 我先判断需求和改动范围
2. 我让AI帮我读代码、找入口、给方案
3. 我选择其中一个方案，让AI生成或修改代码
4. 我检查它引用的类和方法是否真实存在
5. 我跑测试，必要时补边界条件

也就是：

我先想，让AI跑，我来检查。

这个顺序非常关键。

很多差答案是反过来的：我先问AI，AI说怎么改，我照着改，跑一下没报错就提交。

这类回答最大的问题，不是用了AI，而是把方向盘交出去了。

比如一个比较好的回答可以这么讲：

前段时间我要改一个订单状态流转逻辑，我没有直接让AI写代码，而是先让它帮我梳理已有的状态枚举、状态机入口、单测覆盖情况。然后我把目标状态变化和不能影响的历史逻辑列出来，让它只改Service里的某个方法。生成后我重点检查了三个地方：有没有编不存在的方法、异常分支有没有漏、原来的幂等逻辑有没有被破坏。最后我补了两个单测，一个测正常流转，一个测重复请求。

这个回答不一定多高级，但很扎实。

面试官能从里面看到三件事：

第一，你知道AI擅长帮你加速读代码、找模式、补样板代码。

第二，你知道AI不懂你们公司的历史包袱和业务取舍。

第三，你知道验证不是"运行一下没报错"，而是要检查逻辑边界和回归风险。

如果回答到团队层面，可以继续往下拔高。

偏AI Coding的团队，能力建设至少有四层：

层级	要建设什么
需求层	会议、语音、零散描述能不能沉淀成PRD
知识层	代码索引、业务知识库、规范文档能不能让AI低成本拿到
方案层	PRD加代码索引，能不能让AI先穷举方案，人再做取舍
编码层	方案变代码之后，测试、CR、上线决策怎么兜底

注意，越往后越不是"让AI多写代码"这么简单。

真正不可替代的部分，是需求边界、方案取舍、Code Review兜底、上线决策与定责。

所以5年以上候选人如果只讲"我们要统一买个AI工具"，那不够。工具只是入口，流程和知识才是地基。

答不对时，看的是归因能力

我经常会继续追问：

有没有AI明明该答对，但就是答不对的情况？讲个具体例子，当时卡在哪？

这个问题考的不是你有没有被坑过，所有人都会被坑。真正考的是归因能力。

对于3-5年候选人，我会继续问：

这是模型能力不够，还是你给的信息不够？你怎么判断的？

对于5年以上候选人，我会再问：

团队怎么系统性减少这类答不对？prompt规范、知识库、RAG怎么选？怎么衡量答对了？

差一点的回答通常是：

它写错了，我就多问几遍。

或者：

我换了一个更强的模型。

这当然不是完全没用，但这不是工程思维，这更像是网不好就重启路由器。

一个会用AI的人，应该能把"AI答不对"拆开看。

问题类型	好的处理方式
缺领域知识	补DSL语法、业务规则、已有样例
上下文溢出	精简到入口类、目标方法、接口定义
指令模糊	明确边界，尤其说清楚不要做什么
幻觉API	先在IDE里搜类名、方法名是否真实存在
内部规范缺失	把线程池、异常码、日志格式等规范写进prompt或知识库

比如公司内部有一套自定义DSL，模型当然不知道。这个时候你换再贵的模型，也不如直接给它一段语法说明和一个项目里的真实样例。

再比如它引用了一个看起来很像真的类名，你不要跟它来回争论"你确定吗"。模型说有，不代表仓库里真有，直接在项目里搜。

所以面试里比较好的回答，不是"我换了GPT-5.5就好了"，而是：

我先判断它错在什么地方。如果是不了解内部框架，我会贴一个已有实现让它模仿；如果是上下文太长导致注意力分散，我会重新开一个对话，只带当前方法和依赖签名；如果它编了不存在的API，我会先在项目里搜索确认，再决定能不能用。

这类回答会让面试官觉得，你不是在祈祷AI变聪明，你是在控制输入、验证输出、缩小风险。

上下文不是越多越好

很多候选人一聊上下文，就会说现在模型上下文越来越大，以后应该不用管了。

这个回答听起来有道理，但从工程角度看，其实有点危险。

上下文窗口变大，确实能解决一部分问题，但它不是免费的。

你给AI塞得越多，它读得越慢，成本越高，而且注意力也会更分散。就像你让一个人看10个监控屏，理论上信息更多了，但他未必比只看3个关键屏幕判断得更准。

所以AI Coding里真正重要的不是"给多"，而是"给对"。

比如让AI改一个接口超时问题，你不需要把整个项目都塞进去。更合理的是给它：

1. 当前报错或现象
2. 请求入口
3. 调用链上的关键方法
4. 超时配置
5. 一个项目里已有的相似写法

如果任务很长，也不要指望一个对话从需求聊到上线。

更好的方式是分阶段：

第一轮，只让AI读需求和代码，输出改动方案。

第二轮，带着你确认过的方案，让AI改一个明确范围。

第三轮，让AI帮你补测试和检查边界。

第四轮，让AI总结这次改动，作为下一轮上下文。

这样做的本质，是把AI当成一个记忆有限但执行很快的同事。每次交接时，你不能把会议录音全文发给他，而是要告诉他：当前结论是什么，下一步做什么，哪些地方不能碰。

这里有个面试官很喜欢听到的词：刚好够。

只贴相关方法，不贴整包代码；只贴接口签名，不贴无关实现；用一个已有样例代替一大段抽象描述；对话长了，先让AI总结当前结论，再开新对话。

能做到这一点，说明候选人不是在堆料，而是在做上下文工程。

AI替代不了什么，别回答得太玄学

很多人回答"AI替代不了什么"时，喜欢说创造力、情感、共情。

不是说这些不对，而是放在研发面试里，太虚。

我一般会这么问：

层级	问题
1-2年	AI替代不了什么？你工作中有什么事是AI肯定干不了的？
3-5年	如果给AI足够的数据和规则，它是不是就能做了？边界到底在哪？
5年以上	怎么跟老板解释"用了AI但还是要这么多人"？AI会怎么改变团队分工？

我更希望听到的是这些：

AI替代不了责任归属。线上规则该不该上，误杀和漏放怎么取舍，出了问题谁负责，这些不能交给AI拍板。

AI替代不了私有知识。很多业务规则不在文档里，而在老员工脑子里、历史事故里、某个没人敢删的if判断里。模型不知道这些东西，除非你把它们整理出来。

AI替代不了问题定义。很多时候难的不是"怎么实现"，而是"这是不是一个真需求""这个需求有没有更便宜的解法""现在做会不会把系统带偏"。

AI替代不了价值取舍。比如风控系统里，到底是宁愿误杀一点，还是宁愿漏放一点？这不是算法题，这是业务阶段、用户体验、合规风险共同决定的结果。

所以我不太喜欢听候选人说"AI永远不能替代人类"这种大话。

更好的说法是：

AI会替代掉很多低价值执行动作，但不会替代问题定义、方案取舍、责任兜底和上线决策。开发者的价值会从"我能不能写出来"变成"我能不能定义清楚、验证准确、控制风险"。

这才是对研发岗位真正有意义的回答。

慢在哪，比换快模型更重要

还有一个很容易区分候选人水平的问题：

用AI工具时有没有觉得响应太慢？你一般怎么让它快一点？

普通回答是：换个快一点的模型。

这没错，但太粗了。

这道题本质上也是在做归因。

可以继续追：

层级	问题
全级	用AI工具时有没有觉得响应太慢？你一般怎么让它快一点？
3-5年	响应快慢跟哪些因素有关？能列一下吗？哪个影响最大？
3-5年	什么时候开推理模式，什么时候不开？怎么判断？
5年以上	快和好怎么平衡？你是不是一直用最快或者最强的模型？

真正会用的人，会先判断慢在哪里。

如果是读得慢，也就是输入上下文太长，那就精简上下文。别把历史聊天、无关文件、无关工具全带进去。有些工具会把schema常驻塞进上下文，用不上就不要挂太多。

如果是想得慢，也就是开了推理模式，那就看任务值不值得。让AI解释一段简单代码，不需要开深度思考；让它做复杂方案取舍，可以开。

如果是写得慢，也就是输出太长，那就限制输出。比如只让它写关键方法，不要整个类；只让它列风险点，不要写长篇解释。

如果是模型本身慢，那就做任务分级。简单任务用小模型，复杂推理用强模型，生产验证靠测试和Code Review。

可以这样拆：

慢在哪里	可能原因	处理方式
读得慢	上下文太长、工具太多、历史消息太厚	精简上下文，不用的工具别挂，只给当前任务材料
想得慢	开了推理模式，思考token太多	简单问题关推理，复杂问题拆步问
写得慢	输出太长	限制输出长度，只要关键方法，不要完整项目
模型慢	模型太大或任务路由不合理	简单任务走小模型，复杂任务再上强模型

这里面最重要的一句话是：

不是一直用最快的，也不是一直用最强的，而是当前这一步需要什么，就选什么。

比如探索阶段，我愿意用强一点的推理模型，让它多给几个方案；编码阶段，我可能用更快的模型生成样板代码；验证阶段，我反而不会太相信模型，我更相信单测、日志和代码审查。

这个回答背后体现的是成本意识、风险意识和流程意识。

面试官最后怎么打分

如果把所有问题收束起来，其实就一张表：

维度	差答案	好答案
使用节奏	先问AI，等AI告诉我怎么办	我先想，让AI跑，我检查
错误归因	多问几遍，换个模型	判断缺知识、缺上下文、指令模糊还是幻觉
验证方式	跑一下没报错	查API真实性、看边界、跑测试、做回归
上下文管理	全部塞进去	只给当前任务需要的关键材料
模型选择	一直用最强或最快	按任务阶段选择模型
AI边界	创造力、情感这些套话	责任、私有知识、问题定义、价值取舍

如果要再细一点，可以这么看：

层级	表现
L0	没关注过，也讲不出自己怎么用
L1	能说出一个AI事件，并知道它大概为什么重要
L2	能讲出事件对自己使用方式的影响，比如换模型、开始用Agent、考虑本地部署
L3	能从事件推到技术意义和行业影响，比如开源、成本、数据安全
L4	能从事件推到架构决策，比如模型抽象层、多模型热备、本地部署兜底
L5	能串起趋势判断，比如从对话到Agent，再到多Agent和闭环，知道瓶颈正在从模型转向编排

说到底，AI面试不是在考"你听过多少模型"，而是在考你有没有新的工程基本功。

以前我们看一个程序员，会看他会不会拆需求、会不会读代码、会不会定位问题、会不会写测试、会不会做技术取舍。

现在还是这些东西，只不过中间多了一个AI。

AI会放大能力，也会放大问题。

一个本来就知道怎么拆问题的人，用AI会更快；一个本来就没有判断力的人，用AI只会更快地把错误提交上去。

所以面试里最怕的不是候选人没听过某个模型，而是他讲了半天AI，最后结论只有一句：

"AI挺厉害的。"

这句话没有错，但没用。

真正能打动面试官的结论应该是：

"所以我会这样调整我的开发流程。"

前者是观众。

后者才是驾驶员。