夜雨聆风
2026年，AI 编程应用 Anything遭苹果公司在全球 App Store 两次下架 。这个曾被资本和媒体寄予厚望的明星产品，估值一度达到1亿美元，融资1100万美元。然而，安全研究人员在其生成的数千款应用中发现了超过上千个安全漏洞、400多个暴露的密钥，以及175例个人隐私数据泄露，涉及医疗记录、银行账号等敏感信息。
苹果的动作很冷静，也很明确：软件不是“生成出来”就可以交付的。没有工程化保障，所谓的智能开发，只会把风险更快地推向用户、企业和社会。
同一年，Cursor CEO Michael Truell 做了一次极端压力测试：调用数百个 GPT-5.2 智能体，在168小时内生成超过300万行 Rust 代码。结果却是，这些代码连流畅加载谷歌首页都做不到。这个案例值得我们深思：AI 可以极大提升代码生产速度，但代码数量并不等于软件质量，更不等于系统能力。
2026年5月，谷歌威胁情报团队首次确认，攻击者已经利用 AI 生成利用脚本，实现零日漏洞的自动化武器化。这些脚本结构规范、注释详尽，呈现出明显的大模型生成特征。AI 既可以提升软件开发效率，也可以放大攻击能力。智能时代的软件安全，不仅取决于模型能力，更取决于使用者、团队和组织的软件工程素养。
代码生成的门槛，正在降到历史最低点。但门槛降低并不必然带来软件产业的解放。恰恰相反，一场新的危机正在形成：
回到原点：软件工程为什么诞生？
要理解今天的危机，我们必须回到1968年。
那一年，硬件能力快速提升，软件规模急剧膨胀，但软件开发方式仍然停留在手工作坊阶段。“软件危机”全面爆发：项目普遍超支、延期，质量不可控，维护成本失控。北约科学委员会召开国际会议，正式提出“软件工程”这一概念，把“工程”二字郑重地放在“软件”之后。
自此，软件工程有了一个非常清晰的使命：对抗复杂性。
图灵奖得主 Fred Brooks 在《没有银弹》中指出，软件开发最本质的困难来自复杂性。软件具有不可见性、耦合性、易变性和一致性要求，这些特征决定了软件系统天然难以驾驭。Dijkstra 也反复提醒我们，必须保持设计的清晰、解耦和简洁，否则人类将被自己制造的复杂性压垮。C.A.R. Hoare 的那句名言同样值得反复咀嚼：构建软件设计有两种方式，一种是让它简单到显然没有缺陷，另一种是让它复杂到没有显然的缺陷。第一种方式要难得多。
软件工程的发展史，本质上就是一部对抗复杂性的历史。结构化方法用模块分解系统，面向对象用对象映射业务世界，SOA 和微服务从架构层面重新组织系统边界与演化方式。每一次方法论和架构范式的演进，都是为了在更大的规模、更快的变化和更高的不确定性中管理复杂性。
而每一次软件系统的失控，也几乎都源于对复杂性的低估。
国内敏捷的走样：当速度脱离工程基础
软件工程进入2.0时代后，敏捷开发成为主流范式。《敏捷宣言》的初衷是积极的：快速响应变化，缩短反馈周期，打破传统瀑布模型的僵化。
但在国内很多组织中，敏捷被误解甚至被滥用。
国内一些团队把“敏捷”理解为“不需要文档”、“不需要设计”、“不需要架构”；一些项目在两个月内高强度迭代、准时上线，却因缺乏架构设计和质量内建机制，很快暴露出严重的性能、安全和可维护性问题。也有资深开发者总结得很直接：许多大厂中的“屎山代码”、不合理缺陷和长期无法修复的问题，并不是因为开发者不懂技术，而是在高压节奏下，所有人都被迫优先满足上线时间。
我曾听过一个真实案例：某金融系统的核心交易链路中，保留着一段多年无人敢动的逻辑，旁边只有一行注释：“此逻辑模仿自2008年 Excel 宏”。这不是幽默，而是技术债的化石。
敏捷在国内实践中走样的根源在于：工程基本功尚未建立，迭代速度却被强行拉快。没有清晰的模块化设计，没有持续重构机制，没有自动化测试，没有代码评审文化，没有架构治理，就开始追求“两周一个 Sprint”。这样的“敏捷”不是敏捷，而是快速积累技术债。
技术债从来不是突然产生的。它往往是在一次次“先上线再说”、“以后再改”、“这个版本先绕过去”的选择中，逐渐沉淀成系统性风险。
SOA 和微服务也是如此。它们的初衷，是通过更好的架构边界来管理复杂性。Netflix 从单体架构演进到微服务架构，用了多年时间，配套建设了完整的自动化运维、监控、弹性治理和组织能力。但微服务不是把一个系统拆成几十个服务那么简单。它在带来独立部署、弹性扩展和组织解耦的同时，也引入了分布式通信、数据一致性、服务治理、链路追踪和故障隔离等更高层次的复杂性。
没有架构能力支撑的微服务，不是解药，而是新的毒药。
Vibe Coding：正在兑现的认知债务
如果说敏捷时代的“快”仍然主要依赖工程师的直接参与，那么大模型时代的 Vibe Coding，则把“快”推向了新的极致。
自然语言描述需求，AI 生成代码；一句话开发应用，几分钟搭出系统原型。这种能力令人振奋，也确实代表了软件生产力的重要跃迁。但任何生产力工具的真正价值，都不在于它能否生成代码，而在于它能否在工程体系中稳定、可靠、安全地创造价值。
Vibe Coding 的问题不在于“用 AI 写代码”，而在于许多人把 AI 生成代码误认为软件工程本身。
第一重代价，是技术债务的快速累积。
AI 生成的代码常常“看起来正确”，甚至结构清晰、注释完整，但其中可能隐藏着不合理的抽象、重复逻辑、隐式耦合、错误边界处理和安全缺陷。许多问题并不是功能性 Bug，而是代码坏味道和架构坏味道。这些问题短期内不一定导致系统失败，却会在系统持续演进中不断放大。
第二重代价，是理解债务的形成。
手写代码的过程，也是建立心智模型的过程。工程师知道每一段逻辑为什么存在，知道做过哪些权衡，也知道哪些方案曾经被放弃。而当 AI 生成大量代码后，人的工作经常变成“事后理解”。这时，团队面对的不只是代码审查，而是对一个未曾亲历设计过程的系统进行逆向工程。
如果一个 Prompt 能在几秒钟内生成数百行甚至上千行代码，那么真正的风险不是生成太慢，而是理解太慢、验证太弱、治理缺位。前期节省的时间，很可能在后期以调试、返工、安全修复和重构的形式加倍偿还。
第三重代价，是表面繁荣下的底层脆弱。
大模型可以生成语法正确、风格统一、注释详尽的代码，但并不天然理解业务语义、领域约束、系统边界和长期演化成本。早期 AI 生成的错误往往比较明显，而今天的 AI 生成代码更危险的地方在于：它可能“看起来非常专业”，却在关键逻辑、权限模型、并发控制或安全边界上存在深层缺陷。
这是一种新的软件风险形态：CI 是绿的，单元测试是通过的，演示效果是正常的，但系统内部可能埋入了极其微妙的竞态条件、性能瓶颈、权限绕过或数据泄露风险。
历史用代价写下的软件工程教材
轻视软件工程，从来不是一个抽象的技术问题。它可能带来生命损失、经济损失和社会级影响。
Therac-25 是软件安全史上最沉重的案例之一。1985年至1987年，这款放射治疗设备因软件控制缺陷造成多名患者受到过量辐射，至少三人死亡。制造商取消了硬件安全联锁，将安全控制过度依赖软件，而软件又缺乏充分的独立测试和系统性验证。这个案例告诉我们：在安全关键系统中，软件不能脱离工程约束单独承担安全责任。
阿丽亚娜5火箭的失败，则是软件复用失控的经典案例。1996年，欧洲航天局的阿丽亚娜5在发射约40秒后爆炸，直接经济损失巨大。问题源于惯性参考系统软件的复用：一个在阿丽亚娜4上长期稳定运行的模块，到了新的运行环境中，由于数据范围变化导致异常，最终引发系统失效。一个模块过去正确，并不意味着它在新的上下文中仍然正确。复用必须建立在需求、环境、假设和约束的重新验证之上。
波音737 MAX 的两次空难，则更加深刻地揭示了工程流程、商业压力和安全文化之间的关系。MCAS 系统设计中的传感器依赖、冗余策略、飞行员培训、风险披露和认证过程，都暴露出系统性问题。这不是一个单点 Bug，而是软件工程、系统工程和组织治理共同失效的结果。
2024年的 CrowdStrike 事件，则让全球再次看到现代软件供应链的脆弱性。一次软件更新失误导致大面积 Windows 系统蓝屏，影响航空、医疗、金融等多个行业。现代软件已经成为社会基础设施的一部分，一个供应链节点中的工程缺陷，可能通过自动更新机制在全球范围内迅速扩散。
这些案例共同说明：软件工程不是“写代码的流程”，而是人类对抗复杂性、缺陷、不确定性和组织失误的防御体系。
今天，当 AI 能够大规模生成代码时，这些历史教训不仅没有过时，反而更加重要。Therac-25 的教训存在于每一个缺乏安全验证的生成函数中；阿丽亚娜5 的教训存在于每一次未经上下文验证的代码复用中；737 MAX 的教训存在于每一个被商业速度压缩的安全冗余中；CrowdStrike 的教训存在于每一次缺乏灰度、回滚和供应链治理的自动化发布中。
软件工程3.0：不是放弃工程，而是强化工程
大模型时代并不意味着软件工程过时。相反，它意味着软件工程进入了新的阶段。
我把这种演进称为软件工程3.0：大模型驱动的软件研发新范式。在这一阶段，软件研发不再只是人写代码、机器执行代码，而是人、模型、工具链、数据、知识库、规范体系和反馈机制共同构成新的工程系统。
我们称这一时代的软件工程叫“软件工程3.0”，说明软件工程还存在，而且软件工程3.0的核心，不是让 AI 替代工程师，而是让 AI 在工程约束下发挥能力。
首先是上下文工程。
大模型的输出质量高度依赖输入上下文。需求、业务规则、接口约束、架构决策、质量属性、安全规范、历史缺陷、领域知识，都应当被显式化、结构化，并作为模型生成的上下文。工程师的角色不再只是写代码，而是设计和维护一个能够支持正确生成、正确验证和持续演进的上下文体系。
其次是规格驱动开发。
Spec-Driven Development 将人的注意力重新拉回需求和设计。人负责明确业务语义、架构边界、质量目标和验收标准，AI 在清晰规格的约束下完成代码生成、测试生成和文档生成。越是金融、医疗、交通、工业控制等高可靠、高合规领域，越不能接受“大概正确”的代码。规格不是形式主义，而是智能开发时代控制不确定性的基础。
再次是驾驭工程。
我们需要通过环境设计、意图表达、反馈循环、架构规则、测试门禁、安全扫描、代码审查和运行时监控，把大模型的输出纳入工程可控范围。AI 的输出可以是非确定性的，但软件交付不能是非确定性的。软件工程3.0要解决的，正是如何把大模型能力转化为可验证、可治理、可持续演进的软件生产力。
生死攸关的，从来不是工具
Brooks 在1987年写下“没有银弹”。近四十年过去，这句话依然成立。
大模型不是银弹。它不会让软件工程失效，恰恰相反，它把软件工程能力从“优秀团队的加分项”变成了“智能时代的生存能力”。
能够做好需求分析、架构设计、模块分解、测试设计和质量治理的工程师，会在大模型时代获得更大的生产力放大。能够建立规格体系、知识体系、工具链体系和反馈闭环的组织，会真正享受到 AI 带来的效率红利。而那些认为“大模型可以替代一切工程思考”的团队，正在亲手建造下一座技术债务的火山。
无论代码是人写的，还是 AI 生成的，真正决定软件质量的，始终是清晰的需求、合理的架构、严格的规格、充分的测试、持续的反馈，以及对简单性和可维护性的长期坚持。
这不是危言耸听。Therac-25 前逝去的生命，阿丽亚娜5 化为碎片的巨额投入，737 MAX 上346个无法抵达的终点，CrowdStrike 蓝屏背后全球基础设施的震荡，以及 Vibe Coding 应用中暴露的医疗记录和银行账号，都在反复提醒我们：
