AI Agent 正在杀死软件工程
AI Agent 正在杀死软件工程
作为一个程序员，你有多久没有亲手写过代码了？
我是一名有五年工作经验的后端开发工程师。
但最近，我突然意识到一件事情：我已经很久没有像过去那样，打开 IDE，从一个空文件开始，一行一行地完成整个功能了。
现在，需求来了，我会先把需求、现有系统、技术约束和上线要求交给大模型，让 AI 给出第一版设计；人工 Review 之后，再交给另一个不同的模型进行交叉 Review。数据库和接口协议确定以后，Codex、Claude Code、Cursor 这样的 AI Agent 开始阅读仓库、修改代码、运行命令、自主测试。
测试阶段也类似。AI 先设计测试方案，我检查测试场景是否合理，然后让 Agent 编写单元测试、集成测试，运行测试并修复失败的问题。到了端到端测试阶段，甚至可以让 AI 直接操作浏览器，像真实用户一样点击页面。
我的工作逐渐变成了：
定义问题、提供上下文、确定约束、审核设计、编排 Agent、设计验证体系、检查最终结果，然后为整个系统负责。
一开始，我只是把这种变化理解为「AI 提高了开发效率」。
后来我发现，不是。
真正发生的事情可能更加深刻：
被 AI Agent 杀死的不是工程能力，而是以人工编码为中心的软件生产方式。
软件工程并没有消失，但软件开发的范式正在发生根本性的变化。
一、过去的软件，是怎样被生产出来的？
传统软件开发是一套高度依赖专业分工和人工协作的生产体系。
一个功能从客户提出想法，到真正出现在生产环境中，往往需要经过需求调研、需求讨论、系统设计、设计评审、开发排期、编码、自测、前后端联调、测试、产品验收，最后才进入部署上线。
以一个典型需求为例。
产品经理首先需要走访客户，理解用户究竟遇到了什么问题。很多时候，客户说出来的需求并不是真实需求，产品经理需要继续追问：为什么要这个功能？现在是怎么解决的？真正的痛点在哪里？最终形成一份需求文档。
随后，产品经理与研发团队讨论需求。研发人员需要根据现有系统、技术条件和人员情况判断：这个需求能不能实现？大概采用什么方案？哪些要求不合理？哪些应该优先完成？哪些可以放到后面的迭代？
需求确定以后，研发开始设计。
大的方面包括系统架构、通信协议、编程语言、开发框架、数据库、缓存、消息中间件，以及不同系统之间的业务流程和交互方式；深入到具体实现，则需要确定数据库结构、API 协议、数据模型、事务边界、异常处理、并发控制、权限和性能要求。
设计不是一个人写完文档就结束了。复杂系统通常需要多名研发人员，甚至架构师、技术负责人和 CTO 参与评审，从性能、稳定性、可用性、安全性和扩展性等角度寻找问题。设计方案可能反复修改几轮，直到大家形成共识。
然后才是开发排期。例如：
前端开发：5 天
后端开发：10 天
前后端联调：2 天
测试：2 天
部署上线：1 天
由于前后端可以按照提前确定的接口协议并行开发，一个完整项目可能最终需要 15 天左右。排期确定后，还要同步给所有参与人员，让产品、研发、测试和运维共同确认。
真正进入开发阶段以后，前后端按照设计方案分别编码、自测，然后联调。联调完成以后，测试人员介入，对系统功能、异常场景、性能和稳定性进行验收。测试发现问题，开发修复；修复以后重新测试，又发现新的问题，再继续修改。
经过多轮：
测试 → 发现问题 → 修复 → 重新测试
测试人员认为系统符合要求以后，再由产品经理进行体验。产品可能继续发现需求和设计阶段没有考虑到的问题，例如按钮大小、页面配色、提示文案或者业务流程体验。
最后，所有参与方确认没有严重问题，运维人员开始部署。根据系统的重要程度，可能采用滚动更新、蓝绿部署或者灰度发布，先让少量用户获得新版本，再根据运行指标逐步扩大范围。如果线上出现严重 Bug，则需要紧急修复，甚至直接回滚到上一个版本。
这就是过去几十年逐渐形成的软件工程流水线。
图 1：传统软件开发流水线
flowchart LR
A[需求调研] --> B[需求讨论]
B --> C[系统设计]
C --> D[设计评审]
D --> E[开发排期]
E --> F1[前端开发]
E --> F2[后端开发]
F1 --> G[前后端联调]
F2 --> G
G --> H[测试验收]
H --> I{是否存在问题}
I -- 是 --> J[开发修复]
J --> H
I -- 否 --> K[产品体验]
K --> L[部署上线]
L --> M[灰度 / 监控 / 回滚]
M --> N[用户]
传统软件开发需要多人、多个角色，甚至不同部门共同参与。产品经理负责理解用户，架构师和研发人员负责设计，前端、后端和算法工程师负责实现，测试人员负责检查质量，运维人员负责部署和稳定运行。
每个人都是软件生产流水线中的一环。
大家各司其职，通过大量沟通、文档、会议、Review 和流程控制，最终把一个模糊的用户需求变成真正运行的软件。
二、过去的软件公司，其实很像一家房地产开发商
软件开发和房地产开发非常相似。
一家房地产公司决定开发一个项目，首先要回答的也是同样的问题：
究竟要建什么？
住宅、写字楼、商场还是酒店？
客户是谁？
他们需要多大的面积、多高的层高？
预算是多少？
愿意支付多少钱？
需求确定以后，管理层和建筑工程师开始讨论：怎样满足客户需求？怎样符合行业规范？如何保证安全？使用什么结构？怎样降低建设成本？
然后建筑工程师开始设计。
大的方面包括整个楼盘布局、建筑结构、承重方式、电梯、消防通道和地下停车场；深入到细节以后，还需要确定钢筋、混凝土、水电管线、门窗材料和装修标准。
这些设计最终成为建筑图纸和施工规范。
随后，施工队进场。
钢筋工扎钢筋，泥瓦工砌墙，水电工铺设管线，油漆工负责粉刷。不同工种负责不同任务，一根钢筋一根钢筋地铺，一块砖一块砖地砌，一层楼一层楼地建起来。
这是整个项目中最消耗人力和时间的阶段。
但施工完成并不代表项目结束。还需要验收人员检查建筑是否按照图纸施工，有没有偷工减料，材料质量是否符合标准，结构是否安全，水电、消防是否存在问题。
发现问题，施工队返工。
最终验收合格以后，房子才能真正交付给客户。
图 2：房地产开发 vs 软件开发
flowchart TB
subgraph A[房地产开发]
A1[客户需求] --> A2[建筑设计]
A2 --> A3[设计评审]
A3 --> A4[施工队施工]
A4 --> A5[工程验收]
A5 --> A6[房屋交付]
end
subgraph B[软件开发]
B1[用户需求] --> B2[系统设计]
B2 --> B3[设计评审]
B3 --> B4[程序员编码]
B4 --> B5[软件测试]
B5 --> B6[软件发布]
end
A1 -. 对应 .-> B1
A2 -. 对应 .-> B2
A3 -. 对应 .-> B3
A4 -. 对应 .-> B4
A5 -. 对应 .-> B5
A6 -. 对应 .-> B6
如果进一步对应不同岗位：
| 房地产开发 | 软件开发 |
|---|---|
| 客户需求 | 用户需求 |
| 建筑图纸 | 系统设计文档 |
| 建筑工程师 | 架构师、高级研发工程师 |
| 不同施工工种 | 前端、后端、客户端、算法工程师 |
| 施工队 | 软件开发团队 |
| 建筑验收 | 软件测试 |
| 物业和设施管理 | 运维、SRE |
| 房屋交付 | 软件部署上线 |
当然，这个类比并不完全准确。
因为一个真正的软件工程师从来都不只是「建筑工人」。尤其是有一定经验以后，我们也需要设计数据库、定义接口、选择技术组件、解决性能问题和排查生产故障。
所以更准确地说：
过去的软件工程师，是一群既需要画图纸，又必须亲自进入工地砌砖的工程师。
上午设计数据库，下午写 CRUD，晚上排查线上 Bug。
既是设计师，也是施工人员，有时候凌晨还要兼职维修工。
然后，AI Agent 出现了。
三、突然之间，一支不知疲倦的施工队出现了
最初的 AI 编程工具，更像一个高级的代码补全器。
我输入一个函数名，它帮我补充后面的实现；遇到报错，我把错误信息复制给 ChatGPT，它告诉我可能是什么原因；有一段复杂 SQL，我让 AI 帮我分析。
这时候，AI 只是一个辅助工具。
后来进入 Vibe Coding 阶段。
我们开始直接告诉 AI：
帮我实现一个用户管理系统，需要注册、登录和权限控制。
AI 开始一次生成大量代码。对于个人工具、原型、小型项目，这种开发方式非常高效，人甚至不需要理解所有实现细节，只需要不断告诉 AI：「这里不对，改一下」「再增加一个功能」「这个页面不好看」。
但 AI Agent 又向前走了一步。
今天的 Codex、Claude Code、Cursor 等工具已经不只是等待你复制一段代码过来。它们可以阅读完整代码仓库，搜索相关文件，理解已有架构，修改多个文件，执行 Shell 命令，启动程序，运行测试，发现错误以后继续修改，再重新测试。
你给它的已经不再是：
帮我写一个函数。
而可能是：
阅读整个项目，实现这个需求，运行所有测试，如果失败则分析原因并修复，直到测试通过。
Anthropic 在 2025 年对软件开发相关交互的分析中发现，Claude Code 中有 79% 的对话涉及某种形式的自动化，明显高于普通 Claude.ai 对话中的 49%。这至少说明一个趋势：开发者和 AI 的关系，正在从「AI 给建议、人执行」走向「人给目标、AI 执行任务」。
到 2026 年，Anthropic 对真实 Agent 使用情况的研究又发现，随着用户使用 Claude Code 的经验增加，他们会越来越少逐步检查 Agent 的每一个动作，而更倾向于让 Agent 自主工作，只在关键时刻进行干预。
这和我自己的经历非常相似。
一开始，我会检查 AI 的每一次修改。
后来，修改从几十行变成几百行，从一个文件变成几十个文件，我发现自己根本跟不上 AI 的生产速度。
一支不知疲倦、拥有大量知识、可以同时阅读代码、调用工具、执行任务、测试和返工的施工队出现了。
于是，一个无法回避的问题摆在程序员面前：
既然 AI 可以比我快几十倍地砌砖，我还应该继续和它比赛谁砌砖更快吗？
我的答案越来越明确：
不应该。
但这不代表工程师不重要了。
因为仍然必须有人回答：
这栋楼到底应该建在哪里？为什么要建？应该建成什么样？设计是否安全？施工有没有偏离图纸？验收标准是什么？最后凭什么相信它不会倒？
图 3：传统软件团队 vs AI Agent 团队
flowchart LR
subgraph OLD[传统软件团队]
direction TB
O1[产品经理] --> O2[架构师 / 技术负责人]
O2 --> O3[前端开发]
O2 --> O4[后端开发]
O3 --> O5[联调]
O4 --> O5
O5 --> O6[测试人员]
O6 --> O7[运维人员]
O7 --> O8[发布上线]
end
subgraph NEW[AI Agent 时代]
direction TB
N1[人类工程负责人<br/>目标 / 约束 / 决策 / 验收]
N1 --> N2[设计 Agent]
N1 --> N3[编码 Agent]
N1 --> N4[测试 Agent]
N2 --> N5[自动化工程系统]
N3 --> N5
N4 --> N5
N5 --> N6[CI / 测试 / 部署 / 监控]
N6 --> N7[软件产品]
N7 --> N1
end
传统团队当然不会突然全部消失。大型企业、金融、医疗、航空航天和关键基础设施，也不会因为 AI 出现就取消所有专业岗位。
但软件的生产方式已经开始变化。
过去，组织需要大量人力亲自完成编码和测试；现在，越来越多工作可以交给 Agent。人类工程师开始从具体施工过程中抽离，转向目标定义、系统设计、Agent 编排、风险控制和最终验收。
而我自己，已经身处这种变化之中。
四、我的工作方式，已经彻底改变了
在公司不断推动 AI 优先以后，我从最初的抵触，到尝试使用 AI 提高效率，再到今天把大量设计、编码和测试工作交给 AI Agent。
经过一段时间摸索，我逐渐形成了自己的 AI Engineering 工作流。
1. 需求阶段：AI 可以辅助，但很难真正替代人与人之间的需求挖掘
真实需求往往不存在于一份整齐的需求文档里。
客户可能说：「我需要一个导出按钮。」
但继续追问以后，真正的问题可能是：现有报表无法满足监管要求，所以他每周都要手动复制数据到 Excel，花两个小时重新整理。
用户告诉你的，很多时候只是他想到的解决方案，而不是真正的问题。
需求还涉及人的模糊表达、组织利益、业务背景、预算、时间和隐藏诉求。这些东西仅仅把一句话扔给 AI，很难得到真正可靠的答案。
因此，目前在我的工作流里，需求仍然主要由人产生。但 AI 可以参与辅助分析：整理信息、寻找矛盾、提出遗漏的问题、帮助评估技术可行性。
人最终负责回答：
What：我们究竟要做什么？
Why：为什么值得做？
2. 设计阶段：一个 AI 设计，另一个 AI 挑刺，人最终做决定
进入设计阶段以后，我会把需求、已有系统情况、技术约束、公司人力、上线时间和性能要求等信息提供给大模型，让 AI 输出第一版方案。
它可能包括：
系统架构、业务流程、数据库设计、接口协议、组件选型、异常处理、并发控制、性能风险和部署方式。
第一版结果出来以后，我不会直接接受，而是自己 Review。
我会检查：
数据库设计是否符合业务模型？接口边界是否合理？有没有过度设计？有没有遗漏异常情况？是否破坏现有架构？这个系统真的需要 Kafka 吗？一个普通数据库事务就能解决的问题，为什么要引入分布式事务？
人工检查之后，再让 AI 根据反馈修改。
更进一步，我还会把设计文档交给另一个完全不同的大模型，让它站在反方的角度进行 Review：
不要认可这个方案。请从数据一致性、并发、性能、稳定性、安全性、可扩展性和维护成本等角度，尽可能找出设计缺陷。
然后把发现的问题重新交给原来的模型修改。
最终得到一套经过：
AI 设计 → 人工 Review → 第二模型交叉 Review → 再次修改
的设计方案。
当然，三个 AI 都说「没问题」不代表真的没有问题。
多数模型一致，也不等于真理。
最终的技术判断仍然必须由人做。
3. 开发阶段：AI Agent 接管大量具体实现
开发仍然按照软件工程的基本规律进行，而不是对 AI 说一句「帮我把整个系统做完」。
我通常首先确定数据模型和数据库结构，然后定义 HTTP API 或 gRPC protobuf 协议。
这个阶段我会重点人工 Review。
因为数据库 Schema 和 API 是整个系统最关键的边界之一。一旦这里出现方向性错误，后面的 Agent 即使写出几万行完全没有语法错误的代码，也只是在非常高效地实现一个错误的系统。
关键边界确定以后，再让 Codex、Claude Code 或 Cursor 进入代码仓库，完成具体业务逻辑。
它们阅读已有代码，寻找相似实现，增加 Model、Repository、Service 和 API，执行格式化、静态检查和测试。
这时候，最大的变化出现了：
AI 写代码的速度，远远超过我阅读代码的速度。
4. 测试阶段：我开始通过测试反向理解 AI 写的系统
一开始，我仍然试图逐行 Review AI 生成的所有代码。
AI 修改 100 行，我读 100 行。
AI 修改 500 行，我读 500 行。
但很快发现，这种方式根本不可持续。
于是我的重心开始变化。
我先让 AI 根据需求和设计文档，生成完整测试方案，然后重点 Review 的不再是实现细节，而是：
正常业务流程是否覆盖？
异常情况有没有遗漏？
边界值有没有测试？
重复请求怎么办？
并发情况下会不会出错？
服务重启以后数据是否一致？
外部服务超时怎么办？
权限是否可能被绕过？
某个组件失效以后，系统行为是什么？
确认测试方案以后，再让 AI Agent 编写单元测试、集成测试和端到端测试，运行所有用例。测试失败，就分析错误，判断是测试本身的问题还是业务实现有 Bug，然后修改并重新执行。
在 Review 测试方案和测试代码的过程中，我也会通过断点、日志、数据库状态和实际输入输出来理解 AI 的实现。
因为当一次修改涉及几十个文件、几千行代码时，直接从第一行读到最后一行已经很困难。但一个精心设计的测试，可以让我看到：
什么输入进入了系统，经过了怎样的处理，最终产生什么输出；异常发生以后系统如何响应；哪些核心不变量始终不能被打破。
测试不再只是为了找 Bug。
它开始成为我理解 AI 代码、约束 Agent 行为和建立质量证据的一种方式。
5. 发布阶段：开发、测试、运维的边界开始模糊
在我所在的公司，因为推行 AI 优先，已经没有人工测试人员参与我的日常项目开发。自测完成以后，可能继续运行稳定性测试和端到端测试，然后准备发布。
同样，也没有运维人员专门负责每次项目上线。开发人员自己使用 Docker Compose、Kubernetes 和其他自动化工具完成部署。
于是，一个过去可能需要产品、前端、后端、测试和运维多人参与的流程，正在被压缩。
我越来越像一个 AI 施工队的负责人。
Agent 可以设计、编码和测试，自动化系统负责构建、部署和监控，而我的责任变成：定义目标、确定关键边界、设计验收方法、处理复杂问题，并对最终结果负责。
图 4：我的 AI Engineering 工作流
flowchart TB
A[真实业务需求] --> B[人类定义问题<br/>What / Why]
B --> C[AI 生成第一版设计]
C --> D[人工 Review]
D --> E[第二个模型交叉 Review]
E --> F{设计是否合理}
F -- 否 --> C
F -- 是 --> G[确定关键边界<br/>数据库 / API / 核心约束]
G --> H[拆分可验证任务]
H --> I[AI Agent 编码]
I --> J[静态检查 / 编译]
J --> K[单元测试]
K --> L[集成测试]
L --> M[E2E / 浏览器测试]
M --> N{是否满足验收条件}
N -- 否 --> I
N -- 是 --> O[人工检查关键风险]
O --> P[部署上线]
P --> Q[Metrics / Logs / Traces]
Q --> R[用户反馈 / 生产异常]
R --> B
这已经不再是简单的 Vibe Coding。
它更像是一条由人类负责目标和决策、AI Agent 负责大量执行、自动化系统提供反馈的软件生产流水线。
但当大量编码工作真的交给 AI 以后，我遇到了一个新的问题。
而且我认为，这可能是 AI 时代软件工程最核心的问题之一。
五、最大的矛盾出现了：AI 写得太快，我根本看不过来
假设一个 AI Agent 几分钟修改 30 个文件，增加 2000 行代码。
作为工程师，我应该怎么办？
逐行 Review？
那我可能需要一个小时，甚至几个小时才能真正理解。AI 带来的编码效率提升，又重新被人工 Review 吞掉。
完全不 Review？
那我怎么知道它有没有误解需求？有没有隐藏的并发问题？有没有把一个本来简单的函数写成难以维护的复杂结构？有没有引入 SQL 注入、权限绕过或者事务一致性问题？
AI 会犯错。
它会幻觉，会自信地误解业务，会修改错误的文件，会为了让测试通过而改变测试本身，也可能实现了功能，却留下一堆完全不可读的代码。
于是一个新的矛盾出现了：
代码生产已经不再是最大的瓶颈，人类对代码的理解、Review 和质量验证正在成为新的瓶颈。
图 5：AI 生产速度 vs 人类理解与验证速度
1 | |
过去的软件开发可能是：
1 | |
而 AI 时代逐渐变成：
1 | |
这也是为什么，我现在越来越不认同「AI 会写代码，所以软件工程变简单了」这种判断。
代码生成只是整个软件生命周期中的一个环节。
如果代码生产速度提高了十倍，但测试能力没有提高十倍，会发生什么？
如果 Review 能力没有提高十倍呢？
如果监控、灰度和故障发现能力没有提高十倍呢？
最终的结果可能不是效率提高十倍，而是以十倍速度制造技术债务和生产事故。
这就像一家建筑公司突然获得了一万台全自动施工机器人。过去一年只能盖一栋楼，现在一个月可以盖十栋。
但建筑设计能力没有变化。
材料检测能力没有变化。
验收能力没有变化。
工程监理还是原来那几个人。
机器人工作得越快，潜在风险反而可能积累得越快。
Google DORA 2025 年关于 AI 辅助软件开发的研究覆盖了接近 5000 名技术从业者。报告指出，接近 90% 的受访者已经在使用 AI，但 AI 并不会自动让一个组织变得优秀。DORA 将 AI 描述为一种「放大器」：优秀的工程体系会被放大，原有的混乱和薄弱环节同样会被放大；同时，AI 使用程度依然与软件交付稳定性呈负相关。
Stack Overflow 2025 年开发者调查则呈现了另一个非常有意思的现象：46% 的开发者不信任 AI 工具输出的准确性，而信任的只有 33%，高度信任的只有约 3%。经验丰富的开发者更加谨慎。
这其实一点也不矛盾。
我每天大量使用 AI。
同时，我也不完全相信 AI。
使用 AI，不等于相信 AI。
就像建筑工程师使用施工队，并不意味着默认相信所有施工过程绝对不会出问题。正因为施工可能出错，所以才需要图纸、施工规范、监理、抽检和最终验收。
AI 时代真正需要建立的，不是：
如何让我百分之百相信 AI？
而应该是：
如何建立一套即使 AI 犯错，我也能及时发现错误的工程系统？
因此，我开始重新思考 Code Review。
未来，我们当然仍然需要阅读代码，尤其是数据库、并发、权限、安全、事务和核心算法等高风险部分。但当 AI 的生产速度远远超过人的阅读能力以后，我们不可能再把「所有代码都由某个人逐行看过」作为唯一的质量保障。
Review 的对象必须向更高层迁移。
过去主要 Review：
这一行代码写得对不对？
未来还必须 Review：
需求是不是对的？系统边界是不是合理？数据模型是不是正确？核心不变量有没有得到保证？测试是否真的证明了系统行为？生产环境能不能发现未知错误？出现问题以后能不能快速回滚？
换句话说：
代码不再是唯一需要 Review 的对象。整个系统的证据链，才是。
六、被杀死的不是软件工程，而是以人工编码为中心的生产方式
所以，回到这篇文章的标题：
AI Agent 正在杀死软件工程。
这是一个故意具有攻击性的标题。
但我的真正观点并不是「软件工程已经没有用了」。
恰恰相反。
我认为真正的工程能力正在变得更加重要。
正在死亡的是另一种东西：
一种以人工编码为中心，将大量人力投入具体代码生产，并依靠不同角色串行传递工作的传统软件生产方式。
过去，一个系统的大部分成本来自「把设计转变成代码」。
一个十天的后端开发任务，也许七八天都在亲自编写 Model、Repository、Service、Handler，处理各种细节。
现在，Agent 可以在很短时间内完成大量具体实现。
代码正在变得越来越廉价。
但是：
需求仍然可能是错的。
系统设计仍然可能是错的。
数据库模型仍然可能是错的。
接口边界仍然可能是错的。
AI 仍然会幻觉。
测试仍然可能遗漏关键场景。
生产环境仍然会在凌晨三点崩溃。
客户仍然会提出一句需求，而真正想解决的其实是另一个问题。
AI 并没有消灭这些事情。
它只是把软件工程的主要矛盾，从：
怎样把代码写出来？
逐渐推向：
究竟应该写什么？为什么这样设计？怎样约束 AI？怎样证明系统是对的？出现未知问题以后怎么办？
甚至「AI 一定提高开发效率」本身也不是一个可以脱离具体场景成立的结论。
METR 在 2025 年对熟悉自己开源项目的资深开发者进行随机对照实验时，得到了一个非常反直觉的结果：在当时的实验条件下，使用 AI 的开发者完成任务平均反而多花了 19% 的时间。METR 在 2026 年的后续研究中观察到了一些可能的加速迹象，但由于样本和实验限制，仍然无法简单得出一个适用于所有开发工作的统一提升倍数。
这说明，评价 AI 开发效率，不能只看：
生成多少 Token。
增加多少代码。
完成多少 Commit。
关闭多少 Issue。
因为这就像评价房地产公司，只统计一天砌了多少块砖。
真正重要的问题应该是：
房子什么时候能够交付？
质量怎么样？
有没有返工？
三年以后会不会漏水？
十年以后结构是否安全？
因此，我认为 AI 时代真正有价值的效率指标，不应该只是代码生产速度，而应该是：
Time to Verified Outcome——从提出问题，到获得一个真正经过验证、可以可靠交付的结果，需要多长时间？
AI 能一分钟写完一千行代码，不代表一分钟完成了软件开发。
只有当需求、实现、测试、部署和生产反馈形成完整闭环以后，我们得到的才不是一堆代码，而是一个工程结果。
七、我的角色到底变成了什么？
一开始，我把自己的变化简单理解为：
从建筑工人变成建筑工程师。
后来我发现，这个描述并不完全准确。
因为一个有五年经验的后端工程师，本来就不是简单的建筑工人。
过去，我已经需要设计数据库、定义接口、选择 PostgreSQL、Redis、Kafka 等组件，考虑并发和事务，设计系统架构，使用 Docker 和 Kubernetes 部署系统，并处理生产环境中的复杂故障。
我一直都在设计。
只是过去，设计完成以后，我还必须亲自拿起砖头进入工地。
自己写 Model。
自己写 CRUD。
自己写 Service。
自己处理错误。
自己写测试。
自己排查问题。
我是一个既画图纸，又亲自砌墙的工程师。
而现在，AI Agent 开始承担越来越多施工工作。
我的角色正在逐渐变成：
定义究竟要解决什么问题；
给 Agent 提供足够准确的上下文；
选择技术方案；
确定数据库和接口等关键边界；
把复杂任务拆成可以验证的小任务；
编排不同 Agent 完成设计、编码和测试；
设计质量验证体系；
检查高风险部分；
处理 AI 无法解决的复杂问题；
对最终上线结果负责。
这更像一个软件生产系统的总工程师。
图 6：从亲自施工，到负责整个软件生产系统
flowchart LR
A["阶段一<br/>传统开发工程师<br/><br/>自己设计<br/>自己编码<br/>自己测试<br/>自己排错"]
B["阶段二<br/>AI 辅助 / Vibe Coding<br/><br/>人描述需求<br/>AI 生成代码<br/>人检查结果"]
C["阶段三<br/>Agentic Engineering<br/><br/>人定义任务<br/>Agent 自主执行<br/>人验证关键结果"]
D["阶段四<br/>AI-native Engineering<br/><br/>设计多 Agent 协作<br/>建立自动验证体系<br/>控制风险与反馈<br/>对最终结果负责"]
A --> B --> C --> D
过去，我的价值很大一部分来自：
我会写 Go。
我会用 GORM。
我会写 SQL。
我懂 PostgreSQL、Redis、Kafka。
我会 Docker 和 Kubernetes。
现在这些知识依然重要，但它们的价值正在变化。
过去：
我懂这些，是因为我要亲自实现。
现在：
我懂这些，是因为我要设计正确的系统，给 AI 正确的约束，判断 AI 是不是在胡说八道，并且在系统真正出问题的时候知道应该去哪里找。
一个完全不懂数据库的人，也可以让 AI 设计 PostgreSQL 表。
但他不知道这张表是不是合理。
一个不懂消息队列的人，也可以让 AI 部署 Kafka。
但他不知道这个系统可能根本不需要 Kafka。
一个不懂 Kubernetes 的人，可以让 AI 写 Deployment 和 Service。
但 Pod 开始 CrashLoopBackOff 以后，他不知道应该检查应用日志、健康检查、ConfigMap、Secret、资源限制还是存储挂载。
一个不懂网络的人，可以让 AI 配置 Ingress。
但遇到 DNS、NAT、MTU、VXLAN 和路由问题以后，他甚至不知道问题发生在哪一层。
所以，AI 并没有让技术知识失去意义。
它只是让记忆语法、重复编码和模板化实现的价值降低，而让设计、判断、验证和复杂问题处理变得更加重要。
八、以后，我应该把时间花在哪里？
我不认为未来的软件工程师应该放弃技术细节，只学习所谓的「Prompt Engineering」。
模型会变化。
今天是 Codex、Claude Code 和 Cursor，明天一定还会出现新的工具。某一种 Prompt 技巧可能几个月以后就失去价值。
真正值得长期积累的，是一套不依赖具体模型的工程能力。
第一，问题定义
再强的 AI，也无法挽救一个错误的问题。
如果需求本身是错的，Agent 只会用更高的速度实现错误答案。
高级工程师首先应该知道：
用户真正的问题是什么？这个问题值不值得解决？我们是不是在解决错误的问题？
第二，架构设计和技术决策
什么时候拆微服务？
什么时候保持单体？
什么时候使用 PostgreSQL？
什么时候需要 Redis？
什么时候应该使用 Kafka？
什么时候绝对不应该增加一个新组件？
AI 可以同时给出十套架构方案，但最终仍然需要有人根据业务规模、团队能力、现有系统、维护成本和风险进行权衡。
真正困难的从来不是「知道世界上存在 Kafka」。
而是知道：
这个地方到底该不该用 Kafka。
第三，数据建模和系统边界
代码可以重写。
数据库结构和历史数据一旦形成，修改成本却非常高。
API 一旦被多个系统使用，也会逐渐成为长期契约。
因此，我会继续重点关注数据库、API、消息协议、权限边界和系统间交互。
AI 可以帮助设计，但关键边界不能完全失控。
第四，验证能力
AI 越能写代码，我越需要知道怎样证明代码正确。
不是通过一句：
Claude 说所有测试都通过了。
而是建立真正的证据链：
1 | |
未来的软件工程师，可能需要越来越擅长的不是「怎样亲手完成所有实现」，而是：
怎样构建一套即使自己没有读过每一行代码，也能对系统建立合理信心的验证体系。
第五，复杂问题排查
简单问题越来越容易交给 AI。
真正困难的问题，通常发生在系统边界。
应用代码看起来没问题，但数据库连接池耗尽了。
数据库没有问题，但 DNS 偶发解析失败。
容器运行正常，但 MTU 导致部分网络数据包异常。
业务代码正常，但 Kafka 重平衡导致延迟突然升高。
某个服务没有报错，但分布式系统中的数据已经出现不一致。
这些问题横跨应用、数据库、中间件、网络、操作系统、容器和基础设施。
AI 可以帮助分析，但前提是有人能够描述正确现象、提供有效证据、排除错误方向，并判断 AI 的分析究竟是否合理。
第六，最终责任
这是最容易被忽略的一点。
AI 不需要参加生产事故复盘。
AI 不会因为数据丢失而承担责任。
AI 也不会因为系统停机，面对客户、老板和整个团队解释：
为什么会发生？
为什么没有提前发现？
为什么没有及时回滚？
至少现在不会。
最终做出技术决策、允许系统上线并承担结果的人，仍然是人。
所以，我现在越来越认为：
AI 时代真正稀缺的，并不是能够生成代码的人，而是能够定义目标、组织 AI 完成复杂工程、建立可靠验证体系，并对最终结果负责的人。
结语：AI 可以替我搬砖，但我必须知道这栋楼为什么不会倒
五年前，我刚开始做后端开发的时候，会因为自己独立完成一个接口而获得满足感。
我亲自创建文件，定义 struct，设计数据库，编写 SQL，实现业务逻辑，处理异常，然后一点一点看着系统运行起来。
那时候，我知道代码为什么这样写。
因为它是我一行一行写出来的。
现在，AI Agent 可以在几分钟内完成我过去需要几个小时甚至几天才能完成的工作。
我不再需要亲手完成所有编码。
一开始，这让我产生了明显的危机感。
如果 AI 会写 Go，会 SQL，会 PostgreSQL，会 Redis，会 Kafka，会 Kubernetes，而且写得比我快得多，那么我过去五年积累的东西还有什么意义？
后来，我逐渐找到了自己的答案。
当然有意义。
只是意义已经发生变化。
过去，我学习这些知识，是为了亲自施工。
现在，我还需要利用这些知识设计系统、约束 AI、识别错误、处理复杂问题，并判断最后的结果到底能不能交付。
我已经不打算继续和 AI 比赛谁写代码更快。
这就像建筑工程师没有必要和挖掘机比赛谁挖土更快，也没有必要为了证明自己懂建筑，坚持亲手砌完一栋楼里的每一块砖。
但我也不会走向另一个极端：
把需求扔给 AI。
不理解。
不设计。
不检查。
只要能运行，就直接上线。
这不是 AI Engineering。
这只是把软件开发变成一场更高效的赌博。
真正的 AI Engineering，不是让人类退出工程，而是重新定义人类在工程中的位置。
当 AI 开始承担大量编码、测试甚至部署工作以后，人应该把更多精力投入真正决定工程成败的地方：
我们究竟在解决什么问题？
为什么选择这个方案？
数据库设计正确吗？
系统边界合理吗？
Agent 有没有偏离目标？
测试真的覆盖了风险吗？
生产系统出现问题能否及时发现？
发生事故以后能否快速止损？
最终交付的东西，真的为用户创造价值了吗？
过去，我既要画图纸，也要亲手搬砖。
现在，一支越来越强大的 AI 施工队出现在我面前。
我的角色正在变成设计者、Agent 编排者、质量审核者、复杂问题处理者，也是最终结果的负责人。
传统以人工编码为中心的软件工程正在死亡。
但真正的工程能力，并没有因此变得不重要。
恰恰相反。
当代码越来越容易生产，判断什么代码应该被生产、怎样证明它是正确的，以及出了问题以后怎么办，才会变得更加重要。
所以，我不知道五年以后，「程序员」这个职业会变成什么样。
但至少现在，我已经确定了一件事情：
AI 可以替我搬砖，但我必须知道，这栋楼为什么不会倒。