软件行业的职位名称看起来只是招聘启事上的几个字，实际上是一份技术史、组织史和劳动力市场的化石记录。2026 年 11 月，工程师 Ian Miell 用 Claude 加 Graphviz 做了一张 “软件职位名称族谱”，把 1940 年代到 2025 年的 104 个职位画进同一张图，按七大家族分列：开发、分析与架构及领导、运维与基础设施、网络与安全、数据与 AI、质量与测试、支撑与客户面向。图的顶端是 “Computer”—— 不是机器，是人，是那个年代拿笔和纸算数的计算员；图的底端是 2025 年前后出现的 “AI Agent / Context Engineer”。八十多年里，这张图反复演示同一件事：职位名称会分裂、会合并、会消亡、会被回收，而每一次变动背后，都是技术栈变了、交付方式变了，或者客户买的东西变了。
一、这张族谱长什么样
| 维度 | 具体设定 |
|---|---|
| 节点数量 | 104 个职位 |
| 时间跨度 | 1940 年代 —2025 年，按五年一行从上往下排 |
| 分列方式 | 七个家族：开发／分析・架构・领导／运维・基础设施／网络・安全／数据・AI／质量・测试／支撑・客户面向 |
| 连线规则 | 实线＝直接派生，虚线＝影响或平均职业迁移 |
| 数据形态 | JSON 描述文件＋Graphviz 渲染，每个节点可点开看历史与关联 |
| 制作者 | Ian Miell，前 “Head of DevOps”，同一份工作在 SRE、platform engineering 名下干过多年 |
这张图之所以值得看，是因为制作者本人就是 “职位名称通胀” 的受害者：他做过 Head of DevOps，后来同样的活儿被叫 SRE，再后来被叫 platform engineering。他想搞清楚 “这些名字到底从哪来的”，于是有了这张图。
二、六个规律，基本能解释所有职位名称的生死
- 编程一开始是 “文书工作”。1947 年 Goldstine 和 von Neumann 写《Planning and Coding of Problems》，把用机器解题拆成两半：数学家负责规划问题，coder 负责把方案翻译成机器指令。coding 被当成低阶文书活，很多由女性完成；ENIAC 的几位程序员就是从陆军 “人肉计算员” 队伍里招来的。后来 coding 变成了最难最有创造性的部分，coder 这个职位被 programmer 吞掉。
- 职位会分裂，然后再合并。webmaster 大约 1993 年出现，一个人写 HTML、管服务器、回邮件、保站点活着；到 2000 年代中期这个名字基本消失，代码归 web developer，服务器归 sysadmin，内容归编辑和设计。web developer 又约在 2005 年裂成前端和后端，2008 年前后又合并成 “全栈”。这是集中化与分布式的跷跷板，在职位名称上重复上演。
- 有些职位寿命很短。prompt engineer 在 2023 年上过头条，薪水高得离谱；模型变强后，这项能力被并进别的岗位，在族谱上几乎刚出现就被 AI engineer 吸收。scrum master 是慢速版本：2010 年代需求见顶，很多组织把它折回工程管理或交付岗位。
- 名字会被回收再利用。“Systems Engineer” 在图上对应两个完全不同的工作：1960 年代 IBM 的售前角色，陪客户设计安装、把系统跑起来；1990 年代受微软 MCSE 认证推动，变成更资深、偏设计的 sysadmin。同一个名字，两条不相干的枝。
- “新东西” 常常是 “老东西”。2025 年最热的 forward deployed engineer（FDE），本质很像 1960 年代 IBM 的 systems engineer：嵌在客户现场，卖前卖后都在，负责把系统真正跑起来。Palantir 从 2000 年代中期就把这套模式做成了生意。新的是名字，不是模型。
- DevOps 的争论从来没解决。Ben Treynor Sloss 给 SRE 的定义是 “当你让一个软件工程师去设计运维团队时会发生的事”；DevOps 本来是一种开发与运维协作的文化，到 2011 年前后 “DevOps Engineer” 变成了一个职位，通常指做自动化的那个人。图上 SRE 和 DevOps 是双向箭头，platform engineering 把两者当父母，2022 年前后被包装成 “DevOps 的继任者”。同一份活儿，换了三次名字。
三、一条时间轴，看清职位是怎么 “长” 出来的
| 年代 | 代表职位 | 驱动因素 |
|---|---|---|
| 1940s | Computer（人）、coder | 弹道计算、ENIAC，编程被视为文书 |
| 1950s—60s | programmer、systems engineer、MTS | 大型机、IBM 售前模式、贝尔实验室的扁平职称 |
| 1970s—80s | software engineer、configuration management | 软件工程学科化、国防项目变更管理 |
| 1990s | webmaster、sysadmin、network engineer | 互联网、局域网、MCSE 认证体系 |
| 2000s | web developer、front-end／back-end、QA、PM | Web 2.0、分工细化、产品经理崛起 |
| 2008—2015 | full-stack、DevOps、SRE、data scientist、ML engineer | 云、持续交付、大数据、移动端 |
| 2016—2022 | platform engineer、MLOps、cloud engineer | 平台化、模型上线、混合云 |
| 2023—2025 | prompt engineer、AI engineer、FDE、MTS、AI Agent／Context Engineer | 大模型、智能体、企业落地 |
四、三次 “分家 — 合并”，每次都跟着成本走
- Web 那条线：一个人（webmaster）→ 三个岗（开发／运维／内容）→ 前端＋后端 → 全栈。分是因为专业深度要求上来了，合是因为交付速度要求上来了。
- 运维那条线：sysadmin → DevOps（文化）→ DevOps Engineer（职位）→ SRE（可靠性）→ platform engineering（自助平台）。分是因为职责边界清晰了，合是因为开发者体验成了瓶颈。
- AI 那条线：data scientist → ML engineer → MLOps → AI engineer → Applied AI／Agent engineer。分是因为研究和工程分家，合是因为基础模型把 “训练” 这件事商品化了，价值转移到 “应用与评估”。
五、2026 年最热的三根新枝，都带着旧名字的影子
第一根：FDE（Forward Deployed Engineer）
| 指标 | 数据 |
|---|---|
| 岗位增速 | LinkedIn 统计 2023—2025 年增长 42 倍，同期 AI engineer 增长 13 倍 |
| 薪酬区间 | 总包 58.6 万 —145 万美元，股权与奖金占 52%—66%（WSJ 报道） |
| 人才存量 | 美国约 1.7 万名 FDE，其中约 2000 人属顶尖（Christian & Timbers 估算） |
| 组织化 | AWS 设 10 亿美元 FDE 团队；微软 7 月设 25 亿美元、6000 人子公司；OpenAI 5 月成立 DeployCo，140 亿美元估值，收购 Tomoro 与 Northslope |
| 需求方扩散 | Target、Barclays、Bausch and Lomb、American Express 都开过这类岗位 |
FDE 和普通工程师的差别不在技术，在责任边界：普通工程师按规格交付就算成功，FDE 要对 “客户有没有真的用起来、有没有产出结果” 负责；软件能跑但没人用，对 FDE 就是失败。这也是它贵的原因 —— 它同时吃工程能力、行业知识和客户现场沟通。
第二根：MTS（Member of Technical Staff）
| 指标 | 数据 |
|---|---|
| 使用比例 | 2025 年 12 月 LinkedIn：Anthropic 39%、OpenAI 31%、xAI 26% |
| 增速 | 一年内 OpenAI、Anthropic、xAI、微软 AI 合计上升约 50% |
| 历史源头 | 贝尔实验室，1920 年代起用，研究员与工程师同一职称，连研究副总裁也 “只是” MTS |
| 采用理由 | OpenAI 创始人不想把研究员和工程师分桶；Alan Kay 告诉他们 Xerox PARC 用过这个名字；xAI 的说法是 “只有工程师”“研究员是学术界的遗留词” |
| 反差用法 | Salesforce 把 MTS 当成职级阶梯的一档（Associate／Senior／Lead／Principal MTS） |
MTS 的本质是 “反职称”：它故意不告诉你这个人做什么、什么级别，只告诉你他属于技术团队。对前沿实验室来说，这能省掉研究员与工程师之间的头衔之争；对招聘市场来说，它把 “这个 offer 值多少钱” 变成了一个必须先问内部级别才能回答的问题。
第三根：AI Engineer / Applied AI Engineer
2026 年的招聘数据里，Applied AI Engineer 的岗位量已经在 AI 公司里成为 “默认工程职称”，和传统 ML engineer 分开：前者做 RAG、智能体、评估，后者做训练与建模。基础模型越商品化，价值越往 “怎么用对” 这一端移动。
六、AI 正在把 “职位” 融成 “角色”
Claude Code 负责人 Boris Cherny 给了一个更激进的判断：一年内 “软件工程师” 这个职称会开始消失，被 “builder” 取代；三年后写代码、用智能体的人会是今天的 100 倍，但这些人的名片上不叫工程师。他把自己团队看成五种角色，而不是五个岗位：
| 角色 | 干什么 | 典型场景 |
|---|---|---|
| 原型师 Prototyper | 大量冒点子，多数不上线 | 新方向探索 |
| 构建者 Builder | 把原型快速做成生产级产品与基础设施 | 0 到 1 |
| 清理者 Sweeper | 简化代码、清 UI、下线功能、抠性能 | 技术债治理 |
| 增长者 Grower | 接住已成型产品，推 PMF | 1 到 100 |
| 维护者 Maintainer | 守住成熟系统的安全、可靠、速度 | 规模化运营 |
他的关键补充是：这些角色和职位本身没关系 —— 设计师、工程师、PM、数据科学家都可能落在同一类里；一个人常常同时横跨两三种。这与族谱给出的历史结论是同一个方向：职位名称是组织为了方便管理而打的标签，真实的工作从来是流动的。
七、招聘方和求职方怎么读这张族谱
| 看到这个 title | 别急着下结论 | 该问的问题 |
|---|---|---|
| Software Engineer | 可能写代码，也可能做系统设计或 AI 协作 | 团队里代码由 AI 生成的比例是多少？你审不审 AI 产出？ |
| DevOps Engineer | 可能做自动化，也可能兼运维值班 | 你们有 SRE 吗？on-call 怎么排？ |
| Platform Engineer | 大概率做内部开发者平台 | 平台用户是谁？考核指标是开发者满意度还是部署频率？ |
| FDE | 责任到 “客户出结果” | 交付周期多长？成功怎么定义？出差比例？ |
| MTS | 级别信息被隐藏了 | 内部职级是哪一档？薪酬带宽多少？ |
| AI Engineer | 可能做应用，也可能做训练 | 评估体系谁建？模型选型权在谁手里？ |
八、给个人和组织的五条实操建议
- 按 “角色” 更新简历，不只按 “职位”。写清你解决过什么问题、交付过什么结果，比堆砌 title 更抗周期。
- 盯住族谱的 “接口处”。分裂点（前端／后端）、合并点（全栈）、回收点（systems engineer→FDE）都是机会窗口。
- 警惕短命职称。prompt engineer 用两年走完了从爆红到被吸收的全过程；判断一个 title 值时，看它承载的是 “能力” 还是 “工具”。
- 组织别用 title 解决组织问题。MTS 能消除研究员与工程师的等级摩擦，但也让外部招聘与内部晋升失去锚点；用它之前先想清楚职级体系怎么藏在下面。
- 把 FDE 当能力建设，不当人力外包。它的价值在于把客户现场知识回流到产品，如果只当驻场开发用，成本会吃掉全部收益。
九、结论
软件职位名称的族谱，本质是一部 “工作如何被切分又被打包” 的历史。1940 年代 coding 是文书活，1990 年代 webmaster 一个人管一个站，2000 年代拆成前端后端再合成全栈，2020 年代 prompt engineer 刚出现就被 AI engineer 吸收 —— 每一次分合，都是技术复杂度、交付速度和组织成本三方拉扯的结果。2026 年最新的三根枝 ——FDE、MTS、AI Engineer—— 恰好对应三种不同的答案：往前伸（对客户结果负责）、往上收（取消研究与工程的职称边界）、往里融（用角色替代岗位）。它们都在回答同一个问题：当 AI 把写代码这件事变得便宜，人的价值该挂在哪里。族谱没有给出标准答案，但它给出了一条规律：名字会过时，能力不会；职位会消失，活儿还在。
El Ecosistema StartupExponent
【常见问题】
问题 1：软件职位名称的族谱是怎么做出来的，包含多少个职位？
回答 1：这份软件职位名称族谱由工程师 Ian Miell 在 2026 年 11 月发布，用 Claude 辅助整理、Graphviz 渲染，共收录 1940 年代到 2025 年的 104 个职位，按开发、架构与领导、运维、网络与安全、数据与 AI、质量与测试、客户面向七大家族分列，实线表示派生关系，虚线表示影响或职业迁移。
问题 2：软件职位名称的演变里，最早的那个职位是什么？
回答 2：最早的是 “Computer”，指人不是机器，是 1940 年代用纸笔计算的计算员，ENIAC 的几位程序员就是从这类 “人肉计算器” 队伍里招来的。此后编程一度被当作文书工作，coder 这个职位后来被 programmer 吸收，这就是软件职位名称演变的第一段。
问题 3：为什么软件职位会先分裂再合并，比如前端、后端和全栈？
回答 3：分裂是因为专业深度要求上升，合并是因为交付速度要求上升。webmaster 在 1993 年一人管全站，2000 年代中期拆成开发、运维、内容三块，web developer 又在 2005 年前后裂成前端和后端，2008 年前后合并成全栈 —— 这正是软件职位名称族谱里反复出现的集中化与分布式跷跷板。
问题 4：2026 年最热的软件职位名称有哪些？
回答 4：三个：Forward Deployed Engineer（FDE）、Member of Technical Staff（MTS）和 AI Engineer／Applied AI Engineer。FDE 在 2023—2025 年岗位量增长 42 倍，MTS 在 Anthropic、OpenAI、xAI 的 LinkedIn 使用率分别达 39%、31%、26%，AI Engineer 则成为 AI 公司默认的应用工程职称。这三个软件职位名称代表了三种不同的组织答案。
问题 5：AI 会不会让 “软件工程师” 这个职位名称消失？
回答 5：会改写，不一定会消失。Claude Code 负责人 Boris Cherny 判断 “软件工程师” 职称会开始被 builder 取代，团队更像由原型师、构建者、清理者、增长者、维护者五种角色组成；但角色和职位无关，同一个人会在项目不同阶段切换。软件职位名称的演变历来如此，名字换了，活儿还在。
问题 6：普通开发者该怎样应对软件职位名称的快速演变？
回答 6：三条：按角色而非职位更新简历，写清解决过什么问题；盯住族谱的接口处，分裂点、合并点、名字回收点都是机会窗口；判断一个 title 值时看它承载的是能力还是工具。软件职位名称族谱证明，短命职称（如 prompt engineer）两年就会被吸收，能力才是长期资产。
【参考资料】
[2026-11-14]（104 títulos tech: el árbol que ordena DevOps、SRE y FDE）El Ecosistema Startup
[2026-11-03]（A Family Tree of Software Job Titles）zwischenzugs
[2026-10-31]（OpenAI Deployment Company (DeployCo): FDE Profile）Plank Research
[2026-10-21]（Job titles are out. Now we're all 'members of the technical staff'）The New York Times
[2026-10-09]（Member of Technical Staff Meaning: Why AI Labs Use One Title）Marian
[2026-10-01]（100 oficios nuevos de IA）McGrinsey
[2026-09-30]（AI companies are banking on this job title）RALI
[2026-09-04]（なぜ AI 企業は社内で「ソフトウェアエンジニア」と呼ばなくなったのか）@IT
[2026-08-26]（The Most In-Demand Software Engineering Roles）Fonzi AI
[2026-06-30]（半年不写代码，Claude Code 之父：3 年后写代码的人暴涨 100 倍）36 氪
【免责声明】
本文依据 Ian Miell 2026 年 11 月发布的软件职位名称族谱、纽约时报、华尔街日报相关报道转述、Plank Research、Fonzi AI、36 氪等公开资料整理，仅作行业观察与职业分析，不构成职业规划、薪酬谈判或招聘决策建议。文中薪酬区间、岗位增速、使用比例等数据来自不同统计口径（LinkedIn、WSJ、Christian & Timbers、Levels.fyi 等），彼此不可直接相加或横向比较，且随市场快速变化。FDE、MTS 等职称在不同公司含义不同，具体以招聘方内部职级与岗位说明为准。读者据此作出的求职、招聘或组织调整决策，风险自行承担。