AI 写代码越来越快，为什么 Code Review 反而更慢了？

最近在团队里，我明显感觉到一个矛盾：我们用 GitHub Copilot、Cursor 等 AI 工具写代码的速度越来越快，甚至能用自然语言直接生成整个函数、模块，但 Code Review 却变得越来越痛苦、越来越慢。以前一个 PR 可能半小时就看完了，现在动不动卡一整天，甚至要反复讨论好几轮。这背后到底发生了什么？我想从实战角度，用代码来演示这个问题的根源，并给出一些应对思路。### 一、AI 写的代码：快是快，但质量飘忽不定先说结论：AI 写代码快，是因为它擅长“抄模式”。它能根据你的注释或上下文，快速拼接出符合常见规范的代码。但这种“快”是有代价的——它经常生成“看起来对、实际有坑”的代码。#### 案例 1：一个看似完美的 Python 函数假设我需要一个函数，把用户输入的 CSV 字符串转成字典列表，并过滤掉空行。我用 AI 提示“用 Python 写一个函数，解析 CSV 字符串，返回字典列表，跳过空行”。AI 可能几秒钟就给出这段代码：python# AI 生成的代码：parse_csv_string.pydef parse_csv_string(csv_text: str) -> list[dict]: """ 解析 CSV 字符串，返回字典列表，跳过空行。 """ if not csv_text.strip(): return [] lines = csv_text.strip().split('\n') if len(lines) < 2: return [] headers = lines[0].split(',') result = [] for line in lines[1:]: if not line.strip(): continue values = line.split(',') # 问题：这里直接 zip，如果 values 长度不等于 headers 会怎样？ row = dict(zip(headers, values)) result.append(row) return result# 测试用例test_data = "name,age,city\nAlice,30,New York\nBob,25,\nCharlie,35,Los Angeles\n\n"print(parse_csv_string(test_data))这段代码看起来逻辑清晰、有 docstring、测试也跑得通。但作为 Code Review，你会发现至少两个隐藏问题：1. CSV 解析没有处理引号内的逗号（比如 "Smith, John", 30 会被错误拆分）。2. 当某行字段数不等于表头数时，zip 会静默截断或丢失数据（比如上面 Bob,25, 这一行，city 字段缺失，但 zip 后只生成两个键值对，不会报错）。作为 Reviewer，你需要花时间思考这些边界情况，而 AI 生成这些代码只用了几秒。这就是“快”的反面——它不思考业务语义。### 二、AI 写的代码：隐式依赖和“幻觉”问题AI 另一个大问题是它会“幻觉”出一些不存在的 API 或逻辑。这在大型项目中尤其致命，因为 Review 时你要去核实每个调用的正确性。#### 案例 2：一个带外部调用的业务函数假设我们有一个电商系统的订单处理模块，AI 被提示“写一个函数，用订单 ID 从缓存获取订单，如果没有则从数据库加载，并更新缓存”。AI 可能生成如下代码：python# AI 生成的代码：order_service.pyimport redisfrom django.core.cache import cache # 注意：这里混合了 redis 和 django cachefrom myapp.models import Orderdef get_order_with_cache(order_id: int) -> Order | None: """ 根据订单 ID 获取订单，优先从缓存读取，缓存未命中则查库并回写缓存。 """ # 问题 1：cache_key 命名不统一，可能与其他模块冲突 cache_key = f"order:{order_id}" # 问题 2：这里用了 Django cache，但 AI 又 import 了 redis（冗余） order_data = cache.get(cache_key) if order_data: # 假设缓存里存的是 dict，但实际可能存的是 JSON 字符串 return Order(**order_data) # 问题 3：从数据库加载 try: order = Order.objects.get(id=order_id) # 问题 4：直接序列化整个对象到缓存，可能包含敏感字段（如支付信息） cache.set(cache_key, order.__dict__, timeout=3600) return order except Order.DoesNotExist: return None这段代码在 Review 时会让 Reviewer 抓狂：- 缓存策略混乱：同时 import redis 和 django.core.cache，但只用了一个。- 序列化风险：order.__dict__ 会把模型的所有字段（包括外键、时间戳、甚至密码哈希）都塞进缓存，这既浪费内存又可能泄露数据。- 反序列化错误：Order(**order_data) 假设缓存存的是 dict，但实际项目中通常存 JSON 字符串，需要 json.loads。- 并发问题：没有考虑缓存击穿，高并发下多个请求同时查库。Reviewer 需要逐行分析这些问题，而 AI 生成这段代码只用了 10 秒。Review 的时间成本被急剧放大。### 三、为什么 Code Review 变慢了？三个核心原因从上面两个例子，我们可以总结出几个模式：1. AI 代码的“黑盒”性：Reviewer 无法像看待人类写的代码那样，通过逻辑推理理解“为什么这么写”。AI 没有意图，只有统计概率。因此 Reviewer 必须花更多时间验证每个分支、每个边界条件。2. 隐式假设增多：AI 不知道你的项目里缓存是用 Redis 还是 Memcached，不知道你的模型有哪些字段、有什么约束。它生成的代码往往包含大量“通用但错误”的假设，Reviewer 要逐条纠正。3. 代码量膨胀：AI 鼓励“多写注释、多写函数”，但经常生成冗余代码（比如重复的 import、不必要的类型转换）。Review 时这些“噪音”会分散注意力。### 四、如何应对？一些实战建议作为全栈工程师，我认为解决方案不是不用 AI，而是改变 Code Review 的方式：- 建立“AI 代码清单”：在 Review 前，强制检查几个常见问题，比如：是否有未处理的异常？是否有硬编码值？是否有未使用的 import？- 要求 AI 生成测试用例：让 AI 同时生成单元测试，并在 Review 时先看测试是否覆盖了边界情况（比如空值、极值、并发场景）。- Review 时关注“为什么”而非“是什么”：如果 AI 代码看起来“正常但奇怪”，直接问作者“这里为什么这么写？”——通常作者也答不上来，因为 AI 写的。### 五、总结AI 写代码越来越快，这是不争的事实。但 Code Review 变慢，也是现实的代价。核心原因在于：AI 生成的代码缺乏“意图”和“上下文意识”，它只是统计语言模型的输出，而不是经过深思熟虑的工程决策。作为开发者，我们要接受一个现实：AI 是加速器，但不是替身。它能让写代码变得更快，但 Review 的深度和质量不能打折。未来，我们可能需要更智能的 Review 工具（比如自动检测 AI 代码的常见问题），或者改变团队的协作流程——比如让 AI 先自检一遍再提交 Review。但无论如何，记住一点：代码是写给人类读的，其次才是给机器执行。 AI 写代码再快，如果 Review 跟不上，最终交付的质量依然会打折扣。这或许是这个时代全栈工程师面临的新课题。