约 9 分钟5 张卡

AI 辅助开发

AI 辅助开发是使用编码 Agent 或编码助手阅读代码、生成修改并验证结果的过程。助手可以运行命令，再根据输出继续修改；开发者负责明确需求、选择方案和验收交付。

本文从一次开发任务入手，依次说明怎样获取代码上下文、描述任务和反馈问题，最后讨论质量审查。面试既会询问实际使用方法，也会让候选人借助 AI 完成现场编码。两种形式都要求候选人解释修改，并用检查结果证明任务完成。

1. 面试核心

先记住这几条，再读正文

开发流程。 AI 辅助开发以验收条件为依据，完成代码阅读、小步实现、检查和差异审查。卡 · 一次开发任务的流程
提示与反馈。 有效提示说明目标、约束和代码位置，失败反馈给出实际输出与预期行为。卡 · 提示与反馈
代码检索。 关键词搜索能直接定位代码标识符，语义检索可以补充按功能描述查找的能力。卡 · 代码库上下文
质量验证。 行为测试、类型检查、静态分析和人工评审共同验证生成代码的质量。卡 · 质量保障
评审重点。 人工评审优先检查接口、数据、权限和并发变更，格式与类型问题交给自动检查。卡 · 质量保障

2. 一次开发任务的流程

按岗选学卡 · AI 辅助开发的完整工作流是什么？讲一下和 AI 交互完成一个功能的过程。

开发任务需要先定义完成标准，后续每一步才有判断依据。一次任务可以按以下七个环节推进：

需求与验收：写清输入、输出、约束和验收用例。会影响实现的歧义先澄清，比如配置解析失败时是保留旧配置还是报错。
理解代码：让 Agent 阅读入口、相关模块和现有测试，再说明调用关系。发现它理解有误时，先纠正，再进入实现。
计划：多文件或风险较高的修改，需要列出改动点和验证方法。简单修改可以直接实施。
实现：每次完成一个可验证的小单元，及时查看 diff，也就是修改前后的代码差异。这样更容易把失败结果对应到具体改动。
验证：运行相关测试和类型检查，按影响范围补充构建与回归。新增行为缺少测试时，补上正常、边界和失败用例。
审查：检查接口兼容和错误处理，再查看是否混入无关修改。被删除的断言、被吞掉的异常和硬编码的值都要有合理解释。
交付：说明修改内容、已完成的验证和未验证部分。开发者需要能解释每处修改的原因。

验收方式应与改动相匹配。纯文案或低影响修改可以采用格式检查、差异检查等方式。

现场 AI Coding 面试中，第一版完成后还会遇到追加需求或缺陷反馈。候选人需要定位问题、给出具体反馈，并解释后续修改。因此，要给验证和修正留出时间。

3. 代码库上下文

按岗选学卡 · 编码 Agent 为什么常用 grep 检索代码而不是 RAG？两者有什么区别？

编码助手需要先找到与任务有关的实现，才能沿用项目已有设计。获取上下文时，可以结合以下四种方式，逐步缩小阅读范围。

方式	适用问题	使用边界
关键词搜索	函数名、错误文本、配置项	依赖命名与搜索范围
语义检索	按功能描述寻找实现	依赖切块、索引更新和权限过滤
符号与调用关系	定义、引用与调用链	依赖语言服务和项目解析
仓库规则	命令、结构与约定	加载规则取决于具体工具

代码里的函数名、类名和错误文本都适合精确匹配。Agent 可以先用 grep 或文件名搜索找到入口，再读完整函数，沿引用继续查找。直接搜索读取当前磁盘内容，所以刚修改的代码也能立即搜到，省去了索引维护。

语义检索先把代码切成片段，再建立用于相似度查询的向量索引。它适合大型仓库、命名不规范的代码，以及只有功能描述的查找任务。不过，切块会割断函数或类的上下文，代码变更后也需要更新索引。所以，检索命中后还要读相关文件，确认调用关系和当前版本。

语言服务器协议（LSP）让编辑器查询定义和引用，代码图谱也能帮助追踪调用关系。这类工具依赖语言服务与项目解析，可以和关键词搜索、语义检索一起使用。

开发者可以提供以下定位信息，减少无关搜索：

指出相关目录、文件和调用入口。
说明业务术语在代码中对应什么名称。
提供复现命令和错误输出。

检索方案是否提高了任务成功率，见编码 Agent 评测。

仓库中的长期约定怎样组织，见仓库指令。

4. 提示与反馈

按岗选学卡 · 假如要基于内存实现一个缓存，写一下 AI Coding 流程中的提示词。

任务描述需要把目标变成可验证的行为。下面以进程内缓存为例，把代码位置、调用方、约束和验收条件放在一起。

LRU 按最近访问顺序淘汰最久未使用的条目，TTL 则规定条目的有效时间。两者控制的行为不同，因此都要在需求中写清。

目标：在 src/cache/ 中实现进程内 LRU 缓存。
调用方：UserService。
约束：
- 容量可配置，默认 1000；支持 TTL。
- 多线程读写安全；沿用已有依赖。
- 保持 UserService 的公开接口兼容。
验收：
- 测试覆盖命中、过期、淘汰顺序和并发行为。
- 现有相关测试全部通过。
先阅读相关实现，再给出修改点和验证方式。

如果缓存用于查询用户资料，可以进一步说明 UserService 中的调用位置。仓库已有 src/cache/README.md 时，也应让 Agent 先阅读其中的约定，再确定修改方案。

第一版完成后，反馈要提供足以指导修改的具体差异：

测试失败时，给出用例、期望值和实际值，也可以让 Agent 直接运行测试读取结果。
设计存在问题时，指出代码路径和受影响的约束。比如，全局锁让所有访问串行执行，需要结合并发要求检查锁的范围。
同类错误反复出现时，让 Agent 说明当前假设，保留已确认事实，再缩小修改范围。

锁策略也要结合缓存的具体行为。LRU 的 get 会更新访问顺序，也就是命中时仍会修改共享状态。因此，评估读写锁或分段锁时，要同时检查顺序维护和淘汰是否正确。

这些反馈比单纯要求“再检查一下”更有用，因为模型能据此定位具体差异。失败会话的恢复方式见 AI 代码调试。

5. 质量保障

按岗选学卡 · 怎样保证 AI 生成的代码质量？为什么 AI 生成的代码能跑但逻辑很差？卡 · AI 一次生成大量代码或很长的技术方案时，人应该如何评审？

生成代码需要同时满足业务行为和工程约束。程序运行成功后，还需要继续检查边界输入、失败路径和设计是否合理。

评审时要留意以下常见缺陷及成因：

需求只描述主流程时，生成实现容易遗漏并发、错误处理和兼容性要求。
读取的代码范围不足时，助手会重复实现已有工具函数，或采用与项目不同的约定。
围绕失败用例反复修改时，助手会放宽断言、跳过用例，或加入只匹配该输入的特殊分支。
为了尽快完成任务，生成代码还会出现吞掉异常、硬编码配置或残留无用代码的问题。
多轮修改各自解决局部问题后，模块职责会变得混乱，增加维护难度。

因此，编码前要在提示和仓库指令中写明项目约定与禁止事项。复杂修改先检查计划，完成后再按下表验证。

检查对象	验证方式
业务行为	从需求推导正常、边界和失败用例
兼容性	核对调用方、接口和数据格式
错误处理	验证异常传播与资源清理
并发	检查共享状态与执行顺序
改动范围	审查 diff 和已有断言变化
机械规则	类型检查、lint、构建和静态分析