vibe coding 成为技术讨论的高频词以后很多技术团队真正发愁的不是没有工具而是不知道怎样评估一个使用 AI 编程工具的候选人。传统面试看候选人能不能凭记忆写出代码vibe coding 面试里AI 可以在几秒内生成一段可运行代码候选人面对的问题就从“怎么写”变成了“写什么、让谁写、怎么验证、出了问题怎么办”。如果还用旧评分表去衡量很容易出现一种荒诞结果候选人看起来很熟练代码也确实能跑但深问两句就露馅。本文要手捏一套可以用于真实招聘的 vibe coding 面试方法论包含能力模型、面试任务卡、提示词模板、评分表、追问清单和复盘模板。这套方法论不依赖任何特定平台适用于候选人被允许使用常见 AI 编程工具的场景也能帮你把“看起来会 vibe coding”和“真的会 vibe coding”区分开。1. 先想清楚vibe coding 面试到底要筛出什么1.1 vibe coding 重新分配了工程师的职责Vibe coding 的说法很直接开发者用自然语言描述需求AI 负责生成大量代码开发者再阅读、修改、验证并最终对结果负责。它不是什么神秘技术而是一种人机协作的开发方式。关键是这种方式把工程师的工作重心从“写代码”挪到了“定义问题和保护系统”。传统开发链路里工程师把一段自然语言需求翻译成语法正确、逻辑严谨的代码代码本身就是交付物。vibe coding 链路里AI 已经承担了大量机械翻译工作交付物仍然是代码但工程师的增值点变成了能否把模糊需求拆成 AI 能理解的指令能否判断 AI 的输出是偶然正确还是逻辑正确能否在错误发生时快速缩小范围能否守住安全、性能和可维护性底线。如果面试还是只看候选人能不能默写 API、能不能手撕排序那就是在考察一个 AI 已经能做得又快又好的环节。真正稀缺的能力是在 AI 生成的代码面前仍然能保持判断力的能力。1.2 传统算法面试与 vibe coding 面试的核心差异为了设计评分体系先要承认面试重心已经发生变化。下面这张表可以当作面试官的设计起点维度传统算法面试vibe coding 面试主要考察数据结构、算法、语言 API 熟练度问题定义、任务分解、验证、纠错、安全意识时间分配大量时间用来写代码大量时间用来设计 prompt、阅读代码、运行验证出错方式编译错误、逻辑错误上下文丢失、prompt 漂移、AI 幻觉、错误依赖评分依据测试用例是否通过行为过程是否可复现候选人能否解释关键选择防作弊方式代码查重会话记录加追问验证这里要特别说明调整重心不意味着放弃基本功。候选人如果连最基本的数据结构都不认识就不可能判断 AI 给出的哈希方案是否合理如果连 JSON 格式都看不懂就不可能验证 AI 生成的解析逻辑对不对。所以“会 vibe coding”的前提仍然是“能看懂并能守护代码”只是不再要求“从零写出所有代码”。1.3 核心评估对象是人与 AI 的协作品质从结果看AI 生成的最终代码只是一个产物。面试官真正要评估的是候选人如何指挥、验证并负责这段代码。可以观察几条典型行为候选人是否把模糊需求解析成了 AI 能理解的输入。候选人是否会在 AI 给出代码后自己先跑一遍。候选人报错时是否带着上下文和日志而不是只发一句“不行”。候选人会不会接受一个能跑但是不可维护的方案。候选人有没有对依赖来源、敏感信息、执行安全做检查。把这句作为整份方法论的主线评估对象不是“AI 生成的代码”而是“候选人如何与 AI 协作出一个可靠结果”。后续所有任务卡、评分表、追问设计都是为了产生可观察、可评分的行为证据。2. 搭建能力模型用五个维度定义“会 vibe coding”2.1 需求澄清能力实际项目需求经常只有一句话。若候选人直接把一句话丢给 AI通常得到“能用但不对”的代码。例如需求“把用户文件清洗一下”候选人需要追问文件格式是什么、清洗规则是什么、字段保留哪些、重复数据怎么处理、输出给谁用。这个维度在面试里很直观候选人拿到任务后是先复述业务目标、列出假设、明确验收标准还是立刻打开对话框开始写 prompt。优秀的候选人甚至会主动说“我先确认两个点如果没说明我就按约定方式处理”这比默默假设安全得多。2.2 任务分解与系统边界能力AI 擅长生成单文件和小型模块但不适合直接让它一次性产出完整系统。有经验的候选人会把功能拆成多个可验证片段先实现读文件再实现字段筛选再输出结果。每个片段完成后运行一下。更关键的是他们能判断哪些部分用 AI 划算哪些部分必须手写。比如核心算法、权限校验、支付金额计算这些应该由人来掌控而重复的模板代码、结构固定的格式转换可以交给 AI。能说出“这里我不想让 AI 写因为它容易忽略事务边界”的人比只喊着“AI 都能写”的人可靠得多。2.3 提示词设计与工具操作能力提示词不是越长越好。好的 prompt 通常包含角色、任务、输入输出样例、边界条件、禁止事项。候选人还要会利用 AI 编程工具的特性比如让 AI 先给方案再写代码主动控制上下文长度把报错信息完整贴回会话而不是凭记忆描述一个错误。行为证据包括候选人在 prompt 中给过输入输出样例吗。候选人清楚告诉 AI“不要引入第三方依赖”了吗。遇到编译错误时是把自己理解的错误原因告诉 AI还是直接把完整日志丢给 AI。候选人会不会说“先别写代码先给我三种实现方案”。这些细节最能体现候选人是不是真的长期使用 AI 协作而不是临时背了一套 prompt 模板。2.4 验证与错误定位能力这是最容易和“代码能跑”混淆的维度。代码能跑只能说明 AI 的输出没有语法错误不能说明逻辑正确。候选人能让 AI 生成一段代码但无法证明它正确唯一有效的证据是独立验证。所谓独立验证是候选人构造一个输入样例自己先算出期望输出再运行程序对比结果。例如清洗工具里有一条记录缺少 active 字段候选人有没有主动造出这条数据去验证工具不会崩溃。当报错出现时候选人应该缩小范围而不是盲目让 AI 重写整个文件。比如某个字段不存在导致报错候选人应该先定位到具体行确认是数据结构假设错了再决定改代码还是改 prompt。一个把 200 行报错直接丢给 AI 的人本质上是在盲试不是在调试。2.5 工程兜底与安全意识对 AI 生成的内容负责是 vibe coding 最容易出事的地方。AI 会建议安装某个依赖会给出一个可以执行但可能删除文件的命令也会在代码里悄悄写死敏感信息。面试中可以考察这样几点候选人是否检查 AI 建议的依赖安装命令和包来源。候选人是否会把生产数据、密钥、内部域名贴进 prompt。候选人是否在执行 shell 命令前先审查命令内容。候选人是否考虑输出文件覆盖、异常输入、进程退出码等问题。候选人是否能说明“这行代码在真实环境可能有什么副作用”。这类问题在真实项目里会造成事故所以必须纳入评分而不是当成加分项。2.6 五维能力模型速查表把上面五个维度整理成一张速查表方便面试官在面试中对照观察维度最差表现合格表现优秀表现需求澄清直接复制题目不确认任何假设能列出假设并确认用输入输出示例锁定验收标准任务分解让 AI 一次性生成全部代码能拆成 3 到 5 步并逐步验证识别出必须手写和必须人工检查的部分提示词设计一句话丢过去缺上下文有角色、约束、输入输出样例先要方案再要实现能主动管理上下文验证与错误定位报错就整段丢给 AI 重写自己构造样例并运行比对用日志和定位信息找到根因再修正工程兜底盲跑盲执行不检查副作用检查依赖和敏感信息设计异常处理、回滚和输出保护这张表不是最终评分卡而是给面试官在面试过程中使用的“观察线索”。面试结束后再根据实际行为证据打分。3. 设计面试流程准备、实战、复盘三阶段3.1 动手前要定好的三个约束任务复杂度、工具统一性、数据脱敏先处理环境问题否则面试结果会因为网络、账号、工具版本而失真。第一个约束是任务复杂度。建议控制在 30 到 60 分钟能完成的“单个小功能加几个边界条件”不要给完整系统。任务太大候选人会被细节吞没面试官也无法判断失败是能力问题还是时间问题。任务太小AI 一步就能生成五维能力没有观察窗口。第二个约束是工具统一性。尽量让候选人使用团队指定的 AI 编程工具或带会话记录功能的环境。如果候选人坚持使用自己的工具至少要打开共享屏幕和会话记录。这样做不是为了限制候选人而是为了获得可比较的过程证据。没有会话记录候选人说“我改了三轮 prompt”都无法验证。第三个约束是数据脱敏。不要使用生产数据也不要使用内部敏感字段。面试任务数据必须可以公开最好完全使用虚构数据。这既避免数据泄露风险也方便多个候选人使用同一份输入做横向比较。面试网络环境要提前确认避免候选人因为环境访问问题而发挥失常也避免把工具可用性问题错误计分到候选人头上。3.2 任务卡是评分工具不是题目描述很多面试官只发一句话题目比如“用 AI 写一个数据清洗工具”。这句话无法形成稳定评分。任务卡应该包含业务背景、功能要求、输入输出格式、约束条件、验收标准、提交内容。任务卡的意义在于它强制所有人面对同一套边界条件。面试官可以从任务卡里提前埋入几个坑比如“某条记录缺少某个字段”“输入文件不存在”“输出文件已经存在”再观察候选人如何应对。任务卡本身也是评分工具候选人会不会按验收标准自测有没有主动查询约束都会成为行为证据。3.3 一个最小可运行任务JSON 文件清洗命令行工具这里给一个可直接用于面试的任务卡模板你可以按团队实际需求替换字段和命令# 面试任务JSON 文件清洗命令行工具 ## 业务背景 你收到一批用户行为数据每条记录是一个 JSON 对象。 需要提供一个命令行工具从原始文件中筛选出有效记录并输出。 ## 数据样例 input.json: [ {id: 1, name: alice, active: true, score: 89}, {id: 2, name: bob, active: false, score: 42}, {id: 3, name: carol, score: 91} ] ## 功能要求 1. 支持通过 --fields 参数指定输出字段。 2. 支持过滤 active 字段等于 true 的记录记录缺少 active 字段时按 false 处理。 3. 输出为 JSON 数组保存到 out.json。 4. 如果输入文件不存在输出明确错误信息并返回非 0 退出码。 ## 约束 - 可以使用 AI 编程工具完成但需要保留完整会话记录。 - 运行环境只有 Python 3 和标准库不要新增第三方依赖。 ## 验收标准 - 对样例执行后能生成 out.json且字段和过滤结果正确。 - 对缺失文件场景能给出明确错误提示。 ## 提交内容 - 代码文件、out.json、说明文档、AI 会话记录。这个任务有几个设计点值得注意。第三条记录缺少 active 字段是一个故意埋入的边界条件。如果候选人直接让 AI 按“读取 active 字段”的逻辑写运行到第三条时可能报错。候选人有没有预先发现这个情况或者报错后能不能定位会直接反映需求澄清和错误定位能力。约束里要求“只使用标准库”是为了避免候选人让 AI 随意引入第三方包也顺便观察候选人是否关注依赖来源。提交内容包含 AI 会话记录是为了后续评分和追问有据可查。任务卡里还可以加上一条日常运行示例作为“输出正确”的判定基线python clean_data.py input.json --fields id,name --filter active这行命令不是候选人必须照抄的接口而是为了帮助面试官和候选人建立统一验收口径。如果候选人给出的参数设计不同只要能自洽并完成功能不要机械扣分。3.4 如何收集 AI 会话记录和 prompt不要只靠候选人“口头总结”过程那样很容易被叙述能力误导。收集证据的方式有三种使用支持会话历史共享的 AI 编程工具导出对话文件。要求候选人开启屏幕录制并保存关键片段。在没有会话记录时让候选人现场重放一个关键 prompt并接受面试官追问。如果候选人使用共享工具面试官可以在候选人演示后直接查看完整 prompt 链条观察第一版 prompt 和最后一版 prompt 的差异。差异越大说明候选人在过程中学会了表达完全没有差异说明可能已经提前准备好答案。下面是一个合格的 prompt 模板示例它包含了角色、任务、示例、边界和顺序控制你是一名经验丰富的 Python 开发者。 请帮我实现一个命令行 JSON 清洗工具。 任务要求 1. 读取 input.json。 2. 使用 --fields 指定输出字段。 3. 对没有 active 字段的记录按 false 处理。 4. 将结果写入 out.json。 输入样例 [{id:1,name:alice,active:true,score:89}] 输出样例 [{id:1,name:alice,score:89}] 边界条件 - 输入文件不存在时输出错误信息并返回非 0 退出码。 - 不要引入第三方依赖。 请先给设计方案再写完整代码。这里的关键不是让候选人背出同样的模板而是观察他们是不是知道“给输入输出样例”比写一百个字更有效。“请先给设计方案再写完整代码”这句话也很重要它能让候选人先想清楚结构避免 AI 一股脑生成一个不可维护的脚本。4. 评分机制把印象分改成证据分4.1 五档评分标准面试官最容易犯的错误是看到程序能跑就给出“看起来不错”的评价。为了避免印象分建议使用 0 到 4 分五档标准分数表现定义0无有效行为证据或直接拒绝执行或无法解释任何关键选择1有输出但完全依赖 AI无法解释代码不会验证2能完成基本功能但不澄清边界、不验证代码只对固定样例有效3能完成功能能构造样例自测能解释关键选择和边界处理4能主动澄清需求、分解任务、验证边界、定位 AI 错误并守住工程底线这个标准的核心是“证据”不是“感觉”。例如“候选人全程很顺畅”不是证据“候选人发现输入样例里有一条缺少 active 字段并主动追问怎么处理”才是证据。4.2 权重建议与评分理由五个维度不一定等权。推荐权重如下维度推荐权重理由需求澄清20%需求理解是一切协作的基础任务分解20%决定 AI 协作过程是否可控提示词设计15%体现工具熟练度但不是核心验证与错误定位30%最能区分“熟练”和“依赖”工程兜底15%影响生产质量和安全验证与错误定位权重最高是因为真实项目里 error 链路比 happy path 更暴露能力。一个能完成 Demo 却无法处理报错的候选人进入复杂系统后很难独立交付。4.3 可复用的评分表模板建议每次面试都填写固定评分表而不是只在心里打分。模板如下候选人___ 面试官___ 日期___ 任务JSON 文件清洗工具 使用工具___ | 维度 | 行为证据记录具体细节 | 得分(0-4) | | --- | --- | --- | | 需求澄清 | 例拿到任务后问“active 缺失是否按 false 处理” | 3 | | 任务分解 | 例让 AI 先实现读取和输出再单独处理过滤 | 3 | | 提示词设计 | 例prompt 中包含输入输出样例和边界条件 | 4 | | 验证与错误定位 | 例主动构造了缺少 active 字段的记录做验证 | 4 | | 工程兜底 | 例检查了输出文件是否覆盖已有文件 | 2 | 综合___ / 20 权重后得分___ 录用建议□ 强烈推荐 □ 推荐 □ 保留 □ 不推荐 风险点说明____评分表最重要的部分是“行为证据”列。面试官必须写下具体行为比如“候选人主动构造了一条缺少 active 字段的数据”而不是写“候选人比较细心”。“比较细心”是形容词无法校准具体行为才能让另一位面试官复核。4.4 痕迹记录与防漂移面试中存在典型的晕轮效应候选人第一个任务完成得很漂亮面试官就会在后面的维度上给出更高分反之如果候选人刚开始卡壳后面即使补救也可能拿不到合理分数。对抗漂移的方法是强制在评分表里填写证据后再打分先写证据后写分数。多位面试官背靠背评分后再讨论差异。差异最大的维度通常就是需要补充追问的维度而不是立刻选择相信某一方。另外一个常见问题是“会说话的人占便宜”。候选人表达能力好能把不熟练的过程讲得像深思熟虑候选人表达弱即使做了正确操作也可能被低估。所以追问不能只问“你怎么想的”还要问“你做了什么”“运行结果是什么”“你根据什么判断它正确”。5. 追问与验证避免“看起来会但实际不会”5.1 三层追问清单演示结束后面试官需要进入追问环节。追问不是挑刺而是验证候选人行为背后的理解。建议按三层进行第一层行为层你刚才让 AI 做了哪几步顺序是什么你给 AI 的 prompt 里包含哪些约束为什么这样写你让 AI 先给方案还是直接让它写代码第二层验证层你怎么确认 out.json 是正确的如果某条记录没有 active 字段程序会怎样你构造过哪些输入期望输出是什么实际输出是什么第三层复盘层AI 哪一次回答是错的你是怎么发现的如果让你重做你会改变哪一部分 prompt你觉得这个工具上线后最可能出问题的环节是什么只问一次不够。候选人可能背下标准答案但无法落到自己的实际行为上。追问时要引用他们刚才的操作细节“你刚刚让 AI 改了两轮第一轮报错是什么基于这个报错你为什么把 prompt 改成那样”这样能有效区分真实经验和口头包装。5.2 现场扰动改需求、加边界、强制失败候选人完成演示后面试官可以临时加需求。这是强度最高的验证方式因为候选人无法提前准备。比如对 JSON 清洗工具任务可以现场追加“现在要求同时支持 JSON 数组和 JSON Lines 两种格式。”“如果 score 是负数也要保留但需要在输出里增加一个 warning 字段。”“如果处理 100 万条记录你认为当前实现会在哪里遇到瓶颈”“如果 out.json 已经存在增加到交互式确认或备份逻辑。”观察重点不是候选人能不能马上改完而是他们怎么定位需要改的位置。一个真正理解代码的人能迅速指出入口函数、过滤逻辑和输出逻辑分别在哪里一个只依赖 AI 的人会把整个需求重新丢给 AI无法说明改动范围。5.3 常见误判与排查清单面试官自己也容易被某些现象误导。下面这张表可以作为误判排查清单误判现象可能原因检查方式处理建议候选人让 AI 写了大量代码但讲不清可能只是复制粘贴了现成方案随机挑一行让他解释这个判断在做什么代码可运行但无法解释最多给 1 到 2 分候选人不验证只提交 out.json不知道如何建立期望输出现场构造反例运行观察能否发现错误发现不了则验证维度降档prompt 很工整但过程像背出来的提前准备过模板新增一个完全不同的场景用扰动需求打破记忆看应变能力报错后直接整段丢给 AI缺乏定位能力限令“先告诉我错误行和原因再修改”执行后看是否具备根因分析意识所有代码都由 AI 生成没有手写不一定是问题但需要确认理解追问核心算法或边界条件只要能解释清楚就正常给分重点是理解不是来源这张表的核心逻辑不要因为“代码能跑”就给高分也不要因为“用了 AI”就质疑。评分依据永远是有没有理解、能不能验证、敢不敢负责。5.4 候选人可能出现的风险信号除了误判有些信号应该被重点记录但不要机械化一票否决把长段生产数据或疑似真实用户信息贴进 prompt。让 AI 执行未审查的 shell 命令比如直接接受删除文件或修改权限的指令。接受 AI 建议安装某个冷门依赖却说不清这个包是做什么的。对 AI 给出的错误依赖路径完全不质疑。被问到“这段代码有没有副作用”时只回答“AI 说没问题”。这些风险信号的意义在于候选人可能具有强烈倾向“信任 AI 输出”而不是“审查 AI 输出”。在真实生产环境中这种倾向会造成安全事故。面试官可以在复盘中综合判断特别是在招聘高级工程师或需要权限操作的岗位时要高度重视。6. 面试官复盘与长期最佳实践6.1 面试后 15 分钟复盘模板面试一结束面试官的印象就开始衰减所以复盘要趁热完成。建议每次面试后直接填写下面的模板任务名称___ 候选人编号___ 关键行为证据至少 3 条 1. 2. 3. AI 协作中的最大风险点 本次判分争议点 下次面试需要补充的追问 面试题是否需要修订□ 否 □ 是原因“最大风险点”不是“候选人不会写代码”而是更具体的判断比如“候选人倾向于直接信任 AI 的执行建议没有检查命令内容”。“判分争议点”则帮助团队在后续复盘会上对齐标准。6.2 面试题目版本化管理面试题目不是一次性材料。任务卡改动后新旧题目的评分结果不应该直接横向比较。建议把任务卡纳入版本管理。例如在文档目录中存放docs/interview/vibe-coding-task-json-cleaner-v1.0.md docs/interview/vibe-coding-task-json-cleaner-v1.1.md每次修订时记录变更原因是边界条件不够清楚还是 AI 工具能力变化导致任务变简单还是候选人经常在同一个地方产生歧义。如果题目发生变化已经使用旧题目面试的候选人的分数要单独标记避免和采用新题目的候选人直接对比。题目版本化还有一个额外好处可以沉淀团队对“AI 协作能力”的理解。随着面试次数增加任务卡里的边界条件和追问点会越来越精确逐渐形成团队自己的评估资产。6.3 把 vibe coding 评估嵌入日常工作而不是一次性考试面试只是入口真正判断一个人会不会 vibe coding还要靠日常观察。推荐在团队内部建立几条长期机制试用期第一个任务选一个小型内部工具要求候选人保留 AI 会话记录并在代码评审时说明哪些代码由 AI 生成、哪些经过人工修改。日常 Code Review 不禁止 AI 生成代码但要求提交者说明关键设计决策不只贴出 AI 输出。把常见 AI 错误案例沉淀成“AI 陷阱库”后续既可以用作培训材料也可以反向生成面试题。团队内部定期做“AI 代码评估会”每个成员对同一段 AI 生成代码做审查比较各自发现的缺陷和安全问题。这样做的价值在于面试结果不再是孤立事件而是和能力发展体系保持一致。候选人入职后的表现反过来也能验证面试评分表是否有效。6.4 长期迭代建议vibe coding 工具更新非常快面试任务和评分标准也需要定期更新。建议每季度做一次审查当前任务是否仍然适合五维能力观察还是因为工具自动化程度提高而失效。哪些边界条件已经变成 AI 默认处理不再具有区分度。新增的 AI 编程功能是否引入了新的风险点需要在评分表里补充。候选人的平均分数是否整体偏高如果是说明题目难度或评分尺度过松。同时也要保持一定稳定性不要频繁更换题目。稳定的题目才能积累足够的样本让评分标准逐步校准。对同一道题建议积累至少 10 份评分后再调整权重。手捏方法论听起来像临时起意但它的价值恰恰在于把模糊的人才判断拆成可以复现的流程。vibe coding 面试的最终问题不是“候选人有没有用 AI”而是“候选人有没有理解自己在做什么”。一个人可以不会背语法但必须能在 AI 给出的代码面前说清楚为什么可用、为什么不可用、出了问题如何兜底。把这些行为放进任务卡、评分表和追问清单里面试结果就不会只是一句“感觉还行”。下一步你可以从最小任务卡开始在下一场面试里试用两到三个维度再逐步补齐整个评分体系。这个过程中你会发现真正被筛选出来的不是“会用 AI 的人”而是“能和 AI 一起做出可靠系统的人”。