后续面试笔试还会考算法题吗先说我的判断27 届秋招里Vibe Coding 大概率会开始进入一部分公司的笔试和面试。但今年算法题还不能丢比较现实的情况是算法题和 Vibe Coding 一起考。至于明年会不会有公司率先砍掉传统算法题只保留 AI Coding我觉得有可能但现在还别赌。一、Vibe Coding 面试到底在考什么这类面试表面上是“现场让 AI 写代码”面试官实际看的是你能不能把需求问清楚、把代码管住、把结果验出来。Cursor、Claude Code 用哪个都行功能能跑起来也只是第一步。我把常见考察点归成 6 个。准备时可以拿它们逐项检查需求理解能不能先澄清目标、边界、角色和验收标准而不是拿到题目就开写。任务拆解能不能把大需求拆成 AI 可以独立完成、你也能逐步验收的小任务。上下文组织能不能把技术栈、接口约束、目录结构、数据模型和非功能要求说清楚。过程控制能不能限制 AI 的修改范围避免它顺手重构、重复造轮子或改变原有行为。验证能力能不能通过 Code Review、测试、日志和运行结果证明功能真的可用。工程判断能不能识别安全、性能、成本、合规和可维护性风险并知道什么时候必须由人接管。二、Vibe Coding 面试怎么准备2.1 先练熟一套固定工作流先问清楚确认用户、目标、输入输出、边界、非功能要求和验收标准。再做拆解把需求拆成小任务优先处理数据模型、接口契约和关键业务规则。分步交给 AI每次只让 AI 完成一个明确任务并限制文件范围和禁止修改项。每步都验收查看差异、运行测试、检查日志不要等全部代码生成后再统一排错。最后能复盘说明 AI 帮你节省了什么、它犯了什么错、你如何发现并修正。2.2 至少准备两个真实项目案例一个案例讲 AI 帮你提高效率另一个案例讲 AI 出错后你是怎么接管的。每个案例都可以按下面 5 个问题准备任务背景当时要解决什么问题AI 分工哪些工作交给 AI哪些由你完成关键约束你给了 AI 哪些上下文和限制错误与修正AI 出现了什么问题你怎么定位最终结果如何测试、验收并确认可以交付2.3 练习时重点补齐这 4 类能力代码基础看得懂 AI 生成的代码能独立定位常见错误。测试能力会设计正常、异常、边界、并发、性能和安全场景。系统设计知道状态机、幂等、缓存、限流、权限和数据一致性怎么落地。表达能力能把“为什么这么拆、为什么这样验收”讲清楚。三、Vibe Coding 高频八股这一部分来自公开面经和一些同学的反馈开发、测开、Agent 开发都用得上。别把参考回答背成稿先把思路说清再换成你自己的项目细节。3.1 AI 越来越强你的优势是什么回答思路这题别把优势说成“我更会写 Prompt”。面试官真正想听的是模型已经能写代码了你还能多负责哪一步。可以从问题定义、业务理解、工程判断、结果验证和责任边界里挑最能代表自己的两三点再接一个你发现上线风险的案例。参考回答我觉得我的优势是知道什么问题值得解决、什么结果才算真正可交付。比如做商品自动审核功能时AI 很快生成了违禁词匹配模块但我在测试中发现它没有处理大小写、全半角、特殊空格和拆字绕过另外如果把模型的低置信结果直接判为违规还会造成大量误杀。后来我把流程重新拆成文本规范化、规则检测、模型判断、置信度路由和人工复核并补了绕过、误杀和异常输入测试。AI 确实让我写得更快但需求边界怎么定、风险能不能接受、结果能不能上线还是得由我判断。我的优势就在这里知道哪些结果不能直接信。3.2 哪些工作可以交给 AI哪些必须自己做回答思路别按“写代码”和“不写代码”硬分。我更建议看三件事规则清不清楚、出错后能不能回退、结果有没有办法验收。低风险、重复性强的工作可以交给 AI碰到资金、权限、生产数据和业务取舍人必须拍板。参考回答如果让我用 AI 开发一个电商项目我会让它生成商品 CRUD、DTO、接口文档、测试骨架和重复性的参数校验因为这些任务输入输出清晰也容易通过测试验收。但库存扣减、订单状态机、支付回调、权限模型和生产数据变更我不会直接让 AI 自主决定。比如订单能否从“已确认”进入“已支付”背后涉及业务规则和资金风险我会先定义状态流转表、幂等规则和异常处理再让 AI 按规格实现。AI 可以提供候选方案和代码差异但最终方案选择、合并和上线决定必须由我完成。3.3 你怎么证明 AI 生成的代码是对的回答思路这个问题正好是测开的强项。别回答“我会让 AI 再生成一套测试”因为那还是 AI 自证。你要讲清楚验收标准从哪里来、代码怎么看、测试怎么覆盖以及完整链路怎么核对。参考回答以早餐店订单系统为例我不会先让 AI 写页面而是先整理一张状态流转表明确哪些状态允许转换、哪些必须拒绝例如“已确认”不能直接跳到“待取餐”。这张表就是后续验收标准。代码出来后我先看状态判断有没有散落在不同入口是否存在绕过服务端校验的路径。测试也不只跑正常链路两个终端同时改一张订单、服务重启、更新到一半失败这些都要故意打出来。最后再完整走一遍下单、接单、制作、取餐和支付同时核对接口、日志和数据库。只要有一步和最初的状态表对不上就不能算验收通过。3.4 AI 连续修改几次仍然报错怎么办回答思路连续几轮还在原地打转就别继续换 Prompt 了。把它当成一次正常的线上排障先停手保留当前差异做最小复现再根据日志判断是代码、数据还是环境问题。方向由人定AI 只做限定范围的修复。参考回答我遇到 AI 连续修改仍然报错时会先停止让它继续大范围改代码。例如增量数据同步任务出现重复写入AI 连续几次都在调整重试次数但问题始终存在。我会先冻结当前差异用两条数据构造最小场景并模拟“目标端写入成功、Checkpoint 保存失败”的异常。这个最小场景一跑问题就清楚了重试次数不是根因真正缺的是目标端幂等。修复时我会用唯一键或 Upsert 保证重复执行安全并要求一批数据确认成功后才能推进 Checkpoint。方案定下来以后再让 AI 只改相关文件补上故障注入和断点恢复测试。它卡住时人要重新定义问题不能陪着它继续猜。3.5 Vibe Coding 和 Spec Coding 有什么区别回答思路别背两个概念的定义直接拿两个任务对比最清楚。需求还在试、失败成本低可以多用 Vibe Coding订单、支付、权限这类功能规格和验收必须先定下来。参考回答如果只是快速验证一个内部报表页面我可能会采用 Vibe Coding先描述目标让 AI 生成可运行原型再通过几轮对话调整交互。这种任务风险低、修改可逆快速试错比一开始写完整规格更重要。订单、支付或权限功能就不能这么做。我会先定数据模型、接口契约、状态机、异常分支和验收用例再让 AI 分任务实现。实际项目里我通常先用 Vibe Coding 试方案方向确定后再用 Spec 把边界钉死。3.6 如何避免代码和数据泄露大厂一般已经有工具白名单和安全流程能不能用、哪些代码能进模型安全部门会提前划线。中小厂未必这么完善但面试官既然问了还是得把自己的处理原则讲清楚。回答思路回答别停在“我会脱敏”。要说清楚什么绝对不能上传、公司允许用什么工具、上下文怎么缩到最小以及 AI 输出进仓库前还要检查什么。参考回答如果我要让 AI 协助排查线上问题我不会直接上传生产日志、用户信息、数据库备份、密钥或完整私有仓库。我会先提取最小复现所需的日志片段对手机号、账号、订单号等字段脱敏并把配置中的密钥替换成占位符工具方面只使用公司批准的企业版或本地模型。AI 生成代码后我还会检查它是否写入调试日志、硬编码密钥、引入来源不明的依赖提交前再执行密钥扫描和依赖安全检查。如果无法确认某段数据能不能进入模型就默认不上传先走公司的安全和合规流程。3.7 需求很模糊时你会怎么让 AI 开始工作回答思路先别开 IDE。需求只有一句话时最值钱的动作是把未知项列出来让业务负责人确认。目标用户、输入输出、业务规则、异常分支和验收标准没有说清楚AI 写得越快返工越多。参考回答如果产品只说“做一个退款功能”我不会直接让 AI 生成接口。我会先让 AI 帮我列出未知项但答案必须由业务负责人确认例如是否支持部分退款、优惠券如何退回、重复请求如何幂等、退款失败如何补偿、谁有操作权限。这些问题确认后我会整理一页短规格里面放数据模型、接口契约、状态变化、异常分支和验收用例。AI 先交实现计划和文件清单我确认没有越界再让它动代码。这个步骤看起来慢一点实际能省掉后面的大量返工。3.8 如何构建上下文并避免 AI 的回答偏离问题回答思路上下文塞得多不代表效果好。只给当前任务真正需要的文件、接口和错误信息同时写清允许修改的范围、禁止事项和验收条件。对话已经跑偏时及时开新会话比继续补 Prompt 更有效。参考回答比如让 AI 增加用户注册接口我只会给它相关接口文件、用户表结构、错误码规范、现有测试写法和验收条件不会把整个仓库一股脑塞进去。修改范围也会写死只动用户模块不加新依赖不重构无关代码动手前先交方案和文件清单。每完成一步我都会把结果和验收条件对照。如果上下文已经混入多轮无关讨论我会重新开一个干净会话把确认后的规格、当前错误和最小相关文件重新提供避免 AI 继续沿着错误假设回答。3.9 你会怎么 Code Review AI 生成的代码回答思路这题最好说出自己的检查顺序。业务含义有没有做对放第一位后面再看安全、异常处理、并发、可维护性和修改范围。AI 自己写的测试只能当参考不能拿来给自己盖章。参考回答我先看代码做的是不是正确业务能运行不代表逻辑就对。接着查权限、输入校验、敏感信息、依赖和注入风险再看异常处理、并发、资源释放和日志。最后扫一遍差异确认它没有顺手重构无关模块、偷偷加框架或删掉兼容逻辑。例如审查违禁词检测模块时我会重点看大小写、全半角、特殊空格和拆字绕过白名单与误杀正则表达式性能规则版本更新日志脱敏以及检测服务超时时系统是放行、拦截还是转人工。完成审查后还要用我独立设计的边界和故障场景验证。3.10 AI 编程工具的 Token 和使用成本怎么控制回答思路别只说“压缩上下文”。成本控制还包括任务分流、一次把要求说清、复用已经验证过的模板以及连续几轮没进展时及时停手。贵模型留给真正难、真正高风险的部分。参考回答我会按任务难度分流。简单配置可能自己改更快模板代码可以交给便宜模型架构取舍、复杂调试和高风险 Review 再用更强模型。每轮只给当前任务需要的文件和报错需求与验收条件尽量一次写清避免对话越拖越长。团队里还可以复用已经验证过的提示模板、接口约定和测试清单。连续两三轮都没有缩小问题范围我会立刻停掉生成改做最小复现和人工定位。评估成本时也不能只看 Token还要把节省的人时和返工算进去。一个常见误区不要把“AI 做不了复杂业务”当成自己的优势。模型能力会继续提升真正稳定的优势是你能定义问题、控制风险、验证结果并在关键节点做出判断。四、Vibe Coding 真题实操下面几道题是我从公开面经和牛客内容里整理出来的。练习时别背整段答案至少要亲手跑一遍“澄清需求—拆任务—让 AI 实现—看代码—做测试”的过程不然面试官追问两句就容易露馅。4.1 美团 AI Coding商品自动审核系统题目商家提交商品后系统需要自动判断商品是否允许上架。请全程使用 AI 辅助完成方案设计与核心功能实现并回答下面的问题任务拆解把“商品自动审核”拆成至少 5 个可以独立执行的原子任务并标注每个任务的输入和输出。决策边界哪些任务不能完全交给 AI 自主决策说明原因。置信度路由设计高置信、中置信、低置信三档处理策略并说明如何进入自动通过、人工复核或自动拦截流程。代码审查AI 生成了违禁词检测模块合并前至少检查 5 项内容并说明每项对应的生产风险。测试设计至少设计 3 个边界场景并说明为什么选择这些边界。解题思路这题最容易答成一份审核流程介绍。真正要讲清的是每一步吃什么输入、吐什么结果、谁能拍板以及结果不确定时怎么转人工。置信度只是一个信号不能替代业务风险判断。参考回答一、原子任务拆解商品基础校验输入商品标题、描述、类目、价格、图片和商家信息输出标准化商品对象或字段错误清单。文本规范化输入标题与描述输出完成大小写、全半角、特殊空格、繁简体和拆字处理后的文本以及原文位置映射。违禁词与规则检测输入规范化文本、类目和规则版本输出命中规则、风险标签、证据位置和规则编号。图片与 OCR 检测输入商品图片输出 OCR 文本、图片风险标签、置信度和证据区域。类目与资质校验输入商品类目、品牌和商家资质输出资质是否齐全、缺失材料和类目冲突。模型风险判断输入文本、图片和结构化特征输出风险类型、置信度和可解释理由。路由与结果聚合输入规则命中、模型结果和业务风险等级输出自动通过、自动拦截或人工复核。审计与反馈输入审核过程、人工结论和申诉结果输出可追溯日志、误杀漏放样本和规则或模型优化数据。二、AI 不能自主决定的部分平台政策、违规阈值和处罚等级不能由 AI 自己制定涉及高价值商家、资质争议、处罚与申诉的决定必须由人工负责新型违规、证据冲突或低置信样本也不能直接自动判定。原因是这些决策涉及平台规则、法律合规、商家权益和不可逆损失AI 可以提供证据与建议但不能承担最终责任。三、基于置信度与风险方向的路由高置信安全没有命中硬规则、模型高置信判断安全时自动通过并保留抽检。高置信违规只有命中明确硬规则且证据完整时才自动拦截涉及封禁、扣款等处罚仍转人工确认。中置信调用第二套规则或模型复核结果一致且属于低风险场景可自动处理否则进入人工审核。低置信或证据冲突直接转人工不能把“模型不确定”误解成“商品违规”。四、违禁词模块 Code Review是否处理大小写、全半角、特殊空格、同形字、拼音和拆字绕过否则会漏放。是否支持白名单、上下文和类目差异否则“苹果”“枪色”等正常词可能被误杀。正则是否存在灾难性回溯超长文本是否有限制否则可能造成 CPU 飙高或服务阻塞。规则是否有版本号、热更新和回滚能力否则规则变更后结果不可追溯。并发读取与更新是否线程安全缓存是否会出现新旧规则混用否则同一商品可能得到不一致结果。日志是否记录命中证据但不泄露商家敏感信息否则会带来审计与隐私风险。规则服务超时或异常时是否有明确降级策略否则可能默认放行或全量拦截。代码是否修改无关模块、引入不必要依赖并具备监控指标和快速回滚能力。五、上线前测试空字段与缺失图片验证输入校验和异常提示避免空指针或默认放行。全半角、特殊空格、Emoji、同形字和拆字验证规避检测的典型方式。超长标题与描述验证性能、正则安全和截断策略。文字安全但图片违规验证多模态结果冲突时不会只看文本。OCR 模糊或模型恰好落在阈值附近验证边界值和人工路由是否稳定。模型超时、规则更新中断和并发审核验证降级、版本一致性及重复请求幂等。4.2 蚂蚁 AI Coding终端早餐店系统题目题目要求候选人在 AI 辅助下实现一个多终端 TUI 早餐店系统模拟从顾客下单到制作、取餐、支付的完整流程。系统包含三个终端叫号牌端端口 8024展示所有订单及当前状态顾客端端口 8025浏览菜单、创建订单店主端端口 8026查看订单、修改订单状态。订单状态要求按照规定路径流转待确认 → 已确认 → 制作中 → 待取餐 → 已支付↓ ↓已取消 已取消不能跳过中间状态例如不能从“已确认”直接变成“待取餐”。加分项包括使用持久化存储系统重启后订单不丢失增加基础权限控制只有店主能够修改状态设计清晰、易读的终端交互界面。交付物包括完整、可运行的项目代码测试脚本和测试结果安装、启动与使用说明。解题思路时间有限先保住下单到支付的完整链路。中央服务、数据模型和状态机先定下来三个终端能互相看到一致结果后再补持久化、权限和界面。别一上来就追求漂亮。参考回答一、架构选择我会使用一个中央 HTTP 服务保存菜单和订单三个 TUI 终端分别调用接口。技术上可以选择 FastAPI、SQLite 和 RichFastAPI 负责订单 API 与状态机SQLite 保证重启后数据不丢失Rich 用来快速完成终端界面。限时场景下先用短轮询同步数据不急着上 WebSocket因为轮询更容易实现、调试和验收。二、核心模型与状态机核心对象包括 MenuItem、Order、OrderItem、StatusHistory、User 或访问令牌以及用于并发控制的 version 字段。所有状态转换统一在服务端执行客户端只能提交“想转换到哪个状态”不能直接改数据库。服务端维护合法流转表并记录操作者、时间和前后状态。三、开发顺序先写数据模型、状态流转表、接口契约和验收清单。实现最小后端闭环查菜单、创建订单、查订单、合法修改状态。先完成一个最简单的终端模板验证网络、刷新和错误提示。复用模板完成顾客端、店主端和叫号牌端。补 SQLite 持久化、简单令牌权限、并发控制和启动脚本。最后完善测试、README 和界面细节。四、如何使用 AI我不会让 AI 一次把三个终端全写完。先让它交架构、目录和风险点我确认以后只做后端核心接口接口跑通再做一个终端模板其余两个照着扩。每一轮都写清可修改文件和验收条件比如非法状态必须返回明确错误。这样出问题时至少知道是哪一步坏了。五、重点测试完整下单、确认、制作、取餐和支付链路。从已确认直接跳到待取餐、已取消后继续流转等非法路径。同一请求重复提交验证创建订单和状态更新的幂等性。两个店主终端同时修改同一订单验证 version 或乐观锁冲突处理。服务重启后订单与状态历史仍然存在。顾客尝试修改订单状态、令牌缺失或错误时必须被拒绝。中央服务不可用时三个终端能够提示错误并继续重试而不是直接崩溃。取舍说明考试里我会优先提交“粗糙但完整”的闭环。WebSocket、复杂认证和精细动画可以写进后续规划但不能以牺牲状态机、测试和可运行性为代价。4.3 快手面试如何用 AI 从零开发电商项目假设让你使用 AI 编程工具从零完成一个简化版电商项目请说明你会如何拆解需求和安排开发顺序哪些信息需要提前提供给 AI如何限制 AI 的修改范围避免过度设计如何确认 AI 实现的功能符合原始需求你会设计哪些测试和异常场景Spec Coding 和 Vibe Coding 有什么区别如果 AI 连续生成错误方案你会如何接管解题思路开场先主动砍需求。电商项目什么都能做但考试时间不够第一版只保留最小交易链路。后面的回答围绕这个 MVP 展开重点让面试官看到你怎么限制 AI、怎么验收订单和库存。参考回答一、先定义 MVP第一版我只做商品浏览、购物车、创建订单、库存扣减和模拟支付。推荐、优惠券、退款、复杂运营后台先不碰。原因很简单先把“选商品—下单—扣库存—支付”跑通别让 AI 看到“电商项目”四个字就给你搭一套大系统。二、开发顺序确认用户、商品、库存、订单和支付五个核心对象。确定接口契约、订单状态和库存扣减规则。先实现后端核心链路和数据库约束。再实现商品页、购物车和订单页并完成前后端联调。最后补单元测试、接口测试、端到端测试、启动说明和验收记录。三、提供给 AI 的上下文我会明确技术栈、目录结构、数据模型、相关文件、接口输入输出、错误码、代码风格和验收条件。每轮只交付一个任务并写清允许修改的文件、禁止新增的依赖、不能改变的公共接口和需要输出的测试结果。四、如何避免过度设计先让 AI 输出实现计划和预计修改文件不直接写代码明确“不引入新框架、不重构无关模块、不增加规格之外的功能”。如果它提出缓存、消息队列或微服务我会要求说明当前业务量下的必要性没有明确收益就不采用。五、如何验收我会建立需求到测试的对应表每条需求至少有一个正常用例和一个异常或边界用例。除了运行 AI 生成的测试还要独立审查金额精度、库存并发、订单幂等、支付回调重复、权限和异常回滚并跑一次完整端到端链路。六、重点异常场景两个用户同时购买最后一件商品库存不能扣成负数。创建订单请求或支付回调重复到达不能生成重复订单或重复支付。商品下架、价格变化或库存不足时购物车与结算结果要一致。支付成功但本地更新失败时要有补偿或对账机制。金额使用精确小数处理不能直接用浮点数造成误差。七、Vibe Coding、Spec Coding 与人工接管原型期可以用 Vibe Coding 快速探索页面和交互进入订单、库存和支付实现后应先固化接口、状态机和验收标准用更接近 Spec Coding 的方式交付。如果 AI 连续几轮没有缩小问题我会停止生成、回退无效差异、构造最小复现并人工定位根因再把明确的修复方案交给 AI 做限定范围的修改。4.4 阿里千问 Vibe Coding高性能增量数据同步 CLI题目使用 AI 编程工具实现一个高性能增量数据同步 CLI 工具。公开面经记录的面试官追问包括项目里的核心功能有哪些高性能是如何实现的如何避免 AI 的回答偏离问题延伸练习任务中断后如何恢复怎样验证断点续传、数据一致性和并发性能解题思路先追问“增量”和“高性能”到底怎么量数据从哪来、写到哪、允许重复还是允许丢。指标不清楚就谈架构基本都会跑偏。方案里至少要交代恢复点、幂等和对账不然吞吐再高也没用。参考回答一、先澄清需求我会确认数据源和目标端类型、数据规模、延迟与吞吐目标、是否需要同步删除、失败后允许重复还是允许丢失以及目标端是否支持幂等写入。通用工具很难凭一句话承诺严格 Exactly Once我会优先设计为 At Least Once 加目标端幂等并通过 Checkpoint 和对账保证可恢复与可验证。二、核心模块CLI 与配置解析连接信息、批大小、并发度、起止位置和过滤规则。Source Adapter从 CDC、时间戳加主键游标或哈希扫描中读取增量。Transformer字段映射、过滤、校验和数据清洗。Sink Adapter批量写入、Upsert 和删除同步。Checkpoint记录已确认的位置支持中断恢复。Retry 与错误隔离指数退避、错误文件或死信记录。Metrics 与审计吞吐、延迟、失败数、积压量和一致性对账。三、高性能怎么实现性能先从批处理做起把读取、转换和写入拆开用有界队列控制背压。网络和磁盘操作再考虑异步 I/O、连接池批大小和并发度都留成配置项。具体开多少不能拍脑袋得压测。看结果时也别只盯吞吐错误率、P95 延迟、内存和目标端压力要一起看。四、正确性与恢复只有一批数据在目标端确认成功后才推进 Checkpoint目标端使用唯一键或 Upsert 保证重试安全部分失败时保留失败记录不让整批静默丢失重启后从最近确认位置继续。完成同步后用条数、主键范围、抽样哈希和差异清单进行对账。五、如何避免 AI 跑偏我会先写一页需求和验收说明让 AI 每次只做一个模块动手前交差异计划完成后跑对应测试。它如果建议加缓存、消息队列或别的组件必须说清楚现在遇到了什么瓶颈、加完怎么验证。不能因为题目写了“高性能”就默认把架构搞复杂。六、测试与压测写入成功但 Checkpoint 保存前进程退出重启后不能丢数据。重复、乱序和删除事件能够得到确定结果。批次部分失败时成功数据不重复破坏失败数据可重试和追踪。目标端变慢时能够触发背压内存不会持续上涨。大数据量下记录吞吐、P95 延迟、CPU、内存和错误率。同步完成后执行源端与目标端一致性对账。