1. AI 写代码这件事，到底靠不靠谱

这两年我身边写代码的人，几乎没有谁没试过让 AI 帮忙生成几段代码。从最早只能补全一行的自动提示，到现在能一口气吐出整个模块的智能体，工具进化得飞快。但用得越多，我越发现一个规律：AI 生成的代码，跑通容易，跑稳难。它能在几秒钟内给你一个看起来毫无破绽的函数，可一旦放进真实项目里，各种隐蔽的坑就开始冒头。

我自己踩过的、帮同事排查过的、在社区里看到别人吐槽的案例加起来，少说也有上百个。这些坑有个共同特点——它们不会让程序立刻崩溃，而是像慢性病一样潜伏着，等到某个特定输入、某个并发场景、某个边界条件出现时才突然发作。更麻烦的是，因为代码是 AI 写的，很多人潜意识里会降低警惕，觉得“机器写的应该没问题吧”，结果排查起来反而更费劲。

这篇文章想聊的就是这件事：AI 生成的代码，究竟哪些地方最容易埋坑，这些坑长什么样，为什么会产生，以及我们该怎么防、怎么查、怎么补。不管你是刚接触 AI 编程的新手，还是已经把它当日常工具的老手，下面这些内容应该都能帮你少走一些弯路。我会尽量用实际例子说话，把每个坑的来龙去脉讲清楚，让你下次看到类似代码时能条件反射地警觉起来。

2. 为什么 AI 代码的坑特别隐蔽

2.1 训练数据带来的“平均化”倾向

要理解 AI 代码为什么容易埋坑，得先明白它是怎么生成代码的。大模型本质上是在海量代码语料上做概率预测，它见过无数种写法，于是倾向于输出“最常见”的那种。这个特性在多数时候是优点，因为常见写法通常比较稳妥。但问题在于，最常见不等于最正确，尤其是在特定业务场景下。

举个例子，你让 AI 写一个读取配置文件的函数，它大概率会给你一个不带异常处理的版本，因为训练数据里大量示例代码为了简洁都省略了错误处理。可真实项目里，配置文件可能不存在、可能格式错误、可能权限不足，这些情况不处理就是隐患。AI 不是不知道要处理异常，而是“平均而言”它觉得不写也没关系，于是坑就埋下了。

2.2 上下文理解的天然局限

AI 生成代码时，只能看到你给它的那点上下文。它不知道你的项目用了什么框架版本，不知道你的数据库是什么隔离级别，不知道你的部署环境有没有特殊限制。它就像一个只看过图纸没见过工地的工程师，画出来的东西理论上成立，实际施工时处处对不上。

我遇到过最典型的一次，是让 AI 写一个分页查询。它给了一个用OFFSET和LIMIT的实现，逻辑完全正确。但我们的数据表有上千万行，深分页时性能直接崩掉。AI 不知道数据量级，自然也不会提醒你用游标分页。这种坑不是 AI 的错，而是信息不对称造成的，但后果得由我们来承担。

2.3 “看起来对”带来的心理松懈

还有一个很微妙但很致命的原因：AI 生成的代码往往格式工整、命名规范、注释齐全，给人一种“经过精心打磨”的错觉。这种视觉上的可信度会让人放松审查。我自己就中过招，有次扫了一眼 AI 给的代码，觉得结构清晰、逻辑顺畅，直接复制进项目，结果运行时才发现它把一个边界条件写反了。如果那段代码是我自己敲的，我可能会更仔细地检查，但因为它是 AI 写的，我下意识地信任了。

提示：审查 AI 代码时，要刻意提醒自己“这段代码我还没验证过”，把它当成一个陌生同事提交的 PR 来对待，而不是当成标准答案。

3. 高频埋坑点逐个拆解

3.1 边界条件与空值处理

这是 AI 代码翻车率最高的地方，没有之一。AI 特别擅长写“正常路径”的代码，对边界情况却常常视而不见。比如一个求数组最大值的函数，AI 会写得很漂亮，但它可能不处理空数组，也不处理数组里全是负数的情况。你测试时用[1, 3, 2]跑一遍没问题，上线后遇到空数组直接抛异常。

空值处理也是重灾区。AI 生成的代码经常假设输入永远非空，因为训练数据里的示例大多如此。可真实世界里，接口返回null、数据库字段为空、用户没填表单，都是家常便饭。我建议你拿到 AI 代码后，第一件事就是找所有可能为空的变量，逐个问自己“如果这里是空，会怎样”。

# AI 常见输出：看起来没问题 def get_user_name(user): return user.profile.name # 实际应该考虑的情况 def get_user_name(user): if user is None: return "未知用户" if user.profile is None: return "未设置资料" return user.profile.name or "匿名"

上面这个例子很能说明问题。AI 给的版本在理想情况下完全正确，但真实系统里user可能为None，profile可能没初始化，name可能是空字符串。这三个坑任何一个触发，都会导致线上问题。

3.2 并发与线程安全

只要涉及多线程、异步或者共享状态，AI 生成的代码就特别容易出问题。它经常写出看起来逻辑正确、但在并发下会数据竞争的代码。最典型的是“检查后执行”模式：先判断某个条件，再根据判断结果执行操作。单线程下没问题，多线程下两个线程可能同时通过检查，然后都执行操作，导致重复处理。

AI 还会忽略锁的粒度问题。它可能给你加了个锁，但锁的范围太大，把整个函数都包进去了，性能直接腰斩；或者锁的范围太小，关键操作没保护到。这些细节 AI 很难拿捏，因为它不知道你的并发压力有多大，也不知道哪些操作是原子的。

我处理过一个案例，AI 写了一个简单的计数器，用了“读取-加一-写回”三步。单线程测试完全正常，压测时计数总是偏小。原因就是多个线程同时读取了相同的值，各自加一后写回，覆盖了彼此的更新。修复方法是用原子操作或者加锁，但 AI 当初根本没意识到这个问题。

3.3 资源管理与泄漏

文件句柄、数据库连接、网络套接字、内存，这些资源如果没正确释放，短时间看不出问题，时间一长就会耗尽系统资源。AI 生成的代码经常忘记关闭资源，尤其是在异常路径上。它可能记得在正常流程里关闭文件，但一旦中间抛异常，关闭语句就被跳过了。

# AI 常见输出：异常时文件不会关闭 def read_config(path): f = open(path, 'r') data = f.read() f.close() return data # 更稳妥的写法 def read_config(path): with open(path, 'r') as f: return f.read()

这个例子里，如果f.read()抛异常，f.close()永远不会执行，文件句柄就泄漏了。用with语句能保证无论是否异常都会关闭。AI 其实知道with的用法，但它有时会选更“直白”的写法，结果就埋了坑。

3.4 错误处理与异常吞没

AI 生成的错误处理代码有两种极端：要么完全不处理，要么处理得太粗暴。后者更危险，因为它会吞掉异常，让问题变得难以发现。我见过 AI 写出这样的代码：用try-except包住一大段逻辑，然后在except里只打印一句日志，甚至什么都不做。这样程序不会崩溃，但错误被掩盖了，数据可能已经损坏，你却浑然不知。

还有一种情况是异常类型捕获过宽。AI 可能用except Exception捕获所有异常，包括那些本该向上传播的严重错误。这会导致程序在遇到致命问题时继续运行，产生更严重的后果。

注意：看到 AI 生成的try-except时，一定要问自己“这里捕获的异常，真的应该被吞掉吗？吞掉之后，调用方能知道出问题了吗？”

3.5 依赖版本与 API 误用

AI 的训练数据有时间截止点，它可能不知道某个库的最新版本改了 API，也可能把不同版本的用法混在一起。比如某个函数在旧版本里叫foo()，新版本改成了bar()，AI 可能给你一个混合体，看起来像那么回事，运行起来直接报错。

更隐蔽的是参数顺序和默认值的变化。AI 可能记得某个函数有五个参数，但记错了顺序，或者不知道某个参数的默认值在新版本里变了。这类问题在静态检查时不一定能发现，因为类型可能对得上，只有运行时才会暴露。

我建议对 AI 生成的依赖调用，一定要去查官方文档确认当前版本的签名。别嫌麻烦，这一步能省掉大量调试时间。

3.6 安全漏洞与注入风险

这是最需要警惕的一类坑。AI 生成的代码可能在功能上完全正确，但存在安全漏洞。最常见的是 SQL 注入、命令注入和跨站脚本。AI 有时会用字符串拼接来构造 SQL 语句，而不是用参数化查询，因为训练数据里有大量这种“教学示例”。

# 危险：字符串拼接，存在注入风险 def get_user(username): sql = "SELECT * FROM users WHERE name = '" + username + "'" return db.execute(sql) # 安全：参数化查询 def get_user(username): sql = "SELECT * FROM users WHERE name = %s" return db.execute(sql, (username,))

上面这个例子，如果username是用户输入的，攻击者可以构造特殊字符串来篡改查询逻辑。AI 经常生成第一种写法，因为它在教程里太常见了。你拿到 AI 代码后，凡是涉及外部输入的地方，都要检查有没有做转义或参数化。

3.7 性能陷阱

AI 生成的代码在功能上往往没问题，但性能上可能很差。它可能写出时间复杂度是 O(n²) 的算法，而你本可以用 O(n) 解决。它可能在一个循环里反复查询数据库，而不是批量查询。它可能创建了大量临时对象，给垃圾回收造成压力。

这些坑在小数据量下完全看不出来，一旦数据量上来，性能就断崖式下跌。我遇到过 AI 写的一个列表去重，用了双重循环，一万条数据跑了十几秒。改成用集合去重后，毫秒级完成。AI 不是不会写高效代码，而是它默认选了最直观的写法。

4. 一套可落地的审查流程

4.1 先看整体结构再抠细节

拿到 AI 生成的代码，别急着逐行读。先花一分钟看整体：函数划分合理吗？职责单一吗？有没有明显的逻辑跳跃？这一步能帮你快速判断这段代码是“基本可用”还是“需要大改”。如果整体结构就有问题，逐行抠细节是浪费时间，不如重新生成或者自己重写。

我通常会把 AI 代码当成一个草稿，先评估它的骨架能不能用。骨架没问题，再进去填肉补细节；骨架有问题，直接推翻重来。这样效率最高。

4.2 用边界值倒逼隐藏问题

审查时，针对每个函数，列出它的输入可能有哪些边界情况：空值、零、负数、极大值、特殊字符、超长字符串。然后逐个在脑子里模拟，或者直接写测试跑一遍。这一步能揪出大部分边界相关的坑。

我习惯用一张清单来检查，下面这个表格是我常用的边界检查项，你可以直接拿去用：

4.3 资源与异常路径专项检查

专门花时间看两件事：资源有没有正确释放，异常有没有被合理处理。资源方面，找所有打开文件、连接数据库、申请内存的地方，确认在异常路径上也能释放。异常方面，找所有try-except，确认捕获的异常类型是否精确，处理方式是否合理。

这一步我建议用“反向思维”：假设函数在任意一行抛异常，后面的清理代码还会执行吗？如果答案是否定的，就有泄漏风险。

4.4 安全与性能的最后把关

安全方面，重点看所有涉及外部输入的地方：SQL 查询、命令执行、文件路径拼接、HTML 输出。确认都做了参数化或转义。性能方面，看有没有嵌套循环、循环内查询、重复计算，评估数据量增大后的表现。

这两项不需要每次都深挖，但涉及敏感操作时必须过一遍。我一般会把安全检查和性能检查做成清单，每次审查 AI 代码时对照着扫一遍，养成习惯后花不了几分钟。

5. 实战排查案例记录

5.1 一个看似无害的缓存函数

之前有个同事让 AI 写了一个缓存装饰器，用来缓存函数返回值。代码看起来很简单：用一个字典存结果，调用前先查字典。测试时一切正常，上线后却发现缓存偶尔会返回错误的数据。

排查后发现，AI 用的是普通字典，没有考虑并发。多个线程同时读写字典时，可能读到正在被修改的中间状态。更麻烦的是，AI 没有设置缓存过期时间，数据更新后缓存永远不失效。这两个问题叠加，导致用户看到的是旧数据。

修复方案是换成线程安全的缓存实现，并加上过期时间。这个案例说明，AI 生成的代码在单线程测试下完全正常，但并发场景下就是另一回事。

5.2 分页查询的性能雪崩

另一个案例是 AI 写的分页查询。逻辑上完全正确，用LIMIT和OFFSET实现。小数据量下响应很快，数据涨到百万级后，翻到后面几页时查询要好几秒。

原因是OFFSET越大，数据库需要扫描的行数越多。AI 不知道数据量会增长，自然也不会提醒。后来改成基于游标的分页，用上一页最后一条记录的 ID 作为起点，性能立刻恢复正常。

这个坑的教训是：AI 生成的代码要结合数据规模来评估。同样的逻辑，小数据量和大数据量下的表现可能天差地别。

5.3 被吞掉的异常

有个项目里，AI 写了一段数据同步逻辑，用try-except包住了整个同步过程，except里只打了一行日志。结果某次同步失败后，程序继续运行，但数据已经不一致了。因为异常被吞掉，监控没有报警，直到用户反馈才发现问题。

修复方法是把异常重新抛出，或者至少上报到监控系统。AI 当初写try-except可能是想“让程序更健壮”，但过度保护反而掩盖了问题。

提示：AI 生成的try-except要特别警惕。问自己：这个异常真的可以忽略吗？忽略后调用方能感知到问题吗？

6. 让 AI 少埋坑的实用技巧

6.1 提示词里把约束说清楚

AI 埋坑很多时候是因为你没告诉它约束。如果你在提示词里明确说“输入可能为空”“需要考虑并发”“数据量可能达到千万级”，它生成代码时就会把这些因素考虑进去。我现在的习惯是，每次让 AI 写代码前，先花半分钟把关键约束列出来，塞进提示词里。

比如写数据库操作时，我会加上“使用参数化查询，避免注入”“考虑连接池和超时”“异常要向上传播”。这些约束一加，AI 生成的代码质量明显提升。

6.2 要求 AI 自己列出风险点

一个很好用的技巧是，让 AI 生成代码后，再让它自己分析这段代码可能有哪些问题。你可以这样问：“这段代码在边界条件、并发、异常处理方面有哪些潜在风险？”AI 往往能给出不错的自我批评，因为它见过大量代码审查的讨论。

我经常用这招来查漏补缺。AI 自己列出的风险点，有时候比我想的还全。然后我针对这些点逐个确认，效率很高。

6.3 小步验证，别一次性信任

不要一次性让 AI 生成几百行代码然后直接用。更好的做法是让它一小段一小段地生成，每段都验证通过后再继续。这样一旦出问题，排查范围小，定位快。

我现在的流程是：让 AI 写一个函数，我跑测试验证；通过后再让它写下一个。虽然看起来慢，但总体算下来比“生成一大坨再调试”要快得多，因为调试大段 AI 代码非常痛苦。

6.4 建立自己的代码审查清单

把上面提到的坑整理成一张清单，每次审查 AI 代码时对照着过一遍。清单可以包括：边界条件、空值、并发、资源释放、异常处理、依赖版本、安全、性能。用久了会形成肌肉记忆，看到相关代码自动警觉。

下面这张表是我自己用的速查表，你可以参考：

7. 我个人的一些体会

用 AI 写代码这两年，我最大的感受是：它是个极好的加速器，但绝不是可以完全托付的伙伴。它能把你的想法快速变成可运行的代码，省掉大量敲键盘的时间，但代码的质量、安全、性能，最终还得靠人来把关。

我现在的心态是，把 AI 当成一个手速极快但经验尚浅的实习生。它交上来的东西，我会认真看、认真测，该改的地方绝不手软。这样既享受了效率提升，又不会因为疏忽而埋下隐患。

还有一点很重要：别因为用了 AI 就放弃自己的判断。有时候 AI 给的方案看起来很合理，但你的直觉告诉你哪里不对，那就相信直觉，去查、去验证。我踩过的几个大坑，事后回想，其实当时心里都闪过一丝疑虑，只是被“AI 应该没错吧”的想法压下去了。保持怀疑，保持验证，这是用好 AI 编程的关键。

最后分享一个小习惯：我会把每次 AI 代码翻车的案例记下来，攒成一个自己的“坑库”。下次遇到类似场景时翻一翻，能提前避开很多重复的坑。这个坑库现在有几十条了，每一条都是真金白银换来的经验。