AI 改变了软件工程的什么——2 年后的深度反思
AI 改变了软件工程的什么——2 年后的深度反思
适读人群：软件工程师、技术 Leader | 阅读时长：约14分钟 | 核心价值：两年 AI 工程实践后，诚实回答什么真的变了，什么没变，什么是意料之外的变化
两年前我刚开始系统地把 AI 工具引入开发工作流，那时候写了一篇文章，标题叫"AI 会改变软件工程的什么"，里面有很多预测。
今天翻出来，有些预测说对了，有些说错了，还有一些变化是我当时完全没有预料到的。
我觉得正视这种"对账"比继续说预测更有价值。所以这篇文章，我来认真做一次两年后的深度反思。
真的改变了的：编码速度
这件事我不想低调：AI 工具让我的编码速度大幅提升，这是真的，幅度比我预期的还大。
两年前我预测编码效率能提升 30-50%，现在我的评估是：在特定任务类型上，提升超过 100%——也就是说，之前需要两小时的工作，现在一小时内完成。
具体说哪些任务：
样板代码（Boilerplate）。 CRUD 接口、DTO 定义、配置类、单元测试骨架——这些有固定模式的代码，用 AI 生成已经是肌肉记忆了。我几乎不再手写 getter/setter，不再手写标准的 Spring Boot Controller 模板，不再一行一行写 JUnit 测试的 given-when-then 框架。
不熟悉的领域快速上手。 两年前遇到一个没用过的库，我会花一两个小时读文档、找 example、踩坑。现在直接把需求和文档关键段落丢给 Claude，让它生成初版代码，通常能直接跑起来，再根据具体需求调整。这个"陌生领域的上手成本"降低幅度非常大。
调试特定类型的 Bug。 NullPointerException 的位置分析、SQL 查询的性能问题诊断、正则表达式的写法——这类有明确输入输出的调试任务，AI 比我快。
但我要诚实说：效率提升不是均匀分布的。对于我熟悉的核心业务逻辑，AI 的帮助有限。越是需要理解"这个业务逻辑为什么这么设计"的代码，AI 能给的参考价值越低，因为它不知道你的业务背景。
没有改变的：设计和架构判断
这是我认为被低估的一件事：AI 对软件设计决策的影响，远比很多人说的小。
两年下来，我发现 AI 工具在架构层面能做的，主要是：帮你列出某种设计模式的优缺点、生成特定架构的代码示例、回答"这两种方案哪个更适合这个场景"（但答案的质量取决于你能不能问出好问题）。
真正的架构判断——这个系统三年后的演化方向是什么、这个边界划在哪里、现在的过度设计和必要的前瞻设计怎么区分——AI 给不了答案，或者说，给了答案你也不能直接用，因为它不知道你的团队能力、你的业务约束、你的技术债务现状。
我有个具体例子。去年我在设计一个消息处理系统，需要决定是用 Kafka 还是用 Redis Pub/Sub。我问了 Claude，它给了一个非常标准、非常正确的框架性回答：Kafka 适合高吞吐量、持久化要求高的场景，Redis Pub/Sub 适合轻量、实时性要求高的场景。
这个答案没错。但它没法告诉我：我的团队 Redis 运维比 Kafka 熟很多，如果选 Kafka 意味着要花三周时间学习运维，那这个决策是否划算？
这个判断，必须由懂业务、懂团队的人来做，AI 只能辅助，不能替代。
测试策略也一样。 AI 可以帮你生成测试用例，但"这个系统的测试优先级应该怎么排"、"集成测试和单元测试的比例应该是多少"、"哪些地方需要测、哪些地方过度测试是浪费"——这些判断依然高度依赖经验。
没有改变的：Code Review 的本质
这是我见过被误解最多的一件事。很多人觉得 AI 可以做 Code Review，于是要么对 AI Review 过度依赖，要么干脆取消了人工 Code Review。
这两个做法我都见过，两个都有问题。
AI Code Review 能发现的：语法问题、潜在的空指针、不规范的写法、缺少错误处理。这些它做得不错。
AI Code Review 发现不了的：这段代码的逻辑是否和业务需求一致（它不知道需求文档）、这个改动有没有破坏某个隐含的系统假设（它不知道系统历史）、这个 API 设计以后会不会给调用方造成困扰（它不知道调用方的使用场景）。
好的 Code Review 本质上是知识传递和业务理解的过程。两个工程师对着代码讨论为什么这么设计、有什么更好的方式——这个过程，AI 可以参与但不能替代。
没有预料到的变化：知识搜索方式彻底变了
这是我当时完全没预料到的一个变化。
两年前，我的技术学习路径是：遇到问题 -> Google -> 找 StackOverflow 答案 -> 读文档 -> 尝试。
现在，这个路径变成了：遇到问题 -> 问 AI -> 得到一个方向性答案 -> 有需要再读文档核实。
这个变化对效率的提升非常大，但它带来了一个我没预料到的副作用：对概念的理解深度在某些方向上变浅了。
之前 Google 找答案，你会看到不同人的不同解法，看到讨论和争论，看到某个方案的局限性在哪里。这个过程慢，但信息密度高。
现在 AI 给你一个干净的答案，用了，能跑，下一个问题。你不一定知道这个答案背后的 trade-off 是什么。
这个副作用我是在某次 Code Review 被一个更资深的工程师问到"你知道为什么这里要用这个 API 而不是那个吗"的时候意识到的。我知道怎么用，但我说不清楚为什么。
所以我现在的习惯是：对于关键的技术决策，AI 给了答案之后，我还是会去读一下原始文档或者相关讨论，确保自己真的理解了，而不只是"会用了"。
没有预料到的变化：写文档的成本降低了，但很少有人利用这一点
两年前，写技术文档是大多数工程师最不愿意做的事情之一。写代码 1 小时，对应文档通常需要额外 30-60 分钟，而且写出来的文档质量往往很一般。
现在，把代码丢给 AI，让它生成文档初稿，速度很快，质量够用。这件事理论上应该让工程项目的文档覆盖率大幅提升。
但现实是：我观察到的大多数团队，文档状况比两年前并没有好太多。
为什么？AI 把写文档的成本降低了，但没有改变"不写文档没有直接代价"这个现实。 如果团队没有主动建立文档文化，单靠"现在写文档更容易了"这件事，不会自动产生好文档。
这个教训我觉得挺通用的：AI 降低了某些事情的摩擦力，但它不能改变团队的激励结构。
没有预料到的变化：代码量增加，不是减少
这个变化彻底出乎我的意料。
我以为 AI 代码生成会让代码库变小——用更简洁的方式完成同样的事情。实际上，我见到的多数团队，代码量在增加。
原因是：AI 让生成代码的门槛降低了，所以工程师开始做更多之前"觉得太麻烦"的事情：更完整的错误处理、更多的单元测试、更完善的日志。
这些都是好事，但代码量增加意味着认知负担增加，Code Review 的成本也在增加。
这是一个我还在观察和思考的变化，还没有清晰的结论。
总结：什么是 AI 对软件工程最核心的改变
两年下来，我的答案是：AI 改变了软件工程中的执行效率，没有改变软件工程中的判断质量。
编码、搜索、文档、测试用例生成——这些"执行"层面的事情，AI 已经有明显帮助，而且还在提升。
架构设计、系统演化、团队协作、业务理解——这些"判断"层面的事情，AI 的帮助是辅助性的，核心判断仍然依赖有经验的工程师。
这不是在贬低 AI 的价值。执行效率提升本身就价值巨大。两年前需要五个工程师做的工作，现在三个工程师能做，这就是真实的生产力提升。
但如果你以为 AI 会让软件工程变容易——让不需要理解设计原则就能做好软件——这个期望会让你失望。
门槛变低了，上限没变。理解这件事，比什么都重要。