AI 会颠覆软件工程吗?

从软件工程要解决的难题出发，沿着需求、架构和设计、开发、测试、发布、运维六个环节，逐一判断 AI 带来的变化属于改进、重构还是颠覆，人在 AI 软件工程中最终应该发挥什么价值。

一、软件工程到底在解决什么难题

提到软件工程，大家很容易想到 IBM System/360 之父 Fred Brooks 的《人月神话》和《没有银弹》——他将软件项目比喻成焦油坑：没有任何一项技术或管理上的进展，能够在十年内使软件生产力提升十倍，软件的本质困难难以被消除。

1.1 软件的四项本质属性

在软件实践过程中，需求不清与频繁变更、质量定义与度量的鸿沟、成本与进度难以估算、安全与风险等是软件开发过程的常态。

《没有银弹》一书中把软件开发面临的困难归因于软件产品本身的四项固有属性：复杂性（Complexity）、一致性（Conformity）、不可见性（Invisibility）和可变性（Changeability）。

• 复杂性
  软件系统是人类建造的最复杂的事物之一，由成百上千个组件构成，其状态和交互关系超出人脑的直接理解能力。
• 一致性
  软件必须与硬件、操作系统、第三方接口、法规、用户习惯等外部约束保持一致，而这些约束往往无法自由选择。
• 不可见性
  软件没有物理形态，其缺陷和结构无法直观感知，这使得沟通、评审和质量控制尤为困难。
• 可变性
  软件承受的变更压力远超其他任何人造产品。市场力量要求软件必须持续适应，否则其满意度将逐步下降；软件演化过程中复杂度会不断增长，除非主动进行维护或削减。

1.2 为什么需要软件工程

"软件危机"一词自 1969 年 NATO 会议以来，就被用来描述软件项目普遍存在的进度延误、预算超支和产品缺陷。这些问题延续至今日，仍然是大多数项目实际面临的难题。软件工程作为系统工程的一个分支，给出了一套完整的解决方案，软件生产不能依赖个人技巧和随机过程，而必须采用可重复、可度量的工程化方法，产出可运行、可验证、可维护、可演进的软件系统。

ISO/IEC/IEEE 24765 给软件工程的权威定义是："将系统化、规范化、可度量的方法应用于软件的开发、运行和维护，即工程方法在软件上的应用。"

1.3 AI对软件工程的影响

大模型出现之后，AI 替代程序员的观点越来越多，对于软件工程，还有其存在的必要性吗？行业也没有形成统一的观点。Salesforce 给出了企业级实证：94% 的工程师采用率、PR 提速 30%、周期时间缩短 30%、两年 3000 万行 AI 生成代码进入生产、整体生产力提升 50%。

回到软件的四个本质属性，个人认为，AI 擅长的是生成代码，可以短时间交付大量功能，而软件工程的本质是对复杂系统的判断、架构与责任机制。代码量暴增，带来的代码审查、调试、维护和安全保障的风险也会增加，组织积累的技术债和安全债最终会带来脆弱性、不稳定性，最终可能导致系统崩盘。所以，软件工程在 AI 时代也应该被重视，而且应该通过 AI 能力进行增强。

下面的内容，我用三把尺子作为标准，来判断 AI 对软件的关键环节和活动的影响。

← 左右滑动查看完整表格 →

二、沿着六个环节，逐个判断

软件工程的核心环节，大致可以切成六个：需求、架构和设计、开发、测试、发布、运维。每个环节原本解决什么难题，AI 带来了什么变化。

2.1 需求环节重构：从"层层翻译"到"意图直落工件"

需求环节要解决的难题，对应四项属性里的一致性：软件必须顺应用户习惯、业务约束，实现必须和需求一致；以及实践层面的可变性：需求不清、冲突与频繁变更。传统做法是：用户脑子里想的东西，经过需求文档、评审、原型，一层层翻译，每交接一次走样一次，还经常会随着项目进展而发生变化，这是软件工程里损耗最重的一环。

AI 带来的变化，用 Anthropic 在《The AI-Native SDLC Playbook》里的做法最直观：需求不再由委员会层层撰写，而是在提问者自己的话里被捕获，直接落成 intent.md，并通过版本管理起来，人可读、机器可执行。Agent 当场扮演分析师的角色，追问范围、用户、约束、什么算成功，把模糊的意图问清楚。Anthropic 给出的度量是：需求周期从数周缩短到数小时。

McKinsey 与 Osmani 不约而同地把这个变化概括为一句：规格驱动开发取代故事驱动开发（Spec driving development instead of story driven）。

需求环节从需求收集、整理、细化，变成了通过提示词和 AI 交互、AI 辅助生成 intent.md，需求分析的过程没有变化，"把模糊意图翻译清楚"这个难题还在，人主要负责定义和确认需求，职责和分工变了，是"重构"。一个需求要不要做、边界画在哪、什么算成功，这些仍需要人判断，只是它不再以"写需求文档"的形态存在了。

2.2 架构和设计环节重构：从"画出来"到"约束住"

架构和设计要解决的难题，对应四项属性里的复杂性、可变性：把大问题分解成可管理的小问题、确定边界、做出权衡，是资深工程师最核心的判断工作。

AI 带来的变化是显著的：方案生成、多方案对比、架构约束检查可以交给 AI，人只负责提需求和做决策。Anthropic 的实践更进一步，安全、合规、UX 等要求被编码成 skills，在写设计文档的同时就被施加约束，不需要等几周后的评审里才被发现问题。AI 编码 Agent 不会主动给你设计"插件化"架构，也不会主动设计"元数据"架构，除非你明确给它提出设计约束。

复杂性的分解与权衡，变成了方案的优劣如何判定、风险向谁转移，这些问题的答案在岗位责任里，不在模型里。AI 没有消除这个难题，它改变的是分工和设计产出，从给人看的架构文档，变成可被机器理解的约束：规范、契约、技能与护栏。设计这件事还在，做设计的方式变了。

2.3 开发环节的颠覆：从"写代码"到"写约束"

开发环节要解决的难题，是实现成本：把设计与意图转化为可运行的代码。

OpenAI 的指南给出了推理能力的底座：据 METR 2025 年 8 月数据，领先模型已能持续推理 2 小时 17 分钟，以约 50% 的概率正确完成任务，而模型可完成的任务时长大约每七个月翻一番，几年之间，从"补全下一行"走到了"跑完一整条工作链"。由此带来的四大新能力是：统一上下文、结构化工具调用、持久项目记忆、评测循环，工程师的角色从"手动敲代码"转向"把整条工作链委托给 Agent"。

Salesforce 给出了企业级实证：94% 的工程师采用率、PR 提速 30%、周期时间缩短 30%、两年 3000 万行 AI 生成代码进入生产、整体生产力提升 50%。vanja.io 的《The AI-Native Software Engineer》给出了一个更形象的杠杆公式：传统工程是 产出 = 编码速度 × 时间 × 代码质量，AI 原生工程是 产出 =（规格清晰度 × AI 能力）× 验证严格度。瓶颈从"写得快不快"转移到了"说得清不清楚、验得严不严格"。一个熟练工程师过去每天写 50–100 行生产代码，AI 原生工程师在同样的时间里影响 500–1000 行系统行为。

编码不再是瓶颈（Code is no longer the bottleneck）。

写代码把需求翻译成代码，把业务变成确定逻辑，可完全交给 AI。代码从"主要产物"降为"可再生的中间产物"，开发不再编写代码，而是编写意图提示词、约束、验收标准，代码可以完全交给 AI 编码 Agent，成本可以被大幅压缩。

2.4 测试的颠覆：从"补漏"到"持续评测"

测试环节要解决的难题，对应四项属性里的不可见性：缺陷没有物理形态，无法直观感知，验证"做对了没有"极其昂贵。传统测试是开发后的补漏：用例靠人写，回归靠人跑，缺陷靠人一点一点查。

AI 带来的变化，测试不再是阶段边界的闸门，而是织进实现过程的持续评测（continuous evals）。更关键的一点是：这套评测不仅在代码变更时跑，在 Agent 配置变更时也跑——换模型、改提示词、改 CLAUDE.md、改 skills 或 hooks，都触发同一套回归，因为"配置决定了 Agent 的行为，理应享受和代码一样的回归测试"。评测集取自 20–50 个真实历史任务；每一起生产事故，都必须回写成一条永久留在套件里的评测。Salesforce 的实践也印证了这点：AI 生成的测试带来了高覆盖率，连资深工程师都在向会用 AI 测试工具的新人学习。

写用例、跑回归、查缺陷，这套"测试执行"的活动，可以完全交给 AI。但评测用例的验收标准由谁定、容忍多少失败，这些判断不再是"测试工程师"这个岗位的专属，而是会融进开发与运维。

2.5 改进发布："流水线自动化"的效率提升

现代软件工程中 DevOps 的理念已经逐步深入人心，从代码构建到发布，可以通过流水线完全实现自动化的发布，随着云原生技术的发展，部署、扩容、回滚技术也相当成熟，AI 出现之后并不会带来实质性的改变。

2.6 运维的重构：从"监控救火"到"自动进化"

运维环节要解决的难题，对应四项属性里的可变性（持续变更与复杂度递增），以及实践层面的维护与演化：维护成本占据生命周期大头，技术债只增不减。传统运维是"监控 + 救火"：告警响了人去处理，运行过程中的各种问题，只能通过开发流程回馈，并通过待迭代持续优化，重复开发、构建、发布、运维的流程，闭环过程以迭代为单位。

AI 带来的变化，可以快速实现问题诊断、修复代码、构建、验证、发布的全过程自动化，大大加速问题闭环过程。每次生产问题的反馈，都可以增强验证，变成自动化测试用例进行质量守护，形成自我演进机制，让系统持续变好。系统运行的熵增会随着时间的变化下降。人只需要确保运维知识的时效性，高风险操作的审批放行，聚焦在治理上。

2.7 总结

← 左右滑动查看完整表格 →

最后回到 Brooks 的四项本质属性，逐一对照 AI 之后的世界：

三、人在AI软件工程中的价值

软件的大部分环节都被AI重构和颠覆了，AI 软件工程中，人还能发挥什么价值？

3.1 颠覆的是实现过程，设计还依赖人

AI 颠覆了软件工程里的"生成与验证执行"，开发和测试，这两个环节已可完全交给 AI；需求、架构和设计与运维，这三个环节被重构，难题仍在人手里；发布则早已被 DevOps 自动化改进，AI 带来的改变有限。

三个责任主体仍然在人，不能由AI替代：

1. 责任在人
    Agent 走到生产闸门，变更必须有人决策。AI 不是责任主体，出了事故，承担责任的是组织与人。
2. 判断在人
    意图文档、设计约束、审批等的判断交给人，不能由AI的概率决定。
3. 验证的定义在人
    被 AI 替代的是"测试执行"，不是"什么算通过"，这些定义权仍是人。

3.2 从动手更多的变成动脑

vanja.io 给出了一张能力栈对比表，值得直接引用：

写代码、写用例、写发布脚本的能力在贬值；定义问题、判定结果、承担责任的能力在升值。工程师从 code writer 变成 系统思考者（systems thinker）。

3.3 岗位：会减少，但不会归零

需求、开发、测试、发布这些环节里纯粹执行的部分，写需求文档、写代码、写用例、跑发布，对应的工作会大幅收缩，人才梯队需要重新设计。

Agent 管理者取代专精实践者。过去按环节分的专精岗位（BA、架构师、开发、测试、发布、运维），会逐渐重组为"管 Agent 的人"。

风险越高的地方，人越多；确定性越强的地方，人越少。分工的轴心从"按环节"变成了"按判断类型 + 按工作风险"。

3.4 技能模型走向责任全栈

传统全栈是技能全栈：前端、后端、数据库都会，靠技术广度。AI 加速了软件的开发过程，多角色的分工逐渐融合，新时代要责任全栈：从意图到生产的整个闭环，一个人都能判断，知识的广度要求更高，对业务知识的精通有利于效率提升，减少和 AI 的交互次数和抽卡几率，不再需要精通某一项编码技能。全栈不是你会做所有事，而是你对全链路负有判断责任。

3.5 角色：定义者、编排者、评审者、担责者

收束为四个词，人从"生产者"变成"定义者、编排者、评审者、担责者"。

• 定义者
  规格驱动开发的时代，人最重要的产出不再是代码，而是规格：问题、边界、验收标准。
• 编排者
  把整条工作链拆解、委托给 Agent，并检查它们回来的是什么。
• 评审者
  信 AI，但要验证，人守判断位。
• 担责者
  AI 不背锅，最终的所有权、质量与责任，在人。

最后引用 McKinsey 的一句话收尾："Start now, it's a human change, and it will take a lot of time." 技术的变化已经发生，人的变化才刚刚开始。

参考资料

1. Anthropic：The AI-Native SDLC Playbook — https://claude.com/blog/the-ai-native-sdlc-playbook
2. OpenAI：Building an AI-Native Engineering Team — https://cdn.openai.com/business-guides-and-resources/building-an-ai-native-engineering-team.pdf （网页版：https://learn.chatgpt.com/guides/build-ai-native-engineering-team）
3. Salesforce Engineering：The AI-Native Engineer — https://engineering.salesforce.com/the-ai-native-engineer-how-salesforces-next-generation-is-redefining-software-development/
4. Addy Osmani：The AI-Native Software Engineer — https://vanja.io/the-ai-native-software-engineer/
5. McKinsey：AI-native development: Rethinking software from the ground up — https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/ai-native-development-rethinking-software-from-the-ground-up
6. Fred Brooks：《No Silver Bullet》与《人月神话》
7. ISO/IEC/IEEE 24765（SEVOCAB）：软件工程定义
8. SWEBOK Guide V4.0（IEEE Computer Society）
9. ISO/IEC 25010:2011：系统与软件质量模型
10. ISO/IEC/IEEE 12207:2026：软件生命周期过程