软件工程师为何越来越像“万金油”
软件工程师既要跟上不断变化的语言、框架和工具，还常被要求兼顾前后端、运维与管理。文章追问：当岗位边界持续扩张，更细的分工与 AI 辅助能否让工程工作重新可持续。
精准输入
导语
我的笔记
✍️ 写下你的想法，自由记录即可。如果没有灵感，试着回答上方的费曼输出问题。
登录后可记笔记
登录后可保存笔记、高亮、划线和批注。
软件工程师既要跟上不断变化的语言、框架和工具，还常被要求兼顾前后端、运维与管理。文章追问：当岗位边界持续扩张，更细的分工与 AI 辅助能否让工程工作重新可持续。
精准输入
✍️ 写下你的想法，自由记录即可。如果没有灵感，试着回答上方的费曼输出问题。
登录后可保存笔记、高亮、划线和批注。
这是我经常会想的事，因为我忍不住想：大多数其他工作会不会也是这样？
做软件工程师很难。起步时，你得会几门编程语言和一些工具；但这远远不够。公司还希望你熟悉它们正在使用的特定框架，可能是 Rails、Django、Laravel，或别的什么。你还得懂 CSS。要真正学会它也许得花一辈子，而且你可能依然不知道布局为什么会坏掉；不过，学到勉强够用还是做得到的。
你几乎不可能完全不碰 JavaScript。也许你很幸运，只需在维护的旧应用里偶尔加一点 jQuery；但事情会变。
后来 Facebook 的人做出了 React。原来那家拥有数万名工程师的公司一直有两个专长：前端和后端。编程界的集体意识认定 React 成了构建软件的正确方式；同时，公司又决定负担不起更多工程师。于是全栈工程师诞生了，而那个人就是你。去学 React，并在你已经懂得的后端技术上搭建 REST API 吧。
这还不会停。你知道需要类型系统吧？加上 TypeScript。你真的打算像个外行一样在 React 里管理状态吗？加上 Redux。觉得自己聪明，躲过了前两样？那就享受一下弄清 webpack、esbuild 或 rollup 怎么配置的过程，再加上 Prettier 和 ESLint。
你会说：“好吧，但我可以继续按过去的方式做。以前做得很好，我不需要 React。”当然可以。你完全可以在一家节奏飞快、持续烧钱的创业公司里，偏离其他所有人的做法。只要告诉老板：你可以教那些只听说过 React 的新员工，体会服务端渲染的乐趣。
哦，而且原来我们才刚开始。
在恐龙还在地球上游荡的年代，有一种职业叫系统管理员。他们的全部工作，就是保证你的后端好好运行：处理基础设施变更、升级数据库和系统、让守护进程持续运行、负责重启，等等。后来 DevOps 出现了。某家缺钱的公司不知怎么决定：这些事现在都由工程师来做；大家也就同意了。于是你得学 Docker。你的应用只是一个静态链接的单一二进制文件，根本不需要 Docker？那就去学 Ansible，并祝你好运，慢慢弄清要给 SystemD 传哪些选项。
而你甚至还没走到一半。现在还得学 AWS。你不会像个外行一样用图形界面配置基础设施，所以最好学 Terraform、Pulumi 或类似工具。
你工作做得不错，于是升成经理。你又得学另一份工作。不过没关系，因为这已经是终局了，是幸福。以下只是你要做的一部分事：
你最好希望公司到这一步时员工数已经增长到原来的四倍；否则你会一边管理，一边继续做上面所有事情。
而且还总能更糟。几天前，一位招聘人员找我谈一家秘密公司的工程职位。他们要求应聘者同时具备 Rails、Hotwire，以及令人难以置信的原生移动端开发的高级能力。为什么不干脆再加上内核和编译器开发，好让清单更完整？
软件确实更复杂了；这些复杂性也各有原因。但专业分工去哪了？造一栋房子时，会有许多人参与：建筑师、土木工程师、水管工、电工、砌砖工、室内设计师、屋顶工、测量员、铺路工，等等。你不会期待一个人，甚至一家公司，就能完成所有这些工作。
也许未来只要写几个提示词就能做出整个应用，其实没有那么糟。
文章按技能要求不断叠加的顺序展开：先是语言、框架、CSS 与 JavaScript，再是 React 时代把前后端职责合到“全栈”岗位；随后把系统管理、基础设施和云配置也转交给工程师，最后连管理职责也并入其中。作者并不否认软件复杂性的理由，而是借建筑业的专业协作反问：复杂系统为何越来越期待单个工程师包办一切，并以提示词构建应用的可能性留下一个带讽刺意味的出口。
费曼输出