用 AI 写代码：如何避免过度冗余，让代码更简单易懂

1. 为什么 AI 写的代码容易"膨胀"

用 AI 生成代码时，很多人第一反应是"能跑就行"。但把 AI 产出的代码直接贴进项目，往往会发现几个典型问题：

• 防御性代码堆砌：到处是if (x == null) return;、try-catch包一层又一层，实际业务里根本不会出现的分支也写上了。
• 过度抽象：一个只有两行逻辑的功能，被拆成接口、实现类、工厂、策略，读代码的人要跳五个文件才能看懂。
• 重复造轮子：明明标准库或项目里已有工具方法，AI 又生成了一份功能几乎一样的实现。
• 注释与代码不同步：注释写得像教科书，代码却已经改过三轮，注释反而成了误导。
• 样板代码过多：Getter/Setter、日志、参数校验全部展开，核心逻辑被淹没在噪音里。

这些问题的根源在于：AI 的训练目标是"生成看起来完整、正确的代码"，而"完整"和"简洁"经常是矛盾的。所以AI 负责产出，人负责收敛，这个分工必须明确。

2. 提问阶段就把"简洁"写进约束

代码冗余往往在提问那一刻就注定了。与其事后删减，不如在 Prompt 里提前约束。

2.1 明确约束条件

一个有效的提问模板：

请用 Java 17 实现以下功能： - 只写核心逻辑，不要生成 Getter/Setter、日志、参数校验等样板代码 - 优先使用标准库（如 Stream、Optional、Collections），不要引入新依赖 - 单个方法不超过 30 行，超过请拆分并说明理由 - 不要写防御性判空，除非我明确说明该参数可能为 null - 注释只解释"为什么"，不解释"是什么"

2.2 给出上下文，而不是让 AI 猜

AI 冗余的一大来源是"信息不足时的自我补全"。你只说"写个分页查询"，它就会把参数校验、异常处理、日志、缓存全给你加上。把已有代码、项目规范、工具类贴给它，冗余会明显减少：

项目里已有 PageUtils.of(list, page, size) 工具方法，请直接复用，不要自己实现分页逻辑。

2.3 要求"最小实现"而非"完整实现"

把"完整"换成"最小可运行"，效果立竿见影：

• ❌ “帮我写一个完整的用户注册模块”
• ✅ “帮我写用户注册的核心校验逻辑，其他部分我自己补”

3. 审查阶段：识别冗余的四个信号

拿到 AI 代码后，先别急着运行，用下面四个信号快速扫一遍。

3.1 信号一：可以删掉而不影响行为的代码

判断标准很简单——删掉它，程序行为不变，那它就是冗余。常见的有：

• 永远不会触发的else分支
• 重复的判空（上游已经保证非空）
• 只调用一次、且只有一行的私有方法
• 为了"以后可能用到"而预留的参数

3.2 信号二：抽象层级不匹配

一个方法里同时出现"业务语义"和"底层细节"，说明抽象层级混乱：

// 冗余：业务逻辑被底层细节淹没publicvoidregister(Stringemail,Stringpassword){if(email==null||email.trim().isEmpty()){thrownewIllegalArgumentException("email empty");}if(!email.matches("^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+$")){thrownewIllegalArgumentException("email invalid");}if(password==null||password.length()<8){thrownewIllegalArgumentException("password too short");}Stringhash=DigestUtils.md5Hex(password+SALT);userRepository.save(newUser(email,hash));}

// 简洁：校验、加密、持久化各自独立，主流程一眼看懂publicvoidregister(Stringemail,Stringpassword){Validators.checkEmail(email);Validators.checkPassword(password);userRepository.save(newUser(email,PasswordEncoder.encode(password)));}

3.3 信号三：重复出现的相似代码块

AI 很容易在同一个文件里生成三段结构几乎一样的代码。这时应该提取公共方法，而不是保留三份"看起来更直观"的复制粘贴。

3.4 信号四：注释比代码还长

如果一段 5 行的代码配了 20 行注释，通常说明代码本身表达力不够。好的代码应该自解释，注释只用来解释非显而易见的决策。

4. 重构阶段：让 AI 帮你做减法

有意思的是，AI 不仅能写冗余代码，也能很好地删冗余代码——前提是你明确告诉它"做减法"。

4.1 用"减法指令"驱动重构

下面这段代码功能正确，但过于冗长。请在不改变行为的前提下重构： 1. 删除所有不会执行到的分支 2. 合并重复逻辑 3. 用标准库替换手写实现 4. 方法控制在 20 行以内 5. 输出重构后的代码，并用一句话说明每处改动的理由

4.2 让 AI 做"代码审查员"

换个角色，效果完全不同：

请以资深代码审查者的身份，指出这段代码中可以删除的部分， 按"可删除 / 可合并 / 可简化"三类列出，不要直接给重写版本。

先让它指出问题，再由你决定改哪些，比直接让它重写更可控——因为 AI 重写时可能引入新的冗余。

4.3 一次只做一件事

重构时最忌讳"顺手把命名也改了、把架构也调了"。让 AI 分步执行：

1. 第一步：只删无用代码
2. 第二步：只提取重复逻辑
3. 第三步：只优化命名

每一步都单独验证，出问题容易定位。

5. 建立可复用的"简洁规范"

个人经验容易忘，把规范沉淀下来，每次提问时直接引用。

5.1 一份可直接用的规范清单

## 代码简洁规范 1. 能用标准库解决的，不引入第三方依赖 2. 方法只做一件事，超过 30 行必须拆分 3. 不写"防御性判空"，除非调用方可能传 null 4. 注释解释"为什么"，不解释"是什么" 5. 重复三次以上的逻辑必须提取 6. 不为"未来可能的需求"预留参数和抽象 7. 异常处理只捕获能处理的异常，不吞异常 8. 命名优先表达意图，不用缩写

5.2 把规范变成 Prompt 前缀

把上面的清单作为系统提示的一部分，每次对话自动带上，比每次手动描述高效得多。

6. 一个完整的对比示例

需求：从订单列表中筛选出金额大于 100 且状态为已支付的订单，返回订单号列表。

AI 初版（冗余）：

publicList<String>getPaidOrderNos(List<Order>orders){List<String>result=newArrayList<>();if(orders!=null&&!orders.isEmpty()){for(inti=0;i<orders.size();i++){Orderorder=orders.get(i);if(order!=null){if(order.getAmount()!=null){if(order.getAmount().compareTo(newBigDecimal("100"))>0){if(order.getStatus()!=null){if(order.getStatus().equals(OrderStatus.PAID)){if(order.getOrderNo()!=null){result.add(order.getOrderNo());}}}}}}}}returnresult;}

收敛后（简洁）：

publicList<String>getPaidOrderNos(List<Order>orders){returnorders.stream().filter(o->o.getAmount().compareTo(THRESHOLD)>0).filter(o->o.getStatus()==OrderStatus.PAID).map(Order::getOrderNo).toList();}

改动点：

• 嵌套if改为 Stream 链式过滤，逻辑线性可读
• 去掉层层判空（由上游保证数据完整性，或在入口统一校验）
• 魔法值100提取为常量THRESHOLD
• 用toList()替代手动new ArrayList<>()+add

行数从 20 行降到 6 行，行为完全一致。

6.1 收敛的边界：哪些冗余不能删

上一节的对比很容易让人产生一种错觉：判空都是冗余，删得越干净越好。但事实并非如此——判空本身不是冗余，"在错误的位置判空"才是冗余。去冗余的前提是搞清楚数据从哪来、由谁保证。

6.1.1 三类必须保留防御的场景

一、外部输入入口

HTTP 接口参数、消息队列消息体、文件解析结果、命令行参数，这些数据来自系统边界之外，没有任何上游能替你保证非空。入口处的校验不是冗余，而是契约的第一道防线。正确做法是在入口统一校验一次，然后让内部逻辑信任校验结果，而不是每层都判一遍。

二、跨服务调用的返回值

RPC / HTTP 调用返回的对象，字段是否为空取决于对方服务的实现和版本，本地代码无法静态保证。尤其是对方返回null对象、或响应体字段缺失时，直接链式取值就会 NPE。这类判空应当保留，并且最好在调用封装层统一处理，而不是散落在业务代码里。

三、并发共享状态

多线程共享的集合、缓存、单例字段，在读写之间存在可见性和时序问题。if (map.get(key) != null)这类判断看似冗余，实际承担着并发语义。删掉它换来的不是简洁，而是偶发的、极难复现的线上故障。

6.1.2 反例：过度删减导致的 NPE

假设有人照着上一节的思路，把"层层判空"全部删掉，得到下面这段代码：

// 反例：把入口校验和跨服务返回值判空一起删掉了publicBigDecimalqueryUserBalance(StringuserId){// userId 来自 HTTP 请求参数，可能为 null 或空串UserDTOuser=userClient.getById(userId);// 远程调用可能返回 null，也可能返回 balance 为 null 的对象returnuser.getBalance().add(getFrozenAmount(userId));}

这段代码在本地测试时一切正常，因为测试数据总是完整的。但上线后会出现三类故障：

• 请求未传userId→userClient.getById(null)内部抛异常或返回null→user.getBalance()直接 NPE；
• 用户不存在 → 远程返回null→ 同样 NPE；
• 用户存在但从未有过账户 →balance字段为null→add()抛 NPE。

正确的写法不是把判空加回去堆成金字塔，而是在边界处收敛校验，在内部保持简洁：

publicBigDecimalqueryUserBalance(StringuserId){// 边界校验：入口参数只在这里校验一次Assert.hasText(userId,"userId must not be blank");// 跨服务返回值：在调用封装层统一兜底UserDTOuser=userClient.getById(userId);if(user==null){thrownewBizException("user not found: "+userId);}// 业务字段缺失属于正常业务状态，用默认值表达而不是判空BigDecimalbalance=Optional.ofNullable(user.getBalance()).orElse(BigDecimal.ZERO);returnbalance.add(getFrozenAmount(userId));}

6.1.3 判断"该不该删"的三个问题

面对一段疑似冗余的判空，先问自己三个问题：

1. 这个值来自哪里？如果来自系统边界之外（外部输入、远程调用、并发共享），保留。
2. 谁能保证它非空？如果找不到一个明确的、可验证的保证方，保留。
3. 删掉之后，最坏情况是什么？如果最坏情况是 NPE 或数据错误，而不是"多一次无意义的判断"，保留。

三个问题都指向"可以删"，那才是真正的冗余。简洁的目标是让每一行代码都有存在的理由，而不是让代码行数变少——防御性代码只要站在正确的位置，它本身就是理由。

7. 总结

用 AI 写代码，真正的价值不在于"生成得快"，而在于"生成后能收敛得干净"。记住三条原则：

1. 提问时约束：把"简洁"写进 Prompt，明确禁止样板代码和过度抽象。
2. 审查时识别：删掉不影响行为的代码，警惕抽象层级混乱和重复块。
3. 重构时做减法：让 AI 以审查者身份指出冗余，分步重构，一次只改一件事。

AI 是高效的"代码生产者"，但"代码质量的守门人"始终是你自己。简洁不是少写代码，而是让每一行代码都有存在的理由。