AI 编程面试 20 题：Codex、Claude Code 与 AI 工具使用全攻略

适用人群：2026 年校招 / 社招后端、前端、移动端工程师

覆盖范围：AI 编程工具选型（Claude Code、Codex、Cursor、Copilot）、Prompt 技巧、上下文管理、Agent 协作、代码审查、安全规范、开放性问题

每道题包含：题目 → 参考答案 → 面试官追问 → 追问答案

[第一部分：工具认知与选型（第 1--5 题）](#第一部分：工具认知与选型（第 1–5 题）)
[第二部分：Prompt 与上下文工程（第 6--10 题）](#第二部分：Prompt 与上下文工程（第 6–10 题）)
[第三部分：工程实践与代码审查（第 11--15 题）](#第三部分：工程实践与代码审查（第 11–15 题）)
[第四部分：进阶与开放性问题（第 16--20 题）](#第四部分：进阶与开放性问题（第 16–20 题）)

第一部分：工具认知与选型（第 1--5 题）

第 1 题：你平时用过哪些 AI 编程工具？Claude Code、Codex、Cursor 有什么区别？

参考答案：

我日常使用三类工具，按任务粒度分工：

Cursor / Copilot（IDE 级）：适合行级、文件级任务。Tab 补全写样板代码、Cmd+K 局部改写、Composer 多文件联动改一个小组件，都是"分钟级"任务，我能全程盯着每一步修改。
Claude Code（CLI Agent 级）：适合模块级、任务级工作。比如让它读整个仓库梳理调用链、跨几十个文件做重构、分析崩溃日志定位问题。它可以自己规划步骤、执行命令、跑测试，我描述清楚目标后去做别的事，过段时间回来看结果。
Codex（云端 / Agent 级）：适合异步委派任务。我把一个定义清晰的 issue 交给它，它在云端沙箱里独立完成并提交 PR，我只需要做 Code Review。它的强项是"并行开多个任务"，比如同时让它修三个不相关的 bug。

核心区别一句话总结：Cursor 是增强编辑器，Claude Code 是终端里的工程师，Codex 是云上的外包同事。选型原则是：任务越大、越需要自主执行，越往 Agent 工具走；任务越小、越需要手感，越留在 IDE 里。

面试官追问： 如果让你只选一个工具，你选哪个？为什么？

追问答案：

选 Claude Code。理由有三点：

能力上限最高：IDE 工具能做的（补全、改写）它都能做，反过来不行。长上下文 + 工具调用能力让它能处理"读整个仓库再动手"的真实工程任务。
可组合性强：CLI 形态意味着可以接脚本、接 CI、接 Git Hook，可以编排进自动化流程，而 IDE 插件基本只能在编辑器里用。
IDE 不可替代性弱：我可以用 VS Code / IDEA 做日常编辑，遇到大任务切到终端调用 Claude Code，两边不冲突；但反过来用 Cursor 就丢失了终端 Agent 的能力。

当然我会补充：这取决于团队形态，如果团队重度依赖结对编程式的即时反馈，Cursor 的体感可能更好。

第 2 题：你在项目中是怎么实际使用这些工具的？举一个具体例子。

参考答案：

用一个真实场景（STAR 结构）：

S（背景）：我们有个老项目要把网络层从回调风格迁移到 async/await，涉及 40 多个调用方。
T（任务）：要求一周内完成，且不能影响线上稳定性。
A（行动）：我先让 Claude Code 读整个网络层模块，生成一份调用关系文档；然后人工确认迁移顺序和分层方案，写进 CLAUDE.md 作为约束；接着让它逐模块改造，每改完一个模块就让它跑对应的单测；我全程做 Code Review，重点关注线程切换和错误处理语义是否改变。
R（结果） ：三天完成迁移，上线后零故障。AI 写了大约 80% 的代码，但方案、顺序、约束是我定的，每一行我都审过。

面试官追问： 这个例子里 AI 犯的最大的错是什么？你怎么发现的？

追问答案：

AI 把一个回调里"失败时重试三次"的隐含逻辑丢了------它把 retry() 调用改成了直接 throw，因为重试逻辑藏在回调闭包里，语义上看起来像普通错误传播。我是在 Code Review 时对照原实现逐函数 diff 发现的，之后补了一个针对重试行为的单测，并把"保留原有重试语义"写进了 Prompt 约束。

这件事给我的教训是：AI 最容易丢的不是代码，而是隐含的业务语义。所以改造类任务我一定会先让它列"原行为清单"，改造后逐条核对。

第 3 题：现场考察------如果面试让你用 Claude Code / Cursor 现场写一个小功能，你会怎么做？

参考答案：

我会按这个流程走，并且全程大声说出我在做什么（面试官考察的是过程，不只是结果）：

澄清需求（2 分钟）：先问清楚边界------输入输出是什么？异常场景怎么处理？要不要写测试？不会上来就开写。
拆解任务（1 分钟）：把功能拆成 2--3 个可验证的小步骤，告诉面试官我的拆解思路。
写结构化 Prompt：包含目标、约束（技术栈、风格）、验收标准（怎么算完成）。不会只写一句"帮我实现 XX"。
审查 AI 输出：逐段读代码，重点看边界条件、错误处理、有没有幻觉 API。发现问题就针对性追问修正，而不是整个重来。
验证：跑测试或手动构造边界输入验证，让面试官看到我在验证。
总结：说明我接受了什么、改了什么、为什么。

面试官追问： 如果 AI 生成的代码跑不通，你会怎么处理？

追问答案：

分三步：先自己花 30 秒看报错，判断是环境问题还是逻辑问题------环境类问题（依赖、版本）通常我自己修更快；逻辑问题我会把报错信息和相关代码喂回给 AI，让它定位。如果 AI 连续两轮没修好，我会果断接管手动修，并告诉面试官："它已经在这个错误上循环两轮了，继续让它试的期望收益低于我手动修的成本。"面试官想看的正是这种"知道什么时候该接管"的判断力，而不是死磕工具。

第 4 题：什么是 Vibe Coding？你怎么看待它？

参考答案：

Vibe Coding 是 Andrej Karpathy 在 2025 年初提出的概念，指用自然语言描述意图、让 AI 生成大量代码、人只负责引导和验收的开发方式。

我的看法分两面：

作为方法论它成立：模型能力已经足够强，"人定方向、AI 写实现、人做审查"的协作模式确实比纯手写快很多，尤其对原型、脚本、CRUD 类任务。
作为态度它危险：如果"Vibe"意味着不看代码、不理解原理、直接上线，那是工程事故的来源。AI 生成代码的安全漏洞率和边界错误率都显著高于人写的代码，不审查就合入等于把风险外包给概率。

所以我的原则是：可以用 Vibe Coding 的速度，但必须用 Code Review 的标准。代码进了我的仓库，就是我的责任，跟是不是 AI 写的无关。

面试官追问： 那 Spec Coding（规范驱动开发）和 Vibe Coding 有什么区别？你用哪种？

追问答案：

Spec Coding 是先把需求、接口契约、验收标准写成明确的规范文档，再让 AI 按规范实现；Vibe Coding 是边聊边改、意图驱动。两者不是对立的：原型阶段用 Vibe 快速试错，进入正式开发就切换到 Spec 模式------把沉淀下来的决策写成 spec 文件（接口定义、数据模型、边界行为），让 AI 对着 spec 干活，这样输出可预期、可验证，也方便多人协作和多 Agent 并行。实际项目里我是两者混用，越接近上线，Spec 的比重越大。

第 5 题：你们团队对 AI 工具有什么使用规范？敏感代码能发给 AI 吗？

参考答案：

核心逻辑、鉴权、加密、支付相关代码不能直接发给云端 AI 服务。具体规范：

分级管理：核心业务代码走私有化部署模型或本地模型；普通业务代码可以用云端工具但要脱敏。
配置隔离 ：用 .cursorignore / .claudeignore 排除密钥文件、配置文件、敏感模块目录，防止工具自动读取上传。
强制审查：AI 生成的代码必须人工 Review + 单测覆盖才能合入，CI 里接 SAST 扫描。
审计留痕：重要模块的 AI 交互记录保留，出问题可追溯。

面试官追问： 如果公司没有私有化模型，业务又要用 AI 提效，怎么平衡？

追问答案：

三个手段：一是代码切片脱敏 ------只发必要的最小代码片段，把密钥、域名、内部接口名替换掉；二是用工具的数据协议 ------选择承诺不训练、零保留的企业版服务（如 Anthropic/OpenAI 企业版），签 DPA；三是架构层隔离------敏感逻辑收敛到独立模块，该模块禁用 AI，其余模块放开。本质上是用架构设计换取工具使用的安全空间。

第二部分：Prompt 与上下文工程（第 6--10 题）

第 6 题：怎么让 Claude Code / Cursor 更好地理解你的项目？

参考答案：

三板斧：

写规则文件 ：项目根目录放 CLAUDE.md（或 .cursorrules），声明语言版本、框架偏好、架构模式（如 MVVM / 分层架构）、命名规范、目录结构说明、禁止修改的文件清单。这相当于给 AI 的入职文档。
先让 AI 生成项目地图 ：新会话先让它读关键入口文件和构建配置（如 pom.xml / package.json），生成模块结构和调用链文档，作为后续对话的基础上下文。
会话卫生：新任务开新会话，防止旧上下文污染；关键约束放在最新消息里重申，因为长对话中靠前的指令权重会衰减。

面试官追问： CLAUDE.md 里你会写什么、不会写什么？写太长有什么问题？

追问答案：

写：不可违反的硬约束 （技术栈版本、架构红线、禁止事项）、项目特有的约定 （目录职责、命名规则）、常用命令（怎么跑测试、怎么构建）。不写：通用的编程常识（模型本来就会）、长篇的业务背景（放进具体任务的 Prompt 里）、容易过时的信息（如具体接口列表，会过期误导）。

写太长的问题：规则文件每次会话都占上下文窗口，太长会稀释注意力------模型对每条规则的遵从度都下降，还浪费 token。我的经验是控制在 100 行以内，只保留"违反了会出事故"的规则。

第 7 题：你写 Prompt 有什么技巧？举个例子说明好的 Prompt 和差的 Prompt。

参考答案：

核心原则：Prompt 的本质是需求文档，不是聊天。

差的 Prompt："帮我写个用户登录接口。"------没有技术栈、没有约束、没有验收标准，AI 只能猜。

好的 Prompt 包含四要素：

复制代码

目标：在 Spring Boot 项目中新增邮箱登录接口 POST /api/auth/login
约束：
- 复用现有的 JwtUtil 和 UserRepository，不要新建重复组件
- 密码用 BCrypt 校验，错误次数超过 5 次锁定 10 分钟
- 遵循项目现有的统一返回格式 Result<T>
验收：
- 给出正常登录、密码错误、账号锁定三种情况的单元测试
- 不修改现有文件，只新增文件

效果差异是数量级的：结构化 Prompt 一次通过率很高，模糊 Prompt 往往要来回三轮以上，还容易产生幻觉 API。

面试官追问： 任务很复杂的时候，一个长 Prompt 说清楚好，还是分多轮交互好？

追问答案：

分阶段，但不是简单分轮 。我的做法是"先计划、后执行"：第一轮只让 AI 出实施方案------改哪些文件、什么顺序、风险点在哪，我审核确认后，再让它按方案逐步执行，每步验证。原因是长 Prompt 一次性塞太多要求，模型会顾此失彼，而且中间出错无法定位是哪一步的指令有问题。分阶段等于在 AI 的工作流里加了人工检查点，这也是 Agent 工具里 Plan Mode 的设计逻辑。另外复杂任务我会控制单次改动的爆炸半径------一次改 3 个文件比一次改 15 个文件，出错的概率和审查成本都低得多。

第 8 题：什么是上下文管理？长任务中上下文溢出怎么办？

参考答案：

上下文窗口是 AI 的"工作记忆"，所有代码、对话、工具输出都在里面。长任务中它会满，导致模型"忘记"早期的约束和代码，输出质量明显劣化（前后不一致、重复犯错、丢失规则）。

应对手段：

预防：任务开始前估算上下文预算，大任务拆小，每个子任务独立会话。
压缩：利用工具的 compact / summarize 功能，把已完成的探索过程压缩成结论。
外置记忆 ：把关键决策、接口契约写进文件（如 CLAUDE.md、spec 文档），上下文丢了可以从文件恢复------文件是比对话更可靠的长期记忆。
主动断舍离：发现 AI 开始犯"已经纠正过的错误"时，说明上下文已经污染或溢出，果断开新会话，带上最小必要上下文重新开始。

面试官追问： 你怎么判断什么时候该开新会话，什么时候继续在当前会话里推进？

追问答案：

三个信号决定开新会话：一是语义切换 ------从"改订单模块"切到"改支付模块"，旧上下文对新任务只有干扰；二是质量劣化 ------AI 开始重复犯已纠正的错误、引用不存在的代码，说明上下文已污染；三是长度临界 ------上下文用量超过约 60--70% 后，模型的指令遵从度会明显下降。反之，如果后续问题依赖前面的探索结论（比如刚分析完调用链，马上要基于它重构），就留在同一会话。判断标准本质是：当前上下文对下一个任务是资产还是负债。

第 9 题：MCP 是什么？你在项目里用过吗？

参考答案：

MCP（Model Context Protocol）是 Anthropic 推出的开放协议，让 AI 工具以标准化方式连接外部数据源和工具------文件系统、Git、数据库、浏览器、Jira、内部 API 等。可以把它理解为"AI 工具的 USB 接口"：工具不用为每个数据源写定制集成，接 MCP Server 就能获得对应能力。

实际用法举例：给 Claude Code 接 Git MCP 让它直接读提交历史分析变更；接数据库 MCP 让它查表结构再写 SQL；接浏览器 MCP 让它验证前端改动效果。在企业内还可以自研 MCP Server 暴露内部系统能力。

面试官追问： MCP 有什么安全风险？权限怎么控制？

追问答案：

风险主要有三类：权限过大 ------比如文件系统 MCP 给了根目录读写权限，AI 误操作可能删文件；提示注入 ------MCP 返回的外部内容（网页、issue 文本）里可能藏恶意指令，诱导 AI 执行危险操作；数据泄露------AI 可能把敏感数据通过 MCP 传到不该去的地方。

控制手段：每个 MCP Server 按最小权限 配置（只读优先、限定目录/库表）；危险操作（写、删、执行命令）开启人工确认；对外部内容源保持警惕，不让 AI 对外部文本里的"指令"照单全收；企业环境对 MCP Server 做白名单管理。本质上，MCP 把 AI 的能力边界扩大了，权限模型必须同步跟上。

第 10 题：什么是 Subagent / 多 Agent 协作？什么场景下用？

参考答案：

多 Agent 是把一个大任务拆给多个相对独立的 Agent 并行或串行执行。以 Claude Code 为例，可以派生 Subagent 去做独立的探索或实现子任务，各自有独立的上下文窗口，最后把结论汇总给主 Agent。

典型场景：

并行探索：让一个 Agent 查日志、一个查数据库、一个读代码，并行定位问题，比串行快很多。
隔离上下文：让 Subagent 去读大文件、跑冗长的测试输出，只把结论带回来，保护主会话的上下文预算。
角色分工：一个写实现、一个写测试、一个做 Review，模拟小团队协作。

面试官追问： 多 Agent 并行最大的问题是什么？怎么解决？

追问答案：

最大的问题是冲突与一致性 ：两个 Agent 同时改同一批文件会互相覆盖；各自做的假设不一致（比如一个认为用 Redis 缓存、一个认为用本地缓存），合并时方案打架。解决办法：一是任务划分时保证正交 ------按模块边界切，让 Agent 之间不共享修改目标；二是共享契约前置 ------接口定义、数据模型先由主 Agent（或人）定好写进 spec 文件，所有 Subagent 对着同一份契约干活；三是合并前集中审查------并行完成后由主 Agent 或人统一 diff 检查。多 Agent 不是免费的午餐，协调成本是真实存在的，只有当任务天然可分解且子任务足够大时才值得用。

第三部分：工程实践与代码审查（第 11--15 题）

第 11 题：你怎么验证 AI 生成代码的正确性？

参考答案：

"能跑"和"正确"之间隔着整个测试体系。我的验证清单：

编译/静态检查：类型错误、lint 问题先过一遍。
单元测试：覆盖正常、边界、异常三类输入------特别让 AI 自己写测试时，要警惕它"让测试迎合实现"而不是验证需求。
行为对照：改造类任务，逐条核对"原行为清单"，防止隐含语义丢失。
审查 AI 特有错误模式：幻觉 API（调了不存在的方法/库）、编造配置项、错误处理被吞掉、并发安全问题（锁、线程切换标注缺失）。
安全扫描：SQL 注入、XSS、硬编码密钥，过一遍 SAST。
运行验证：在真实环境构造边界数据跑一遍，而不只是看代码。

面试官追问： AI 说它"已经跑过测试并且通过了"，你会信吗？

追问答案：

不信，我要看证据 。Agent 工具有个已知的失败模式：声称"测试通过"但实际没跑，或者跑了但忽略了失败用例，或者为了让测试通过把断言改宽松了。我的做法是看它的工具调用记录------确认测试命令真的执行了、退出码是 0；对关键测试，我会自己手动重跑一遍；还会检查它有没有顺手修改测试文件本身。"信任但验证"对 AI 输出永远适用，而且验证成本必须计入 AI 提效的净收益------如果审查一个模块的时间超过自己写的时间，那这个任务就不该交给 AI。

第 12 题：AI 生成的代码出现过哪些典型的坑？举例说明。

参考答案：

按出现频率排：

幻觉 API：编造不存在的方法、库、配置项，尤其在长上下文任务后期更容易出现。对策：编译 + 查阅官方文档核实。
边界遗漏：空集合、null、并发、超时、重试------AI 默认写"happy path"。对策：Prompt 里显式列出边界场景，验收时逐个构造。
安全漏洞：拼接 SQL、前端直接插 HTML、密钥硬编码、过宽的 CORS。对策：SAST 扫描 + 安全相关代码人工写。
过度工程：为一个简单需求引入三层抽象、五个设计模式。对策：Prompt 里明确"最小实现，不要引入新抽象"。
越权修改：让它改 A 模块，它"顺手"重构了 B 模块。对策：限定改动范围，Review diff 时检查是否越界。

面试官追问： 这些坑里，你觉得哪个对团队危害最大？

追问答案：

越权修改 + 过度工程的组合 ，因为它最隐蔽。幻觉 API 编译就报错，边界遗漏测试能抓住，但"AI 顺手把无关模块重构了"这种改动能过编译、能过测试，Review 不仔细就合进去了------它改变了你没要求改变的代码路径，引入的回归风险可能几周后才暴露，而且污染了 git 历史，让回溯变难。所以我在团队里推的规矩是：AI 改动的 diff 必须完整 Review，改动范围必须在 Prompt 里显式约束，CI 里对改动文件数设阈值告警（一个改 3 个文件的任务突然动了 20 个文件，自动打回）。

第 13 题：用 AI 工具做 Code Review，靠谱吗？AI 能 Review AI 吗？

参考答案：

能用，但要摆正位置：AI Review 是第一道筛子，不是最终守门员。

AI Review 擅长：风格一致性、常见坏味道、明显的空指针/资源泄漏、测试覆盖缺口提醒。它不擅长：业务语义正确性（代码是否符合需求文档没写出来的潜规则）、架构层面的长期影响、需要组织上下文才能判断的取舍。

"AI Review AI"是可行且值得做的------用不同模型做交叉 Review 效果不错，因为生成模型和审查模型的错误模式不完全相关。但最终责任必须在人：合并按钮前的最后一眼必须是人看的，尤其是资金、安全、数据一致性相关代码。

面试官追问： 如果 AI Review 和人 Review 结论冲突，听谁的？

追问答案：

默认听人的，但要把冲突当信号而不是噪音 。冲突分两种情况：AI 报了人认为不是问题的问题------通常是 AI 缺少业务上下文，误报，我会把这个约束写进规则文件降低未来误报；人觉得没问题但 AI 报了------这时候要警惕，AI 在模式匹配上比人敏感（比如它发现这个写法和某处不一致），值得花两分钟核实。真正危险的场景是人因为 AI 没说问题就放弃思考------AI Review 通过会给人虚假的安全感。所以流程设计上，人 Review 应该先看代码再看 AI 意见，而不是反过来。

第 14 题：AI 编程对 Git 工作流有什么影响？你们的提交规范有变化吗？

参考答案：

影响很大，核心是提交粒度变细 + 检查点前移：

高频小提交：AI 每完成一个可验证的子任务就提交一次，这样 AI 改崩了可以秒级回滚------版本控制从"记录历史"变成了"AI 操作的安全网"。
提交信息标注 ：AI 生成的提交在 message 里标注（如 [AI-assisted]），方便后续追溯和统计 AI 代码的缺陷率。
分支策略调整：AI 任务开独立分支，人只在审查通过后合并，隔离爆炸半径。
Review 前置到 Prompt 阶段：很多团队在 PR Review 之外增加了"Prompt / Spec Review"------先审需求描述和约束，再审代码。

面试官追问： AI 生成代码的归属和责任怎么算？出了线上事故算谁的？

追问答案：

算提交人的，没有任何争议空间。代码进了仓库，责任主体就是 Review 并合入它的工程师，这跟"抄了 Stack Overflow 的代码出 bug 算谁的"是同一个问题------工具不承担工程责任。这也是为什么团队规范里"AI 代码必须人工 Review"不是形式主义。从管理角度，我还见过团队做的一件事：统计 AI 标注提交的事故率 vs 人工提交的事故率，用数据校准"哪些模块可以放心用 AI、哪些必须收紧"，而不是拍脑袋定规范。法律层面，AI 生成代码的版权归属、开源许可证污染（AI 可能输出与 GPL 代码雷同的片段）也是企业合规需要关注的，敏感项目建议跑代码溯源扫描。

第 15 题：现场调bug题------给你一段有问题的代码，允许你用 AI 工具，你的调试流程是什么？

参考答案：

我的流程是"先假设、后验证、AI 当放大镜"：

先自己看 2--3 分钟：读代码、看报错，形成初步假设。这一步不能省------直接扔给 AI 等于放弃定位能力的展示。
向 AI 提供高质量上下文：不是只贴代码，而是附上错误堆栈、复现步骤、我的初步假设，让 AI 在我的方向上验证或证伪。
二分定位：让 AI 帮忙加日志 / 写最小复现用例，缩小范围。
修复后做根因分析：不只改对，还要说清根因------是这个 case 没考虑到，还是设计层面有缺陷？后者要追问是否需要系统性修复。
补回归测试：为这个 bug 补一个会失败的测试，防止复发。

面试官追问： 如果 AI 给的修复方案能跑通但你没看懂原理，你会接受吗？

追问答案：

不接受，先弄懂再合入 。跑通但不懂的代码是定时炸弹------下次它在边界场景出问题，我连从哪里查起都不知道，而且 Review 别人的代码时我也无法辩护这段逻辑。我会让 AI 解释修复原理（"为什么这样改是对的？原来的代码错在哪？"），或者自己查文档验证。如果实在时间紧迫要先合入，我会：加详细注释标明"此处机制待确认"、建跟踪任务、限制该代码的影响范围。但这是例外不是常态。"不提交自己不理解的代码"是 AI 时代工程师最不能丢的底线------工具可以加速理解，但不能替代理解。

第四部分：进阶与开放性问题（第 16--20 题）

第 16 题：AI 编程工具最大的风险是什么？怎么规避？

参考答案：

我认为最大的风险不是安全漏洞，而是能力退化与责任稀释：

能力退化：长期只审不写，基本功萎缩，遇到 AI 解不了的硬问题（复杂并发、性能优化、底层原理）时没有储备。对策：关键模块手写、定期做不借助 AI 的编码练习、Code Review 时强制自己先给结论再看 AI 意见。
责任稀释："这是 AI 写的"成为 bug 的借口。对策：制度上明确提交人责任制，代码归属不分人机。
架构失控：AI 倾向局部最优，每个任务都合理，叠加起来架构腐化。对策：架构决策人审，AI 只在既定架构内实现。
安全合规：漏洞、许可证污染、数据外发。对策：SAST、溯源扫描、数据分级。

面试官追问： 你说能力退化，那初级工程师还有必要练基本功吗？直接学怎么指挥 AI 不行吗？

追问答案：

不行，顺序不能反 。指挥 AI 的能力本身依赖基本功：你不会并发，就看不出 AI 写的代码有竞态；你不懂索引原理，就审不出 AI 生成的慢 SQL。AI 输出的质量上限，很大程度上取决于审查者的判断下限。行业数据也印证了这点：资深工程师从 AI 工具获得的效率提升远大于初级工程师------因为资深工程师能驾驭它，初级工程师容易被它带偏。所以对初级的建议是：用 AI 加速学习，而不是跳过学习------让 AI 解释原理、出练习题、Review 你的手写代码，把它当导师而不是替身。

第 17 题：你怎么看待 AI 对后端 / 前端开发岗位的影响？初级程序员会被淘汰吗？

参考答案：

岗位不会消失，但工作内容的重心在迁移：

被压缩的：样板代码、CRUD、简单单测、文档初稿------这些占初级工作量的比例在快速下降。
被放大的：系统设计、复杂业务建模、性能与稳定性治理、AI 输出质量的判断力、跨团队协作。
新出现的：Agent 工作流设计、Prompt / 上下文工程、AI 代码审查体系、内部 AI 工具链建设。

初级岗位减少的不是需求，而是"只会写 CRUD 就能拿到 offer"的时代结束了。门槛从"会写代码"上移到了"会定义问题 + 会验证方案"。

面试官追问： 那你觉得未来三年工程师的核心竞争力是什么？

追问答案：

按优先级排：

问题定义能力：把模糊业务需求翻译成精确的、可验证的技术规格------这正好是 Prompt 的本质，也是 AI 替代不了的部分。
系统判断力：架构取舍、技术选型、性能权衡------需要全局上下文和踩坑经验，AI 只有局部视野。
验证与审美：快速判断 AI 输出的对错优劣，知道"好代码"长什么样。
杠杆思维：把 AI 当团队用------会拆解任务、会并行委派、会建自动化流程，一个人产出过去一个小团队的量。
基本功：前面所有能力的地基，包括计算机基础和领域深度。

一句话：从"代码的生产者"转向"技术方案的负责人"。

第 18 题：如果让你评估一个陌生候选人的 AI 协作能力（你是面试官），你会看什么？

参考答案：

我会设计一个 60 分钟的现场任务，观察五个维度：

任务拆解：拿到需求是先澄清拆解，还是直接整段扔给 AI------前者是工程师思维，后者是抽奖。
Prompt 质量：约束是否具体、验收标准是否明确。
审查行为：会不会逐行读 AI 输出，能不能抓住边界问题------我会故意让任务里有一个 AI 容易写错的边界 case。
介入时机：AI 卡住时，是死磕、乱试，还是判断后手动接管。
所有权：最后能不能讲清每一行代码为什么这么写------讲不清的，代码不是自己"拥有"的。

面试官追问： 候选人 AI 用得很溜但基本功明显弱，你会给过还是挂？

追问答案：

看岗位，但默认挂 。AI 熟练度三个月能练出来，基本功三年未必补得上，招聘应该押注难培养的那个维度。例外是：岗位本身就是 AI 工具链 / Agent 应用方向，且候选人展现出很强的学习能力（比如能讲清 AI 输出背后的原理，只是手写不熟练），可以给过但要在 offer 里明确成长要求。最怕的一种画像是"AI 熟练 + 基本功弱 + 自以为很强"------工具的流畅度掩盖了判断力的缺失，这种人给团队引入的风险大于产出。反过来，基本功强 + AI 用得保守的候选人我通常给过，因为保守是可以被培训和环境改变的。

第 19 题：公司内部要建设 AI 编程提效体系，你会怎么推进？

参考答案：

按四个阶段推进：

试点期：选一个意愿高的团队，选定工具栈（IDE + CLI Agent 组合），跑通"规则文件 + 权限配置 + 审查流程"的最小闭环，用前后对比数据说话（交付周期、缺陷率、人均产出）。
规范化：沉淀团队级的 CLAUDE.md 模板、Prompt 模式库（常见任务的标准 Prompt）、安全红线清单、AI 代码 Review Checklist。
平台化：接 MCP 打通内部系统（文档库、缺陷库、发布系统），建内部 Agent 市场 / Skills 库，让各团队能复用彼此的 AI 工作流沉淀。
度量与迭代：统计 AI 代码占比、AI 提交缺陷率、审查耗时占比，用数据调整各模块的 AI 使用松紧度。

面试官追问： 怎么衡量 AI 提效是真的提效，而不是"看起来快"？

追问答案：

关键是不能只看"代码产出速度"，要看端到端交付指标：

前置指标：需求到上线周期（lead time）、PR 从提交到合入的时间。
质量对冲指标：线上缺陷率、回滚率、事故数------如果产出快了 50% 但缺陷率翻倍，净收益是负的。
隐藏成本：Code Review 耗时变化（AI 代码审查负担通常更重）、新人 onboarding 难度。
对照实验：最严谨的方式是同类任务分组对照------一组用 AI 一组不用，比交付时间和三个月后的缺陷率。

行业里很多"提效 50%"的宣传只算了打字时间，评审、调试、返工才是软件交付的大头，度量体系必须覆盖全链路，否则就是在优化局部、恶化全局。

第 20 题：AI 编程接下来会怎么发展？你在做什么准备？

参考答案：

我看到的三个趋势：

从辅助到委派：工具形态从"补全 → 对话 → 自主执行"演进，工程师越来越多地写 Spec、审 PR，越来越少地手写实现。异步 Agent（如 Codex 的云端任务模式）会成为标配，一个人同时推进多个任务流。
从单 Agent 到组织化：多 Agent 分工、Agent 间的契约与协作协议会成为新的工程问题，"管理 AI 团队"开始像管理真人团队一样需要方法论。
从通用到内嵌：AI 能力会沉到 CI/CD、监控、运维等各个环节，不只是编码环节，全研发链路都会被重构。

我的准备：保持手写核心代码的手感；系统性练习任务拆解与 Spec 写作；在团队里主导 AI 工作流试点，积累"管 AI"的实证经验；持续跟踪模型能力边界的变化------知道 AI 今天不能做什么，和知道它能做什么同样值钱。

面试官追问： 如果三年后 AI 能独立完成 90% 的编码工作，工程师这个角色的护城河在哪？

追问答案：

护城河在三个地方：

责任与信任：系统出事故时，需要一个能签字负责的主体。企业不会把资金系统、医疗系统的最终决策权交给一个无法追责的实体------这不是技术问题，是组织和法律问题。
模糊地带的判断：真实业务里大量决策发生在"需求没说清、约束互相冲突、各方利益要平衡"的地带，这需要组织上下文、商业理解和人际协调，AI 拿到的是过滤后的二手信息。
定义"什么值得做"：AI 优化的是"怎么做"，但"做什么、不做什么"是价值判断，依赖对业务和用户的理解。

所以我对自己的定位是：成为那个给 AI 下定义、做取舍、负责任的人。编码能力会变便宜，但定义问题的能力、承担责任的意愿、跨域判断的经验，会持续升值。与其担心被替代，不如确保自己站在分工链的上游。

附录：面试准备速查清单

准备项	自检问题
工具熟练度	能否说出 Claude Code / Codex / Cursor 各自最适合的场景？
实战案例	是否有 2--3 个 STAR 结构的 AI 协作案例（含 AI 犯错+你纠正的细节）？
规则文件	能否默写出一份合格的 CLAUDE.md / .cursorrules 结构？
审查方法论	能否脱口而出 AI 代码的 5 类典型错误及对策？
安全规范	敏感代码分级、.ignore 配置、SAST 流程是否讲得清？
开放题观点	对"AI 替代程序员""核心竞争力"是否有自己一贯的、可辩护的观点？
现场实操	是否练过"边用 AI 边讲解"的 live coding（考察过程而非结果）？

最后一句提醒：面试官问 AI 工具，本质上问的不是工具------工具三个月一换代，答案会过期。他在乎的是：你有没有自己的方法论、能不能驾驭工具而不被工具驾驭、以及出了问题时你敢不敢负责。所有的题，最后都回到这三个点上。