一篇 HN 上的文章引发了不小的讨论，标题直接问了一个很多开发者心里都嘀咕的问题：如果 AI 写代码已经变得这么强了，为什么软件体验反而越来越差？说实话，这个矛盾我一直挺在意的。过去两年 AI 代码生成工具的进步有目共睹，GitHub Copilot、Cursor、Codex 这些工具越来越成熟。但与此同时，软件的 bug 率、崩溃率、用户体验——翻翻社交媒体就知道了——并没有明显变好。
代码生成效率不等于软件质量
翻了下原文和 HN 评论区的讨论，发现一个被很多人忽略的点：AI 生成代码的速度太快了，但代码质量的可控性并没有同步提升。举个实际的场景——你用 Copilot 或者 Codex 写一个函数，AI 可能几秒钟就生成完了，看起来很完整，甚至还有注释。但问题在于，这些生成的代码很少被认真审查。原因很简单：生成得太快了，快到开发者潜意识里觉得"AI 写的应该没问题"。我见过一个项目里，AI 生成的代码在 CI 跑过了就合进去了，结果几周后才发现那个"没问题"的代码里有个边界条件没处理，导致生产环境的偶发崩溃。从工程角度看，这里的问题不是 AI 生成的质量低，而是"生成速度 >> 审查能力"。以前手写一段代码可能需要半小时，审查也是半小时；现在 AI 十秒生成，你花在审查上的时间可能还是半小时，但心理压力完全不同——你总觉得"AI 写的应该没问题，我再看看就行"，结果很多问题就这么滑过去了。
一个真实的部署事故
正好前阵子在处理一个 case。同事用 Cursor 写了一段数据处理逻辑，AI 生成的时候看起来逻辑清晰，代码风格也好。部署到 staging 环境跑了几天没问题，就推到了生产。结果上线后第二天，发现部分用户数据没有按预期被处理——原因是 AI 生成的代码里有一个隐藏的类型转换问题，特定输入下会导致数据静默丢失。更麻烦的是——因为代码是 AI 生成的，出问题后排查的方向都搞偏了。一开始大家以为是业务逻辑的问题，翻了几百行代码才发现是某个类型注解没对齐导致的。如果这段代码是自己手写的，排查路径会更清晰，因为你知道自己当时想做什么。但 AI 写的代码，你并不知道它为什么用了这个类型而不是那个类型。真正的问题是——AI 代码生成工具让"写代码"变快了，但让"理解代码"变难了。
开发流程需要重新设计
说实话，我不觉得 AI 代码生成本身有问题。工具没有问题，但流程需要重新设计。以前开发者的工作流是：需求分析 → 设计 → 编码 → 审查 → 测试 → 部署。AI 把这个流程里"编码"这一步的效率提升了可能 5-10 倍，但审查、测试、部署这些环节的流程并没有同步升级。结果就是编码成了整个流水线的最快环节，瓶颈转移到了审查和测试上。一个有意思的现象——我注意到一些团队开始采取"AI 代码必须先通过自动化测试才能进入人工审查"的策略。听起来像是常识，但在 AI 代码生成普及之前，不是每个团队都严格要求这个流程的。怎么说呢，AI 代码生成实际上倒逼了工程流程的规范化。当然——这个问题的另一面是，AI 也在进步。Claude Opus 5、GPT-5.6 这些模型的理解能力在提升，也许未来的 AI 不仅能写代码，还能帮我们审查和调试代码。但那是未来的事。对现在的开发者来说，重要的是建立一种意识：AI 生成的代码，不能省掉审查环节。那问题来了——当一个工具让某个环节变快了 10 倍，但上下游还没准备好，整个流程的效率其实不是看最快的环节，而是看最慢的瓶颈。这大概就是为什么 AI 代码生成这么强了，我们的软件体验却不升反降。
夜雨聆风