企业官网建设流程全解析

这次我们聊一个偏实战的话题：怎么把 vibe coding 变成一套能用于技术面试的方法论。

先说结论：vibe coding 不是“用 AI 聊天写代码”，也不是“让 AI 全部代劳”。它的核心是工程师在 AI 生成代码的过程中，持续做需求澄清、任务拆解、代码审查、运行验证和缺陷修复。放在面试场景里，它考察的真实能力是“候选人能不能在 AI 辅助下交付一个可运行、可验证、可后续维护的功能”，而不是“候选人会不会用某个聊天窗口”。

这套方法论的价值在于，它可以同时服务面试官和候选人。面试官用它设计面试题、观察候选人的工程判断；候选人用它做自测，看看自己是不是真的具备 AI 时代的交付能力。下面我会拆解五个核心考察点，给出一套可以直接复制的面试流程，再用一个“待办事项 API”的完整案例把整个 vibe coding 过程演一遍，最后补充评分维度、常见错误和合规边界。无论你在 Vercel 这类云端 AI 编程平台上实践，还是在本地 IDE 的 AI 插件里完成，方法论本身是一致的。

1. vibe coding 面试专用方法论核心能力速览

整套方法论的基本单位是“小步交付”：每轮只让 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 流程模板

这套流程的关键是“强制进入代码走查环节”。很多候选人完成运行验证后就直接交卷，而面试官想知道的是：他有没有意识到 AI 生成的代码存在哪些坑？如果候选人把所有步骤都做完了，却说不出来代码哪里可能出错，那这个交付质量要打问号。

3.3 面试官观察点

面试官不要一直在旁边提示候选人怎么用 AI。最好的观察方式是：给定初始需求后，让候选人独立完成，过程中记录他说的话和动作。例如候选人是不是一开始就说“我需要先确认几个问题”，还是直接开始打字；候选人遇到报错时会不会先看日志；候选人追加需求时会不会把新功能拆成一个独立的增量任务。这些细节比最终代码是否漂亮更有参考价值。

4. 实操演示：一个待办事项 API 的完整 vibe coding 流程

下面用一个后端岗位常见的面试题“待办事项 API”来演示整套流程。这里使用的代码只是示意，实际 AI 工具生成的结果可能不完全相同，但判断标准和审查思路是一样的。

4.1 角色设定与任务拆解

候选人拿到需求后，应该先把任务拆成几个小步骤，再开始问 AI。比如这样：

1. 搭建 FastAPI 服务，先提供一个/health接口确认服务能跑。
2. 实现创建和查询待办事项两个接口。
3. 实现标记完成和删除接口。
4. 补充必要的测试。

然后向 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(id=str(uuid4()), title=todo.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_code=404, detail="todo 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_code=404, detail="todo 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?status=pending 只返回未完成事项。 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.py：

from 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 实现一个接口，AI 却顺手加上了一个登录模块。这时候正确的做法不是重新开一局，而是明确告诉 AI“当前任务只包含 X，删除多余部分”。这本质上是在训练 AI 的输出边界，也是面试官观察候选人项目管理能力的好窗口。

7. 评分维度与人才判断

这套评分维度不是让面试官打分后淘汰谁，而是给双方一个共同语言。候选人如果能在代码走查环节主动说“这个接口没有做输入校验”，在测试环节主动补一个空字符串用例，哪怕最终功能没有完全跑通，也是值得进一步考察的信号。因为 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 输出负责”，流程就不会过时。建议先把今天这套流程保存下来，下次面试或自测时直接套用。