AI Coding 面试 13 问：工具选择、工作流与代码验收

以主要使用 Claude Code 维护后端项目、也用过编辑器内补全的经历为条件化示例：

我最熟悉的是 Claude Code。我会让它在仓库里完成有明确边界的任务，例如给一个查询接口补输入校验和回归用例。先让它定位路由、业务实现和现有测试，确认应该在哪层改，再小步修改并运行相关检查。我会看 diff，核对它有没有扩大范围，以及测试是否真的覆盖原问题。

如果失败，我会提供复现输入、完整错误和预期结果，让它沿证据继续修；如果方向已经偏了，就先撤回错误改动，重新缩小任务。它能把读代码、修改和检查串起来，但业务取舍、结果审阅和最终交付仍由我负责。编辑器补全更适合写代码时接受局部候选，我不会把这两种使用方式混为一谈。

选择 Coding Agent，主要看它能否在当前项目里稳定完成“理解仓库、修改代码、运行验证、根据失败修复”的任务，并降低从需求到可合并改动的总成本。比较时要同时看模型能力、Agent 执行环境和团队工作流，不能只比较模型榜单或界面形态。

以选择 Codex 完成一个跨前后端需求为参考：它能够在仓库中读取相关文件、编辑代码、运行已有开发工具，并根据测试结果继续调整；如果团队主要使用终端，或者希望把重复任务接入脚本，这些能力与需求比较匹配。具体选型还要验证它能否正确定位调用链、遵守项目约定、保留已有行为，以及是否方便审查和恢复改动。

最后用同一组代表性任务比较候选工具：记录独立验收后的完成情况、人工审查与修复时间、任务耗时和使用成本，再结合权限、数据处理方式及团队集成要求做选择。若主要工作是边写边调试、频繁查看 UI 和 Diff，IDE 内的 Agent 也可能更合适；工具形态不是能力高低的固定划分。

我的 AI Coding 工作流是：先把需求和验收讲清楚，读现有实现，再让 AI 小步修改，用审阅和可执行检查推动下一轮。

开始时，我会确认要解决哪个用户问题、哪些地方允许改，以及怎样判断完成；然后让工具定位已有模式和相关测试，避免重复造一套实现。实现时按能独立验证的小块推进，检查 diff，运行与改动相关的测试、类型或构建检查。失败就带着复现输入、错误输出和预期行为继续修；通过后再核对需求覆盖和必要的界面交互，最后说明改了什么、验证了什么、还缺什么条件。

流程重量按任务决定。局部文案或已有字段展示可以直接改并针对性检查；跨模块状态、公共接口或权限变化，才需要更细的设计与验证。

假设知识问答服务中，业务设计和关键处理由自己完成，AI 辅助生成了部分代码，可以这样回答：

我主要负责需求拆解、接口和数据结构设计、检索与回答流程，以及关键失败路径的实现。AI 主要辅助生成重复的接口骨架、数据转换代码和测试初稿，具体采用哪些由我审阅决定。开源框架提供的能力，我也会与自己实现的模块分开说明。

一次具体修正是：AI 生成的检索结果合并逻辑把“没有召回文档”也当成正常回答输入。我改成显式处理空召回，返回不足以作答的状态，并补了正常召回、空召回和检索异常的用例。我能解释这条分支为什么存在、输入输出是什么，以及怎样验证它。我的贡献是这些设计、实现和验证判断，不能只用“多少代码由我敲出来”概括。

Vibe Coding强调用自然语言描述意图、快速生成并运行代码，再根据效果反复调整；Spec Coding强调先把目标、关键约束和验收行为表达清楚，让AI围绕这些约定实现。两者的差别主要是如何减少需求理解与实现之间的偏差，而不在于是否使用AI。

原型探索适合快速试错；已有业务系统、跨模块协作或需要长期维护的功能，更需要明确接口、状态和边界。实际开发可以先用原型发现需求，再补齐必要约定；简单修改也可以只用几条清楚要求，不必为采用Spec Coding创建一整套文档。

让 AI 遵守项目规范，我会同时做好三件事：让规则可读取，让任务范围清楚，让结果可验证。

先把技术栈、目录职责、代码风格、常用命令和关键约束写进仓库中的规范入口，并按模块补充局部规则；开发前让 Agent 阅读相关代码和现成实现，再给出本次目标、改动范围及验收要求。生成后运行适当的格式、类型或测试检查，检查代码差异和业务行为。

团队使用不同 Coding Agent 时，共享同一份规范内容，再按工具实际支持的入口加载，避免各维护一套互相冲突的规则。文档指导模型行为；能自动检查的约束交给现有工具执行，业务取舍和功能正确性仍需审查。

不同 Coding Agent 的差异，主要在宿主如何为每轮调用准备上下文：规则从哪里加载、代码和工具信息何时进入窗口、历史如何清理压缩、任务如何恢复，以及新增要求何时生效。同一个模型接入不同宿主，也可能看到不同的信息。

以具体机制来说：Claude Code 会清理旧工具输出并在需要时摘要，Skill 和子 Agent 也参与控制上下文占用；Codex CLI 的官方指南明确了分层 AGENTS.md 加载，并介绍用 compaction 衔接长任务；OpenCode 暴露自动压缩、旧结果清理和缓冲预算等配置。若说的是 DeepSeek Harness，还可以从它的完整会话日志与实际发给模型的消息分开管理来分析。

这些机制会随版本、模型接口和配置变化，不能把所有产品都归纳成“最近 N 轮加摘要”，也不能只用上下文窗口大小判断谁管理得更好。

Coding Agent 的沙箱，是给实际执行代码和命令的进程设定文件、网络、权限和资源边界。模型可以提出操作，工具执行器先检查权限，再把命令放入受约束的环境；操作系统或虚拟化机制在运行期间实施限制，子进程也应处于相应边界内。

例如让 Agent 修复仓库并运行测试，可以只开放项目目录和必要临时空间，限制访问凭证、其他项目及不需要的网络地址，同时限制 CPU、内存、进程数和执行时间。测试产生的结果再返回给 Agent，供它决定下一步。

具体可用本地系统沙箱、受加固的容器、gVisor 或 microVM，取决于是否执行不可信代码、是否多人共用及兼容性要求。切换工作目录、写提示词或弹一次确认，都不能代替执行隔离；沙箱也不保证代码正确，更不能撤销已经完成的外部业务操作。

从一次命令执行看沙箱怎样起作用：执行器先核对身份、参数和权限，再在受限环境里启动进程。图中分别标出文件、网络、身份与资源限制，以及执行结果的返回路径。

约束并验证 AI 生成代码，关键是建立生成前有约束、生成中控范围、生成后有独立验收、失败后能反馈修正的闭环，不能只靠一句“请保证代码质量”。

1. 先明确任务和项目约束：给出输入输出、接口契约、边界条件、依赖版本及相关实现，写清哪些文件能改、什么行为必须保留。
2. 让 AI 小步修改：优先复用现有组件和方法，一次解决明确的问题，检查 diff 是否混入无关重构、依赖变化或测试删除。
3. 用工具和业务用例验证：按改动运行相关测试及必要的构建、类型或 lint 检查；涉及接口、权限和数据等行为时，再补充相应的集成、安全、性能或端到端验证。验收标准来自需求和业务规则，不能只使用 AI 按自己实现写出的测试。
4. 按风险审查并修正：人工重点看业务逻辑、权限、数据一致性和架构影响；将失败用例与日志反馈给 AI，修复后回归，保留可追溯的改动和检查结果。

例如生成订单查询接口，返回正确 JSON 还不够，还要验证用户只能读取有权访问的订单。类型检查能发现字段错误，权限用例和接口测试才能发现“换一个订单 ID 就能查到别人的数据”这类问题。

拿到 AI 生成的 diff，我会先把需求允许改变的行为说清楚，再沿实际调用链检查实现，最后用独立于生成结果的用例验证判断。AI 对代码的解释可以帮助导航，审查结论要落到代码位置、触发条件和实际行为。

1. 对照需求和改动范围：明确输入输出、兼容性和必须保留的业务规则，查看哪些文件、依赖、配置和测试发生了变化。
2. 逐文件追踪控制流与数据流：从入口读到服务、存储或外部调用，检查正常、异常和提前返回分支；追踪用户输入、身份、资源归属和敏感数据经过哪些处理。
3. 验证实现与测试：检查实际依赖版本和接口，再从需求推导正常、边界与反例，确认测试会在关键行为出错时失败，而不是只验证 AI 自己的实现假设。
4. 形成可验证的问题说明：指出具体文件和位置、什么输入或状态触发、预期与实际差异及影响；修复后重跑复现用例和受影响的回归。

例如知识库接口新增缓存后，正常查询可能都通过，但若缓存命中直接返回，绕过了原来的文档权限检查，就会出现数据泄露。审查时要把新增的快捷分支放回完整调用链中看，不能只看缓存代码是否写对。

生成单元测试应从需求和可观察行为出发，先列出必须成立的规则、失败条件与边界，再让工具或 AI 提出用例和测试代码。覆盖率能发现遗漏执行路径，但无法证明业务覆盖完整；“100% 行覆盖”也可能只有很弱的断言。

更合理的目标是：关键契约有明确预期，主要分支和高风险边界被覆盖，测试能在实现出错时失败，并且执行稳定、维护成本可控。

先把“不符合预期”变成具体、可复现的差异，再判断是需求、上下文、实现还是验证出了问题。向AI提供目标、实际行为、最小复现、相关代码与错误输出，让它修正对应原因；反复追加“再好一点”或整段重写，通常会增加试错。

提效的关键是减少无效生成：用现有模式和验收例子缩小范围，小步修改后立即检查，保留已证实的结论与失败原因。需要时换方案或人工处理局部，不必让模型在同一个错误思路里无限循环。

可以按“原来的卡点—主动学习—小范围应用—结果与复盘”讲一段完整经历。下面以学习 Coding Agent 并用于接口回归测试为条件化示例：

我之前维护后端接口时，容易把时间花在重复准备测试数据和补测试骨架上，所以主动学习了 Coding Agent 的仓库检索、任务约束和执行反馈流程。我先看项目已有测试和官方用法，再选一个输入校验改动试用，没有直接让工具重写整个模块。

我负责确定接口约定和验收场景，让工具生成测试初稿，并辅助修改实现。初稿只覆盖了正常输入，我补了空输入、非法参数和下游异常，还修正了一个与业务约定不符的期望值。最终这项改动有了可复现的回归用例和明确的运行方式，原来的失败输入能被稳定检查。

收益主要是减少重复准备工作、加快从想法到可运行初稿的过程；审查业务语义仍需要我完成。因为当时没有统一记录人工开发与辅助开发的总耗时，我只报告这项交付和观察到的变化，不给出未经对照的提效百分比。之后我把反复需要的测试命令和项目约定整理下来，减少每次重新说明的成本。