从“Computer”到“AI Agent”：一张软件职位家族树梳理 104 个职位演变

有几年我的头衔是“DevOps 负责人”。在得到这个头衔之前，我曾以其他名目做过几乎相同的工作；此后，我又看着同样的工作被称为 SRE，然后它似乎又向平台工程演变。如果你在这个行业待过一段时间，就会看到头衔这样来来去去，也许还会好奇它们都是从哪儿来的。

于是，我（在 Claude 先生的帮助下）构建了这棵从 1940 年代至今的软件职位头衔家谱。

在这里：ianmiell.github.io/sw-job-title-family-tree

它是什么

共有 104 个头衔，从最顶端的“Computer”（指人，不是机器）到最底端的“AI Agent / Context Engineer”。

时间从上到下，以五年为一行。头衔按家族分列在七个彩色列中：

• 开发
• 分析、架构与领导
• 运维与基础设施
• 网络与安全
• 数据与 AI
• 质量与测试
• 支持与面向客户

实线箭头表示该头衔由父级头衔发展而来。虚线箭头表示影响，或常见的职业流动。里程碑式的头衔以粗体显示。

在网站上，你可以点击某个家族只查看该列（这里是 Data & AI），或点击某个头衔查看其历史、背景和关联（这里是 SRE）。

整个东西就是一个 Graphviz 文件和一个描述 JSON 文件。每个头衔在 .dot 文件中占一行，图片通过以下方式渲染：

$ dot -Tsvg job_title_family_tree.dot -o job_title_family_tree.svg

添加一个头衔只需三处小改动：在其家族列中添加一个节点，在其五年周期的行中添加一个条目，以及它的父级箭头。

关于日期，需要说明一下。它们大致是某个头衔变得常见的时间，而不是首次有记录的用法，而且它们是我的最佳估计，并非有来源的引用。有些是众所周知的（2003 年 Google 的 SRE，2009 年创造的“DevOps”，2008 年的“Data Scientist”）。很多则只是“约”加一个耸肩。

我注意到的六件事

把它画出来，让一些模式变得难以忽视。

1）编程最初是文书工作

1947 年，Goldstine 和 von Neumann 的《问题的规划与编码》将使用计算机的工作分为两部分：数学家规划问题，编码员将计划翻译成机器指令。编码被视为地位较低的文书工作，其中大部分由女性完成。

结果，编码最终成了困难且富有创造性的部分，而编码员并入了程序员。

再往前追溯，就更奇怪了。首批 ENIAC 程序员中有几位是从陆军的人类计算机中招募的，那些人的工作就是手工计算。所以，这份工作把名字给了机器，把人员给了编程。

2）头衔先分裂，再重新合并

网站管理员（webmaster）大约在 1993 年出现，通常是一个人写 HTML、运行 Web 服务器（常常是桌子底下的一台机器）、回复电子邮件，并让网站保持运行（有时靠踢它一脚，更常见的是踢完再插回电源）。

到 2000 年代中期，这个头衔几乎消失了，因为它显得老土得古老。代码交给了 Web 开发者，服务器交给了系统管理员，内容交给了编辑和设计师。

然后 Web 开发者在大约 2005 年分裂为前端和后端，两者又在大约 2008 年重新合并为“全栈”。

这就是我之前写过的集中化/分散化的跷跷板效应，在职位头衔中上演。

3）有些头衔不会持久

这位提示工程师在2023年凭借几个令人瞠目结舌的高薪职位招聘登上了头条。随着模型变得越来越好，这项技能被并入了其他工作，而在这棵树上，它几乎刚一出现就被AI工程师吸收了。

Scrum Master是同一个故事的慢速版本：需求在2010年代达到顶峰，此后许多组织又把它并回了工程管理或交付岗位。

这棵树上最新的头衔是“AI Agent / Context Engineer”（约2025年）。目前对它的描述是“它是否会保持为一个独立头衔，时间会给出答案”。我可不打算打赌。

4) 名称会被回收再利用

“系统工程师”在这棵树上是两个不同的工作。在1960年代的IBM，它是一个售前岗位，与客户合作设计安装方案并让系统运行起来。到了1990年代，很大程度上得益于微软的MCSE认证，它指的是更资深、更偏重设计的系统管理员。同样的头衔，不同的分支，毫无关系。

“配置管理”最初是1960年代美国国防领域用于跟踪硬件变更的一门学科，1970年代变成了软件版本控制，几十年后又回来成了Puppet和Chef这类工具的名称。

5) 新事物往往是旧事物

“前向部署工程师”（FDE）是2025年最热门的头衔之一，OpenAI、Anthropic以及大量AI初创公司都在招聘FDE，让AI在客户组织内部真正运转起来。

Palantir大约从2010年起就围绕他们建立了业务：软件工程师嵌入客户之中，常常驻场，构建一切必要的东西，让产品能解决该客户的问题。

这听起来很像1960年代IBM的系统工程师，他们在售前和售后与客户合作，设计安装方案并让系统运行起来。（这听起来也很像老式咨询，但这话是我说的。）

6) DevOps之争就在那里

Ben Treynor Sloss将SRE定义为“当你让一位软件工程师去设计一个运维团队时会发生什么”。DevOps本意是一种开发与运维协同工作的文化，但到2011年左右，“DevOps工程师”已经成了一个职位头衔，通常指做自动化的人。在这棵树上，SRE与DevOps之间的箭头是双向的。平台工程把两者都作为父节点，并在2022年前后被宣传为“DevOps的继任者”。

Dev/Ops之间的分歧从未得到解决。它只是不断获得新的名字。

何必费这个劲？

当我被问到DevOps工程师、SRE和平台工程师之间有什么区别时，诚实的答案总是一小段历史课。这是我目前能做到的最短版本。

这些日期都是最佳猜测，我肯定会漏掉一些头衔、弄错一些谱系，并画出会让人争论的箭头。如果你知道得更清楚，请告诉我，或者在仓库上提一个PR。

这又让我回到了程序员身上。

1947年，编码是文书性的部分，真正的工作在于规划。快进八十年，你会听到关于编码的几乎同样的说法，因为AI。上一次，程序员们最终被证明做的才是困难的部分。

这个箭头就留给你自己画了。