8. 从零到一 AI Coding 面试高分 Prompt 手册
title: 从零到一 AI Coding 面试高分 Prompt 手册 created: 2026-09-16 updated: 2026-09-16 tags:
- AI编程
- 提示词
- 面试
- VibeCoding
- 从零到一
[!note] 📎 姊妹篇 本文是《[[7. AI Coding 面试高分 Prompt 手册]]》的从零到一（Greenfield）专用版。那一篇讲"在已有代码上做功能改造"，这一篇讲"面试官只给一句话需求、没有代码库、从空目录开始实现"。两者工作机制差别很大，建议对照阅读。
从零到一 AI Coding 面试高分 Prompt 手册
适用于允许使用 AI 编程工具、题目为"从零实现一个东西"的前端、后端、全栈和原型开发面试。
从零到一的题目，最诱人也最危险的姿势就是：把题目原封不动丢给 AI，让它"帮我写一个完整的 XX 系统"。 结果通常是：AI 兴奋地铺开二十个文件、引入五个你没把握装上的依赖，十五分钟后你得到一个既跑不起来、你也讲不清的项目。
从零题考的不是"能不能生成代码"，而是三件事：
- 你能不能把一句模糊需求收敛成可交付的 MVP；
- 你能不能在无历史包袱的情况下做出并解释技术选型；
- 你能不能先让它跑起来，再一圈一圈长出来。
稳定的工作循环：
定边界 → 砍 MVP → 定选型 → 骨架先跑 → 定契约 → 排实现顺序 → 小步长肉 → 验证 → 审查 → 演示汇报
一、两种玩法：从零到一 vs 改造现有代码
很多人在从零题上翻车，是因为套用了"改代码"的习惯。先看清差别：
| 维度 | 改造现有代码 | 从零到一 |
|---|---|---|
| 事实来源 | 代码库本身就是事实，先读再动 | 只有一句题目，事实要你自己建立 |
| 主要风险 | 破坏既有行为、踩坏调用方 | 做不完、跑不起来、过度设计 |
| 架构决策 | 沿用现有约定，决策成本低 | 你得现场定，并且讲得出为什么 |
| AI 的典型失效 | 虚构不存在的函数/文件 | 生成巨型脚手架、引入装不上的重依赖 |
| 验证方式 | 跑既有测试 | 你得自己定义"能跑"并证明它 |
| 时间杀手 | 理解陌生代码 | 装环境、选型摇摆、返工数据模型 |
| 高分关键 | 最小 diff | 最小可运行切片 + 清晰取舍 |
一句话区别：改造题考"别碰坏东西"，从零题考"别造多余的东西"。
二、面试官在从零题里真正看什么
| 能力 | 高分表现 | 低分表现 |
|---|---|---|
| 需求收敛 | 主动砍需求，说清 MVP 和非目标 | 题目说什么就全做，最后一样没做完 |
| 提问能力 | 开场 3 分钟问清用户、持久化、形态、限制 | 闷头开写，做完了才发现方向错 |
| 技术选型 | 2 个方案对比后拍板，讲清取舍 | AI 推荐什么用什么，答不出理由 |
| 架构骨架 | 先定目录、数据模型、接口契约，再排实现顺序 | 想到哪写到哪，中途反复推倒 |
| 先跑起来 | 第 10 分钟左右、最晚第 16 分钟有一条端到端可运行路径 | 半小时还在搭脚手架 |
| 小步推进 | 每步都能运行、都能演示 | 一次性生成整个项目再调试 |
| 验证能力 | 种子数据 + 手动路径 + 测试都有证据 | "应该能跑吧" |
| 边界与错误 | 覆盖空、非法、重复、失败路径 | 只做 happy path |
| 沟通能力 | 全程说明在做什么、为什么砍 | 全程沉默，AI 输出即最终答案 |
| 时间管理 | 宁可少一个功能，也要可演示 | 前半程铺摊子，最后没有可运行成果 |
一句话原则：从零题里，你的价值是"决定做什么、不做什么、以及为什么"，不是打字速度。
三、万能 Prompt 结构（从零版）
从零题的 Prompt 要补上改造题没有的两块：使用者与场景、技术选型。
▼text复制代码目标：一句话说清用户最终能完成什么。 场景：谁用、在什么环境下用、使用频率与规模。 范围：MVP 必须做什么，明确不做什么。 选型：语言、框架、存储、运行方式，以及为什么。 约束：依赖限制、时间限制、代码风格、安全红线。 验收：可观察的完成标准 + 演示路径。 工作方式：先出方案还是直接写、每步如何验证、最终如何汇报。
可直接复制的总控 Prompt（从零版）
▼text复制代码你是我的结对编程助手。当前目录是空的，我们要从零实现一个项目。请帮我快速交付一个 可运行的最小版本，但不要替我做未确认的产品或架构决定。 【用户与场景】 <谁在用，核心使用场景是什么，规模多大> 【MVP 必须做到】 - <核心功能 1，必须是能演示的一条完整路径> - <核心功能 2> - <关键边界条件> 【本轮明确不做】 - 登录/权限/多用户 - 数据库迁移、消息队列、缓存、容器化 - 国际化、主题、移动端适配、导出功能 - 任何需要联网申请 key 的第三方集成 【技术选型（已定，不要推翻）】 - 语言与运行时：<如 Python 3.11 / Node 20 / Java 17 + Spring Boot> - 框架：<如 FastAPI / Express / Spring Boot> - 存储：<内存 / 本地文件 / SQLite> - 测试：<pytest / vitest / JUnit> - 启动方式：一条命令，如 `npm run dev` 【工程约束】 - 优先标准库和我已熟悉的依赖；新增依赖必须说明理由和替代方案 - 依赖必须能在 5 分钟内安装完成，否则换方案 - 目录结构扁平清晰，不要过早抽象分层 - 显式处理输入校验、空状态、错误状态和重复操作 - 不要生成 README、CI、Dockerfile 等本轮用不上的文件 【验收标准】 - <可观察结果 1，例如：POST /tasks 后 GET /tasks 能看到它> - <可观察结果 2> - 一条命令能启动，并能用我给的演示路径走通 【工作方式】 1. 先用不超过 5 行复述你要建的东西，并列出你的假设。 2. 输出目录结构和启动命令，我确认后再写代码。 3. 第一步只做"能启动 + 一条最小端到端路径"，跑通后停下汇报。 4. 定完数据模型和接口契约后，先给出按依赖排序的实现步骤清单，我删减确认后再动手。 5. 之后每步只实现一个能力，每步结束都要能运行、能演示。 6. 完成后审查全部代码，并按"结果、证据、取舍、未完成项"汇报。
[!tip] 为什么"本轮不做"要写得这么狠 从零题里 AI 的默认倾向是补全一个"完整工程"：登录、权限、Docker、CI、README 全给你安排上。这些东西每一个都在偷走你的面试时间，而且面试官不会因为文件多给你加分。先把它们列进黑名单，AI 才不会自由发挥。
四、MVP 砍需求三刀 + 选型定桩卡
4.1 砍需求三刀
拿到题目，先砍三刀再动手，把"一个系统"砍成"一个能跑的切片"：
| 刀 | 砍什么 | 换成什么 |
|---|---|---|
| 第一刀：砍角色 | 多用户、多角色、权限体系 | 只有一个使用者，不做登录 |
| 第二刀：砍持久化 | MySQL/Redis/消息队列 | 内存、本地文件或 SQLite |
| 第三刀：砍集成 | 第三方 API、支付、短信、对象存储 | 本地 mock / 假数据 / 固定返回 |
砍完还剩什么？一条从输入到输出的完整路径。这就是 MVP。
砍需求不是偷偷少做，而要当着面试官的面砍：
我先把范围收敛一下：本题核心是 XX，所以我第一轮只做单用户、内存存储、命令行/单页交互，登录、持久化和导出我列为非目标。如果您更想看其中某一项，我可以换进来。
这句话本身就是加分项——它证明你在管理范围，而不是被题目牵着走。
4.2 选型定桩卡
从零题里最贵的错误是选型跟着 AI 漂流：AI 说用 Next.js 就用 Next.js，最后你连为什么要 SSR 都答不上。
动手前先填完这张卡（写进 Prompt，也写进代码注释或项目根目录的 NOTES.md——不要为了它单独生成一个 README）：
▼text复制代码【选型定桩卡】 - 语言/运行时： - 框架： - 存储： - 是否要界面（CLI / 单页 / 全栈）： - 测试方式： - 启动命令： - 选它的理由： - 我放弃的方案及原因： - 这个选型的已知局限：
三条硬规矩：
- 只用你能在 5 分钟内装好的东西。 面试环境网络不确定，装不上的依赖等于自杀。
- 优先你真正熟悉的栈。 从零题要的是"能讲清楚"，不是"看起来先进"。
- 选型一旦定桩，中途不许换。 中途换栈是从零题最常见的时间黑洞。
五、面试现场 Prompt 链
0. 开场三分钟：先问面试官（不是问 AI）
▼text复制代码我想先确认几个会影响架构的问题： 1. 这个东西的核心用户是谁？最典型的一条使用路径是什么？ 2. 需要持久化吗？重启后数据要不要还在？ 3. 交付形态有要求吗？命令行、接口，还是需要页面？ 4. 语言或框架有限制吗？ 5. 这轮时间大概多少？您更想看完整功能，还是看我的工程过程？
高分点：从零题里提问质量本身就是评分项。问完立刻用一句话复述："所以我要做的是 XX，对吗？"
1. 把题目压缩成 MVP 规格
▼text复制代码请把下面这道面试题压缩成一个 60 分钟内能做完并演示的最小规格，不要扩展需求。 【题目】 <原题> 输出： 1. 一句话用户目标； 2. 3～5 条可观察的验收标准（每条都要能演示出来）； 3. 一条完整的端到端演示路径（从输入到可见输出的具体步骤）； 4. 正常路径、空状态、错误输入、重复操作分别怎么处理； 5. 本轮明确不做的内容，以及你建议我向面试官确认的取舍； 6. 仍存在歧义的地方。 不要开始写代码。
2. 技术选型：让 AI 给两个方案，你拍板
▼text复制代码基于上面的规格，给出两个能在 <语言/环境> 下 60 分钟内跑通的技术方案。 每个方案请说明： - 目录结构（不超过两层）； - 依赖项清单，以及安装耗时和失败风险； - 数据如何存储与传递； - 最可能卡住的地方； - 与另一个方案相比的取舍。 最后给出你的推荐及理由。我只需要推荐方案的目录结构和启动命令，暂时不要写代码。
拿到结果后你做三件事：删依赖（能不用就不用）、压层级（目录不要超过两层）、确认启动命令（必须是一条你真能执行的命令）。
3. 骨架先跑起来（Walking Skeleton）
这是从零题最关键的一步：在写任何业务逻辑之前，先让一个空壳端到端跑通。
▼text复制代码现在只做骨架，不要实现任何业务逻辑。 目标：一条命令启动后，能走通"输入 → 处理（可先返回固定值） → 输出"这条链路。 要求： - 按确认的目录结构创建文件； - 每个文件都要有明确职责，暂时没内容的用占位实现并标注 TODO； - 提供明确的启动命令和验证方式（例如 curl 一行、或一个可点击的页面路径）； - 不要引入测试框架之外的任何新依赖； - 不要写 README、Dockerfile、CI 配置。 完成后停止，汇报：创建的文件、启动命令、我该如何验证它真的跑起来了。
[!important] 没有跑起来之前，不要写第二个能力 从零题最大的时间黑洞是"写了一堆文件，第一次运行时同时暴露十个错误"。 骨架跑通之后，每一圈加一个能力，任何时刻你都有一个可演示的版本——这是你面对面试官的底气。
4. 数据模型 / 接口契约先行
[!question] 为什么骨架跑通了才定契约，而不是反过来？ 因为两步要解决的问题不同：骨架验证"能不能跑"（环境、依赖、启动命令是否 OK），契约定义"跑的东西长什么样"（字段、接口、边界）。 在环境还没验证时就花 5 分钟设计数据模型，一旦技术栈跑不起来，这份契约就白做了。所以顺序是：先让空壳跑通，再往空壳里填真正的数据结构。 只有一种例外：如果题目本身就是数据密集型（报表、ETL、建模题），可以把契约提到骨架之前，因为数据模型就是这类题的骨架。
▼text复制代码在写业务逻辑前，先把数据和契约定下来。 输出： - 核心数据实体、字段、类型与约束（用类型定义或表结构表示）； - 实体之间的关系； - 接口清单：方法、路径、入参、成功响应、失败响应； - 每个字段的边界：必填/可选、空值、非法值、长度或范围上限； - 哪些字段是本轮不需要的。 定完后等我确认。如果后续实现需要改动契约，先告诉我改动原因，不要直接改。
高分点：从零题里返工数据模型 = 返工一半代码。先定契约，后面才有资格小步快跑。
5. 让 AI 排出实现顺序，你删减后拍板
骨架跑通、契约定好之后，AI 知道"要建什么"了，但还不知道"按什么顺序建"。这一步必须补上——顺序错了会导致反复返工（比如先写列表页再补创建接口、先上持久化再改数据结构），而每次返工在面试里都是不可逆的时间损失。
▼text复制代码基于已确认的数据模型和接口契约，把 MVP 拆成一份有序的实现清单。 要求： 1. 按依赖关系排序，每一步只产出一个可演示的能力（不要出现"第 3 步：完成所有接口"）； 2. 每步列出：目标能力、要改/新建的文件、依赖的上一步、验证方式（能跑什么命令或走什么路径证明它生效）； 3. 标出每步最可能失败的地方，以及失败后的回退方案； 4. 给出步骤之间的取舍：哪些是必做，哪些是"时间有余再做"，哪些可以合并； 5. 明确告诉我：如果只剩 20 分钟，应该做到第几步停下来最稳； 6. 步骤不超过 6 步，超过说明拆得不够聚焦； 7. 暂时不要写任何代码。 输出格式：编号步骤 + 一句话目标 + 验证方式 + 必做/可选标记。
拿到清单后，你要做三件事，不要直接批准：
| 动作 | 具体做法 |
|---|---|
| 删 | 划掉任何"锦上添花"的步骤（导出、排序、搜索、美化），它们不是 MVP |
| 并 | 把两个 5 分钟能一起做完的小步合并，减少来回确认的开销 |
| 排 | 把风险最高、最能暴露架构问题的步骤往前挪——早失败比晚失败便宜 |
然后向面试官同步这份清单，这本身就是加分项：
我按依赖排了个顺序：1 内存存储层 + 创建接口，2 列表与详情，3 编辑与删除，4 边界与错误处理。前 3 步是必做，第 4 步之后是时间允许项。如果时间紧，我做到第 3 步停下，仍然是一个可演示的 Demo。
[!important] 这份清单是你和面试官的"进度契约" 从零题最怕的不是做不完，而是做完了三件半成品、一件都不能演示。清单按"每步可演示"来排，你随时停下都有一个能跑的版本；面试官也能提前知道你在第几步、还剩多少。
6. 小步长肉：一次只加一个能力
▼text复制代码现在实现第 <N> 步：<该步的能力>（不要实现后面的步骤）。 约束： - 只改实现这个能力必需的文件； - 保留 TODO 占位，不要顺手实现后面的能力； - 显式处理空输入、非法输入、重复操作和依赖失败； - 补一个能证明这个能力生效的检查（测试或可复现的手工步骤）； - 每改完立刻用启动命令验证服务仍然可运行。 完成后停止，汇报：改了什么、怎么验证、下一步是什么、当前还剩哪些 TODO。
[!tip] 每步跑通就提交一次（git）
git init之后，每完成一个步骤就git add -A && git commit -m "step N: xx"。三个好处： ① 改崩了能一步回退到上一个可运行版本，不用让 AI 反向修复； ② 面试官能看到你的推进轨迹，而不是最后一大坨代码； ③ 最终汇报时可以直接说"我做到第 3 步，第 4 步之后是可选"。 从零题里这是成本最低的保险，别嫌麻烦。
7. 精准 Debug（从零版特供：先怀疑环境和依赖）
▼text复制代码出现下面的失败： 【复现步骤】 <如何稳定复现> 【实际结果】 <报错、日志、失败测试或页面现象> 【预期结果】 <正确行为> 先不要改代码。请按这个顺序排查： 1. 环境问题：依赖是否真的装上、版本是否匹配、启动命令是否正确； 2. 契约问题：数据形状、字段名、类型是否和前面定下的契约一致； 3. 逻辑问题：从报错点向上追踪调用链，提出最多 3 个根因假设并排序。 对每个假设给出可证伪的最小检查。选出证据最强的一个，给出最小修复和防止回归的测试。 不要用吞掉异常、删除断言、硬编码结果或"先注释掉"的方式绕过问题。
从零题的坑一半在环境和版本，不在逻辑。报错先问"装上了吗、版本对吗、命令对吗"，能省大量时间。
8. 种子数据 + 边界测试
▼text复制代码为演示和测试准备种子数据，并补齐边界测试。 1. 生成一组能覆盖核心展示场景的种子数据（含一条"看起来正常"、一条"空/极少"、一条"超长或异常"）； 2. 给出加载种子数据的命令或开关； 3. 按下面的矩阵列出还缺的测试，先给矩阵，我确认后再实现： - 正常路径； - 空值、零值、上限值； - 非法输入与依赖失败； - 重复提交/重复调用。 说明每个测试能捕获哪种具体回归，不要为了覆盖率堆测试。
高分点：从零题的演示环节，空白页面就是事故。种子数据是你的保险。
9. 审查与最终验收
▼text复制代码请以严格代码审查者的视角检查当前全部代码，不要继续加功能。 逐项检查： - 是否完整满足验收标准，有没有实现偏题； - 空、非法、重复、并发/顺序等边界是否显式处理； - 是否有没用上的文件、抽象、依赖或 TODO 残留； - 输入校验、错误信息、敏感信息和资源释放； - 测试是否真的验证行为，而不是只跑通代码； - 有没有为了跑通而硬编码、吞异常或跳过检查的地方。 每个发现给出：严重程度、文件位置、触发条件、影响、修复建议。 如果没有发现，也说明你检查了哪些路径，不要只回"看起来没问题"。
最终验收：
▼text复制代码请执行最终验收： 1. 对照每条验收标准逐项核验； 2. 用一条命令从零启动（含安装与初始化），确认能复现； 3. 走一遍演示路径，给出每一步的预期输出； 4. 运行测试与静态检查； 5. 检查是否有调试代码、临时文件、未使用的依赖。 最后只按以下格式汇报： - 已完成： - 验证证据： - 关键设计取舍： - 已知风险或未验证项： - 如果再有 15 分钟，下一步会做： 任何没有实际运行的检查必须标为"未运行"。
六、不同题型的加分 Prompt
命令行 / 小工具
▼text复制代码实现前先把输入输出契约定死： - 参数与子命令格式、默认值、必填项； - stdin/stdout 的数据格式； - 退出码约定（成功、用法错误、运行失败）； - 错误信息是否对人友好、是否给出修复提示。 先输出 `--help` 的内容和三个使用示例（正常、缺参、非法值），再实现。
Web 全栈 CRUD
▼text复制代码实现前先给出： 1. 数据模型与字段约束； 2. 路由/接口表（方法、路径、入参、响应）； 3. 页面状态表：加载、成功、空数据、错误、提交中、禁用； 4. 种子数据方案。 要求：后端先返回固定结构并跑通，再接前端；不要在前后端都没跑通时同时调试两边。
算法 / 数据结构
▼text复制代码不要直接给我最终代码。先做三件事： 1. 用一句话说清思路，并给出时间与空间复杂度； 2. 列出需要覆盖的边界（空输入、单元素、重复、极大/极小、已排序、逆序）； 3. 给出一个暴力/朴素实现作为对照。 然后实现目标解法，并用随机小数据与暴力实现对拍验证，输出对拍结果。
高分点：算法题里对拍是最强的验证证据——它证明你不是在碰运气。
数据处理 / 脚本
▼text复制代码先确认输入数据的结构、规模和脏数据情况，再设计处理流程。 要求： - 用一个 5～10 行的小样本手工推导预期结果； - 处理 NULL、重复、乱序、编码和时区问题； - 明确是否幂等（重复运行结果是否一致）； - 先输出处理前后的对照表，再写代码。 完成后用小样本 + 反例各跑一次。
演示 / 原型
▼text复制代码这是一个演示型任务，可演示性优先。 请先设计一条 30 秒能讲完的演示路径，并准备对应的假数据。 至少覆盖：正常展示、空状态、错误态三种画面。 不要为了视觉效果引入重型 UI 库，优先简洁可读的原生实现。
七、边操作边讲什么
开场提问后
我先确认核心用户和验收标准。从零题最容易做偏，所以我要先知道什么是"做完"。
砍需求时
我把范围收敛到 MVP：单用户、内存存储、一条完整路径。登录、持久化、导出列为非目标，如果时间有余我再补。
选型时
AI 给了两个方案，我选 A 不选 B，因为 B 需要引入 XX 依赖，安装风险高，而本题收益不大。这个选型的局限是 XX，如果后面要 XX 我会换。
骨架跑通时
我先在写业务逻辑之前让骨架跑通。这样后面每一圈加能力，我都能立刻知道是哪一步引入的问题。
排出实现顺序后
我按依赖排了四步，前三步必做，第四步之后是时间允许项。这样我随时停下都有一个能演示的版本，您也能知道我当前在第几步。
长肉时
我现在只加清单里的第 N 步：XX。其他步骤我留着不动，避免多个改动同时出错无法定位。
遇到失败时
我先怀疑环境和依赖，再怀疑数据契约，最后才怀疑逻辑。我会用最小检查逐个证伪，而不是让 AI 随机改。
时间不足时
我优先保证一条可演示路径完整可跑。剩下的能力我会明确列为未完成项，而不是塞半成品进来。
收尾演示时
我从零启动一遍给您看：安装、启动、走这条路径。已验证的是这些，没覆盖的是这个外部依赖场景。
八、60 分钟从零题节奏
| 时间 | 目标 | 你要留下的证据 |
|---|---|---|
| 0～3 分钟 | 向面试官提问、复述目标 | 用户、场景、限制、时间预算 |
| 3～6 分钟 | 砍出 MVP 与非目标 | 3～5 条验收标准、演示路径 |
| 6～9 分钟 | 选型定桩 | 选型卡、目录结构、启动命令 |
| 9～16 分钟 | 骨架跑通（硬 Deadline） | 一条命令启动 + 端到端空壳可跑 |
| 16～20 分钟 | 定数据模型与接口契约 | 实体/字段、接口清单、边界约定 |
| 20～23 分钟 | 让 AI 排实现顺序，你删减拍板 | 编号步骤清单、每步验证方式、必做/可选标记 |
| 23～38 分钟 | 按清单小步长肉，一次一个能力 | 每步可运行、可演示，且每步一次 git 提交 |
| 38～48 分钟 | 种子数据 + 边界/错误测试 | 测试矩阵与运行结果 |
| 48～56 分钟 | 审查全部代码 + 演示走查 | 无残留 TODO、演示路径通畅 |
| 56～60 分钟 | 总结汇报 | 结果、证据、取舍、剩余风险 |
只有 30～45 分钟？砍功能，不砍"骨架先跑"和"最后演示"这两个环节。 从零题没有可运行成果，等于交白卷。
[!warning] 15 分钟红线 如果到第 15 分钟你的项目还启动不起来，立刻停下来做减法：砍掉所有非核心依赖，退回最小栈（标准库 + 内存），先把空壳跑通。一个跑得起来的半成品，远好过一个跑不起来的完整设计。
九、面试官追问怎么接
从零题结束后，追问往往比实现更决定分数。提前准备好这四个：
| 追问 | 高分回答骨架 |
|---|---|
| 为什么选 X 不选 Y？ | 说清两个方案的差异点、本题的实际约束（时间/依赖/规模），以及 X 的局限。承认局限比吹嘘优点更可信。 |
| 流量涨 10 倍怎么办？ | 先指出当前瓶颈在哪（内存？单线程？查询？），再给最小改动（换存储、加索引、加缓存），不要一上来就上微服务。 |
| 如果 AI 生成的代码有隐藏 bug 呢？ | 讲你的验证策略：契约先行、每步验证、边界测试、对拍/回归测试，以及哪些是你人工复核的。 |
| 时间再多你会做什么？ | 按价值排序：先补测试与错误处理，再做持久化，最后才是功能扩展。能说出"为什么是这个顺序"最关键。 |
还有一句兜底回答，用于被问到不会的细节：
这块我目前是基于 AI 的建议实现的，我对它的把握度不高，我不会假装熟悉。我的验证方式是 XX，如果要上生产，我会先补 XX。
承认不确定 + 给出验证/收敛方案，比硬编一个答案得分高得多。
工具出问题时：应急三招
从零题对工具依赖更重，AI 卡死、网络断了、依赖装不上都可能发生。提前想好，遇事不慌：
| 情况 | 应急动作 |
|---|---|
| 依赖装不上 | 立刻退回最小栈：标准库 + 内存存储 + 命令行输出。宁可功能少，也要有可运行版本。 |
| AI 反复给错方案 | 停止对话式纠缠，把已确认的契约和当前代码贴给 AI，让它只回答一个具体问题；或者直接自己写那 20 行核心逻辑。 |
| AI 完全不可用 | 立刻切"手工模式"：按已定的步骤清单，用你最熟的写法实现第 1 步。同时向面试官说明情况——能讲清楚你在做什么，本身就是交付的一部分。 |
关键心态：AI 是加速器，不是依赖。 你有清单、有契约、有骨架，就算没有 AI 也能往前推。
十、从零题最常见的失分方式
1. 让 AI"帮我写一个完整的 XX 系统"
问题：范围失控，AI 铺开几十个文件，你既跑不起来也讲不清。 改法：先砍 MVP，先要目录结构和启动命令，再写第一行业务代码。
2. 前十分钟还在选框架、装依赖
问题：从零题最贵的资源就是时间，环境问题是无底洞。 改法：只选你 5 分钟内能装好的栈；装到 3 分钟还没成功就立刻换方案，不要死磕——死磕是从零题最常见的时间黑洞。
3. 选型跟着 AI 漂流
问题：AI 推荐什么用什么，面试官一问"为什么"就卡壳。 改法：让 AI 给两个方案 + 取舍，你拍板并写在选型卡里。
4. 数据模型拍脑袋，中途返工
问题：写到一半发现字段不够/关系错了，一半代码要重写。 改法：实现前先定实体、字段、接口契约，改动契约先说明理由。
5. 骨架没跑通就堆功能
问题：第一次运行时同时暴露十个错误，定位不了。 改法：先让"输入 → 固定返回 → 输出"跑通，再一圈一圈长肉。
6. 没有种子数据，演示时一片空白
问题：核心路径明明通了，演示环节却翻车。 改法：提前准备种子数据，并覆盖正常、空、异常三种场景。
7. 只做 happy path
问题：面试官随手输个空值或重复提交就崩。 改法：实现前先列状态表和边界清单，至少覆盖空、非法、重复。
8. 一次性生成整个项目
问题：AI 输出即真相，你对代码没有掌控力。 改法：一次一个能力，每步结束用自己的话解释数据怎么流。
9. 没有实现顺序，想到哪写到哪
问题：先写列表再补创建、先上持久化再改结构，反复返工；也容易中途插入"顺手做一下"的功能，把主线拖死。 改法：契约定完后先让 AI 排出编号步骤清单，自己删/并/排一遍再动手，并同步给面试官作为进度契约。
10. 最后一分钟才第一次运行
问题：没有集成时间，也没有证据。 改法：骨架阶段（第 16 分钟前）必须有可运行版本，之后始终保持可运行。
11. 被问到细节时硬编答案
问题：一个追问就暴露你没真正理解。 改法：直接说明把握度，并给出你的验证方式和收敛计划。
十一、提交前自评分表
每项 0～2 分：0 = 没做，1 = 做了但证据不足，2 = 有清晰证据。
| 项目 | 分数 |
|---|---|
| 我向面试官问清了用户、场景和限制 | /2 |
| 我把题目砍成了一个明确的 MVP 和非目标 | /2 |
| 我能解释技术选型及放弃的方案 | /2 |
| 我在写业务前先跑通了骨架 | /2 |
| 我先把数据模型和接口契约定下来 | /2 |
| 我让 AI 排出实现顺序，并自己删减/重排过 | /2 |
| 每个小步都能运行、都能演示 | /2 |
| 我覆盖了空值、非法输入和重复操作 | /2 |
| 我有种子数据，演示路径走通 | /2 |
| 我审查了全部代码，没有残留 TODO 和死代码 | /2 |
| 我能说清关键取舍和"下一步做什么、为什么" | /2 |
建议目标：18 分以上（满分 22）。低于 14 分，通常不是 AI 不够强，而是你没在管它。
十二、平时怎么练
从零题是可以练出肌肉记忆的。挑一个 45 分钟能做完的小东西，录屏走完整套流程：
| 练习题库 | 练什么 |
|---|---|
| 命令行 Todo（本地文件存储） | MVP 收敛、输入输出契约、持久化取舍 |
| URL 短链服务（内存 + 接口） | 数据模型、ID 生成、冲突处理 |
| 简易限流器（固定窗口/令牌桶） | 边界、并发、可验证性 |
| Markdown 博客生成器 | 文件处理、脏数据、幂等 |
| 单页 CRUD + 种子数据 | 状态表、演示路径、前后端联调顺序 |
| 日志清洗脚本 | 小样本推导、反例验证 |
复盘只看五件事：
- 我有没有在 AI 写代码之前就定下了"做完"的标准？
- 我砍掉了什么？我有没有当着"面试官"的面说明为什么砍？
- 我在第几分钟让项目第一次跑起来的？
- 我有没有至少一次推翻或修正 AI 的方案，并说清理由？
- 断网或 AI 不可用时，我还能不能解释并调试这份代码？
最后记住
从零到一的 Vibe Coding 面试，高分候选人做的事情其实很朴素：
- 先问清楚，再动手；
- 先砍需求，再写代码；
- 先跑骨架，再长功能；
- 先定契约，再谈实现；
- 始终有一个可演示的版本，并且说得出每一个取舍。
不要向面试官证明 AI 能生成多少代码，要证明在空目录面前，你依然有章法。