Java 面试 & 后端通用面试指南（Github 收获155+k Star，共有 600+ 位贡献者共同参与维护和完善）：javaguide.cn。

腾讯面试的时候，面试官问我：“用过什么 AI 编程工具？”。我说：“Trae。”

空气突然安静了两秒。

我搞不清楚为什么面试官沉默了，当时我还在想：“是不是我回答得不够高级？”。

面试被挂后才意识到：Trae 是字节的，腾讯家的是 CodeBuddy，阿里家的是 Qoder。

段子归段子，面试季要来了，Guide 这里总结了 7 道当下校招和社招技术面试中经常会被问到的一些 AI 编程相关的开放性问题，希望对你面试有用：

1. 用过什么 AI 编程 IDE 吗？什么感觉？
2. 知道哪些 Cursor 使用技巧？
3. Skills 了解吗？你的项目用到了吗？
4. 你如何看待 AI 对后端开发影响？
5. 你觉得 AI 会淘汰初级程序员吗？
6. AI 带来的最大风险是什么？
7. 你觉得未来 3 年后端工程师的核心竞争力是什么？

用过什么 AI 编程 IDE 吗？什么感觉？

我用过几款 AI 编程工具，例如 Cursor、Trae、Claude Code，其中我日常开发中主要用的是 Cursor（根据你自己的使用去说就好，我这里以国内用的比较多的 Cursor 为例）。

目前整体感觉是：AI 编程能力进步真的太快了！它现在已经不是几年前简单的代码补全工具，而是一个可以深度协作的工程助手。

我总结了一套自己的使用方法论：

1. 在接手复杂项目或模块时，我不会直接让 AI 写代码，而是先让 Cursor 分析整个代码库，生成一份包含核心架构、模块职责和数据流的文档。这一步非常关键，因为它决定了后续协作的质量。只有当我和 AI 对项目有一致理解时，后续产出才会稳定、高质量。
2. 对于每个独立的开发任务，我都会开启一个新的对话，并提供必要的上下文，包括需求背景、涉及模块和约束条件。这种方式能显著减少上下文污染，让 AI 生成的代码更加精准，基本不需要大幅返工。
3. 我也会定期删除冗余实现和废弃代码。旧代码会误导 AI 的判断，增加上下文噪音，长期不清理会直接影响协作效率。

AI 是一个强大的知识库和辅助工具，可以帮我们快速实现功能、学习新知识。但如果完全依赖 AI 写代码而不理解其原理，个人技术能力可能会退化。

因此我会坚持几个原则：

• AI 生成代码之后必须人工 Review。
• 关键逻辑必要时自己重写。
• 核心路径必须做压测和边界测试。

我希望效率提升，但不以牺牲技术能力为代价。

知道哪些 Cursor 使用技巧？

这里是以 Cursor 为例，其他 AI IDE 都是类似的。

1. 先理架构再动手：无论是自己写代码还是让 AI 生成代码，都必须先明确需求、整体架构和模块边界。如果在架构模糊的情况下直接编码，很容易出现重复实现或职责冲突，后期修改成本反而更高。
2. 单 Chat 专注单功能：新功能或大改动开启新的 Chat，并在开头引入项目结构说明或关键文档作为上下文基础。这样可以避免历史对话干扰，提高输出质量。
3. 功能落地后写指南：让 AI 总结实现过程，抽象出通用步骤，形成“操作指南”。比如新增接口的标准流程、文件导出的统一实现方式等。这些沉淀下来的内容，可以在后续类似需求中快速复用。
4. 不依赖 AI，主动复盘：AI 仅作辅助，代码生成后需认真 Review，理解原理、优化不合理处，避免技术停滞。
5. 定期删无用代码：清理冗余代码，减少对 AI 的误导和上下文干扰，提升开发效率。
6. 用好配置文件：.cursorrules 定义 AI 生成代码的规则、风格和常用片段；.cursorignore 指定不允许 AI 修改的文件 / 目录，保护核心代码。
7. 持续维护文档：项目重大变更后，让 AI 同步更新文档、记录 “踩坑” 经验，积累团队知识库。
8. 让 AI 先 “学” 项目：大型项目先让 Cursor 分析代码库，生成含架构、目录职责、核心类等的结构文档，作为后续开发的基础上下文。

Skills 了解吗？你的项目用到了吗？

Skills 可以简单理解为把“能力”做成可复用、可调用、可组合的模块。

为什么要有 Skills？

传统用法是：

• 每次写一大段 Prompt
• 把规则、步骤、输出格式都塞进去

这样的话，会存在重复、不稳定、难复用、难组合等问题。

Skills 的目标是把能力沉淀下来，这样：可复用、可组合、可被调用、更工程化。

AI 像调用函数一样调用能力比如：

• summarize-article - 文章总结
• analyze-resume - 简历分析
• generate-interview-questions- 面试问题生成
• code-review - 代码审查

在多人协作场景下，我会利用 AI 做 Code Review 辅助。把 PR 内容交给 Cursor，让它从可读性、异常处理、一致性和潜在风险角度进行分析，然后再人工判断。这样可以提升 Review 的覆盖度，但最终决策仍由人完成。

这个场景其实非常适合通过 Skill 来固化。

我会定义一个专门的 Code Review Skill，明确它的职责，例如：从架构合理性、异常处理完整性、日志规范、边界条件覆盖、安全风险、性能隐患等多个维度进行结构化审查。这样每次 Review 不需要重复写 Prompt，只需要调用 Skill，就能获得稳定、标准化的分析结果。

除了 Code Review，我也会定义其他 Skill，例如：

• api-endpoint-generator - 按项目统一响应结构与异常模型生成标准化接口代码
• database-access-review - 审查数据库访问逻辑，关注索引使用与慢查询风险
• refactor-analysis - 先评估影响范围与依赖关系，再输出分步骤重构方案
• security-audit - 扫描 SQL 拼接、XSS、权限绕过等常见安全风险

当 Skill 被定义清晰后，AI 的角色就从“自由发挥”变成“按规则执行”。这不仅提升输出质量，也减少了风格漂移和架构失控的风险。

从团队协作角度看，Skill 还可以成为一种“隐性规范载体”。新人不需要完全理解所有约定，只要调用对应 Skill，就能得到符合团队标准的实现建议。这在一定程度上提升了整体一致性。

这里 Guide 多提一下，回答这个问题的时候，你也可以说自己团队用到了一些开源的软件开发 Skills 集合，例如 Superpowers 中内置的。

你如何看待 AI 对后端开发影响？

我认为 AI 不会取代后端工程师，但会显著改变后端工程师的工作方式和能力结构。

AI 将我们从重复的、模式化的工作中解放出来，成为我们最强的帮手：

• 在编码层面：AI 编程工具（如 Cursor）极大地提升了 CRUD、单元测试、胶水代码的编写效率。以我自己的经验，常规业务接口的开发效率可提升 50%~70%，尤其是样板代码和重复逻辑的生成，AI 表现出色。
• 在架构层面：AI 正在催生新的应用范式，比如智能体（Agent）驱动的自动化业务流程，后端需要提供更灵活、更原子化的能力接口。传统的"大而全"接口正逐步拆解为可被 AI 调用的原子化能力。
• 在运维与排障层面：AI 可以辅助分析日志、监控告警，甚至预测系统瓶颈，让问题排查更智能。例如，基于 AIOps（智能运维）的工具可以自动分析异常日志模式，定位根因。

AI 让后端工程师能更专注于业务建模、复杂系统设计和架构决策这些更具创造性的核心工作。并且，AI 同样能够辅助我们更好地完成这些事情。

拿我自己来说，我经常会和 AI 讨论业务和技术方案，它总能给我不错的启发——尤其是在需求拆解和技术选型时，AI 能提供多角度的思考。

你觉得 AI 会淘汰初级程序员吗？

短期内不会淘汰，但会彻底改变初级程序员的能力结构。

以前初级工程师的价值在于：

• 写 CRUD 增删改查
• 写基础接口
• 写 SQL 查询语句
• 写基础工具类/配置

现在这些工作 AI 都能做得很好，甚至更高效、更少出错。但这并不意味着初级程序员会被淘汰——而是他们的价值创造点发生了迁移。

未来初级工程师需要具备：

• 需求拆解能力：将模糊的业务需求转化为清晰的技术任务。
• 业务理解能力：理解领域模型和业务规则，而不仅是"翻译需求"。
• 架构感知能力：理解系统整体架构，知道自己代码在系统中的位置。
• Prompt 表达能力：能精准地描述问题，从 AI 获取高质量答案。

AI 让编程门槛变低，但对"理解能力"的要求反而更高。未来的初级工程师更像是一个"AI 协调者"，而非单纯的"代码编写者"。

从企业招聘角度看，纯编码能力的需求会减少，但对"能利用 AI 快速交付业务价值"的工程师需求会增加。

AI 带来的最大风险是什么？

我认为主要有三个层面：

1. 技术能力退化

过度依赖 AI 会导致工程师自身技术能力的退化，尤其是：

• 调试能力下降：习惯让 AI 排查问题，自身对底层原理的理解变浅。
• 代码敏感度下降：对"好代码"和"坏代码"的判断能力变弱，甚至不知道什么是好代码。
• 架构思维退化：长期只关注功能实现，忽视架构设计和扩展性。

2. 架构失控

AI 生成的代码往往关注"当前功能可用"，容易忽视：

• 模块边界：生成代码可能职责不清，导致模块耦合严重。
• 技术债务：为快速实现功能，可能引入临时方案或反模式。
• 一致性：不同 Chat 生成的代码风格和模式可能不一致。

3. 安全风险（尤其需要重视）

• 代码漏洞：AI 可能生成包含安全漏洞的代码（如 SQL 注入、XSS、权限校验缺失）。
• 数据泄露：不当使用可能泄露公司代码、业务逻辑给外部模型（尤其是云端托管的 AI 服务）。
• 供应链风险：AI 推荐的依赖包可能存在已知漏洞或恶意代码。
• 密钥泄露：AI 生成的代码可能硬编码密钥、Token 等敏感信息。

因此我认为企业使用 AI 必须建立配套的安全治理体系：

• 强制代码审查：AI 生成的代码必须经过人工 Review 才能合并。
• 自动化安全扫描：集成 SAST（静态分析）、SCA（依赖分析）到 CI/CD 流程。
• 明确数据合规边界：规定哪些代码/数据不允许发给外部 AI，必要时使用私有化部署。
• 访问审计：记录 AI 工具的使用日志，便于事后追溯。

你觉得未来 3 年后端工程师的核心竞争力是什么？

我认为核心竞争力的焦点会从"写代码能力"转向以下四个维度：

1. 系统设计能力

AI 非常擅长生成单个功能的代码，但系统级设计仍需工程师主导：

• 服务拆分与模块边界划分
• 微服务与单体架构权衡
• 数据模型设计与一致性策略
• 接口版本演进策略
• 分布式事务与幂等设计

2. 复杂业务建模能力

过去我们说 AI 不擅长领域建模，但现在情况已经变了。AI 在需求拆解、规则梳理、场景推演等方面已经很强。

不过，还是需要工程师配合将业务规则转化为适合当前项目可执行的设计：

• 领域驱动设计（DDD）建模
• 业务流程抽象与状态机设计
• 边界上下文划分

3. 性能与稳定性治理能力

AI 生成的代码往往只关注功能，性能和稳定性需要深度优化：

• SQL 慢查询优化与索引设计
• 缓存策略设计与一致性保障
• 服务降级、熔断、限流方案
• 容量规划与弹性伸缩

在性能治理阶段，我也会借助 AI 做方案对比与优化思路发散，但最终仍需通过压测与数据验证。

4. AI 协作能力

如何高效地与 AI 协作本身就是一种核心竞争力：

• 精准表达需求（Prompt 能力）
• 拆分问题并引导 AI
• 判断 AI 输出质量
• 代码安全与合规校验
• 结合 AI 工具链（如 Cursor 规则、自定义插件）

未来竞争的关键不再是“代码产出速度”，而是“系统设计质量”和“业务价值交付能力”。

大模型实战项目推荐

推荐一个基于 Spring Boot 4.0 + Java 21 + Spring AI 2.0 的 AI 智能面试辅助平台。系统提供三大核心功能：

1. 智能简历分析：上传简历后，AI 自动进行多维度评分并给出改进建议
2. 模拟面试系统：基于简历内容生成个性化面试题，支持实时问答和答案评估
3. RAG 知识库问答：上传技术文档构建私有知识库，支持向量检索增强的智能问答

项目地址 （欢迎 star 鼓励）：

• Github：https://github.com/Snailclimb/interview-guide
• Gitee：https://gitee.com/SnailClimb/interview-guide

完整代码完全免费开源，没有 Pro 版本或者付费版！

《SpringAI 智能面试平台+RAG 知识库》配套实战项目教程正在持续更新，涉及到 Prompt Engineering、大模型集成、RAG（检索增强生成）、高性能对象存储与向量数据库。Spring AI 和 RAG 面试题已更新，两篇加起来接近 60 道题目。