2026年的软件工程：来自服务器机房的视角
Source: Dev.to
I read Ben Congdon’s article “Software Engineering in 2026” and found myself nodding along to many of his points. But I also noticed something: the conversation around AI and software engineering often feels like it’s happening in a different world from mine.
我阅读了 Ben Congdon 的文章 “Software Engineering in 2026”，发现自己对他的许多观点点头赞同。但我也注意到一点：关于 AI 与软件工程的讨论常常像是发生在与我截然不同的世界里。
I’m a Full‑Stack Engineer managing distributed systems across 15+ production sites in Malaysia. My daily work isn’t only about building shiny new features; it’s also about keeping things running, handling database migrations at 2 AM, and making sure our 99 %+ uptime stays that way. I’m basically wearing multiple hats: writing specs, developing products, code‑reviewing, delivering, and ensuring everything works without issue.
我是一名全栈工程师，负责管理遍布 马来西亚 15+ 生产站点 的分布式系统。我的日常工作不仅仅是构建光鲜的新功能；还包括确保系统持续运行、在凌晨 2 点处理数据库迁移，并保证我们的 99%+ 的正常运行时间 维持不变。我基本上身兼数职：编写需求文档、开发产品、代码审查、交付，以及确保一切顺利运行。
Ben’s article got me thinking: What does the AI revolution in software engineering look
Ben 的文章让我思考：AI 革命在软件工程中会是什么样子
我同意的地方：AI 已改变游戏规则
先说明一下。AI 工具确实改变了我的工作方式。正如 Ben 所说，“高质量代码的边际成本已经下降”， 这是真的。
我日常工作中最大的影响
- 编写模板代码 – 设置一个带有适当验证、错误处理和文档的新 FastAPI 端点过去大约需要 30 分钟；现在大约 5 分钟。AI 负责重复性工作，我则专注于业务逻辑。
- 模式代码审查 – 在审查 AI 生成的代码时，我发现 AI 在遵循既定模式方面出奇地好。当你提供明确的示例时，它很少会想出奇怪的解决方案。
- 文档编写 – 编写 docstring、API 文档和 README 文件过去感觉像是一项苦差事。现在几乎是自动化的。我只负责审阅和编辑，繁重的工作已经完成。
所以说，生产力提升是真实的。但我的经历开始与主流叙事产生分歧的地方在于：
没有人谈论的部分：操作系统
Ben 做了一个重要的观察，我希望更多人关注它：
“从我看到的情况来看，‘操作’系统目前受到 LLM 的影响最小。”
这正好符合我的经验，我认为这是在 AI 讨论中被忽视的最重要的软件工程部分。
当你管理 15+ 生产站点 时，你会很快明白写代码只是开始。真正的挑战在于后续工作：
- 部署
- 监控
- 大规模调试生产问题
- 处理只有在高峰时段三个特定条件同时满足时才会出现的边缘案例
AI 可以帮助我编写数据库迁移脚本。但它能告诉我应该在午餐时间还是午夜后运行迁移吗？它能预测迁移对不同数据分布站点的查询性能的影响吗？如果出现问题，它能处理回滚吗？
还不能。可能还要等一段时间。
生产经验教会你的东西
有一种知识只能通过让系统保持运行来获得。让我分享一些例子。
数据库决策会随时间累积
去年，我对如何组织某个表做了一个选择。当时看起来很小。几个月后，随着产品规模的扩大，这个决定影响了查询性能。AI 可以建议模式设计，但它不了解你的具体数据访问模式、增长预测或生产工作负载的奇怪之处。
网络现实与理论不同
我在沙捞越工作，那里的网络状况可以说是……有趣。我们的系统需要应对不稳定的连接、高延迟和偶尔的中断。这些都不在任何训练数据中。你只能在凌晨 3 点调试失败的请求并构建能够优雅降级的系统时学到。
正常运行需要人为判断
当生产环境出现故障时，首要问题不是 “怎么修复？” 而是 “这有多严重？” 你需要决定：
- 我们是否立即回滚？
- 能否快速打补丁？
- 是否需要叫醒其他团队成员？
这些决定需要了解业务影响，而不仅仅是技术问题。
为什么后端工作感觉不同
Ben 提到 “LLM 似乎特别擅长理解前端。” 我也注意到了这一点，并对其原因有自己的猜想。
- 前端工作有即时、可见的反馈。 你修改代码，就能看到结果。这让在 AI 辅助下迭代更容易；你可以快速验证 AI 的建议是否有效。
- 后端工作则不同。 你的决定的后果往往不会立刻显现。一个设计不佳的 API 可能今天运行良好，但六个月后会导致扩展性问题。数据库索引的选择可能在数据量不大时看似无关，直到你拥有 1000 万行数据才会暴露问题。缓存策略在开发环境可能正常，但在生产负载下会失效。
这种延迟的反馈循环使得 AI 辅助变得更具挑战性。当你意识到 AI 的建议并不理想时，往往已经在其基础上构建了大量代码。
更重要的技能
那么，2026 年后端工程师应该关注哪些方面？结合我的经验，我正在投入的方向如下：
- 系统设计与架构 – Ben 提到 “清晰的人为引导抽象”，我认为这正是关键。能够设计出可维护、可扩展且结构清晰的系统，在代码变得廉价的时代显得尤为重要。任何人都能生成代码，但并不是每个人都能设计出长期可靠的系统。
- 运营卓越 – 了解监控、可观测性、事故响应以及生产环境下的调试。这些技能难以自动化，因为它们需要对具体系统和业务需求的深度理解。
- 权衡取舍的理解 – 每一个技术决策都涉及权衡：一致性 vs. 可用性、性能 vs. 可维护性、速度 vs. 可靠性。AI 可以列出选项，但判断哪种权衡最适合你的情境，需要经验和判断力。
- CI/CD 与部署实践 – 精通流水线、自动化测试、金丝雀发布以及回滚策略。
结论
AI 是提升代码编写、生成模板代码和撰写文档的强大生产力倍增器。然而，软件工程的运营层面——部署、监控、事故响应以及长期系统设计——仍然是以人为中心的领域。对于那些在数十个生产站点上保持系统稳定运行的工程师来说，提升系统设计、运营以及权衡分析的能力，将成为 2026 年及以后真正的差异化竞争点。
Ben 也强调了这一点，我完全赞同。 当 AI 生成的代码越来越多时，你对代码进行测试、验证和安全部署的能力就变得至关重要。现在对稳固的 CI/CD 基础设施进行投入，回报会更大。
“构建 vs. 运营” 差距
Ben 询问不断下降的代码成本是否会改变“自行构建还是购买”的计算。他指出，运营成本并没有像开发成本那样下降。
这就产生了一个有趣的局面。构建某个东西比以往任何时候都更容易，但要在生产环境中可靠地运行它并没有变得更容易。这个差距只会越来越大。
我预计这意味着运营专长会变得更有价值，而不是更不值钱。公司可以更快地启动新系统，但仍然需要能够让这些系统持续运行的人。如果你是后端工程师，这可是个好消息。你在生产可靠性方面积累的技能并不会被自动化取代。
展望未来
我并不是想显得反对 AI 工具——我每天都在使用它们。它们让我更高效。但我认为我们需要更平衡的讨论，哪些地方 AI 能帮助，哪些地方仍然需要人类专业知识。
软件工程一直不仅仅是写代码。它涉及理解问题、权衡取舍以及构建在真实世界中可运行的系统。AI 正在改变我们写代码的方式，但它并未改变这些基本原则。
对于从事后端和基础设施工作的我们来说，我从 2025 年走向 2026 年得到的讯息是：
- 继续提升你的运维技能。
- 继续学习系统设计。
- 继续积累生产环境经验。
这些技能正变得越来越有价值，而不是变得不重要。
如果你在管理跨多个站点的分布式系统，同时 AI 处理了一些样板代码，那么无论接下来会发生什么，你都处于相当有利的位置。
你在后端或基础设施工作中使用 AI 工具的经验是什么？我很想听听那些从事运维密集型角色的朋友的看法。请在下方留言。