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

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

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

段子归段子!今天小 G 分享 9 道当下校招和社招技术面试中经常会被问到的 AI 编程开放性问题,希望对你有帮助。

⭐ AI 编程 IDE:Cursor、Claude Code 等工具的使用技巧

⭐ AI 对后端开发的影响:AI 会淘汰初级程序员吗?最大风险是什么?

⭐ 未来核心竞争力:3 年后端工程师的核心竞争力是什么?

AI 编程 IDE 使用技巧

AI 编程 IDE 使用技巧

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

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

目前整体感觉是:AI 编程能力进步很快。它已经从几年前简单的代码补全,进化成了一个可以深度协作的工程助手。

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

在接手复杂项目或模块时,我不会直接让 AI 写代码,而是先让 Cursor 分析整个代码库,生成一份包含核心架构、模块职责和数据流的文档。这一步非常关键,因为它决定了后续协作的质量。只有当我和 AI 对项目有一致理解时,后续产出才会稳定、高质量。

对于每个独立的开发任务,开启一个新的对话,并提供必要的上下文,包括需求背景、涉及模块和约束条件。这种方式能减少上下文污染,让 AI 生成的代码更精准。

定期删除冗余实现和废弃代码。旧代码会误导 AI 的判断,增加上下文噪音。

AI 编程的核心原则

AI 编程的核心原则

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

几个原则:

AI 生成代码之后必须人工 Review。

关键逻辑必要时自己重写。

核心路径必须做压测和边界测试。

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

⭐ Cursor 实战技巧

⭐ Cursor 实战技巧

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

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

先理架构再动手:无论是自己写代码还是让 AI 生成代码,都必须先明确需求、整体架构和模块边界。如果在架构模糊的情况下直接编码,很容易出现重复实现或职责冲突,后期修改成本反而更高。

单 Chat 专注单功能:新功能或大改动开启新的 Chat,并在开头引入项目结构说明或关键文档作为上下文。这样可以避免历史对话干扰。

功能落地后写指南:让 AI 总结实现过程,抽象出通用步骤。比如新增接口的标准流程、文件导出的统一实现方式等。这些内容可以在后续类似需求中快速复用。

不依赖 AI,主动复盘:AI 仅作辅助,代码生成后需认真 Review,理解原理、优化不合理处。

定期删无用代码:清理冗余代码,减少对 AI 的误导和上下文干扰,提升开发效率。

用好配置文件:.cursorrules 定义 AI 生成代码的规则、风格和常用片段;.cursorignore 指定不允许 AI 修改的文件 / 目录,保护核心代码。

.cursorrules
.cursorignore

持续维护文档:项目重大变更后,让 AI 同步更新文档、记录 “踩坑” 经验。

让 AI 先“学”项目:大型项目先让 Cursor 分析代码库,生成含架构、目录职责、核心类的结构文档,作为后续开发的基础上下文。

⭐Claude Code 使用技巧

⭐Claude Code 使用技巧

上下文窗口是你最贵的资源——所有技巧本质上都在帮你把这块白板用得更高效。

先规划后执行——Plan Mode 投资的是后面的时间。

CLAUDE.md 自我进化——把纠正转化为规则,让 AI 越用越顺手。

CLAUDE.md

并行是最大的效率杠杆——多实例 + Worktree + 子代理。

验证优于信任——给 Claude 验收标准,让它自己检查。

/compact 比反复纠正更有效——上下文被污染后,压缩或清空重来更好。

/compact

Claude Code 详细内容我单独分享过:Claude Code 使用指南。

Claude Code 使用指南

AI 编程对程序员的影响

AI 编程对程序员的影响

你如何看待 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 会淘汰初级程序员吗

AI 会淘汰初级程序员吗

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

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

写 CRUD 增删改查

写基础接口

写 SQL 查询语句

写基础工具类/配置

现在这些工作 AI 都能做得很好,甚至更高效、更少出错。但初级程序员不会被淘汰,只是价值创造点发生了迁移。

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

需求拆解能力:将模糊的业务需求转化为清晰的技术任务。

业务理解能力:理解领域模型和业务规则,而不仅是“翻译需求”。

架构感知能力:理解系统整体架构,知道自己代码在系统中的位置。

Prompt 表达能力:能精准地描述问题,从 AI 获取高质量答案。

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

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

AI 带来的最大风险是什么

AI 带来的最大风险是什么

我认为主要有三个层面:

  1. 技术能力退化

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

调试能力下降:习惯让 AI 排查问题,自身对底层原理的理解变浅。

代码敏感度下降:对“好代码”和“坏代码”的判断能力变弱,甚至不知道什么是好代码。

架构思维退化:长期只关注功能实现,忽视架构设计和扩展性。

  1. 架构失控

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

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

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

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

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

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

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

.cursorrules

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

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

工程规范适配:AI 生成的代码架构虽然合理,但与既有工程规范的适配往往需要人工把关。比如文件名组织、代码风格差异、依赖管理策略——这些“看起来没问题”的代码,可能在团队协作中制造麻烦。

工程规范适配:AI 生成的代码架构虽然合理,但与既有工程规范的适配往往需要人工把关。比如文件名组织、代码风格差异、依赖管理策略——这些“看起来没问题”的代码,可能在团队协作中制造麻烦。

  1. 安全风险(尤其需要重视)

代码漏洞:AI 可能生成包含安全漏洞的代码,常见问题包括: SQL 注入:使用字符串拼接而非参数化查询XSS:未对用户输入进行 HTML 转义权限校验缺失:缺少接口级/方法级权限检查敏感信息泄露:日志中打印密钥、Token 或密码依赖漏洞:引入存在已知 CVE 的第三方库

SQL 注入:使用字符串拼接而非参数化查询

XSS:未对用户输入进行 HTML 转义

权限校验缺失:缺少接口级/方法级权限检查

敏感信息泄露:日志中打印密钥、Token 或密码

依赖漏洞:引入存在已知 CVE 的第三方库

数据泄露:不当使用可能泄露公司代码、业务逻辑给外部模型(尤其是云端托管的 AI 服务)。

供应链风险:AI 推荐的依赖包可能存在已知漏洞或恶意代码。

密钥泄露:AI 生成的代码可能硬编码密钥、Token 等敏感信息。

  1. 分布式场景下的失效模式(尤其危险)

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

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

失效模式AI 常见问题生产风险

失效模式

AI 常见问题

生产风险

幂等性缺失未考虑接口幂等,直接插入或更新网络超时重试导致重复数据、资金重复扣款

幂等性缺失

未考虑接口幂等,直接插入或更新

网络超时重试导致重复数据、资金重复扣款

并发竞态缺乏分布式锁或 CAS 机制库存超卖、并发修改覆盖、统计口径错误

并发竞态

缺乏分布式锁或 CAS 机制

库存超卖、并发修改覆盖、统计口径错误

分布式事务边界模糊未明确事务边界和回滚策略数据不一致、部分成功部分失败、难以追溯

分布式事务边界模糊

未明确事务边界和回滚策略

数据不一致、部分成功部分失败、难以追溯

超时与降级缺失仅设置默认超时,无熔断降级逻辑级联故障、雪崩效应、服务整体不可用

超时与降级缺失

仅设置默认超时,无熔断降级逻辑

级联故障、雪崩效应、服务整体不可用

连接池泄漏未及时释放连接或连接数配置不当连接池耗尽、服务假死、重启才能恢复

连接池泄漏

未及时释放连接或连接数配置不当

连接池耗尽、服务假死、重启才能恢复

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

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 把你的能力放大了,以前一天写三个接口就觉得自己挺能干,现在一天能写十个,还能顺手把架构设计、测试用例、文档全部搞定。多巴胺疯狂分泌,你会忍不住接更多的活儿,因为“我能搞定”的信心被 AI 撑大了。

但问题来了:效率越高,老板欲望膨胀得越快。“一人即团队”的幻觉让招聘名额先砍一半,剩下的兄弟往死里用。以前你只需深耕一个模块,现在要同时应付前后端、多线程任务、甚至一堆 Agent。

更魔幻的是岗位少了,活多了。你不仅要写代码,还要审 AI 的代码、改 AI 的 Bug,最后还得给领导解释为什么 AI 生成的代码上线就崩。有时候分不清楚是自己用 AI 还是 AI 用自己。

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

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

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

  1. 系统设计能力

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

服务拆分与模块边界划分

微服务与单体架构权衡

数据模型设计与一致性策略

接口版本演进策略

分布式事务与幂等设计

  1. 复杂业务建模能力

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

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

领域驱动设计(DDD)建模

业务流程抽象与状态机设计

边界上下文划分

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

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

P99 延迟:AI 可能生成 N+1 查询、未加索引的 SQL、同步阻塞调用,导致长尾延迟激增

内存逃逸:不恰当的对象创建和闭包使用可能导致频繁的 GC 甚至 OOM

连接池膨胀:未限制并发数、未设置超时可能导致连接池耗尽,引发级联故障

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

SQL 慢查询优化与索引设计(EXPLAIN 分析执行计划)

缓存策略设计与一致性保障(本地缓存 vs 分布式缓存)

异步化改造与线程池参数调优(核心线程数、队列容量、拒绝策略)

服务降级、熔断、限流方案(Sentinel、Hystrix 应用)

容量规划与弹性伸缩(压测评估 QPS 水位、自动扩缩容)

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

  1. AI 协作能力

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

精准表达需求(Prompt 能力):使用结构化 Prompt(背景-任务-约束-输出格式),避免模糊指令

拆分问题并引导 AI:将复杂任务拆解为可独立验证的子任务,利用 Chain-of-Thought 引导推理

判断 AI 输出质量:建立代码 Review checklist,关注正确性、安全性、性能、可维护性

代码安全与合规校验:熟悉 OWASP Top 10,能够识别 AI 生成代码中的安全风险

结合 AI 工具链:掌握 .cursorrules、自定义 Skills、IDE 插件的配置与使用

.cursorrules

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

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

总结

总结

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

从 Prompt 到 Harness,短短四年,写代码这件事正在从程序员的“手艺”变成 Agent 的“标准操作”。有人说:“未来可能一个 CTO 就能管所有 Agent,让它产出所有代码、部署、改 bug。”这话听着激进,但你仔细想想,好像也不是完全没可能。

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

说实话,从去年这个时候开始就挺焦虑 AI 发展,尤其是 Coding 方向。到今天,进化速度这么快,我反而有些释然了。会写代码正在从核心技能变成基础素养,就像会用 Excel 不算竞争力一样。真正值钱的是定义问题、设计方案、把控质量、交付业务价值。

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

实际使用过才能回答好:面试官问 AI 编程工具,最怕的就是“听说过没用过”。哪怕只是用 Cursor 写过几个小项目,也比只看过教程强。

建立自己的方法论:不要只是“会用”,要有自己的使用心得和最佳实践,这是面试中的加分项。

保持批判性思维:AI 生成代码后必须 Review,这是基本素养。面试中展示这种态度,会让面试官觉得你是一个靠谱的工程师。

关注技术趋势但不要焦虑:AI 会改变很多,但系统设计、架构思维、业务理解这些核心能力不会过时。

用好 AI 工具 + 保持独立思考,这两者缺一不可。AI 时代,程序员的未来说不定会在各行各业发光。共勉!