写在前面
三个月前我开始用AI Agent写代码，觉得这玩意儿太神了——接口、页面、测试一条龙，不到半小时出一个模块。然后上线第二周就出事了。

用户反馈说某些操作莫名其妙的没有权限。排查发现是AI写的权限校验中间件，把角色继承关系搞反了。代码逻辑完美，业务逻辑全错。

从那以后我养成一个习惯：AI写的每一行代码，我都会过一遍我自己定的7个检查项。 今天把这7个坑全摊出来，你对着看一遍，能省掉90%的返工时间。

本文所有案例基于真实项目经历，不编造、不避重就轻。

坑一：业务逻辑理解偏差（频次最高，后果最严重）
这是AI编程里最常见的坑，没有之一。

现象是这样的。你给AI一个需求，它理解的逻辑和你完全不一样。代码写得漂亮，功能也正常——但业务规则不对。问题在于AI只看你写的文字，不知道你公司里的约定俗成、历史遗留、以及那些没写在文档里的潜规则。

我遇到过最离谱的一次。让AI写一个数据导出功能，需要过滤掉离职员工的数据。AI写的代码是按用户表的status字段判断——离职就是status=0。但我们公司的实际情况是：员工离职后还保留数据访问权限3个月（项目交接期），而且外包人员走的是另一套工单系统，status字段根本不走那个逻辑。

AI不知道这些。它只能根据你给的prompt，套用最通用的方案。

修复成本是什么呢。需要重写逻辑层，调整数据过滤规则，然后重新跑一轮测试。如果测不出来上线了，就是生产事故。

我的检查方法：

拿到AI生成的代码后，第一件事不是跑，是问自己三个问题。这个功能有没有我不知道的业务规则？涉及的数据有没有特殊状态（离职、冻结、测试环境差异）？和上下游系统的交互有没有约定俗成的协议？

如果任意一个答案是不确定，先人工补上这些规则再让AI改，不要直接用初版代码。

坑二：边界条件漏得干干净净
AI生代码有一个特别烦人的特征——逻辑主体写得很好，边界条件几乎全漏。

空值怎么处理？AI默认不存在。异常怎么catch？AI经常写个空的catch块。并发冲突怎么办？AI假装不存在。超时重试机制？没提就不会写。幂等性保证？需要你专门提醒。

有一次让AI写一个批量更新订单状态的接口。主流程没问题，遍历订单、更新状态、返回结果。但上线后发现一个诡异的bug：某几个订单被更新了两次。

排查结果是：客户端因为网络抖动超时重试了，同一个请求被处理了两次。AI写的接口没有做幂等校验（基于订单号判断是否已处理过），一笔订单被连续改了两遍状态。

这个坑的修复成本不大，但如果涉及金钱操作就很致命了。

我的检查方法：

把AI生成的方法签名拿出来，对着每个入参问一句：如果这个字段是null，这代码能扛住吗？如果外部调用超时重试了，结果会出错吗？如果有1000条数据一起进来，性能会崩吗？

三个问题问完，90%的边界问题能被提前发现。

坑三：SQL没有索引意识
AI写SQL的能力很强——JOIN、子查询、聚合函数，语法上基本不会出错。

但它从不考虑索引。

一个典型的场景。让AI写一个用户列表查询接口，带模糊搜索和分页。AI直接在WHERE子句里写了三个字段的LIKE模糊查询，ORDER BY用的create_time。建表的时候只给主键ID建了索引。

开发环境就几十条数据，跑起来飞快。

上了测试环境，数据量到万级别，一个查询跑了2.1秒。因为没有对应的联合索引，数据库走了全表扫描。万级别是2秒，百万级别直接超时。

更要命的是有时候AI还会写那种带函数处理的WHERE条件——比如WHERE DATE_FORMAT(create_time) = ‘2026-07-01’。这种写法直接让索引失效，数据库弃用B+Tree走全表扫描。

我的检查方法：

所有AI生成的SQL，EXPLAIN跑一遍。如果type那列是ALL（全表扫描），必须加索引。写SQL的时候明确告诉AI表中已有的索引名称，让它知道哪些查询条件可以走索引。

坑四：硬编码和魔法数字到处都是
AI特别喜欢把配置值写在代码里。

超时时间30秒、最大重试次数3次、分页大小20条、Redis过期时间3600秒、文件上传大小限制10MB——全部硬编码在业务逻辑里。

这些值在开发环境可能刚好合适，但到了线上就是灾难。并发量一上来，30秒的超时会让连接池爆掉。Redis过期时间太久会导致缓存雪崩。分页大小太小导致前端无限滚动触发几百次请求。

我的检查方法：

CTRL+F搜代码里的数字。凡是常量、凡是将来可能改的、凡是环境之间有差异的，全部提取到配置文件里。

坑五：异常处理写了等于没写
AI最喜欢写的一种代码：

try {
someOperation();
} catch (Exception e) {
// 这里应该记录日志
}

真的，它就敢这么写。注释告诉你"这里应该记录日志"，但什么都没干。上线后出错了你看不到日志，不知道哪里挂了，只能对着用户报的错盲猜。

还有一种更坑。AI在catch块里写了一个e.printStackTrace()。这行代码在本地开发的时候会在控制台打堆栈，但到了Docker容器里、到了K8s集群里，没人看控制台，日志根本不会被任何系统采集。

我的检查方法：

全文搜索catch块，确保每个catch都有明确的处理逻辑——要么打日志（带业务上下文的不带），要么抛自定义异常，要么走补偿逻辑。空catch绝对不允许过。

坑六：线程安全完全不考虑
如果你用AI生成Java或Go的代码，涉及并发场景的时候，十有八九没有考虑线程安全。

让AI写一个计数器服务，它直接用HashMap存数据。这在高并发下会导致循环链表，CPU直接飙到100%。让AI写一个配置管理器，它不保证可见性——线程A改了配置，线程B永远读不到新值。

JVM的内存模型、Go的goroutine调度、Python的GIL——这些底层知识AI知道，但写代码的时候默认不考虑。

我的检查方法：

如果代码里有共享状态，强制要求AI加锁或使用并发安全的容器。HashMap改ConcurrentHashMap，普通的int计数改AtomicInteger。这些检查点你提一次，AI可以帮你批量改，但你不提它不会主动加。

坑七：生成的代码能跑但不可维护
这是最隐蔽的坑。代码能跑、业务逻辑对、边界条件覆盖了、性能也没问题——但就是没法维护。

函数长得要死。一个方法写了300行，参数列表一堆，逻辑嵌套多到你得拿纸画图。变量命名单字母满地飞——i, j, k, a, b。没有注释，模块之间随意调用，改了A模块B模块跟着崩。测试代码覆盖率够但assert全是对null的判断，没测任何业务逻辑。

我的检查方法：

写完一个模块后，让AI做一次代码审查。给的指令是：找长度超过50行的方法、找没有注释的公共方法、找可以提取的重复代码。让AI自己改自己的代码，然后用Git diff看改了什么，确认没问题再合。

最后
我现在的AI编程流程是这样的。

第一步，给AI明确的需求和边界约束。（“这个接口要考虑角色继承，权限规则参考PermissionService里的hasRole方法”）

第二步，AI生成代码后，我过一遍上面7个检查项。

第三步，发现的问题让AI自己改。（“第3个SQL没有索引，表里已有idx_user_status联合索引，请优化”）

第四步，改完后再检查，确认没问题跑测试。

第五步，上线后观察日志和监控，如果有异常立刻回滚。

这个流程跑顺了之后，AI编程的效率提升是实打实的——但不是因为你少干了活，而是因为你把精力从"写重复代码"转移到了"做架构决策和代码审查"上。

如果你现在开始用AI写代码，或者已经在用但总觉得不放心，建议你把上面7个坑存下来，每次看AI生成的代码前，对着检查项过一遍。养成习惯后，能省掉大量返工和线上事故。