AI 模型是用海量公开代码训练出来的。"公开代码"的平均质量并不高。AI 生成的是统计上最常见的写法，不是最好的写法。
文章举了一个例子。题目是搭一个 Recipe（食谱）管理系统的基本增删查。参与者让 AI 写，AI 给出了这样的代码（使用 Jakarta Persistence，Java 的一套传统数据库操作规范）：
@ApplicationScoped public class RecipeRepository { public List<Recipe> findAll() { EntityManager em = createEntityManager(); try { return em.createQuery( "SELECT r FROM Recipe r ORDER BY r.recipeName", Recipe.class ).getResultList(); } finally { em.close(); } } public Recipe findById(Long id) { EntityManager em = createEntityManager(); try { return em.find(Recipe.class, id); } finally { em.close(); } } public List<Recipe> findByName(String term) { if (term == null || term.isBlank()) return findAll(); String t = "%" + term.trim().toLowerCase() + "%"; EntityManager em = createEntityManager(); try { return em.createQuery( "SELECT r FROM Recipe r WHERE LOWER(COALESCE(r.recipeName,''))" + " LIKE :t ORDER BY r.recipeName", Recipe.class ) .setParameter("t", t) .getResultList(); } finally { em.close(); } } private EntityManager createEntityManager() { EntityManagerFactory emf = JpaUtil.getEntityManagerFactory(); return emf.createEntityManager(); } }
这段代码能跑，没 bug。但每个方法都在手动管理数据库连接（ createEntityManager 、 em.close() ），三个方法里这段样板代码重复了三次。SQL 查询用字符串拼接，有注入风险，维护起来也费劲。
这个写法就是 AI 从训练数据里学到的最常见的 Java 数据库操作写法。它能用，但不简洁。
同样的功能，如果改成 Jakarta Data（Java 的声明式数据访问规范），只需要一个接口：
@Repository public interface RecipeRepository extends BasicRepository<Recipe, Long> { List<Recipe> findByName(String name); }
四十几行变成五行。这不只是语法糖。前者暴露了基础设施细节（连接管理、查询拼装），后者只表达业务意图（按名字找食谱）。是抽象层次的不同。
AI 不是故意挑了一个差的方案。它挑了一个最常见的方案。这就是问题所在：不加约束地让 AI 写代码，得到的是整个生态系统的平均水准。但我们要的从来不止是平均水准。
对策不难，难在执行：审查 AI 生成的代码、在 prompt 里说清楚你要什么（比如"用声明式 API，不要手动管理连接"）、要求它给出多个方案对比。不做这三步，AI 加速的不是开发，是技术债。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。