9 道 AI 编程相关的开放性面试问题

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

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

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

段子归段子！今天 Guide 分享 7 道当下校招和社招技术面试中经常会被问到的 AI 编程开放性问题，希望对你有帮助。通过本文你将搞懂：

1. ⭐ AI 编程 IDE：Cursor、Claude Code 等 AI 编程工具有什么使用技巧？如何建立自己的使用方法论？
2. ⭐ AI 对后端开发的影响：你如何看待 AI 对后端开发的影响？AI 会淘汰初级程序员吗？AI 带来的最大风险是什么？
3. ⭐ 未来核心竞争力：你觉得未来 3 年后端工程师的核心竞争力是什么？

AI 编程 IDE 和使用技巧

用过什么 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 分析代码库，生成含架构、目录职责、核心类等的结构文档，作为后续开发的基础上下文。

知道那些 Claude Code 使用技巧？

和上一个问题其实是有重合的，我单独分享过一篇：⭐Claude Code使用技巧总结。

AI 对后端开发的影响

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

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

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

• 在编码层面：AI 工具在生成模式化代码（Boilerplate）方面表现卓越，CRUD、单元测试、胶水代码的编写效率可提升 50%~70%。但在分布式约束（如分布式锁的超时续租、消息队列的 Exactly-once 语义、接口幂等性设计）上，AI 存在显著的**"幻觉"风险**——它往往只给出 Happy Path 代码，忽略了生产环境中的异常补偿逻辑、竞态条件处理和分布式事务边界控制。
• 在架构层面：AI 正在催生新的应用范式，比如智能体（Agent）驱动的自动化业务流程，后端需要提供更灵活、更原子化的能力接口。传统的"大而全"接口正逐步拆解为可被 AI 调用的原子化能力。
• 在运维与排障层面：AI 可以辅助分析日志、监控告警，甚至预测系统瓶颈，让问题排查更智能。例如，基于 AIOps（智能运维）的工具可以自动分析异常日志模式，定位根因。

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

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

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

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

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

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

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

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

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

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

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

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

我认为主要有三个层面：

1. 技术能力退化

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

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

2. 架构失控

AI 生成的代码往往关注"当前功能可用"，容易忽视长期架构健康度。这很大程度上源于 Vibe Coding（氛围编程）——依赖模糊意图让 AI"自由发挥"。

• 模块边界模糊：AI 倾向于"快速完成功能"，可能将多个职责混入同一模块。建议在编码前明确模块职责（DDD 风格的 Context Boundary），通过预先定义的接口契约约束 AI 生成范围。

• 技术债务累积：为快速实现功能，AI 可能使用硬编码、绕过标准异常处理、引入不必要的循环依赖等反模式。这些债务在项目规模增长后会显著增加重构成本。

• 风格一致性缺失：不同 Chat 会话中生成的代码可能采用不同的命名规范、错误处理模式和日志格式。建议通过 Spec Coding 的方式，预先定义统一的技术规范和代码风格（如 .cursorrules），让 AI 始终在同一套规则下工作。

• 资源治理缺失：AI 不会自动考虑连接池大小、线程池队列长度、缓存过期策略等资源约束。例如，生成的代码可能创建大量线程但无界队列，在流量激增时导致内存溢出；或使用默认数据库连接池配置，在高并发下成为瓶颈。

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

• 代码漏洞：AI 可能生成包含安全漏洞的代码，常见问题包括：
  • SQL 注入：使用字符串拼接而非参数化查询
  • XSS：未对用户输入进行 HTML 转义
  • 权限校验缺失：缺少接口级/方法级权限检查
  • 敏感信息泄露：日志中打印密钥、Token 或密码
  • 依赖漏洞：引入存在已知 CVE 的第三方库
• 数据泄露：不当使用可能泄露公司代码、业务逻辑给外部模型（尤其是云端托管的 AI 服务）。
• 供应链风险：AI 推荐的依赖包可能存在已知漏洞或恶意代码。
• 密钥泄露：AI 生成的代码可能硬编码密钥、Token 等敏感信息。

4. 分布式场景下的失效模式（尤其危险）

AI 生成的代码在分布式环境中极易忽略关键约束，导致生产事故：

失效模式	AI 常见问题	生产风险
幂等性缺失	未考虑接口幂等，直接插入或更新	网络超时重试导致重复数据、资金重复扣款
并发竞态	缺乏分布式锁或 CAS 机制	库存超卖、并发修改覆盖、统计口径错误
分布式事务边界模糊	未明确事务边界和回滚策略	数据不一致、部分成功部分失败、难以追溯
超时与降级缺失	仅设置默认超时，无熔断降级逻辑	级联故障、雪崩效应、服务整体不可用
连接池泄漏	未及时释放连接或连接数配置不当	连接池耗尽、服务假死、重启才能恢复

典型案例：AI 生成"扣减库存"代码时，通常只写 UPDATE stock SET count = count - 1 WHERE id = ?，而忽略：

• 并发场景下的行锁或分布式锁
• 库存不足时的幂等性保证（同一请求多次扣减不应重复）
• 下游服务超时时的补偿机制
• 数据库连接超时与熔断策略

应对策略：

• 在 Spec 中显式约束：要求 AI 生成分布式锁、幂等校验、补偿逻辑的代码模板
• 强制 Code Review：重点关注跨服务调用、事务边界、异常处理分支
• 混沌工程验证：通过故障注入测试分布式场景下的容错能力

企业必须建立配套的安全治理体系：

• 强制代码审查：AI 生成的代码必须经过人工 Review。
• 自动化扫描：集成 SAST/SCA 工具，并增加针对 AI 特有风险的扫描（如 git-secrets, TruffleHog）。
• 架构守护：配合 Spec Coding，使用 ArchUnit 等工具进行架构约束的自动化测试。

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

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

1. 系统设计能力

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

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

2. 复杂业务建模能力

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

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

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

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

AI 生成的代码往往只关注功能正确性，而忽视生产环境的性能特征：

• P99 延迟：AI 可能生成 N+1 查询、未加索引的 SQL、同步阻塞调用，导致长尾延迟激增
• 内存逃逸：不恰当的对象创建和闭包使用可能导致频繁的 GC 甚至 OOM
• 连接池膨胀：未限制并发数、未设置超时可能导致连接池耗尽，引发级联故障

工程师需要具备性能度量与调优能力：

• SQL 慢查询优化与索引设计（EXPLAIN 分析执行计划）
• 缓存策略设计与一致性保障（本地缓存 vs 分布式缓存）
• 异步化改造与线程池参数调优（核心线程数、队列容量、拒绝策略）
• 服务降级、熔断、限流方案（Sentinel、Hystrix 应用）
• 容量规划与弹性伸缩（压测评估 QPS 水位、自动扩缩容）

验证手段：AI 生成代码后，必须通过压测（JMeter、Gatling）验证 P95/P99 延迟，通过 JVM 监控（MAT、Arthas）排查内存泄漏，而非仅依赖功能测试。

4. AI 协作能力

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

• 精准表达需求（Prompt 能力）：使用结构化 Prompt（背景-任务-约束-输出格式），避免模糊指令
• 拆分问题并引导 AI：将复杂任务拆解为可独立验证的子任务，利用 Chain-of-Thought 引导推理
• 判断 AI 输出质量：建立代码 Review checklist，关注正确性、安全性、性能、可维护性
• 代码安全与合规校验：熟悉 OWASP Top 10，能够识别 AI 生成代码中的安全风险
• 结合 AI 工具链：掌握 .cursorrules、自定义 Skills、IDE 插件的配置与使用

这本质上是从"代码编写者"向"AI 协作工程师"的角色转变。

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

总结

AI 编程工具正在深刻改变开发者的工作方式。从 Cursor、Claude Code 到 Trae，这些工具已经从简单的代码补全进化为可以深度协作的工程助手。

但工具再强大，也只是工具。真正决定你职业发展的，是你如何使用这些工具，以及你在使用过程中是否保持了对技术的深度思考。

最后给正在准备面试的几点建议：

1. 实际使用过才能回答好：面试官问 AI 编程工具，最怕的就是"听说过没用过"。哪怕只是用 Cursor 写过几个小项目，也比只看过教程强。
2. 建立自己的方法论：不要只是"会用"，要有自己的使用心得和最佳实践，这是面试中的加分项。
3. 保持批判性思维：AI 生成代码后必须 Review，这是基本素养。面试中展示这种态度，会让面试官觉得你是一个靠谱的工程师。
4. 关注技术趋势但不要焦虑：AI 会改变很多，但系统设计、架构思维、业务理解这些核心能力不会过时。

未来属于那些既能善用 AI 工具，又能保持独立思考的工程师。