前 DevOps 负责人 Ian Miell 借助 Claude 梳理并开源了一份软件职位名称家谱（托管于 GitHub 的 ianmiell/sw-job-title-family-tree 仓库），用 104 个职位头衔画出了软件业近 80 年的分工演变。这张图谱纵向按 5 年为一行，从 1940 年代的人类计算员一路延伸到 2025 年前后的 AI Agent 与 Context Engineer；横向则划分为开发、分析与架构、运维与基础设施、网络与安全、数据与 AI、质量与测试、支持与面向客户 7 大职能家族。整个交互项目底层极为精简，仅靠一个 Graphviz 的 .dot 文件和一个 descriptions.json 描述文件驱动。
科技圈每隔几年就会掀起一轮头衔通胀，但底层工程问题往往换汤不换药。把这 104 个头衔放在同一张时间轴上审视，能帮一线工程师和技术管理者看清两件事：哪些高薪新岗位只是随时会被技术升级抹平的过渡补丁，哪些挂着前沿名号的团队其实在重复半个世纪前的苦力活。
从文书女工到天价提示词：技术抽象如何吞噬过渡职位
图谱最顶端的起点不是机器，而是人。1945 至 1946 年间，最初的 ENIAC 程序员是从美国陆军负责手工计算弹道的人类计算员（Computer）中招募的 6 名女性：Kathleen McNulty、Betty Jean Jennings、Betty Snyder、Marlyn Wescoff、Frances Bilas 和 Ruth Lichterman。这群女性不仅把计算员的职位名称赋予了机器，还亲手摸索出早期编程与调试体系。
然而在 1947 年 4 月 1 日，Herman H. Goldstine 与 John von Neumann 发表了《Planning and Coding of Problems for an Electronic Computing Instrument》第 2 部分第 1 卷（后续卷分别于 1948 年 4 月 15 日和 8 月 16 日发表），将计算机工作一分为二。数学家负责高高在上的规划，而把逻辑翻译成机器指令的编码（Coding）则被定性为低地位的文书工作。历史随后开了一个巨大的玩笑：被轻视的编码最终演变为软件业最核心、最具创造力的硬骨头。直到 1968 年 10 月 7 日至 11 日的北约（NATO）Garmisch 会议上，软件工程（Software engineering）才被正式确立为职业愿景，尽管会议联合编辑 Brian Randell 指出 J. P. Eckert 早在 1965 年就已使用过这一词汇。
在此后的半个多世纪里，软件职位始终在专业化拆分与全栈化合并之间像钟摆一样摇摆。1993 年前后出现的网站管理员（Webmaster）往往是一个人包揽写 HTML、踢两脚桌底下的服务器主机和回邮件；到 2000 年代中期，这个显得老派的头衔消亡，拆解为 Web 开发、系统管理员与编辑设计师；约 2005 年 Web 开发进一步拆成前端与后端，到了 2008 年前后又重新合并为全栈（full-stack）。同年，Facebook 的 Jeff Hammerbacher（在 2008 年 2 月 29 日至 3 月初的邮件中先后提议 Data Applications Scientist 和 Data Scientist）与 LinkedIn 的 DJ Patil 共同推动了数据科学家这一融合分析、研究与工程的新头衔普及。
相比之下，那些为了弥补某一代技术临时缺陷而诞生的岗位，生命周期往往极短。2023 年曾引发高薪招聘潮的提示词工程师（Prompt Engineer），随着底层大模型理解能力升级，在图谱上几乎一出现就被吸收进了普通 AI 工程师的日常技能中，走上了当年敏捷教练（Scrum Master）在 2010 年代达到需求峰值后被并回工程管理岗位的老路。对于图谱底部最新浮现的 2025 年新头衔 AI Agent / Context Engineer，连作者本人都不敢打赌它能否作为一个独立职位存活下来。
凡靠修补上一代技术缺陷吃饭的头衔，终将被下一代底层进化抹平。
- 提醒.一线开发者在规划职业路径时，切勿将核心竞争力绑定在提示词调优或临时上下文拼装这类过渡性技巧上，底层系统设计与领域建模才是抗周期的硬通货。
DevOps 到平台工程的改名游戏：50% 琐事红线戳破假转型
Ian Miell 制作这张图谱的直接诱因，是他发现自己干着差不多的活，头衔却从 DevOps 主管一路变成了 SRE（站点可靠性工程师）和平台工程师（Platform Engineer）。在图谱中，2003 年诞生于 Google 的 SRE 与 2009 年被造出的 DevOps 之间画着双向箭头，而 2022 年前后被包装为 DevOps 继任者的平台工程，则把前两者同时列为父节点。
但把这三者单纯看作文字游戏，容易掩盖企业组织架构演进的真实硬标准。根据 Google、DORA 与 CNCF 的工程规范，三者有着明确的职能边界。Google 将 SRE 官方定义为 class SRE implements interface DevOps，并划定了一条硬指标：SRE 处理纯运维琐事（toil）的时间占比必须控制在 50% 以下，确保工程师有足够精力用代码消除重复故障；而平台工程的核心是将内部基础设施做成自助式产品，降低业务开发者的认知负载。
现实中，绝大多数公司只是跟风换了部门门牌。从 2011 年左右开始，许多企业把写自动化脚本的人直接改叫 DevOps 工程师；如今又把同一批靠提工单、拼体力救火的系统管理员改名为平台工程师。开发与运维的裂痕从未真正弥合，只是每隔五年换一套更贵的招聘话术。
OpenAI 争抢的 FDE，藏着大模型倒退回 IBM 时代的真相
这张家谱最刺眼的一条跨时代连线，落在了 2025 年大红大紫的前线部署工程师（FDE，Forward Deployed Engineer）上。如今 OpenAI、Anthropic 以及大批 AI 初创公司都在重金招募 FDE，派他们驻扎到客户企业内部，帮客户把大模型真正跑起来。
如果顺着图谱往上追溯，会发现老牌大数据公司 Palantir 早在 2010 年左右就围绕 FDE 建立起了核心业务模式：让软件工程师直接进驻客户现场，定制开发一切能让产品落地的代码。再往上翻半个世纪，这与 1960 年代 IBM 的系统工程师（Systems Engineer）如出一辙——当年的 IBM 系统工程师同样是售前售后驻场角色，帮客户设计安装方案并把庞大笨重的系统跑通（到了 1990 年代，受微软 MCSE 认证推动，系统工程师才在另一条毫不相干的分支上变成了高级系统管理员的代称；类似被回收再利用的还有配置管理，它从 1960 年代美国国防部追踪硬件变更的规范，变成 1970 年代的软件版本控制，几十年后又成了 Puppet 和 Chef 等自动化工具的统称）。
OpenAI 与 Anthropic 纷纷捡起 60 年前的驻场模式，戳破了当前生成式 AI 在企业端落地的叙事泡沫。如果大模型真的像云计算早期的标准化 SaaS 一样开箱即用，头部模型厂商根本不需要养庞大的驻场工程团队。FDE 头衔的翻红说明，当前企业级 AI 交付高度依赖脏活累活的现场定制与数据清洗。
- 结论.企业 CIO 和软件买方在采购大模型服务时必须算清一笔账，看自己支付的高昂费用究竟买到了可复用的标准智能产品，还是在为披着 AI 外衣的传统驻场外包咨询买单。