7. AI Coding 面试高分 Prompt 手册
[!note] 📎 关联总纲 本文是《[[从零到一设计 Agent：结合生产实践，Pi，Claude Code|从零到一设计 Agent]]》的展开阅读笔记（对应：第 21 章 · Vibe Coding Prompt），与总纲双向互链，点击总纲可回到全书语境。
[!tip] 📎 姊妹篇 本文面向已有代码库的功能改造题。如果面试官是从零实现（空目录起步），请看 → [[8. 从零到一 AI Coding 面试高分 Prompt 手册]]。
AI Coding 面试高分 Prompt 手册
适用于允许使用 AI 编程工具的前端、后端、全栈和原型开发面试。
Vibe Coding 面试不是“谁让 AI 写得最快”，而是看你能否像一名可靠的工程师一样驾驭 AI：理解需求、控制范围、审查代码、发现错误，并用可复现的证据证明结果正确。
真正拉开分差的不是一条神奇 Prompt，而是一套稳定的工作循环：
理解 → 澄清 → 计划 → 小步实现 → 验证 → 审查 → 汇报
一、面试官真正关注什么
| 能力 | 高分表现 | 低分表现 |
|---|---|---|
| 需求理解 | 先复述目标，确认边界和验收标准 | 看完题目立刻让 AI 开写 |
| 任务拆解 | 按可验证的小步推进 | 一次生成整个项目 |
| 工程判断 | 能解释方案、取舍和风险 | 只会转述 AI 的回答 |
| 上下文管理 | 让 AI 先读相关代码和约定 | 不看现有结构，另起炉灶 |
| 代码审查 | 主动检查 diff、调用链和边界条件 | AI 写完直接接受 |
| 调试能力 | 根据报错提出假设并最小化修复 | 反复说“还是不行，继续修” |
| 验证能力 | 测试、类型检查、Lint、手动验收都有证据 | 以“看起来能跑”作为完成标准 |
| 沟通能力 | 持续说明当前判断和下一步 | 全程沉默操作工具 |
| 时间管理 | 先交付核心路径，再处理增强项 | 前半程过度设计，最后没有可运行结果 |
一句话原则：AI 负责提高吞吐量，你负责方向、判断和质量。
二、万能 Prompt 结构
高质量 Prompt 通常包含六部分：
▼text复制代码目标：要实现什么用户结果。 上下文：相关文件、现有行为、技术栈和项目约定。 范围：必须做什么，明确不做什么。 约束：兼容性、性能、安全、依赖和代码风格要求。 验收标准：什么结果才算完成。 工作方式：先分析还是直接改、每步如何验证、最终如何汇报。
可直接复制的总控 Prompt
▼text复制代码你是我的结对编程助手。请帮助我完成下面的任务，但不要替我做未经确认的产品或架构决定。 【目标】 <用一句话描述用户最终能完成什么> 【必须满足】 - <功能要求 1> - <功能要求 2> - <关键边界条件> 【本轮不做】 - <非目标 1> - <非目标 2> 【工程约束】 - 遵循现有项目结构、命名和代码风格 - 优先复用已有组件、工具函数和依赖 - 除非确有必要，不新增依赖、不做无关重构 - 不删除、跳过或弱化现有测试来让结果通过 - 对输入、失败状态和安全边界进行显式处理 【验收标准】 - <可观察结果 1> - <可观察结果 2> - 相关测试通过，且没有引入新的类型或静态检查错误 【工作方式】 1. 先阅读相关代码和项目说明，概括当前实现。 2. 列出不超过 3 个需要我确认的问题；若信息足够，写明合理假设并继续。 3. 给出最小可行方案、将修改的文件、风险和验证方法，暂时不要改代码。 4. 等我确认后按小步实现；每一步都说明改了什么以及如何验证。 5. 完成后审查完整 diff，运行相关检查，并按“结果、证据、风险、未完成项”汇报。
面试中不要机械粘贴所有内容。题目越小，Prompt 越短；只保留真正影响结果的约束。
三、面试现场 Prompt 链
相比一条超长 Prompt，分阶段对话更容易展示你的判断，也更方便在 AI 走偏时及时纠正。
1. 先理解代码库
▼text复制代码先不要修改代码。请快速检查项目结构、启动方式、测试命令和与任务最相关的文件。 请输出： 1. 当前功能和数据流的简要说明； 2. 最可能需要修改的文件及原因； 3. 可以复用的现有模式、组件或工具函数； 4. 你发现的歧义、风险和未知项； 5. 建议运行的最小验证命令。 只报告你从代码中确认的事实；推测请明确标记为“假设”。
高分点：先建立事实，再做方案；避免 AI 凭经验虚构项目结构。
2. 把题目变成可验收规格
▼text复制代码请把题目整理为一个最小可交付规格，不要扩展需求。 输出： - 一句话用户目标； - 3～5 条可观察的验收标准； - 正常路径、空状态、错误路径和关键边界条件； - 本轮明确不做的内容； - 仍需确认的问题。 如果题目与现有代码行为冲突，请指出冲突，不要自行选择。
你可以对面试官说：
我先把自然语言题目转成可验证的验收标准，这样后面能判断 AI 写的是不是正确的东西。
3. 让 AI 规划，但由你拍板
▼text复制代码基于已确认的验收标准，给出一个能在当前面试时间内完成的最小方案。 要求： - 优先沿用现有架构和依赖； - 将任务拆成 2～4 个可独立验证的步骤； - 对每步列出修改文件、核心逻辑和验证方式； - 标出最可能失败的地方； - 如有多种方案，只比较最合理的两种，并给出推荐及取舍； - 暂时不要修改代码。
拿到计划后，你应该主动删掉不必要的抽象、依赖和增强项，而不是直接批准。
4. 实现一个最小切片
▼text复制代码现在只实现计划中的第 <N> 步。 约束： - 修改最少且必要的文件； - 遵循相邻代码的实现模式； - 不顺手重构无关代码； - 不新增依赖，除非先说明现有方案为何不足； - 补充覆盖本步行为的测试； - 修改后运行最相关的快速检查。 完成后停止，并汇报：修改内容、检查结果、下一步和仍存在的风险。
高分点：把 AI 的“自由生成”变成受控的小批量变更。
5. 精准 Debug
不要只说“修一下”。把错误现象、预期行为和证据一起交给 AI。
▼text复制代码出现了下面的失败： 【复现步骤】 <如何稳定复现> 【实际结果】 <报错、日志、失败测试或页面现象> 【预期结果】 <正确行为> 请先不要改代码。完成以下分析： 1. 从错误发生点向上追踪相关调用链； 2. 提出最多 3 个根因假设，并按可能性排序； 3. 为每个假设给出可证伪的最小检查； 4. 选出证据最强的根因； 5. 给出最小修复和防止回归的测试。 不要用吞掉异常、删除断言、跳过测试或硬编码结果的方式绕过问题。
验证假设后再发：
▼text复制代码检查结果支持假设 <N>。请只修复这个根因并添加回归测试，不要扩大修改范围。完成后重新运行失败测试及其相邻测试，并解释为什么这次修复解决的是根因而不是症状。
6. 主动补齐测试
▼text复制代码根据验收标准和当前 diff，列出还缺少的测试。优先级依次为： 1. 会导致核心功能错误的边界条件； 2. 错误处理和非法输入； 3. 容易被本次修改破坏的既有行为； 4. 安全或数据一致性风险。 先给出测试矩阵，不要立即生成大量测试。选择最高价值的最小集合，说明每个测试能捕获哪种具体回归；经确认后再实现并运行。
测试矩阵建议使用：
| 场景 | 输入/前置条件 | 预期结果 | 测试层级 |
|---|---|---|---|
| 正常路径 | 合法输入 | 正确输出 | 单元/集成 |
| 边界值 | 空值、零值、上限 | 行为符合规格 | 单元 |
| 错误路径 | 非法输入、依赖失败 | 明确且安全地失败 | 单元/集成 |
| 回归场景 | 本次缺陷的最小复现 | 缺陷不再出现 | 回归测试 |
7. 审查 AI 生成的代码
▼text复制代码请以严格代码审查者的视角检查当前完整 diff，不要直接继续修改。 逐项检查： - 是否完整满足验收标准，有没有实现错问题； - 正常、空、错误和并发/重复操作等边界； - 是否破坏现有调用方、接口或数据兼容性； - 输入校验、权限、敏感信息、注入和依赖风险； - 是否存在多余抽象、重复逻辑或无关改动； - 测试是否真的验证行为，而不只是覆盖代码； - 是否有被删除、跳过或弱化的测试。 每个发现请给出：严重程度、文件与位置、触发条件、影响、修复建议。 如果没有发现，也要说明检查过哪些调用链和边界，不要只回复“看起来没问题”。
8. 最终验收
▼text复制代码请执行最终验收： 1. 对照每条验收标准逐项核验； 2. 运行适合本次修改的测试、类型检查、Lint 和构建； 3. 检查完整 diff 与未跟踪文件； 4. 确认没有调试代码、硬编码密钥、无关改动、被跳过测试或多余依赖； 5. 如条件允许，执行一遍核心用户路径的手动冒烟测试。 最后只按以下格式汇报： - 已完成： - 验证证据： - 关键设计取舍： - 已知风险或未验证项： - 如果再有 15 分钟，下一步会做： 任何没有实际运行的检查必须标为“未运行”，不能推断为通过。
四、不同题型的加分 Prompt
前端 / UI
▼text复制代码实现前先把页面拆成状态，而不只是静态画面：加载、成功、空数据、错误、禁用和提交中。 请检查： - 组件边界和状态归属是否清晰； - 键盘操作、焦点、标签和基础可访问性； - 窄屏和宽屏布局； - 长文本、空值、重复点击和慢请求； - 是否复用已有设计系统和组件； - 是否引入不必要的全局状态。 先给出组件树、状态表和最小验收路径，再开始实现。
后端 / API
▼text复制代码实现这个接口前，请先追踪现有请求链路，并明确： - 输入 schema、认证与授权边界； - 成功和失败响应契约； - 数据一致性、幂等性、事务和并发风险； - 超时、重试、日志及敏感信息处理； - 数据库查询数量和明显的性能风险； - 与现有调用方的兼容性。 优先复用现有 handler/service/repository 模式。先输出接口契约和测试矩阵，再做最小实现。
SQL / 数据处理
▼text复制代码请先确认表结构、字段语义、数据规模和目标输出，再设计查询。 要求检查： - NULL、重复数据、时区和日期边界； - JOIN 是否可能放大行数； - 聚合粒度是否正确； - 查询是否可利用现有索引； - 写操作是否需要事务或幂等保护。 先用一个小型示例数据集手工推导预期结果，再写查询；完成后用反例验证。
性能优化
▼text复制代码不要凭感觉优化。请先定位可测量的瓶颈，并给出当前基线、可能原因和测量方法。 只实施一个证据最充分的改动，然后使用相同输入和环境比较前后结果。说明时间复杂度、空间代价、可读性影响，以及为什么没有选择其他方案。
安全敏感功能
▼text复制代码先标出信任边界、攻击面和敏感数据流。重点检查权限绕过、输入注入、越权访问、密钥泄露、不安全默认值以及错误信息暴露。 不要自行读取或输出密钥，不要关闭安全检查。任何涉及权限模型、数据删除或外部系统写入的决定先暂停并向我说明风险。
五、边操作边讲什么
Prompt 只是屏幕上的证据，口头表达才让面试官理解你的判断。
开场
我先确认核心用户目标和验收标准，然后让 AI 快速熟悉相关代码。拿到方案后我会控制范围，先完成一条可运行的核心路径。
AI 给出方案后
这个方案基本可行，但它建议新增依赖和重构公共模块，这两项不是本题必需。我会保留现有结构，把修改限制在最小范围。
AI 生成代码后
我不会因为代码能编译就直接接受。现在我会检查关键数据流、错误路径、调用方兼容性和测试是否真正验证了需求。
遇到失败时
我先把现象与根因分开。这个报错可能来自数据形状、状态更新或接口契约，我会用最小检查逐个证伪，而不是让 AI 随机改代码。
时间不足时
我会优先保证核心路径可运行、可演示、可验证。增强功能记录为后续项，不牺牲正确性去堆功能数量。
收尾
核心验收标准已经逐项验证。当前证据包括这些测试和手动路径；仍未覆盖的是这个外部依赖场景，如果继续我会优先补它。
六、60 分钟实战节奏
| 时间 | 目标 | 你要留下的证据 |
|---|---|---|
| 0～5 分钟 | 复述需求、确认限制 | 验收标准、非目标、假设 |
| 5～10 分钟 | 浏览代码、确认运行方式 | 相关文件、数据流、检查命令 |
| 10～15 分钟 | 选择最小方案 | 2～4 步计划、风险、测试策略 |
| 15～40 分钟 | 小步实现核心路径 | 每步可运行、局部测试通过 |
| 40～50 分钟 | 边界、错误与回归测试 | 关键测试矩阵和运行结果 |
| 50～57 分钟 | 审查 diff、手动冒烟 | 无无关改动，核心路径可演示 |
| 57～60 分钟 | 总结 | 结果、证据、取舍、剩余风险 |
如果只有 30～45 分钟，压缩功能范围，不要删除验证环节。
七、最常见的失分方式
1. 一上来就说“帮我完成这个项目”
问题：范围模糊，AI 容易过度实现，面试官也看不到你的思考。
改法：先让 AI 读代码、整理验收标准，再只实现第一步。
2. 复制一条巨大 Prompt 后全程沉默
问题：Prompt 再漂亮，也无法证明你理解每个决策。
改法：使用短 Prompt 链，每次输出后主动评价、纠偏并说明取舍。
3. AI 说“测试通过”就相信
问题：AI 可能没有运行测试、只跑了局部测试，或误读了输出。
改法：要求展示实际命令、结果和未运行项；关键路径自己复核。
4. 为了变绿而删测试或吞异常
问题：这是明显的工程判断失分项。
改法：要求先定位根因，新增回归测试，再做最小修复。
5. 只追求界面效果，忽略状态和边界
问题：演示可能好看，但加载、空数据、错误、重复提交就会失败。
改法：实现前先列状态表，至少覆盖核心状态。
6. 随意新增框架和依赖
问题：增加安装失败、安全、兼容性和解释成本。
改法：默认复用当前依赖；新增依赖必须说明收益和替代方案。
7. 看不懂 AI 代码却继续叠功能
问题：面试官追问任意一行都可能暴露失控。
改法：每个小步结束后，用自己的话解释数据如何进入、转换和输出。
8. 最后一分钟才运行项目
问题：没有时间处理集成问题，也没有完成证据。
改法：尽早打通一条最小路径，之后每个阶段都保持可运行。
八、提交前自评分表
每项 0～2 分：0 = 没做，1 = 做了但证据不足，2 = 有清晰证据。
| 项目 | 分数 |
|---|---|
| 我准确复述了用户目标和非目标 | /2 |
| 我定义了可观察的验收标准 | /2 |
| 我理解并能解释相关代码流 | /2 |
| 我质疑或修正过 AI 的方案 | /2 |
| 修改范围小且符合现有模式 | /2 |
| 我审查了完整 diff | /2 |
| 我验证了正常、边界和错误路径 | /2 |
| 我运行了相关测试和静态检查 | /2 |
| 我能解释关键设计取舍 | /2 |
| 我明确汇报了风险和未验证项 | /2 |
建议目标：16 分以上。如果低于 12 分，通常不是 Prompt 不够花哨，而是工程闭环没有完成。
九、平时怎么练
选一个 45～60 分钟能完成的小功能，录屏完成整套流程。复盘时只看四件事：
- 你是否在 AI 写代码前定义了成功标准？
- 你是否至少一次拒绝或纠正了 AI 的建议，并说清原因？
- 你是否用实际运行结果证明完成，而不是口头宣称？
- 在断网或 AI 不可用时，你是否仍能解释并调试最终代码？
最有效的训练题不是从零生成 Todo App，而是在陌生的小型项目中完成真实改动，例如：增加一个带校验的接口、修复一个回归缺陷、补齐错误状态、优化一条慢查询，或为既有功能添加测试。
最后记住
高分候选人的 Prompt 往往并不炫技。它们只是持续做到四件事：
- 给 AI 足够且相关的上下文；
- 把任务限制在清晰、可验证的范围内；
- 对 AI 输出保持怀疑并主动审查；
- 用测试、运行结果和清楚的解释承担最终责任。
不要向面试官证明 AI 很强，要证明你能让 AI 在你的控制下稳定交付。
