2026 年的软件工程：AI 时代下工程师的转型

原文来源：Software Engineering in 2026 — 2025 年 AI 编程工具的进步将如何重塑 2026 年软件工程的实践

假期里，Ben Congdon 一直在思考 2025 年 AI 编程工具的进步对 2026 年软件设计、构建和运维方式意味着什么。他的分析冷静务实，没有夸夸其谈，也没有贩卖焦虑——只是诚实地思考每一个环节正在发生的改变。

LLM 到底改变了什么？

LLM 工具最核心的影响是：高质量代码的边际成本（时间成本和金钱成本）大幅下降了。但这只是软件工程的一部分。写代码从来不是工程师唯一做的事，所以瓶颈正在转移。

如果我们给软件工程师的工作下一个粗略的定义：构建、演进和运维能产生实际业务价值的分布式软件系统。其中"构建"这个环节受 LLM 影响最大，"演进"次之，"运维"到目前为止受影响最小。

不同团队受益程度也不同。产品团队（尤其是前端）受益最大，因为 LLM 对前端代码的理解出奇地好，而且产品侧的新项目更多。基础设施团队受益相对有限。

市场会期望软件工程师从 LLM 中提取生产力增益。整个行业正在变得更机械化，但整体产出确实在提高。转型正在加速，但大部分影响还没有完全落地。

2026 年加速发生的变革

基础设施抽象层——回报加速

好的基础设施抽象层的回报正在加速积累。你能快速发布二进制文件吗？能同样快速地回滚吗？有没有开箱即用的方式来快速启动新的计算资源？

所有核心基础设施组件依然重要：指标监控、日志、事件响应、功能开关、发布、自动伸缩、编排、工作流引擎、配置、缓存、网络等等。公司把这些基础设施做成对人和 LLM 都易用的形式，会获得巨大回报。理想状态是：基础设施尽可能自助服务，提供友好的 CLI 或 MCP 接口，不需要基础设施工程师介入来解除阻塞。

CI 基础设施——重要性空前

随着 AI Agent 编写越来越多代码，CI 基础设施的质量、保真度和速度变得比以往更重要。可能我们需要重新思考单元测试的意义，在底层组件上投入更多资源做属性测试和形式化验证。

有意思的观察：人类通常不喜欢写测试——它们不好玩，是机械性的，感觉像是对"真正写代码"的一种税。但 LLM 完全没有这种心理障碍。所以，我们再也没有借口不做到接近穷尽的测试场景覆盖了。

人工引导的抽象层——最稀缺的能力

明晰的、由人引导的抽象层变得前所未有的重要。LLM 如果没有强有力的指导，会通过贪心策略填塞解决方案来让 CI 检查通过，长期来看代码会越变越像意大利面。良好的直觉、成熟的"系统品味"——这些东西依然需要人来提供。

模块边界、库接口、基础设施和产品层之间的契约，正在成为维护长期代码质量的高杠杆支点。缺乏这些清晰边界的系统，技术债积累的速度会更快。

LLM 生成的代码质量没有保障。虽然过去一年质量显著提升，但几个构造不当的 PR 就足以让你溺死在自己的技术债里。

人工代码审查——新瓶颈

人工代码审查正成为越来越重要的瓶颈。需要有新的"审查品味"。

风格类问题应该尽可能推到自动化 lint 工具里，在合并前（最好在 LLM Agent 提交前）就解决了。人工审查应该聚焦在那些不容易被自动生成替代的决策上：接口变更、数据持久化相关的敏感代码、性能关键代码。

这给初级工程师带来了一个悖论：他们需要更早地培养"审查品味"，但实际写的代码更少了，而写代码正是构建直觉的主要方式。

整个行业需要共同面对这些问题：哪些不够完美但可以接受的代码风格可以入库？哪些绝对不能入库？新的代码坏味道是什么？代码审查本身有多少能被自动化？

项目时间估算——方差越来越大

可以预见，项目估算的方差会显著增大。一个任务能被 LLM 化的程度，越来越影响它的实际耗时。这给高价值项目带来了压力——它们会被"推"向更有利于 LLM 处理的方向。

但矛盾在于：最需要降低风险的高价值项目，往往是最不适合 LLM 辅助的——因为它们需要深度上下文，涉及底层系统，或风险范围太大。

有些以前很耗时的工作变容易了（比如代码迁移、跨语言翻译），有些则稳定不变（比如网络相关）。

"自建 vs 购买"的决策天平

代码成本下降会影响 SaaS 的 "build vs buy" 决策吗？作者的猜测是：边际上"会"，整体上"不会"。

对于商品化的 SaaS（大部分是 CRUD 上包一层 UI），中大型科技公司会倾向于自建。但对于基础设施即服务、合规即服务这类产品，决策不会变化太多——因为运维成本没有像开发成本那样下降。

仍然开放的问题

文章最后提出了一些没有人能回答的问题：

我们还需要对每行代码进行人工审查吗？这个审查要求有多承重？哪些系统需要仔细把关，哪些真正可以"vibe code"？
对于软件工程师来说，最好的"对抗杂音"方式是什么？
模型变快 100 倍、1000 倍、变便宜 100 倍后会发生什么？一个有意思的点：届时在每条服务日志上运行 LLM 都会变得足够便宜。现在听起来毫无意义，但保不齐事故调试时真能用上。已经有人在展示用于事故调试的自动化 LLM 辅助工具了。

写在最后

这篇文章的价值不在于给出答案——实际上它也没给出什么确定的答案。它的价值在于提出了正确的问题。

2026 年的软件工程师不会因为 AI 而失业，但工作方式确实在剧烈变化。那些能理清模块边界、维护良好的抽象层、具备"系统品味"的工程师会越来越稀缺。而那些只会写 CRUD 代码、没有深层判断力的人，日子确实会越来越难过。

这不是一篇贩卖焦虑的文章。它只是在诚实地描述：水正在变，你需要学会在新环境中游泳。