AI 辅助开发的正确工作流是什么？

2026年阅读约 8 分钟面试指南 · AI面试

AI 面试 AI编程

AI编程面试题：人机协作开发工作流，任务拆解、上下文工程、规则文件、先测后码、迭代修正、遗留代码重构与单测生成实战，分三层讲解。

一句话总结

正确工作流的灵魂是角色定位：人是 owner，AI 是不需要休息的初级搭档——人负责拆任务、给上下文、做验收，AI 负责高速产出初稿。标准循环：拆小任务 → 给足上下文 → 生成 → 测试验证 → 人工 review。核心技能不是"会写提示词"，而是上下文工程——决定给模型看什么、不给它看什么。

初级理解

任务拆分决定成败："帮我写一个电商下单功能"是坏任务（歧义巨大）；"为本项目写 OrderService.createOrder 方法，遵循接口约定（见 IOrderService），扣减库存用现有 StockService.deduct，只实现主流程，异常抛 BusinessException"才是好任务。判断标准：任务的验收条件你能一句话说清，AI 才可能做对。

小步快跑：一次让 AI 做一个函数/一个用例，验证通过再下一步；一次性生成 500 行然后逐行调试，总耗时反而高于分步走。每个小步都落一次 commit，随时可回退。

新手最常见误区：把 AI 当搜索引擎用一句话提问，然后抱怨答得泛——你给一个新同事安排活儿都不会只说三个字，对 AI 也一样。

中级深入

上下文工程四要素：

项目约定：规则文件（.cursorrules / CLAUDE.md）沉淀技术栈、目录结构、代码风格、禁用项——让 AI 每次开口就"懂规矩"
相关代码：显式给出接口定义、调用方示例、相似实现（"参考 OrderService 的写法"）——AI 模仿能力远强于凭空设计
验收标准：测试用例/输入输出示例直接给——示例是最精确的规格说明
负面清单：明确"不要做什么"（不要引入新依赖、不要改动现有方法签名）——防止 Agent 自作主张

先测试后实现（TDD 与 AI 天然契合）：人写测试用例（定义"对"），AI 写实现（追求"绿"）——验收标准前置，AI 跑偏立即被测试抓住。这是把"AI 不可靠"变成"可控"的最实用一招。

迭代修正的技巧：带着报错回去（贴完整堆栈 + 相关代码），说清"期望 vs 实际"；连续两轮修不好就换策略——让 AI 先解释代码/复述需求，而不是继续盲改；修好一个问题后又坏另一个 → 说明任务太大，重新拆。

高级拓展

大代码库的上下文策略（资深岗考点）：上下文窗口装不下整个仓库——分层给：任务相关的直接文件 + 接口签名摘要 + 架构文档；用工具的代码库索引（语义检索）自动带出相关片段；把"模块地图"写进规则文件。万行级重构拆成阶段：先让 AI 出迁移方案 → 人审方案 → 按文件分批执行 → 每批跑回归。

工程化集成：脚手架与样板由 AI 生成并入库团队复用；CI 中接 AI code review（第一道筛子，人审聚焦设计）；内部工具文档喂给 Agent（通过 MCP 连接工单/文档系统），让"查资料"也自动化。度量看交付：周期时间、变更失败率、返工率。

遗留系统改造工作流（高价值场景）：① 让 AI 为老模块生成"行为快照"测试（characterization tests）锁住现有行为；② 再让 AI 重构内部实现；③ 测试保持绿色即安全。——先锁行为再动刀，这句话说出来就是经验。

面试加分项：讲一个"AI 走偏被我纠正"的具体故事（比如它自作主张引入了新依赖/改了公共接口），比讲十个成功案例更有说服力——证明你真的在日常使用且有把关意识。

实战场景

场景一：新功能开发全流程（面试标准答案模板）

1. 人：拆任务（接口设计 + 验收用例），写测试骨架 2. AI：按测试实现代码（给足接口定义与相似实现参考） 3. 跑测试 → 不绿则带报错迭代（≤3 轮，不行重拆） 4. 人：review diff（边界/异常/安全）→ 提 PR → 正常流程合入 5. 复盘：这次 AI 踩的坑回写到规则文件

场景二：给老项目补单测

// 逐函数让 AI 生成测试，但人工把关断言质量： // 删除"形式断言"（assert result != null 这种），补上业务断言 // 优先覆盖：分支复杂的核心逻辑、曾出过线上问题的代码 // 产出的测试跑 mutation testing（如 PIT）验证有效性

场景三：线上 bug 排查

// 把"报错堆栈 + 相关代码 + 最近变更"一次性给 AI // 让它列可能原因并排序，逐个验证——AI 是假设生成器，验证靠你 // 注意：不要把敏感配置/用户数据贴给外部工具（合规红线）

面试模拟

Q：什么是"上下文工程"？为什么比提示词技巧更重要？

A：上下文工程是决定"模型这一轮能看到什么信息"的系统化方法——项目规范、相关代码、示例、负面清单的组织与取舍。它比话术重要是因为：模型输出质量的方差主要来自信息不足与误导，而不是措辞花哨度。工程化手段：规则文件沉淀 + 显式引用 + 按任务裁剪上下文，本质是给 AI 做信息架构。

Q：怎么避免团队里有人"AI 生成直接上线"？

A：靠流程不靠自觉：① AI 产出走同一 PR 门禁，CODEOWNERS 覆盖核心模块；② CI 强制单测覆盖率阈值 + 静态扫描 + 依赖审计；③ 规则文件统一 AI 行为（禁用库、风格）；④ 事故复盘对事不对人——把踩坑点变成检查项。技术上堵死"绕过"的可能，文化上允许试错。

Q：AI 一直改不对一个复杂 bug，你的处理流程？

A：三轮法则——连续三轮没修好就停下。第一步换任务：让 AI 复述问题、解释相关代码，往往是我给的上下文有误；第二步换人：自己读代码定位根因（这时发现 AI 缺的关键信息）；第三步换拆法：把"修复 bug"拆成"先复现的测试 + 最小修复"。核心认知：AI 修不好通常是我没把问题定义清楚，止损比硬磕重要。