2、代码生成工具与手写代码的边界

说实话，我刚接触AI代码生成那会儿，也犯过傻——恨不得让AI把整个项目都写了。结果呢？改bug的时间比手写还长。后来我慢慢摸清了门道：知道什么该交给AI，什么必须自己来，这才是真本事。

这一章，我就跟你聊聊我总结出的边界感。说白了，就是给AI画个圈——圈里的事它干，圈外的事别碰。

2.1 AI生成代码的典型场景

我个人习惯把AI当成一个超级实习生。它速度快、不喊累，但你不能指望它做决策。哪些活适合交给它？我归纳了三类。

2.1.1 样板代码——AI的舒适区

样板代码是什么？就是那些重复、机械、有固定模式的代码。比如：

  • getter/setter 方法
  • DTO（数据传输对象）的字段定义
  • 配置类的骨架
  • REST API 的 CRUD 接口

我在项目中遇到过这样一个场景：一个微服务项目，光DTO就有30多个，每个都有七八个字段。手写？得花半天。用AI？5分钟搞定。

我的经验：给AI一个模板，它就能批量生产。比如你写好一个DTO的示例，告诉它“按这个格式生成UserDTO、OrderDTO、ProductDTO”，它基本不会出错。

举个例子，下面这段代码，我通常会让AI生成：

// AI生成的样板代码示例
public class UserDTO {
    private Long id;
    private String username;
    private String email;
    private LocalDateTime createTime;

    // getter/setter
    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }
    // ... 其他字段省略
}

你想想看，这种代码有什么技术含量？没有。但你不写又不行。交给AI，省下来的时间干点正事不好吗？

2.1.2 单元测试——AI的拿手好戏

写单元测试，说实话，挺枯燥的。尤其是那些边界条件、异常场景，人脑容易遗漏。但AI不一样，它记性好，能帮你覆盖到各种犄角旮旯。

我记得有一次，我让AI帮我生成一个支付模块的单元测试。它不光写了正常流程，还自动补了超时、金额为负、并发冲突这些场景。我当时就一个感觉：这实习生，靠谱。

小技巧：给AI提供被测方法的签名和核心逻辑，它生成的测试覆盖率通常能到80%以上。但关键路径的断言，我建议你手动检查一遍。 
// AI生成的单元测试示例
@Test
void testCalculateDiscount_ShouldReturnZero_WhenAmountIsNegative() {
    // Arrange
    DiscountService service = new DiscountService();
    BigDecimal amount = new BigDecimal("-100");

    // Act
    BigDecimal result = service.calculateDiscount(amount);

    // Assert
    assertEquals(BigDecimal.ZERO, result);
}

2.1.3 数据模型——AI的强项

数据模型这东西，说白了就是字段+类型+约束。模式固定，变化少。AI处理起来得心应手。

比如你告诉AI：“帮我建一个用户表，包含id、用户名、密码、邮箱、注册时间。”它立马就能给你生成：

-- AI生成的数据模型示例
CREATE TABLE `user` (
    `id` BIGINT AUTO_INCREMENT PRIMARY KEY,
    `username` VARCHAR(50) NOT NULL UNIQUE,
    `password` VARCHAR(255) NOT NULL,
    `email` VARCHAR(100),
    `created_at` DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

嗯，这里要注意：索引设计、分表策略、字段长度这些，AI不一定能拿捏准。它给的只是通用方案，具体优化还得你来。

2.2 手写代码的典型场景

好了，说完AI能干的，咱们聊聊必须自己动手的部分。这些场景，我建议你一个字都别让AI碰。

2.2.1 核心算法——AI的盲区

核心算法是什么？是业务的核心竞争力。比如推荐系统的排序算法、风控模型的评分逻辑、加密解密的核心流程。

为什么不能让AI写？因为算法需要理解业务意图。AI不懂你的业务，它只能拼凑出“看起来对”的代码，但很可能有逻辑漏洞。

我曾经踩过的坑：让AI写了一个库存扣减算法。它用了普通的减法，没考虑并发。上线第一天就超卖了。从那以后，核心算法我再也不交给AI。 
// 手写代码示例：带乐观锁的库存扣减
public boolean deductStock(Long productId, Integer quantity) {
    // 这里必须手写，因为涉及事务和并发控制
    String sql = "UPDATE product SET stock = stock - ? WHERE id = ? AND stock >= ?";
    int affected = jdbcTemplate.update(sql, quantity, productId, quantity);
    return affected > 0;
}

2.2.2 复杂业务逻辑——AI搞不定

复杂业务逻辑，我指的是那种多条件分支、状态流转、规则引擎之类的代码。比如订单状态机、审批流程、计费规则。

这类代码的特点是：牵一发而动全身。AI生成的代码，你很难验证它是否覆盖了所有分支。万一漏了一个，线上就是事故。

我个人习惯：先画流程图，再手写代码。流程图理清了，代码自然就顺了。

我的建议：复杂业务逻辑，手写+单元测试双保险。AI可以帮你生成测试用例，但核心逻辑必须自己把控。

2.2.3 性能敏感代码——AI的短板

性能敏感代码，说白了就是不能慢、不能卡、不能崩的代码。比如：

  • 高频调用的热点方法
  • 大数据量的循环处理
  • 内存缓存的管理
  • 数据库查询的优化

AI写这类代码，往往只考虑“能不能跑”，不考虑“跑得快不快”。它不会帮你做缓存预热、连接池调优、索引优化这些事。

// 手写代码示例：性能敏感的内存缓存
public class LocalCache {
    private final Map<String, Object> cache = new ConcurrentHashMap<>();
    private final long ttl;

    public Object get(String key) {
        // 手写：考虑缓存击穿、过期策略
        CacheEntry entry = cache.get(key);
        if (entry == null || entry.isExpired()) {
            return loadFromDB(key); // 手动控制加载逻辑
        }
        return entry.getValue();
    }
}

2.3 边界划分的实战原则

说了这么多，你可能想问：到底怎么判断该不该让AI写？我总结了一个简单的原则：

判断维度 交给AI 自己手写
代码重复性 高（模板化、模式化） 低（每次都不一样）
业务复杂度 低（CRUD、数据转换） 高（状态机、规则引擎）
性能要求 低（非核心路径） 高（热点路径、并发控制）
错误容忍度 高（出错可快速修复） 低（出错影响大）

你想想看，这个表格其实就是个决策矩阵。每次写代码前，拿它过一遍，基本不会出错。

2.4 本章知识体系

最后，我用一张图帮你梳理一下本章的核心逻辑：

代码生成 vs 手写 AI 生成代码 样板代码（DTO、配置、CRUD） 单元测试（边界、异常、覆盖率） 数据模型（表结构、字段定义） 特点：重复、模式化、低风险 手写代码 核心算法（排序、加密、风控） 复杂业务逻辑（状态机、规则） 性能敏感代码（缓存、并发） 特点：独特、复杂、高风险 核心原则：AI做重复，手写做决策

这张图其实就一句话：AI做重复，手写做决策。记住这个原则，你就能在AI时代游刃有余。

可可精品资料库

← 上一章 📖 返回目录 下一章 →