AI写代码会堆出新一代屎山吗？

过去十年，我们对“屎山代码”的想象几乎形成了固定模板：缩进混乱、变量名像密码、函数动辄上千行、注释早已与实现脱节。于是当自动补全和代码生成工具普及后，很多人第一反应是：机器写出来的代码语法规整、命名规范、注释齐全，是不是反而更干净？

现实给出的答案并不乐观。会，而且正在发生。 只不过这种新时代的屎山，和我们过去十年见到的那种屎山，在表现形式上完全不同；更棘手的是，解决这类问题的排查与修复成本，可能比纯人工手写的旧代码还要高出数倍。

一、行业现状：讨论的早已不是“要不要用”

先纠正一个常见的感知偏差。今天在大型研发组织中，自动化生成代码的比例已经相当高。某云厂商在近期的财报沟通中明确提到，约有一半的代码由智能体编写、再由工程师审查；某代码托管平台的年度报告显示，绝大多数新注册开发者在第一周就开始使用自动补全类工具；结合多家机构近期的调研数据，整个行业中AI参与编写的代码比例即便没有绝对过半，也已接近一半。

这意味着一个前提性的转变：我们讨论的已经不是要不要用的问题，而是如何为这种开发模式“擦屁股”的问题。 代码生成的边际成本被压到极低，审查与治理的边际成本却没有同步下降，这个剪刀差正是新一代技术债的温床。

二、重新定义屎山：表层整洁不等于工程健康

很多外行或初级开发者对屎山的理解停留在表层：缩进乱、命名差、函数长。如果以此为标准，AI生成的代码几乎无可挑剔——语法极其规整、缩进完美、变量命名符合规范，甚至会贴心地补上规范的英文注释。单看一个文件，挑不出毛病，甚至赏心悦目。

但工程语境中的系统性灾难，从来不是因为缩进难看引起的。真正的灾难来自技术债的无序积累：

• 模块边界混乱：生成代码往往“就地解决问题”，把本应属于领域层的逻辑塞进接口层或数据访问层，边界被一次次侵蚀；
• 重复实现业务逻辑：同一个校验规则在多个文件里各写一遍，彼此语义略有差异，后续修改时无人知道该改哪一处；
• 隐式依赖全局状态：直接读写全局变量、单例或环境上下文，使调用链的正确性依赖运行时的“巧合”；
• 错误处理被强行吞掉：异常被捕获后仅打印一行日志或静默忽略，故障被推迟到更难定位的环节才爆发。

AI恰恰在制造这类深层结构性灾难上效率高得惊人。它擅长在局部生成“看起来正确”的代码，却缺乏对系统整体约束、并发模型和历史债务的全局理解。局部最优的叠加，往往是全局最差。

三、一个真实场景：状态机重构与线上状态错乱

某核心业务线要做订单状态流转的重构。一位工作不到两年的年轻工程师接下了需求，非常熟练地把需求文档喂给一个智能编程工具，让它生成对应的状态机流转代码。几分钟后，几百行代码生成完毕，单元测试全绿，手动点了几下页面功能正常，直接提交了合并请求。审查的导师看代码规整、注释完整，跑了主流程没问题，便批准合入。

三个星期后，线上开始零星出现订单状态错乱的客诉：用户明明已经付款成功，但在某些特定并发场景下，订单状态却被重置回待支付，系统据此自动触发了库存释放逻辑，造成超卖风险。

排查这类问题的困难在于：如果换成人工手写代码，有经验的工程师大概率能猜到是某处并发忘了加锁，或数据库事务边界没控制好；而面对生成代码，问题往往藏在一段“每条语句都正确”的组合里。示意性地看，生成代码可能长这样：

def transition(order_id, target_status):
    order = load_order(order_id)          # 读
    if not is_valid_transition(order.status, target_status):
        return False
    order.status = target_status          # 改
    save_order(order)                     # 写
    if target_status == "PAID":
        release_inventory(order)          # 副作用
    return True

单看没问题，但它把“校验—修改—持久化—副作用”放在一个没有并发保护、没有幂等语义、也没有版本号乐观锁的函数里。当支付回调与超时补偿任务并发执行时，后写者覆盖前写者，状态回退便发生了。更麻烦的是，生成代码常常把状态判断分散在多个辅助函数中，隐式依赖调用顺序，排查时必须先重建一整张“谁在什么时候改了状态”的时序图。

四、为什么修复成本反而更高

1. 语义意图缺失：人工代码里的“为什么这么写”往往能从提交记录、注释和讨论中还原；生成代码只表达“怎么写”，不表达“为什么不能那样写”，审查者难以判断边界条件是否被考虑。
2. 错误被均匀分布：人工 bug 常集中在少数高风险模块，生成代码的缺陷则均匀散布在大量看似规范的代码行中，定位成本被摊薄到每个文件。
3. 测试的虚假安全感：生成代码擅长让单元测试变绿，但测试往往与实现同源生成，覆盖的是“实现所假设的路径”，而非真实并发与异常路径。
4. 风格一致掩盖结构不一致：统一命名和缩进让代码库看起来整齐，反而降低了审查者的警觉性。

五、可落地的治理实践

1. 把审查重心从“风格”移到“约束”。 建立架构约束清单：分层边界、领域逻辑归属、并发与幂等要求、异常处理规范。审查时逐条核对，而不是看注释写得好不好。

2. 对生成代码实行“边界先行”。 先由人确定接口契约、状态机迁移表、事务与锁策略，再让工具在边界内填充实现。约束越显式，生成结果的自由度越可控。

3. 强化可观测性。 在关键状态变更处埋点，记录变更前后的状态、触发来源与请求标识，使“状态为何回退”可被追溯，而不是靠日志猜测。

4. 用不变量测试替代路径测试。 针对状态机编写属性测试或不变量断言（如“已支付订单不得回退到待支付”“库存释放必须幂等”），让测试检验业务规则而非实现细节。

5. 控制单次生成规模。 大块生成难以审查，应拆分为可独立验证的小变更，每个变更附带明确的约束说明与验证方式。

6. 建立技术债台账。 对生成代码中识别的重复实现、隐式全局状态、被吞掉的异常登记在册，设定清理窗口，避免债务静默累积。

结语

AI 让写代码变便宜了，但没有让“写对的代码”变便宜。新一代屎山的可怕之处，不在于它难看，而在于它好看——规整的语法、完整的注释和全绿的测试，会让人误以为系统是健康的。真正决定系统长期可维护性的，始终是模块边界、状态一致性、异常语义与可观测性这些工程约束。工具只是放大器：约束清晰时它放大效率，约束缺失时它放大的就是债务。