AI 辅助开发
AI 辅助开发指使用编码 Agent 或编码助手阅读代码、生成修改、运行命令并根据反馈继续迭代。面试中常见两种形式：询问实际使用方法，或者允许使用 AI 完成现场编码任务。两种形式考察的都是开发者能否明确需求、提供正确的上下文、验证结果并对交付负责。本文讲一次开发任务的完整流程、代码库上下文、提示与反馈，以及质量保障。
1. 面试核心
先记住这几条，再读正文- 流程是：明确需求和验收条件 → 让 Agent 读懂相关代码 → 确认计划 → 小步实现 → 运行测试和检查 → 审查 diff → 交付。模型“说完成了”不等于验收通过。卡 · 一次开发任务的流程
- 提示的有效内容是目标、约束、相关代码位置和实际反馈（报错、失败输入、期望与实际的差异）；反复要求“再检查一下”几乎没有信息量。卡 · 提示与反馈
- 代码库上下文按需获取：编码 Agent 通常用搜索和读文件工具沿调用链定位，而不是把整个仓库放进上下文。卡 · 代码库上下文
- 质量靠外部证据保证：测试、类型检查、静态分析和人工评审。生成的代码同样要求开发者能解释，能跑但设计差的代码要在评审中拦下。卡 · 质量保障
- 大段生成的方案和代码要按风险分配审查：高影响的接口、数据和权限变更由人重点审查，机械检查交给工具。卡 · 质量保障
2. 一次开发任务的流程
- 需求与验收：把需求拆成输入、输出、约束和验收用例。会改变实现的不明确之处先澄清，例如“配置解析失败时保留旧配置还是报错”。
- 理解代码：让 Agent 找到入口、相关模块和现有测试，复述它对调用链的理解；理解有误时先纠正，再写代码。
- 计划：对多文件或有风险的修改，先让 Agent 列出修改点和验证方式，确认后再实施。简单修改可以直接做。
- 实现：一次完成一个可验证的单元，避免一次生成跨越很多模块的大改动。
- 验证：运行相关测试、类型检查、构建；没有测试的行为补充测试，至少覆盖正常、边界和失败路径。
- 审查：阅读 diff，检查是否有无关修改、删除的断言、吞掉的异常、硬编码的值。
- 交付：说明改了什么、验证了什么、还有哪些没有验证。
现场 AI Coding 面试中，面试官通常会在第一版完成后指出问题或追加需求，观察候选人如何定位、如何给 AI 反馈以及能否解释修改。时间分配上要给验证和修正留出空间。
3. 代码库上下文
编码 Agent 获取代码上下文的常见方式：
| 方式 | 做法 | 特点 |
|---|---|---|
| 搜索工具 | grep、按文件名查找，然后读文件 | 精确匹配符号名，结果实时，不需要索引维护 |
| 语义检索 | 对代码块建向量索引 | 能按功能描述查找，但索引可能过期，代码切块会破坏结构 |
| 符号与调用关系 | LSP、代码图谱查询定义和引用 | 准确的跳转，需要语言工具支持 |
| 规则文件 | 仓库指令说明目录结构、命令和约定 | 每次会话自动加载，见仓库指令 |
代码中的标识符精确、可搜索，Agent 可以像开发者一样边搜索边读，逐步缩小范围，读取的内容也总是最新的。语义检索在大型、命名不规范或需要按功能描述查找的仓库中有补充价值。
开发者能帮助 Agent 的是：指出相关目录和文件、说明业务术语对应的代码名称、提供复现命令和错误输出。
4. 提示与反馈
一个有效的任务描述包含：
目标：在 src/cache/ 中实现进程内 LRU 缓存，供 UserService 查询用户资料时使用。
约束：
- 容量可配置，默认 1000；条目支持 TTL。
- 多线程读写安全；不引入新的第三方依赖。
- 不修改 UserService 的公开方法签名。
验收：
- 新增单测覆盖：命中、过期、淘汰最久未使用、并发读写。
- 现有测试全部通过。
先阅读 UserService 和现有的 src/cache/README.md，给出实现计划后再写代码。
反馈要具体：
- 测试失败时，给出失败的用例、实际输出和期望输出，或者直接让 Agent 运行测试读取结果。
- 设计不符合要求时，指出具体位置和原因，例如“
get中加了全局锁，读多写少场景下会成为瓶颈，改为分段锁或读写锁”。 - 同一个错误反复修不好时，停下来让 Agent 解释它的假设，或者回退到上一个可用版本缩小范围，不要连续要求重写。
5. 质量保障
AI 生成代码的常见问题：
- 按字面需求实现，忽略隐含约束（并发、错误处理、兼容性）。
- 为了让测试通过修改测试或增加特殊分支。
- 重复实现已有的工具函数，不遵循项目约定。
- 吞掉异常、硬编码配置、留下无用代码。
- 能运行，但职责混乱、难以维护。
对应的保障：
- 事先：在提示和仓库指令中写明约定和禁止事项；先确认计划。
- 测试：测试从需求和行为契约出发，而不是从生成的实现反推；检查 Agent 是否修改了已有断言。
- 自动检查：类型检查、lint、静态分析、安全扫描在提交前运行。
- 评审：人工审查 diff；也可以让另一个模型实例评审，但它的结论同样需要代码和运行结果支持。
- 能解释：开发者应能解释每一处修改为什么这样做，无法解释的代码不交付。
6 · 面试题卡片
6.1 AI 辅助开发的完整工作流是什么？讲一下和 AI 交互完成一个功能的过程。
出现公司：百度、美团、字节跳动、阿里淘天、新旦智能
考察重点
- 需求、上下文、计划、实现、验证、审查的顺序。
- 人负责的判断与交付责任。
相关内容：一次开发任务的流程。
参考回答
先把需求拆成输入、输出、约束和验收用例，不明确且影响实现的地方先澄清。然后让 Agent 阅读相关代码，复述调用链和修改点，理解有误先纠正。多文件或有风险的修改先让它给出计划和验证方式，确认后按可验证的小单元实现。
每完成一步就运行测试、类型检查和构建，缺少的行为补测试；失败时把具体输出反馈给 Agent。最后人工审查 diff，检查无关修改、被改动的断言和吞掉的异常，确认自己能解释每处修改，交付时说明已验证和未验证的部分。人负责需求判断、方案取舍和最终验收，AI 负责加速阅读、编写和执行。
6.2 假如要基于内存实现一个缓存，写一下 AI Coding 流程中的提示词。
出现公司：百度、Microsoft、Meta、美团、字节跳动
考察重点
- 目标、约束、相关代码和验收条件。
- 基于运行结果的具体反馈。
相关内容：提示与反馈。
参考回答
提示包含四部分。目标：在哪个模块实现什么，供谁调用。约束：容量与淘汰策略（如 LRU）、是否需要 TTL、线程安全要求、不引入新依赖、不改变已有接口。验收：单测覆盖命中、过期、淘汰顺序、并发读写，现有测试全部通过。流程要求：先阅读相关代码，给出实现计划后再编码。
第一版完成后根据实际结果反馈：测试失败就给出用例、实际值和期望值；设计问题指出具体位置和原因，例如全局锁导致读路径串行化。反复失败时让模型说明假设或回退缩小范围，而不是只说“再检查一下”。
6.3 编码 Agent 为什么常用 grep 检索代码而不是 RAG？两者有什么区别？
出现公司：蚂蚁、携程、快手
考察重点
- 精确搜索与语义检索在代码场景的适配性。
- 索引新鲜度、结构完整性和迭代式探索。
相关内容：代码库上下文。
参考回答
代码中的函数名、类名、错误信息都是精确标识符，grep 能直接命中；搜索结果总是基于当前文件，不存在索引过期的问题，Agent 修改代码后立即可以搜到。Agent 可以像开发者一样多轮搜索、读文件、再搜索，逐步缩小范围，只把需要的内容读入上下文。
RAG 需要预先切块和建索引：代码切块可能破坏函数和类的结构，代码频繁变化时索引会过期，语义相似也不等于调用关系相关。它的优势是能用自然语言描述功能来查找，适合命名不规范或非常大的仓库。实际工具中两者可以并存，再配合 LSP 等符号跳转。
6.4 怎样保证 AI 生成的代码质量？为什么 AI 生成的代码能跑但逻辑很差？
出现公司：快手、字节跳动、科大讯飞、深信服、新旦智能、阿里云、美团
考察重点
- 生成代码的典型缺陷及原因。
- 事前约束、测试、自动检查和评审组成的保障链。
参考回答
模型以完成当前请求为目标：需求描述中没有的隐含约束（并发、错误处理、兼容性、项目约定）容易被忽略；它看到的代码有限，可能重复实现已有功能；遇到测试失败时可能改测试或加特殊分支。所以代码能跑，但职责混乱、可维护性差。
保障分几层：事先在提示和仓库指令中写明约定和禁止事项，先确认计划；测试由人根据需求和行为契约给出场景，AI 可以帮助编写，但要检查是否修改了已有断言；提交前自动运行类型检查、lint、静态分析和安全扫描；人工审查 diff，关注设计、边界和副作用；开发者必须能解释每处修改。也可以用另一个模型评审，但结论仍要有代码和运行结果支持。
6.5 AI 一次生成大量代码或很长的技术方案时，人应该如何评审？
出现公司：字节跳动、汇川技术、小鹏汇天、安软、阿里
考察重点
- 按风险拆分审查重点。
- 自动检查、AI 辅助审查与人工判断的边界。
相关内容：质量保障。
参考回答
技术方案先对照需求看三件事：是否满足验收条件，关键取舍（数据模型、接口、一致性、失败处理）是否合理，有没有超出需求的复杂设计。只抓会影响结果和后续维护的点，细节可以在实现中调整。
代码按功能和依赖拆分差异，先看接口兼容、数据修改、权限和并发等高影响位置。格式、类型、静态规则交给自动检查；AI 可以帮助梳理调用链和找疑点，但结论要有代码和运行证据。变更大到无法解释时，要求缩小改动分批提交。多个模型都认可不能替代测试。最终由人对交付负责，并说明已验证的范围和剩余风险。