AI 越会写代码面试越爱考基本功今天鸭鸭刷脉脉看到一条挺适合面试鸭的帖子笔试考 dijkstra 算法实现有多少人能写出来字节 2-2 的人能搞定吗说真的这题看着有点复古。现在大家面试聊的都是大模型、Agent、RAG、Cursor、Claude Code。突然有人问一句“Dijkstra 能不能手写”很多人的第一反应大概是这玩意工作里用得多吗鸭鸭也能理解这个反应。大部分后端开发日常写接口、查数据库、调 RPC、排线上问题确实不会天天手写最短路。真遇到路径规划、推荐图谱、网络路由也大概率先找成熟库不会从零搓一遍。但面试官问这题很多时候不是想知道你背没背下来。他想知道的是你离开 AI 之后还能不能把一个问题拆明白。这句话听起来有点扎心但这就是现在面试变化最真实的地方。过去面试考算法有时候确实像刷题比赛。谁刷得多谁模板背得熟谁就占便宜。现在不太一样了。AI 已经能把很多模板代码写得很顺。你让它写 Dijkstra它能写。你让它讲堆优化它也能讲。你让它顺手给你补个注释它比不少候选人还耐心。那面试官为什么还要问鸭鸭说句实在话面试官不是不知道 AI 会写 Dijkstra。他是想看看你是不是只剩下 AI 会写 Dijkstra。这里面有三个小变化很多候选人还没反应过来。第一基础题从“考你会不会背”变成“考你能不能解释清楚”。以前候选人背一个模板边界条件不太懂也能混过去。现在面试官反而会顺着问为什么要用优先队列为什么已经确定最短距离的点不用再更新如果边权有负数怎么办如果图很大内存放不下怎么办这些问题 AI 都能回答但面试现场是你在回答。你一旦开始背稿面试官很容易听出来。因为背稿的人会把步骤念得很完整但一追问为什么马上卡住。会写代码和知道代码为什么这么写是两回事。第二公司现在更怕“看起来能跑”的代码。这两年大家用 AI 写代码爽是真的爽坑也是真的坑。AI 写出来的东西经常第一眼能跑第二眼也挺像那么回事第三眼上线后才发现某个边界条件没处理。比如 Dijkstra 这种题最容易暴露这个问题。有的人能让 AI 写出一个版本但他说不清楚边权为什么不能为负。也有人写了 visited但解释不清楚什么时候一个点才算最终确定。还有人一上来就写一堆代码结果图是稀疏图还是稠密图都没想过。这不是算法题本身的问题。这是工程问题。公司怕的是你以后 review AI 代码时看着一段“能跑”的代码点了通过。第三AI 让简单代码变便宜也让基本功变得更容易露馅。以前一个候选人不会写某个细节还可以说“平时不常用”。现在不太好这么说了。因为 AI 可以马上把细节补出来。面试官真正要看的就变成你能不能判断 AI 补出来的东西对不对。这就是为什么最近基础题反而有点回潮。你以为是公司突然怀旧了。其实是因为业务代码被 AI 写掉一大块之后面试官只能换一种方式确认这个人脑子里有没有基本的模型。Dijkstra 只是其中一种。它考的不是你以后每天写最短路而是几件很朴素的事你能不能把一个大问题拆成“当前最短”和“待更新”的两部分你能不能分清楚贪心什么时候能用什么时候会翻车你能不能说出代码背后的约束而不是只交一段能跑的实现这几件事不玄。说白了就是你有没有基本判断力。所以这类题怎么准备鸭鸭说几句实在话。别只背模板先讲人话版本比如 Dijkstra 就一句话先从起点出发每次挑当前距离最短的点把它的邻居更新一遍。能把这句话讲明白再写代码。每个算法至少准备三个问题它解决什么问题什么时候不能用复杂度为什么是这个。能答这三个面试官通常会觉得你不是纯背。用 AI 学算法时别只让它给答案让它给你出反例。比如问“Dijkstra 遇到负权边为什么不行”再让它造一个最小例子。这个比看十遍模板有用。面试里别装自己全会真忘了某个细节可以说“实现细节我可能要推一下但核心思路是这样”。这比硬背错一个模板强。面试官更怕的是你不知道自己哪里不确定。最后说一句鸭鸭看完这条脉脉帖之后的判断现在基础算法不会因为 AI 会写就消失。它会从“你能不能写出来”变成“你知不知道它为什么这么写”。这对候选人不是坏事。因为背题的人会越来越难装真正理解过的人反而更容易被看见。下次面试官让你手写 Dijkstra别急着吐槽“工作又用不到”。你可以先问一句边权都是非负的吗图是稀疏图还是稠密图需要返回距离还是要返回具体路径这三句话一出来面试官大概率就知道你不是只会让 AI 帮你写代码的人。大家最近面试有没有遇到这种“看着很老派其实在考基本功”的题评论区聊聊……今天鸭鸭和大家分享一道 AI 大模型面试题。【Dijkstra 算法的核心思想是什么它为什么不能处理负权边】回答重点选模型的核心逻辑就一句话任务匹配优先资源约束其次生态完善兜底。先看任务类型。文本生成、对话这类任务选 Decoder-only 架构LLaMA、Qwen、Mistral 都行文本分类、NER 这种理解型任务BERT 系列更合适多模态场景就得上 CLIP、LLaVA 这类模型。再看资源约束。一张 3090 24G 显存全量微调最多跑 7B 模型用 QLoRA 能上到 30B。预算有限就别硬上大模型7B 的 Mistral 在很多任务上能打过早期的 13B 模型性价比更高。最后看生态。Hugging Face 上下载量大、issue 活跃的模型踩坑少。选个冷门模型遇到问题连个参考都找不到调试成本极高。扩展知识领域匹配的重要性预训练数据和目标任务的领域越接近微调效果越好需要的标注数据也越少。通用模型在垂直领域容易翻车。拿医学问答来说用通用 LLaMA 直接微调模型可能把心肌梗死和心绞痛搞混因为预训练阶段压根没见过多少医学文献。换成在 PubMed 论文上继续预训练过的 BioMistral效果能提升 10-15 个点。目前各领域都有专门的预训练模型领域代表模型预训练语料生物医学BioMistral、BioGPTPubMed、MIMIC法律LegalBERT、SaulLM法律文书、判例金融FinBERT、BloombergGPT财报、新闻、研报代码CodeLLaMA、DeepSeek-CoderGitHub、StackOverflow模型规模的选择策略不是越大越好得看任务复杂度。简单任务别上大模型。情感分类、意图识别这种BERT-base 110M 参数就够了上 7B 模型反而浪费算力推理延迟还高。复杂推理任务才需要大模型。多轮对话、复杂指令理解、长文本生成这些7B 以下模型撑不住至少得 13B 起步70B 效果更稳。实际选型可以参考这个经验1分类、NER、简单问答1-3B 模型足够 2单轮生成、简单对话7B 模型性价比最高 3复杂推理、多轮对话13B-70B 模型看预算选 4追求极限性能70B或者 MoE 架构如 Mixtral基准测试要怎么看别只盯着一个指标。MMLU 高不代表代码能力强HumanEval 高不代表中文好。得看和你任务相关的 benchmark。做中文任务重点看 C-Eval、CMMLU 这些中文榜单做代码相关看 HumanEval、MBPP做数学推理看 GSM8K、MATH。还要注意基准测试的版本和评测方式。同一个模型0-shot 和 5-shot 差距可能有 10 个点不同 prompt 模板也会影响结果。官方报告的数字通常是挑最好的配置实际复现可能达不到。开源许可和商用限制这点很多人忽略上线前才发现不能商用就尴尬了。LLaMA 系列需要向 Meta 申请使用权且有用户数限制Mistral、Qwen 是 Apache 2.0 协议商用没问题一些模型声称开源但附带非商业条款比如 LLaMA 早期版本。如果是做商业产品建议选 Apache 2.0 或 MIT 协议的模型法律风险最小。快速验证的实践方法别一上来就全量微调先用小数据集 PEFT 快速验证几个候选模型。fromtransformersimportAutoModelForCausalLM,AutoTokenizerfrompeftimportget_peft_model,LoraConfig candidates[mistralai/Mistral-7B-v0.1,Qwen/Qwen2-7B,meta-llama/Llama-2-7b-hf]formodel_nameincandidates:modelAutoModelForCausalLM.from_pretrained(model_name,load_in_4bitTrue)# 快速 LoRA 微调peft_modelget_peft_model(model,LoraConfig(r8,target_modules[q_proj,v_proj]))# 用 1000 条数据跑 1 个 epoch30 分钟内出结果# 对比验证集指标选最好的再做全量实验一般跑 1000-2000 条数据训练 1 个 epoch就能看出哪个模型底子更适合当前任务。确定候选后再投入大量算力做正式微调。篇幅有限更多 AI 大模型面试题可以进入面试鸭进行查阅。