wehub-resource-sync
20 KiB
title, description, category, icon, head
| title | description | category | icon | head | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 10 道 AI 编程相关的开放性面试问题 | 涵盖 Cursor、Claude Code、Trae 等 AI 编程 IDE 使用技巧，Spec Coding 与 Vibe Coding 区别，以及 AI 对后端开发影响等高频面试问题。 | AI 应用开发 | mdi:code-tags |
|
腾讯面试的时候，面试官问我：“用过什么 AI 编程工具？”。我说：“Trae。”
空气突然安静了两秒。我搞不清楚为什么面试官沉默了，当时我还在想：“是不是我回答得不够高级？”。
面试被挂后才意识到：Trae 是字节的，腾讯家的是 CodeBuddy，阿里家的是 Qoder。
段子归段子！今天小 G 分享 9 道当下校招和社招技术面试中经常会被问到的 AI 编程开放性问题，希望对你有帮助。
- ⭐ AI 编程 IDE：Cursor、Claude Code 等工具的使用技巧
- ⭐ AI 对后端开发的影响：AI 会淘汰初级程序员吗？最大风险是什么？
- ⭐ 未来核心竞争力：3 年后端工程师的核心竞争力是什么？
AI 编程 IDE 使用技巧
用过什么 AI 编程 IDE 吗？什么感觉？
目前整体感觉是：AI 编程能力进步很快。它已经从几年前简单的代码补全，进化成了一个可以深度协作的工程助手。
我总结了一套自己的使用方法论：
- 在接手复杂项目或模块时，我不会直接让 AI 写代码，而是先让 Cursor 分析整个代码库，生成一份包含核心架构、模块职责和数据流的文档。这一步非常关键，因为它决定了后续协作的质量。只有当我和 AI 对项目有一致理解时，后续产出才会稳定、高质量。
- 对于每个独立的开发任务，开启一个新的对话，并提供必要的上下文，包括需求背景、涉及模块和约束条件。这种方式能减少上下文污染，让 AI 生成的代码更精准。
- 定期删除冗余实现和废弃代码。旧代码会误导 AI 的判断，增加上下文噪音。
AI 编程的核心原则
AI 是一个强大的知识库和辅助工具，可以帮我们快速实现功能、学习新知识。但如果完全依赖 AI 写代码而不理解其原理，个人技术能力可能会退化。
几个原则：
- AI 生成代码之后必须人工 Review。
- 关键逻辑必要时自己重写。
- 核心路径必须做压测和边界测试。
我希望效率提升，但不以牺牲技术能力为代价。
⭐ Cursor 实战技巧
这里是以 Cursor 为例，其他 AI IDE 都是类似的。
- 先理架构再动手：无论是自己写代码还是让 AI 生成代码，都必须先明确需求、整体架构和模块边界。如果在架构模糊的情况下直接编码，很容易出现重复实现或职责冲突，后期修改成本反而更高。
- 单 Chat 专注单功能：新功能或大改动开启新的 Chat，并在开头引入项目结构说明或关键文档作为上下文。这样可以避免历史对话干扰。
- 功能落地后写指南：让 AI 总结实现过程，抽象出通用步骤。比如新增接口的标准流程、文件导出的统一实现方式等。这些内容可以在后续类似需求中快速复用。
- 不依赖 AI，主动复盘：AI 仅作辅助，代码生成后需认真 Review，理解原理、优化不合理处。
- 定期删无用代码：清理冗余代码，减少对 AI 的误导和上下文干扰，提升开发效率。
- 用好配置文件：
.cursorrules定义 AI 生成代码的规则、风格和常用片段；.cursorignore指定不允许 AI 修改的文件 / 目录，保护核心代码。 - 持续维护文档：项目重大变更后，让 AI 同步更新文档、记录 “踩坑” 经验。
- 让 AI 先“学”项目：大型项目先让 Cursor 分析代码库，生成含架构、目录职责、核心类的结构文档，作为后续开发的基础上下文。
⭐Claude Code 使用技巧
- 上下文窗口是你最贵的资源——所有技巧本质上都在帮你把这块白板用得更高效。
- 先规划后执行——Plan Mode 投资的是后面的时间。
CLAUDE.md自我进化——把纠正转化为规则，让 AI 越用越顺手。- 并行是最大的效率杠杆——多实例 + Worktree + 子代理。
- 验证优于信任——给 Claude 验收标准，让它自己检查。
/compact比反复纠正更有效——上下文被污染后，压缩或清空重来更好。
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 辅助编程的能力可以归纳为两个维度：
- 从 0 到 1 的规划与交付：给出需求描述，AI 可以自主完成技术选型和架构设计，适合快速验证构想，但方案仍需人工评审。
- 既有代码的增量优化：在已有复杂度的代码库中，AI 能够理解既有架构、定位问题、完成优化。但 AI 给出的方案“看起来对”，上生产就翻车的情况并不少见。
前后端开发者的核心竞争力已经变了
说句实话，前后端开发者的核心竞争力已经变了。
以前前端拼手速和还原度，后端拼 CRUD 和八股文。现在这些东西 AI 全能做，而且又快又不喊累，就废点 Token。你花半天切的页面，AI 十分钟搞定；你写两小时的增删改查，AI 三分钟交卷。不是说这些技能没用了，而是不稀缺了，就不值钱。
前端受冲击最直接。页面还原、组件编写、样式调整，模式化程度太高，大模型最擅长这类活。但死掉的不是前端这个岗位，是“只会写页面”的前端。
有竞争力的前端往两个方向走：要么往深扎——性能优化、渲染管线分析、工程化基建，AI 替代不了；要么往难走——WebGL、大规模可视化、跨端底层原理，AI 生成质量差，反而是护城河。
后端稍好，但也别乐观。AI 写单个接口已经很强了，它的短板是系统级思考——服务怎么拆、数据模型怎么设计、缓存一致性怎么保证、容量瓶颈在哪。这些需要结合业务场景和技术债综合判断，AI 给的方案“看起来对”，上生产就翻车。
后端的核心竞争力在往系统设计、稳定性治理、复杂业务建模转。
不管前端后端，有一件事已经是基本功：高效跟 AI 协作。不是会用 ChatGPT 就行，而是能拆解问题、引导输出、判断结果靠不靠谱、识别安全隐患。你从“写代码的人”变成了“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 不会自动考虑连接池大小、线程池队列长度、缓存过期策略等资源约束。例如，生成的代码可能创建大量线程但无界队列，在流量激增时导致内存溢出；或使用默认数据库连接池配置，在高并发下成为瓶颈。
-
工程规范适配：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 等工具进行架构约束的自动化测试。
AI 编程正在让程序员更累、更卷？
有人说：“以为有了 AI 提效就能轻松点？清醒点，它没让你变轻松，它只是让老板觉得你一个人能顶三个人用。”
这话听着扎心，但确实是很多人的真实感受。
AI 把你的能力放大了，以前一天写三个接口就觉得自己挺能干，现在一天能写十个，还能顺手把架构设计、测试用例、文档全部搞定。多巴胺疯狂分泌，你会忍不住接更多的活儿，因为“我能搞定”的信心被 AI 撑大了。
但问题来了：效率越高，老板欲望膨胀得越快。“一人即团队”的幻觉让招聘名额先砍一半，剩下的兄弟往死里用。以前你只需深耕一个模块，现在要同时应付前后端、多线程任务、甚至一堆 Agent。
更魔幻的是岗位少了，活多了。你不仅要写代码，还要审 AI 的代码、改 AI 的 Bug，最后还得给领导解释为什么 AI 生成的代码上线就崩。有时候分不清楚是自己用 AI 还是 AI 用自己。
⭐ 未来 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 等工具，已经从代码补全进化到了可以深度协作的工程助手。
从 Prompt 到 Harness，短短四年，写代码这件事正在从程序员的“手艺”变成 Agent 的“标准操作”。有人说：“未来可能一个 CTO 就能管所有 Agent，让它产出所有代码、部署、改 bug。”这话听着激进，但你仔细想想，好像也不是完全没可能。
真正决定你职业发展的，是你如何使用这些工具，以及你在使用过程中是否保持了对技术的深度思考。
说实话，从去年这个时候开始就挺焦虑 AI 发展，尤其是 Coding 方向。到今天，进化速度这么快，我反而有些释然了。会写代码正在从核心技能变成基础素养，就像会用 Excel 不算竞争力一样。真正值钱的是定义问题、设计方案、把控质量、交付业务价值。
最后给正在准备面试的几点建议：
- 实际使用过才能回答好：面试官问 AI 编程工具，最怕的就是“听说过没用过”。哪怕只是用 Cursor 写过几个小项目，也比只看过教程强。
- 建立自己的方法论：不要只是“会用”，要有自己的使用心得和最佳实践，这是面试中的加分项。
- 保持批判性思维：AI 生成代码后必须 Review，这是基本素养。面试中展示这种态度，会让面试官觉得你是一个靠谱的工程师。
- 关注技术趋势但不要焦虑：AI 会改变很多，但系统设计、架构思维、业务理解这些核心能力不会过时。
用好 AI 工具 + 保持独立思考，这两者缺一不可。AI 时代，程序员的未来说不定会在各行各业发光。共勉！