ARTICLE · 1286564

面试官问我用没用AI写代码怎么答?Java后端面试这样回答,反而加分

发布时间：2026-10-31 16:30:38 最近访问：2026-10-31 16:30:38

上周有个学弟给我发消息，说他面一家做支付的公司，技术面聊得挺顺，最后面试官随口问了一句：“你平时写代码用AI吗？”

他脑子一热，说了句“基本不用，我都自己写”。

结果面试官笑了笑，追问：“那你最近有没有用过Cursor或者Copilot？团队里其他人用你不用，你怎么看？”

他当场卡壳，后面聊得就很别扭，最后没过。

他问我：“这问题到底怎么答才对？说用吧，怕人家觉得我能力不行；说不用吧，又显得跟不上时代。”

这个问题最近问的人特别多。刚好这段时间AI编程工具的话题一直很热，从Cursor到各种Agent，讨论度居高不下，面试官问这个问题的频率明显变高了。今天我就结合Java后端的真实场景，把这道题拆开讲清楚：面试官到底在问什么、你该怎么答、以及怎么用一段SpringBoot代码把话说圆。

先说结论：这道题不是考你“用不用AI”，而是考你“会不会用AI，以及用了之后能不能对代码负责”。

一、面试官问这句话，到底想听什么

很多新手以为面试官在试探你的“纯洁度”，其实不是。站在面试官角度，他关心的通常是三件事：

第一，你的真实水平边界在哪。如果你说“我全靠AI写”，那他没法判断你到底会不会；如果你说“我从来不用”，他又会怀疑你是不是没接触过现代工具链。

第二，你有没有辨别AI代码对错的能力。AI生成的代码经常“看着能跑，实际有坑”，面试官想知道的，是你能不能看出这些坑。

第三，你的工程习惯。比如你会不会把公司代码贴到外部工具里、会不会做Code Review、会不会写测试。

我整理了一张表，你可以对照着理解面试官的潜台词：

你的回答面试官听到的潜台词风险我完全不用AI可能没接触过现代工具，或者不诚实显得脱节我基本靠AI写独立解决问题能力存疑直接减分我用，但会验证和改写有工程判断力加分我用，还会判断哪些场景不该用有边界意识，成熟明显加分

所以核心不是“用或不用”，而是“你怎么用”。

二、三套回答话术，按你的真实情况选

我按三种常见情况给你准备了话术，你挑最贴近自己的那套，稍微改改就能用。

话术一：你确实用得不多

“我平时会用AI辅助查API、写一些样板代码，比如生成实体类的getter/setter、写单元测试的骨架。但核心业务逻辑我还是自己写，因为AI对业务上下文理解不够，生成的代码经常要改。我更多把它当成一个查文档和补全的工具。”

这套话术的关键是：承认用，但把AI定位在“辅助”而不是“代写”。

话术二：你用得比较多（大部分新手属于这种）

“我用得挺多的，但我的习惯是让AI先出草稿，我再逐行过一遍。特别是涉及数据库事务、并发、缓存这些地方，我一定会自己验证。比如它给我生成一个@Service方法，我会检查事务注解加的位置对不对、异常有没有吞掉、有没有N+1查询。”

这套话术的关键是：用得多不怕，怕的是你说不出“验证”这两个字。

话术三：你想借机展示深度

“用，而且我会刻意区分场景。像写CRUD、DTO转换、日志埋点这种重复劳动，我放心让AI生成；但像幂等设计、分布式锁、复杂SQL优化，我会自己主导，AI只用来做交叉验证。因为这类问题AI给的方案经常是‘通用解’，不一定适配我们的业务约束。”

这套话术最适合面中高级岗位，直接把你和“只会复制粘贴”的人区分开。

不管用哪套，记住一个原则：一定要给出一个具体的验证动作。空说“我会检查”很虚，说出“我会检查@Transactional的传播行为”就很实。

三、用一段SpringBoot代码，把话说圆

光说不够，面试官很可能顺着往下问：“那你举个例子，AI给你的代码你怎么改的？”

这时候你要是能现场讲一段代码，效果完全不一样。我给你准备了一个特别典型的例子：让AI写一个“扣减库存”的Service方法。

AI大概率会给你生成类似这样的代码：

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class StockService {

    private final StockMapper stockMapper;

    public StockService(StockMapper stockMapper) {
        this.stockMapper = stockMapper;
    }

    // AI生成的版本：看起来没问题，其实有三个坑
    @Transactional
    public void deductStock(Long productId, Integer count) {
        // 坑1：先查再减，高并发下会超卖
        Integer stock = stockMapper.selectStock(productId);
        if (stock < count) {
            throw new RuntimeException("库存不足");
        }
        // 坑2：这里是内存计算后覆盖写，不是原子操作
        stockMapper.updateStock(productId, stock - count);
    }
}

这段代码能跑，单测也能过，但上线就出事。问题在哪？

坑1是“先查后改”，两个请求同时查到库存10，都判断够，最后都减，库存变负数，也就是超卖。

坑2是抛的是RuntimeException，虽然能触发回滚，但业务异常用运行时异常不规范，且没有明确异常类型。

坑3是没考虑幂等，同一个请求重试两次会扣两次。

那正确写法是什么？用一条带条件的原子更新：

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class StockService {

    private final StockMapper stockMapper;

    public StockService(StockMapper stockMapper) {
        this.stockMapper = stockMapper;
    }

    @Transactional(rollbackFor = Exception.class)
    public void deductStock(Long productId, Integer count) {
        if (count == null || count <= 0) {
            throw new IllegalArgumentException("扣减数量必须大于0");
        }
        // 关键：把判断和扣减合并成一条SQL，由数据库保证原子性
        // update stock set stock = stock - #{count}
        // where product_id = #{productId} and stock >= #{count}
        int affected = stockMapper.deductAtomic(productId, count);
        if (affected == 0) {
            // 影响行数为0，说明库存不足或商品不存在
            throw new BizException("库存不足，扣减失败");
        }
    }
}

对应的Mapper方法长这样：

import org.apache.ibatis.annotations.Mapper;
import org.apache.ibatis.annotations.Param;
import org.apache.ibatis.annotations.Update;

@Mapper
public interface StockMapper {

    // 原子扣减：条件写在where里，避免先查后改
    @Update("UPDATE stock SET stock = stock - #{count} " +
            "WHERE product_id = #{productId} AND stock >= #{count}")
    int deductAtomic(@Param("productId") Long productId,
                     @Param("count") Integer count);
}