# 中高级软件工程师

> 去改自己没写过的系统、决定什么能发出去、并为它怎么坏负责 —— 软件工作里主要是「对某一个具体代码库的判断」而不是打字的那一部分。

网页: https://flyvolo.ai/zh/careers/experienced-software-engineer
影响指数: 46/100 · 置信度 低置信度 · 评估于 2026-09-12
这不是失业概率。

## 适用范围

适用于在一个持续维护的生产代码库里做了几年的工程师 —— 做评审、做设计、决定什么能发的那批人。这一页按资历切;前端、后端与数据工程按「你负责哪一层」切,各有自己的页面 —— 所以一个资深前端会同时落在两页上,而它们问的是不同的问题。入门岗单独评估;专职测试另有一页。机器学习工程与 AI 研究现在各有自己的一页;稳定性工程是真实存在且确实不同的一份工作,本站还没有覆盖 —— 那是一个缺口,不是「它属于这一页」的判断。

## 任务

### 去改一个不是你写的系统

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 这一页上分量最重的证据讲的正是这项任务,而它指向的方向出人意料:在一次针对真实问题、且仓库由参与者自己维护的随机试验里,资深开发者使用 2025 年前后的 AI 工具后耗时多了 19%,而他们自认为快了 20%。一次改动需要的上下文,长在一个人对这个具体系统的心智模型里,而把它喂给工具的成本比省下来的多。
- 这还不能说明什么: 一次试验、16 名开发者、他们自己熟悉的成熟仓库 —— 作者明确说过它不描述大多数开发者、也不描述新项目。它没有说同样的工具一年之后表现如何,而一次测到的「变慢」不是工具的永久属性。
- 记录:
  - 2025-07-10 · 限制或撤回 · METR 对 16 名资深开源开发者、246 个真实问题的随机试验发现:使用 2025 年初的 AI 工具后耗时多 19%,而他们自认为快了 20% — https://flyvolo.ai/zh/changes/ev-20250710-junior-software-developer-2 (来源: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

### 审查机器写出来的东西

- 方向: 新出现的任务
- 依据: 有证据(附已核实记录)
- 为什么: 生成把瓶颈挪了地方,而不是消除了它:进来的代码更多了,读这些代码的活落到对这条分支负责的人身上。GitHub 主要靠自家智能体把 Copilot 运行时迁移到 Rust 时,那位开发者的 2,639 条消息里有 31.0% 用在审查、测试和持续集成上;美国一个部署了 AI 开发工具的机构记录写明,工具的产出必须经过审查和批准才能进入代码库;在 Stack Overflow 对 49,009 名开发者的调查中,经验最丰富的人对工具产出的不信任程度最高。
- 这还不能说明什么: 「有多大比例的代码是生成的」不说明审查花了多久、做得好不好,也不说明工程师总数变了没有。审查量上升本身也不等于好工作 —— 它恰恰是在赶时间时最容易做砸的那一部分。
- 记录:
  - 2026-09-16 · 技术能力 · GitHub 报告:一名开发者借助自家 Copilot 代理,把 Copilot 运行时迁移成 832,378 行 Rust;他发出的 2,639 条消息里,31.0% 用在审查、测试与 CI 上 — https://flyvolo.ai/zh/changes/ev-20260916-experienced-software-engineer-4 (来源: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-06-23 · 使用者采用 · Stack Overflow 对 49,009 名开发者的调查发现:84% 在用或打算用 AI 工具,而经验最多的那一群对它产出的东西最不信任 — https://flyvolo.ai/zh/changes/ev-20250623-experienced-software-engineer-2 (来源: https://survey.stackoverflow.co/2025/ai)
  - 2025-04-15 · 实际部署 · 美国移民及海关执法局报告 2025 年 4 月 15 日上线 AI 开发者工具,并写明其输出须经审阅批准才能进入代码库 — https://flyvolo.ai/zh/changes/ev-20250415-experienced-software-engineer-3 (来源: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

### 按「它会怎么坏」来设计

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 模型可以提出一种架构,并且论证得很流畅。它做不到的是承担这个取舍的后果 —— 而这里的取舍不是技术偏好,是「这家组织扛得住哪一种故障」的赌注,取决于关于这家组织的事实,而不是关于代码的事实。
- 这还不能说明什么: 这是对工作的判断,不是测量。架构评审很少公开;一个政府部门的工程标准是个例外,它写明设计责任仍在团队身上;但在别处,设计决定是否被交给机器,大多从公司外部看不到。
- 记录:
  - 2026-03-20 · 限制或撤回 · 英国一个政府部门的工程标准写明,AI 不能取代人对设计的责任,并要求所有 AI 辅助的产出在进入生产前由人批准 — https://flyvolo.ai/zh/changes/ev-20260320-experienced-software-engineer-5 (来源: https://engineering.homeoffice.gov.uk/standards/use-ai)

### 决定什么能发出去

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 机器现在能把一个改动推进得更远,才有人去看:在 GitHub 迁移 Copilot 运行时的过程中,一位开发者借助智能体在几个月里产出了 832,378 行 Rust 代码,而什么可以接受,一直由这位开发者决定。在把这个决定写成规则的地方,它属于人:Fedora 理事会规定,AI 不得作为一项贡献取舍的唯一或最终裁决者,接受与否的最终责任在授权这一操作的人身上,即便执行它的是自动化。
- 这还不能说明什么: 一家公司对自己项目的叙述,加上一个开源项目关于接受贡献的规则;两者都没有显示一般公司的发布决定是怎么作出的,也没有显示通过了所有检查的东西有多常出问题。
- 记录:
  - 2026-09-16 · 技术能力 · GitHub 报告:一名开发者借助自家 Copilot 代理,把 Copilot 运行时迁移成 832,378 行 Rust;他发出的 2,639 条消息里,31.0% 用在审查、测试与 CI 上 — https://flyvolo.ai/zh/changes/ev-20260916-experienced-software-engineer-4 (来源: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-10-24 · 限制或撤回 · Fedora 理事会禁止把 AI 当作贡献取舍的唯一或最终裁决者,接受与否的最终责任在人 — https://flyvolo.ai/zh/changes/ev-20251024-experienced-software-engineer-7 (来源: https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/)

### 让另一个人也能做这件事

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 这项任务正在变成承重墙,而原因在任务之外:如果底下进来的人变少,判断力的传递就不再是一个好习惯,而是供应线。有些工程社区已经把这一点写成了规则:LLVM 禁止用 AI 工具处理标为「good first issue」的问题,把它们留作新贡献者的学习机会,并说审阅新人的修改就是培养下一代贡献者的方式。
- 这还不能说明什么: 一个开源项目的规则为新人保留了练手的活;它没有涉及公司内部的带人,这里也没有任何东西测量初级进人是否在减少,或更多教的工作是否落到资深头上。
- 记录:
  - 2026-01-16 · 限制或撤回 · LLVM 禁止用 AI 工具处理标为「good first issue」的问题,把它们留作新贡献者的学习机会 — https://flyvolo.ai/zh/changes/ev-20260116-experienced-software-engineer-6 (来源: https://llvm.org/docs/AIToolPolicy.html)

### 为那些会写代码、会改代码的智能体负责

- 方向: 新出现的任务
- 依据: 有证据(附已核实记录)
- 为什么: 这项工作在 2022 年还不存在,默认也没有人被分派去做。只要允许生成的代码进入仓库,它就会出现:美国一个部署了 AI 开发工具的机构记录写明,工具的产出必须经过审查和批准才能进入代码库;在 GitHub 自己迁移 Copilot 运行时的过程中,是一位开发者指挥这些智能体、守住目标架构,并把大部分消息花在审查、测试和对设计的质疑上。
- 这还不能说明什么: 一个机构的清单条目,加上一家公司对自己项目的叙述;两者都没有显示这种负责有多普遍,这里也没有任何东西说明它已经是一个有人为之付薪的角色。
- 记录:
  - 2026-09-16 · 技术能力 · GitHub 报告:一名开发者借助自家 Copilot 代理,把 Copilot 运行时迁移成 832,378 行 Rust;他发出的 2,639 条消息里,31.0% 用在审查、测试与 CI 上 — https://flyvolo.ai/zh/changes/ev-20260916-experienced-software-engineer-4 (来源: https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/)
  - 2025-04-15 · 实际部署 · 美国移民及海关执法局报告 2025 年 4 月 15 日上线 AI 开发者工具,并写明其输出须经审阅批准才能进入代码库 — https://flyvolo.ai/zh/changes/ev-20250415-experienced-software-engineer-3 (来源: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

## 怎么引用

- 单位是任务,不是职位名:说哪些任务在变、哪些不变。
- 每项任务的依据与限制要一起带上;推断不是结论。
- 本页不给年份。不要从中推出一个。
- 更多: https://flyvolo.ai/llms.txt