这次我们聊一个偏实战的话题怎么把 vibe coding 变成一套能用于技术面试的方法论。先说结论vibe coding 不是“用 AI 聊天写代码”也不是“让 AI 全部代劳”。它的核心是工程师在 AI 生成代码的过程中持续做需求澄清、任务拆解、代码审查、运行验证和缺陷修复。放在面试场景里它考察的真实能力是“候选人能不能在 AI 辅助下交付一个可运行、可验证、可后续维护的功能”而不是“候选人会不会用某个聊天窗口”。这套方法论的价值在于它可以同时服务面试官和候选人。面试官用它设计面试题、观察候选人的工程判断候选人用它做自测看看自己是不是真的具备 AI 时代的交付能力。下面我会拆解五个核心考察点给出一套可以直接复制的面试流程再用一个“待办事项 API”的完整案例把整个 vibe coding 过程演一遍最后补充评分维度、常见错误和合规边界。无论你在 Vercel 这类云端 AI 编程平台上实践还是在本地 IDE 的 AI 插件里完成方法论本身是一致的。1. vibe coding 面试专用方法论核心能力速览能力项说明方法论定位面试评估与候选人自测不绑定具体 AI 平台核心能力需求澄清、任务拆解、AI 生成、代码审查、运行验证、迭代修复适用岗位前端、后端、全栈、测试开发、AI 应用开发岗位面试节奏30 到 60 分钟完成一个小功能从需求到可运行交付标准功能跑通、关键逻辑可解释、能指出 AI 存在的问题常见误区把 vibe coding 等同于“会写提示词”或“复制代码”安全边界不替代 code review、安全审计和架构设计整套方法论的基本单位是“小步交付”每轮只让 AI 做一个足够小的改动改完立刻运行验证然后再进入下一轮。这样做的原因很现实——AI 生成代码的能力越强代码里可能存在的隐性错误也越多。如果一次让 AI 生成 500 行代码然后直接粘贴进入口一旦报错排查成本会远高于手写同样的功能。这套方法论也不要求候选人掌握某种特定 AI 工具。候选人可以自由选择对话式 AI、IDE 内联补全、云端编程工具甚至是本地私有化模型。面试官关注的是候选人能不能把工具的产出变成可靠的软件交付而不是工具本身多花哨。2. vibe coding 面试到底在考什么2.1 需求澄清能力AI 对自然语言的理解很强但它不会主动追问业务背景。候选人如果直接把一句模糊需求丢给 AI例如“做一个用户系统”得到的多半是一个看似完整、实则到处都是猜测的空壳字段名称靠猜、认证方式靠猜、权限模型靠猜。面试中真正值得关注的是候选人能不能在描述需求时补充边界条件比如“只需要演示用不接真实数据库”“登录部分暂时不做只做管理员增删用户”。这背后反映的是候选人的需求分析基本功而不是提示词技巧。2.2 任务拆解能力这是 vibe coding 面试中最容易拉开差距的环节。普通候选人会直接说“帮我写一个完整项目”有经验的候选人会把项目拆成先搭一个能返回健康检查的 Web 服务再实现第一个接口然后追加数据存储最后补充测试。拆解的意义在于把单次 AI 交互的失败成本降到最低。即使某一轮生成结果完全不可用损失也只是几十行代码而不是整段时间。2.3 代码审查与纠错能力AI 生成代码最麻烦的问题不是语法错误而是“语法正确但逻辑错误”。它会一本正经地编造不存在的第三方包、使用错误的标准库 API、遗漏异常处理、甚至把字段名前后写得对不上。候选人如果只看输出不审查代码就只能在面试官面前持续报错。面试中应该重点观察候选人拿到 AI 代码之后是先跑一遍还是先逐行确认关键逻辑遇到可疑 API 时是直接相信 AI还是去看官方文档2.4 运行调试能力vibe coding 面试不是纸上谈兵。候选人必须能把生成的项目在本地跑起来然后通过接口调用或页面操作验证功能。这个环节暴露的问题通常很真实有人能让 AI 生成飞快但不会安装依赖有人能写出一套漂亮的接口但根本启动不了服务。运行调试能力强的候选人会先把环境固定住再小步验证遇到报错先看日志再决定是让 AI 修复还是自己动手。2.5 安全与边界意识AI 生成的代码经常包含安全风险明文密码、拼接 SQL、把密钥硬编码、给接口加上不合理的权限控制。面试官需要看到候选人具备基本的安全直觉。一个加分回答是候选人主动说“这段 SQL 可能存在注入风险应该改成参数化查询”或者“这个配置文件里有 Token不能提交到仓库”。如果候选人完全信任 AI 输出任何安全提醒都由面试官提出那说明他在生产环境中可能埋下隐患。3. 面试题设计与整体流程3.1 题目设计面试题不要设计成“让 AI 做一个电商系统”这种题目太大无法在 30 分钟内完成。更好的方式是给一个小而完整的单模块需求例如做一个待办事项列表支持新增、标记完成、删除刷新后数据不丢失。做一个 Markdown 转 HTML 的小工具支持文本粘贴预览和下载结果。做一个天气查询接口接入某个公开 API返回结果做缓存。题目选择要看岗位方向。后端岗位可以选“待办事项 API”前端岗位可以选“带过滤功能的列表页面”测试开发岗位可以选“为一个已有接口补充测试用例”。核心标准是候选人能在 30 到 60 分钟内交付第一版可运行结果同时留下足够的变更多轮空间。3.2 流程模板环节时间建议要观察的内容需求理解3 分钟候选人是否主动澄清边界任务拆解5 分钟候选人是否先列出小步计划AI 生成10 分钟提示词是否清晰、有没有一次生成过多本地运行验证10 分钟能否安装依赖并启动服务代码走查10 分钟能否指出 AI 生成的缺陷需求变更10 分钟能否追加需求并完成迭代总结评分2 分钟候选人复盘是否到位这套流程的关键是“强制进入代码走查环节”。很多候选人完成运行验证后就直接交卷而面试官想知道的是他有没有意识到 AI 生成的代码存在哪些坑如果候选人把所有步骤都做完了却说不出来代码哪里可能出错那这个交付质量要打问号。3.3 面试官观察点面试官不要一直在旁边提示候选人怎么用 AI。最好的观察方式是给定初始需求后让候选人独立完成过程中记录他说的话和动作。例如候选人是不是一开始就说“我需要先确认几个问题”还是直接开始打字候选人遇到报错时会不会先看日志候选人追加需求时会不会把新功能拆成一个独立的增量任务。这些细节比最终代码是否漂亮更有参考价值。4. 实操演示一个待办事项 API 的完整 vibe coding 流程下面用一个后端岗位常见的面试题“待办事项 API”来演示整套流程。这里使用的代码只是示意实际 AI 工具生成的结果可能不完全相同但判断标准和审查思路是一样的。4.1 角色设定与任务拆解候选人拿到需求后应该先把任务拆成几个小步骤再开始问 AI。比如这样搭建 FastAPI 服务先提供一个/health接口确认服务能跑。实现创建和查询待办事项两个接口。实现标记完成和删除接口。补充必要的测试。然后向 AI 提出第一轮任务提示词可以参考下面这个模板你是一位 Python 后端工程师代码风格简洁清晰。 现在需要实现一个待办事项 API使用 FastAPI技术约束如下 - 使用内存存储先不接数据库。 - 提供 POST /todos 创建待办事项字段为 title。 - 提供 GET /todos 查询所有待办事项。 - 提供 PATCH /todos/{todo_id} 将待办事项标记为已完成。 - 提供 DELETE /todos/{todo_id} 删除待办事项。 - 提供 GET /health 健康检查接口。 - 返回的 JSON 结构保持一致字段使用 id、title、done。 请只生成 main.py 文件不要生成其他多余文件。提示词里包含了角色、任务、技术栈、接口定义、存储方案和输出约束。里面最重要的不是“请写得优雅”而是“请只生成 main.py 文件”——这能避免 AI 在首轮就生成一堆 init 文件、配置文件和 README把面试过程拉长。4.2 生成最小可运行版本AI 可能会生成下面这样一份代码。注意这份代码是示意代码真实 AI 输出可能风格不同但核心结构可以参考。from fastapi import FastAPI, HTTPException from pydantic import BaseModel from uuid import uuid4 app FastAPI() todos [] class TodoCreate(BaseModel): title: str class Todo(TodoCreate): id: str done: bool False app.get(/health) def health(): return {status: ok} app.post(/todos) def create_todo(todo: TodoCreate): item Todo(idstr(uuid4()), titletodo.title) todos.append(item) return item app.get(/todos) def list_todos(): return todos app.patch(/todos/{todo_id}) def mark_done(todo_id: str): for item in todos: if item.id todo_id: item.done True return item raise HTTPException(status_code404, detailtodo not found) app.delete(/todos/{todo_id}) def delete_todo(todo_id: str): for i, item in enumerate(todos): if item.id todo_id: todos.pop(i) return {ok: True} raise HTTPException(status_code404, detailtodo not found)这里需要给读者一个明确的判断标准第一版代码不需要完美只要满足“能启动、接口能调通、基本结构清楚”即可。候选人拿到代码后先不要急着东改西改先放到项目目录里然后进入启动验证。4.3 启动与功能验证把main.py保存后先安装依赖pip install fastapi[standard] uvicorn pytest然后启动服务uvicorn main:app --host 127.0.0.1 --port 8000 --reload启动无报错后用接口验证功能。这里建议使用 curl简单直观curl http://127.0.0.1:8000/health预期返回{status:ok}创建一条待办事项curl -X POST http://127.0.0.1:8000/todos \ -H Content-Type: application/json \ -d {title:完成面试复盘}预期返回{id:某个uuid,title:完成面试复盘,done:false}查询列表curl http://127.0.0.1:8000/todos这里有一个关键提示如果候选人发现创建后返回的字段和预期不一致不要直接让 AI 重写整个文件而是把报错信息或预期差异粘贴给 AI让它做定向修复。这是 vibe coding 中非常重要的迭代习惯。4.4 代码走查与审查要点运行通过不代表代码合格。候选人接下来应该主动做一次代码走查逐个确认下面几个问题AI 是否引用了不存在的依赖如果 AI 生成了from fake_library import something在安装依赖时就会暴露。PATCH 接口的实现是否严谨当前实现是一次性把整个Todo对象读出来再修改如果后续字段变多这种写法会逐渐失控。内存存储是否满足需求题目要求“刷新后数据不丢失”显然内存存储不满足这里就要引出持久化变更。有没有缺少异常处理例如创建待办事项时title为空字符串当前代码会直接放行应该提示校验。面试官这里要听的不是标准答案而是候选人有没有“主动审查”的意识。如果候选人直接跳过这一步等于把风险留给下一个接手代码的人。4.5 需求变更与修复迭代面试官可以在这个节点追加新需求考察候选人的迭代能力。比如这样说新的需求如下 1. GET /todos 支持按状态过滤例如 /todos?statuspending 只返回未完成事项。 2. 数据需要持久化到 SQLite服务重启后数据不丢失。 3. 补充 2 个 pytest 测试用例覆盖创建和过滤逻辑。候选人应该把新需求拆成“持久化”和“过滤”两个子任务而不是让 AI 一次性替换整个文件。一个可行的做法是先改数据存储层再改查询接口。import sqlite3 from fastapi import FastAPI from pydantic import BaseModel from uuid import uuid4 DB_PATH todos.db app FastAPI() def get_db(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row return conn def init_db(): with get_db() as db: db.execute( CREATE TABLE IF NOT EXISTS todos ( id TEXT PRIMARY KEY, title TEXT NOT NULL, done INTEGER NOT NULL DEFAULT 0 ) ) init_db() class TodoCreate(BaseModel): title: str app.get(/health) def health(): return {status: ok}这段代码同样不是唯一答案但至少引入了“数据库连接”和“初始化表结构”的概念。候选人需要自行决定是否让 AI 重写全部函数还是保留原有内存版本的接口逻辑、只替换存储实现。通常更稳妥的方式是把现有接口函数逐个改成读写 SQLite而不是整体重写。过滤逻辑可以这样实现app.get(/todos) def list_todos(status: str | None None): with get_db() as db: if status pending: rows db.execute(SELECT * FROM todos WHERE done 0).fetchall() elif status done: rows db.execute(SELECT * FROM todos WHERE done 1).fetchall() else: rows db.execute(SELECT * FROM todos).fetchall() return [dict(row) for row in rows]测试用例可以是一个独立文件test_main.pyfrom fastapi.testclient import TestClient from main import app client TestClient(app) def test_create_todo(): resp client.post(/todos, json{title: demo}) assert resp.status_code 200 assert resp.json()[title] demo def test_filter_pending(): resp client.get(/todos, params{status: pending}) assert resp.status_code 200 assert isinstance(resp.json(), list)运行测试pytest -q这个变更流程完整展示了 vibe coding 的常态AI 负责批量产出代码候选人负责定义验收条件、修正方向、确认测试通过。整个过程中AI 是执行者候选人才是决策者。4.6 候选人表现分层较弱表现拿到需求后立刻让 AI 生成完整项目然后完全信任输出功能跑不起来时不知道从哪查。合格表现会先拆任务能启动服务接口验证通过但对 AI 生成的代码缺少审查意识。优秀表现主动追问需求边界分小步迭代能指出 AI 代码中的坑追加需求时能按现有结构做增量修改并主动补测试。面试官可以用这套分层标准快速给候选人定位而不是只凭“代码最终能不能跑”来判断。5. vibe coding 方法论的六个关键维度第一最小可运行优先。任何需求都从最小的可运行版本开始先确认服务能启动、接口能返回再叠加功能。这样即使 AI 某轮生成质量很差损失也可控。第二增量迭代而不是一次成型。每轮只让 AI 做一个明确的改动改完立刻运行验证再进入下一个任务。项目规模一旦变大一次性生成的代码会迅速变成“运行不了的黑盒”。第三用运行结果验证 AI 输出。AI 生成的代码是否可用最终要由日志、接口返回和测试结果来证明而不是由 AI 自己的表述来证明。候选人在面试中频繁说“AI 说这样做没问题”是不加分的。第四把需求翻译成验收条件。比如“数据不丢失”是一个模糊需求落到技术上就是“服务重启后所有待办事项仍然存在”进一步可以写成一条测试用例。具备这种翻译能力的候选人才是真正理解产品的工程师。第五保留人工审查环节。vibe coding 不能替代 code review。面试官要明确告诉候选人AI 生成代码必须经过人工走查重点看依赖、异常处理、数据安全和并发问题。第六把“如何让 AI 不犯错”变成面试问题。面试官可以反问候选人“如果让你控制 AI 的犯错率你会怎么设计提示词”这个问题能逼出候选人真正的工程经验而不是表面上的聊天技巧。6. vibe coding 常见错误与排查现象可能原因排查方式解决方法AI 生成了不存在的包模型幻觉编造依赖运行安装命令看是否能解析让 AI 只使用已知依赖锁定版本代码启动报错Python 版本或依赖冲突查看完整报错堆栈固定 Python 版本使用虚拟环境接口返回 500未捕获异常或数据格式错误查看服务端日志补充异常处理核对返回结构功能运行后数据丢失使用了内存存储检查启动时是否写入文件或数据库改用 SQLite / 文件存储安全风险信任 AI 生成的 SQL 拼接走查代码搜索字符串拼接强制参数化查询需求越加越多缺少变更控制对比原始需求文档将变更写成新任务逐个完成提示词换来换去对模型输出缺乏判断标准明确每一步的验收条件先定义“怎么算完成”再写提示词一些候选人在面试中遇到的典型问题是AI 在一轮生成中引入了多个无关功能。比如候选人只让 AI 实现一个接口AI 却顺手加上了一个登录模块。这时候正确的做法不是重新开一局而是明确告诉 AI“当前任务只包含 X删除多余部分”。这本质上是在训练 AI 的输出边界也是面试官观察候选人项目管理能力的好窗口。7. 评分维度与人才判断评分维度建议权重识别方法合格标准需求澄清15%候选人是否主动追问边界能说清输入、输出和异常处理任务拆解20%是否把功能拆成小步每轮任务 30 分钟内可完成代码审查25%能否指出 AI 生成的逻辑缺陷至少发现 2 个真实问题运行调试20%能否独立跑通并定位报错服务启动、接口调用正常测试与边界20%是否补充测试和安全考虑有最小测试用例能说清边界这套评分维度不是让面试官打分后淘汰谁而是给双方一个共同语言。候选人如果能在代码走查环节主动说“这个接口没有做输入校验”在测试环节主动补一个空字符串用例哪怕最终功能没有完全跑通也是值得进一步考察的信号。因为 vibe coding 最大的风险不是 AI 写得不好而是人不知道怎么判断好坏。面试官还应该注意控制评分误差。AI 工具的随机性会导致候选人产出路径不同但方法论层面的能力是可比的。与其比较候选人最终生成了多少行代码不如比较候选人如何面对失败是持续追问 AI还是果断回滚重做还是自己动手修复。这三种反应对应着完全不同的工程性格。8. vibe coding 实践中的合规与安全边界vibe coding 在企业面试和技术评估中应用时必须兼顾合规安全与隐私保护。AI 生成代码很可能来自训练数据其中包含大量开源项目片段这带来潜在的许可证和版权问题。商用场景下团队需要确认最终代码的许可证合规性不能因为代码是 AI 生成的就不做来源审查。面试环境和日常开发也需要注意数据边界不要让 AI 工具访问包含客户端密钥、内部 Token、生产数据库地址的代码仓库。面试沙箱中尽量使用模拟数据不要引入真实用户信息。涉及人脸、声音、证件等敏感信息的项目要明确限制 AI 工具的输入范围。如果公司提供了内部 AI 编程工具或私有化模型优先走内部渠道。AI 生成的代码必须经过安全走查重点检查注入漏洞、硬编码密钥和越权接口。技术本身不区分好坏但如果把 AI 生成的代码直接部署到生产环境没有任何审查风险就会转移到真实用户身上。这也是 vibe coding 面试中值得纳入考察的一部分。候选人具备安全意识比单纯会使用某个 AI 工具更稀缺。9. 总结与下一步这套 vibe coding 面试方法论最值得尝试的点是把“会不会用 AI 聊天”拉回到“能不能交付功能”。面试官和候选人都应该清楚vibe coding 不是对工程能力的替代而是对工程判断力的放大。工具可以不断更新但需求澄清、任务拆解、代码审查、运行调试这些能力在任何 AI 工具出现之前和之后都成立。如果要在面试中开始试运行这套流程建议先做两件事第一把一个真实的简单需求写成候选人可以直接使用的任务描述第二亲自用 AI 工具把流程走一遍记录可能出现的错误和陷阱。面试官只有自己先暴露在 AI 生成代码的风险里才能设计出有区分度的题目。最容易踩的坑是把它做成一套“必须答对的八股题”。面试官如果按照提示词是否规范、是否使用了某个特定 AI 工具来打分就会漏掉真正重要的工程能力。记住方法论是评估框架不是考试答案。下一步可以继续扩展的方向包括多人协作场景下的 vibe coding 工作流、存量代码库改造中的 AI 辅助实践、以及 AI 编程产出物的自动化测试覆盖。这套方法论同样可以迁移到鸿蒙应用开发、云端全栈开发甚至硬件脚本场景只要底层逻辑是“人对 AI 输出负责”流程就不会过时。建议先把今天这套流程保存下来下次面试或自测时直接套用。