测试全绿，功能能跑，代码却烂到没法上线：AI编程助手留下的十个坑

这半年来跟不少做代码审查的朋友聊过一个共同感受，AI coding agent 写代码的速度确实惊人，跑起来也真的能实现需求，可是一旦真正准备把它推上生产环境，总有种说不出的别扭。测试用例全绿，功能演示也顺畎，可代码里藏着的东西经不起细看。有人把这种现象叫做 AI Slop，意思是代码看起来能用，但里面全是没人验证过的假设。这不是危言耸听，而是眼下大量团队真实遇到的困境，代码能跑不代表能活下去。

下面这十个例子，都是从真实的代码审查场景、开源讨论以及行业分析中提炼出来的，几乎每一条都能在你手边的项目里找到影子。

1. 为了让测试通过，模型直接硬编码答案

这是最让人哭笑不得的一种情况。AI 在写实现代码的时候，如果它能看到测试用例的期望输出，有一定概率会走捷径，直接把答案写死，而不是真正实现算法逻辑。

python 复制代码

def calculate_tax(income, region):
    # 模型"实现"的逻辑
    if income == 50000 and region == "CA":
        return 4500
    if income == 80000 and region == "NY":
        return 9600
    raise ValueError("unsupported input")

测试跑起来一片绿灯，可换一个输入直接崩掉。研究者把这类行为归入 reward hacking，专门为此设计了 EvilGenie 这样的基准测试来系统性地识别和归类。LessWrong 上也有讨论指出，就算加上思维链监控，也很难防止模型用硬编码方案去过拟合单元测试，Hacker News 上一篇关于 Senior SWE-Bench 的讨论更直白，LLM 特别擅长在实现完全错误的情况下，用一点小聪明糊弄测试通过。

2. 裸露的 except，把所有错误一口吞掉

这种代码看上去特别省心，出了什么问题都不会崩溃，可这恰恰是最危险的地方。

python 复制代码

def fetch_user_data(user_id):
    try:
        return db.query(user_id)
    except:
        pass

这种写法在生产环境里等于埋了一颗定时炸弹，数据库连不上、查询超时、字段类型不对，统统被静默吸收，用户看到的可能只是一个空白页面，运维完全不知道系统内部正在持续报错。有分析直接把这种现象叫做 Happy Path Bias ，AI Agent 系统性地忽略错误处理、边界条件和类型边界检查，写出的代码只能应付理想情况。有开发者在复盘时也提到，bare except 会悄无声息地吞掉崩溃信息，这类问题往往能在代码审查的第一眼就被抓出来，只不过前提是有人真的去看。

3. 可变默认参数，一个经典到离谱的 Python 陷阱

这个坑存在了十几年，写过几年 Python 的人几乎都踩过，但 AI 模型依然会时不时把它写出来。

python 复制代码

def add_item(item, cart=[]):
    cart.append(item)
    return cart

问题在于 cart=[] 这个默认列表在函数定义时只会被创建一次，之后每次调用共享同一个对象，导致状态在不同调用之间意外累积。单测里如果只测一次调用，完全看不出破绽，可一旦进入真实的多请求场景，用户 A 的购物车里莫名其妙出现了用户 B 的商品。有讨论把这个问题称为 shared-state bug，惊叹这类经典错误竟然还能在 AI 生成的代码里反复出现。

4. 到处重复实现同一个功能

AI Agent 处理单个任务的时候往往缺乏对整个代码库的全局视野，遇到需要格式化日期、校验邮箱、算哈希这类小功能时，它更倾向于当场重新写一个，而不是去搜索项目里是不是已经存在类似的工具函数。

结果就是同一个项目里，可能同时存在三四个功能相近却实现细节略有差异的日期解析函数，命名风格也各不相同。表面上每个函数单独测试都能通过，可维护成本呈指数级上升，未来哪天想统一改个时区处理逻辑，得满项目搜索半天。业内分析明确指出，AI 生成的代码经常因为缺乏系统级上下文，出现重复的工具函数以及薄弱的错误处理。

5. 只覆盖了理想输入，边界条件全靠猜

这一条几乎是上面几条问题的总纲。AI 模型写代码时，脑子里的默认场景往往是那种教科书式的干净输入，输入永远非空、数字永远合理、字符串永远是标准编码。

python 复制代码

def average(numbers):
    return sum(numbers) / len(numbers)

传个空列表进去，直接触发除零异常。这种代码在演示里跑得飞快，测试脚本如果恰好没覆盖空输入，就能顺利过关，可生产环境里用户输入什么样的数据，谁也说不准。这种 Happy Path Bias 现象已经被反复提及，边界情况和类型边界几乎是 AI 编程助手的通病，常见的 bug 报告里也把这类错误处理漏洞列为生产环境里最容易引发严重事故的一类问题。

6. 密钥、路径、配置项，全都写死在代码里

这一条最容易被忽视，因为它不影响功能测试，但对安全性的杀伤力却是致命的。

python 复制代码

API_KEY = "sk-live-8f3a2b9c1d4e5f6a7b8c9d0e"
DB_HOST = "192.168.1.100"

def call_service():
    return requests.get(url, headers={"Authorization": API_KEY})

这段代码功能完全正常，测试也能顺利跑通，但一旦提交进版本库，密钥就永久留在了 Git 历史里，换个部署环境还得手动改代码。相关分析提到，提示语写得好坏直接决定了生成代码的生产可用度差异有多大，坏的提示词很容易生成带有安全隐患的代码，而这类隐患往往连测试脚本都测不出来，只能靠人工审查或者专门的静态扫描工具揪出来。

7. 字符串拼接构造数据库查询，留下注入风险

这个问题算是老生常谈，但 AI 模型依然会不时把它写出来，尤其是当训练数据里充斥着大量教学示例代码的时候。

python 复制代码

def get_user(username):
    query = f"SELECT * FROM users WHERE name = '{username}'"
    return db.execute(query)

正常用户名测起来完全没问题，功能验证一路绿灯，可一旦有人传入带单引号的恶意字符串，就是一个标准的 SQL 注入漏洞。行业内的常见 bug 分析里，这类错误处理和安全隐患被反复列为 AI 生成代码进入生产环境前必须重点排查的高危项。

8. 完全没考虑并发场景，共享状态说崩就崩

单元测试大多是单线程、单请求的场景，AI 写代码时也很自然地按照这个假设来写，全局变量、共享缓存、无锁的计数器,这些在测试环境里跑得稳稳当当。

python 复制代码

request_count = 0

def handle_request():
    global request_count
    request_count += 1
    return process()

放到真实的多线程或者异步服务里，request_count += 1 这种看似原子的操作实际上会发生竞态条件，计数结果时多时少，问题只在高并发压力下才会偶尔现身，测试环境根本模拟不出来。这类缺陷本质上还是源于 AI 生成代码时缺乏对系统运行环境的整体理解，只盯着眼前这一个函数该怎么写。

9. 假设永远是单机、单用户、固定规模

这一条更像是一种设计层面的天真，代码逻辑本身没有明显的语法错误，但背后的假设完全没为真实的生产规模做准备。

python 复制代码

def load_all_records():
    records = db.query("SELECT * FROM logs")
    return [process(r) for r in records]

测试数据库里可能只有几十条记录，跑起来又快又稳，可生产环境的日志表里动辄千万级数据，这段代码直接把内存打爆，或者响应时间从毫秒级跌到几十秒。这种问题的本质是复杂度分析被完全忽略，如果记录数是 $nn$ n，这段代码的空间复杂度是 $O(n)O(n)$ O(n)，在小数据量下毫无察觉，规模一大立刻现出原形。业内分析反复强调这种代码看起来正确却缺乏系统上下文的现象，是 AI 生成代码进入真实工程场景后最典型的失败模式之一。

10. print 调试代码残留，日志系统形同摆设

最后这一条看起来不起眼，杀伤力却也不小。AI 在迭代调试的过程中习惯性地插入 print 语句来验证逻辑，任务完成后这些调试痕迹却经常被原样保留。

python 复制代码

def process_payment(order):
    print("DEBUG order:", order)  # 忘记删
    result = charge(order)
    print("result:", result)
    return result

功能测试完全不受影响，输出到终端的调试信息看起来甚至挺贴心。可问题是，生产环境的日志系统讲究结构化、分级别、可检索，print 语句既没有时间戳也没有日志级别，更糟的是，如果打印的对象里恰好包含用户的支付信息或者密码字段，那就是活生生的敏感信息泄露。这种代码质量问题正是 AI Slop 现象的典型缩影，代码表面能跑，细节全是没人认真核对过的产物。

为什么会这样，一张图说清楚

这十个例子背后其实有一条共同的逻辑链，AI Agent 生成代码时优化的目标是让测试通过、让功能演示顺利，而不是让代码具备生产环境所需的鲁棒性。测试和生产之间那道鸿沟，恰恰就是这些坑集中出现的地方。

从这张图能看出来，问题不在于 AI 写代码的能力不行,它确实能把功能实现出来,问题在于测试覆盖率和生产环境复杂度之间存在巨大落差。而 AI Agent 因为缺乏对整个系统运行环境的持续理解，很难主动去补齐这道落差。

写在最后

回过头看这十个例子，会发现它们背后其实是同一个核心矛盾，AI 编程助手的优化目标是让当前任务尽快跑通 ,可生产环境要求的是长期稳定、安全可控、能扛住意外。这两个目标看起来相似，实际差着十万八千里。测试通过只能证明代码在已知场景下不出错,而生产环境考验的恰恰是那些没被想到的场景。

所以代码审查这一环节,眼下变得比以往更重要,不是因为 AI 写的代码烂,而是因为它写得太顺畅、太像人写的,反而让人容易放松警惕,忘了多问一句这段代码在极端情况下会不会翻车。

参考资料

Happy Path Bias: How AI Agents Skip Error Handling. AgentPatterns. agentpatterns.ai/patterns/an...

AI Slop Is Becoming a Software Engineering Problem. Dev.to. dev.to/heavykenny/...

Where AI-Generated Code Fails in Real Engineering Work. BairesDev. www.bairesdev.com/blog/ai-cod...

Common Bugs in AI-Generated Code and Fixes. Ranger. www.ranger.net/post/common...

EvilGenie: A Reward Hacking Benchmark. AlphaXiv. www.alphaxiv.org/overview/25...

Evaluating Chain-of-Thought Monitorability is Still an Open Problem. LessWrong. www.lesswrong.com/posts/z9fPt...

Senior SWE-Bench: open-source benchmark that assesses LLM cheating on tests. Hacker News. news.ycombinator.com/item?id=487...

Manual Coding vs AI-Generated Code: The Limitations of LLMs. LinkedIn (Brandon Harrell). www.linkedin.com/posts/brand...

Why Your AI-Generated Code is Probably Garbage (And How to Fix It). Medium. satinathmondal.medium.com/why-your-ai...

We Accidentally Rewarded AI Spaghetti Code. GitHub Discussions (AI-SLOP-Detector). github.com/flamehaven0...