自从IT软件成为工业产业化的那一刻，如何更高效、更可控地管理软件开发过程就是一个绕不开的话题，从80 年代提出的“瀑布模型”，规定软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护 等六个基本活动。到90 年代提出的“敏捷开发”，强调人的主观能动性，以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

那么进入AI时代下的软件开发生命周期（Software Development Life Cycle，SDLC）又会是如何？2025年，通用Agent+skill的模式，在Claude Code、Open Code等框架的助推下，慢慢地浸入到各行各业的开发流程，类似上一波企业数字化一样，这一波的AI编程Agent+skill来打通各流程：从需求分析，到SPEC文档书写，再到架构文档、代码、测试用例编写，再到部署问题调试。

虽然本质来说Claude Code、Open Code等AI编程框架也就是一种提升编程和解决问题效率的框架，一如之前开放的各种语言框架：Spring cloud/VUE等，但这一次真如《年少有为》电视里戏称一样“C语言也是语言，文字工作都是通用的”。

本文从软件开发生命周期触发，看看一个传统行业的软件开发在不同时代下可能的实现路径：从「瀑布模型下，汽车产业ASPICE开发验证流程---> IPD，瀑布模式快速迭代的一种妥协 ---> 敏捷开发，将IPD目标引入PI，通过Sprint快速实现 ---> AI编程，人为主Agent为辅，协助打通各个环节 --->AI Context为中心，AI为主，人提供各角色SKILL，主动实现从需求建立到实现的全流程」

阶段一：瀑布模型为核心的强合规 SDLC—— 以汽车产业 ASPICE 为代表

这是传统行业软件开发的起点，核心是文档驱动、阶段冻结、双向追溯、合规优先，完全适配工业级软件的安全与监管要求。以汽车行业 ASPICE（汽车软件过程改进和能力测定）模型为例，其严格遵循瀑布式生命周期：客户需求→系统需求分析→软件需求分析→软件架构设计→软件详细设计→编码实现→单元测试→集成测试→系统测试→验收交付，每个阶段有明确的准入准出标准，前一阶段的交付物必须冻结、评审、签字确认后，才能进入下一阶段，全流程强制建立需求 - 设计 - 代码 - 测试的双向追溯矩阵，完全对齐 ISO26262 功能安全标准。

核心痛点

1. 1. 周期刚性极强，一款车载 ECU 软件开发周期长达 18-24 个月，需求变更成本呈指数级上升，无法适配智能汽车快速迭代的用户需求；

2. 2. 文档与代码严重脱节，多数企业的 ASPICE 合规沦为 “为过审补文档”，而非真正落地过程管控；

3. 3. 验证成本占比超 60%，测试环节严重滞后，bug 发现越晚，修复成本越高，且跨职能部门协同壁垒极高。

阶段二：IPD—— 瀑布框架下的有限迭代妥协

IPD（集成产品开发）是传统行业对纯瀑布模型的第一次改良，核心是阶段门管控 + 阶段内小迭代，在不打破强合规大框架的前提下，释放有限的灵活性。其核心逻辑是把产品全生命周期拆分为概念、计划、开发、验证、发布、生命周期管理 6 个阶段，每个阶段之间设置刚性的决策评审门（Gate），只有通过门控评审才能进入下一阶段，守住合规与安全底线；而在每个阶段内部，允许拆分小的迭代循环，实现局部的快速优化，解决纯瀑布 “一错到底、完全无法调整” 的问题。

核心痛点

1. 1. 改良仅停留在 “流程形式”，未解决核心矛盾：跨阶段的需求变更依然受限，文档与代码脱节的问题完全没有改善；

2. 2. 对组织能力要求极高，多数传统企业落地后沦为 “走流程的形式主义”，迭代仅局限在编码环节，前端需求与后端验证仍保持瀑布模式；

3. 3. 跨角色协同效率依然低下，职能墙的问题没有得到根本解决。

阶段三：规模化敏捷 ——IPD 目标锚定 + PI 规划 + Sprint 迭代

这是传统行业 SDLC 的第二次关键演进，核心是把 IPD 的产品目标拆解为可落地的增量价值，用规模化敏捷框架适配传统行业的组织与合规要求，最典型的就是车企广泛落地的 SAFe 规模化敏捷框架。其核心逻辑是：把 IPD 的中长期产品目标，拆解为 3 个月左右的 PI（项目增量），每个 PI 拆分为 4 个 2 周的 Sprint 迭代；把刚性的需求文档拆解为可落地的用户故事，小步快跑、持续集成、持续验证；同时在 PI 规划阶段，对齐合规、安全、硬件交付等刚性约束，在迭代中全程嵌入合规检查，解决纯互联网敏捷与工业级合规的冲突问题。

核心痛点

1. 1. 天然的内生矛盾：敏捷的 “拥抱变化” 与工业软件的 “合规可控” 始终存在冲突，多数企业落地为 “伪敏捷”—— 仅编码环节迭代，需求、架构、合规仍为瀑布模式；

2. 2. 对人的能力要求极高，需要跨角色的全栈研发能力，而传统行业的职能型组织架构（需求、架构、开发、测试、运维分部门），导致敏捷落地严重水土不服；

3. 3. 测试与合规跟不上迭代速度，自动化测试覆盖率低，迭代越快，bug 累积越多，合规风险越高，最终陷入 “为了迭代而牺牲质量” 的恶性循环。

阶段四：AI 编程 1.0—— 人为主、AI 为辅，全流程环节提效

这是 2024-2025 年正在全行业落地的阶段，也是 AI 正式浸入 SDLC 全流程的起点，核心是人始终是流程的决策者、责任主体，AI 作为 “副驾驶”，在 SDLC 的每个环节提供提效能力，解决前序阶段的核心能力瓶颈。以 Claude Code、Open Code、GitHub Copilot X 等框架为代表，Agent+Skill 的模式首次实现了 SDLC 全环节的覆盖，而非仅局限于编码环节，这也是其与 Spring Cloud、VUE 等传统开发框架的本质区别 —— 传统框架仅解决 “编码环节的效率问题”，而 AI 编程框架解决的是 “全研发流程中，所有基于规则与逻辑的文字工作的效率问题”，正如行业戏称的 “C 语言也是语言，文字工作都是通用的”。

SDLC 环节	AI 核心能力	解决的传统痛点
需求分析与 SPEC 文档书写	自然语言需求转结构化 PRD / 需求规格书，自动拆解系统 / 软件需求，自动生成 ASPICE 需求追溯矩阵，对齐合规条款	需求拆解不规范、文档与后续环节脱节、合规追溯靠人工补全
架构设计	基于需求生成架构文档、模块划分、接口定义、时序图 / 数据流图，自动完成 DFMEA 失效分析，对齐 AUTOSAR、MISRA 等行业规范	架构设计与需求脱节、行业规范落地不彻底、架构评审效率低
编码实现	代码自动生成、逻辑补全、静态扫描、规范对齐、代码评审、bug 自动修复	编码效率低、规范落地不到位、重复代码工作量大
测试用例编写与执行	基于需求与代码自动生成单元 / 集成 / 系统测试用例，自动执行测试、分析失败原因、修复代码、生成合规测试报告	测试用例覆盖不全、测试滞后于迭代、测试报告合规性不足
部署与调试	自动生成部署脚本、日志分析、问题定位、故障排查、回滚预案生成	部署环境不一致、问题定位效率低、运维门槛高

本阶段的核心约束

AI 的所有输出都必须经过人的审核与确认，合规与安全的最终责任主体依然是人，尤其在汽车、医疗等安全相关领域，AI 无法替代人的决策与责任，仅作为提效工具存在。

阶段五：AI 编程 2.0——AI Context 为中心，AI 为主、人提供角色 Skill 的全流程自主实现

这是 AI 时代 SDLC 演进的终局形态，核心是从 “流程驱动” 彻底转向 “目标驱动”，从 “人主导的环节串联” 转向 “AI 统一上下文驱动的全流程自主协同”，彻底重构了 SDLC 的权责关系与组织形态。

核心特征与本质变革

1. 1. 统一 AI Context 成为 SDLC 的核心载体不再有瀑布、敏捷的阶段划分，所有需求、架构、代码、测试、合规、运维数据全部沉淀到一个贯穿全生命周期的统一 AI 上下文中。人只需给出最终的业务目标与约束条件（例如 “开发一款 L2 + 辅助驾驶泊车 ECU 软件，符合 ASPICE CL3、ISO26262 ASIL-B 等级，6 个月内交付”），AI 即可在统一上下文内，自主完成从需求拆解、架构设计、编码、测试、合规验证到部署交付的全流程，无需人工推动环节流转。

2. 2. 人的角色完成根本性重构人从 “全流程的操作者、执行者”，转变为Skill 提供者、规则制定者、最终风险决策者：

   • • 不再需要人工撰写需求文档、画架构图、写代码、写测试用例，而是将各角色的核心行业 Know-How、方法论、规范、合规要求，封装为可被 AI 调用的 Skill（例如需求专家封装 “汽车电子需求拆解方法论”、安全专家封装 “ISO26262 功能安全验证规则”、合规专家封装 “ASPICE 全流程合规校验标准”）；

   • • AI 在全流程中，自主调用对应 Skill 完成各环节工作，自动解决环节间的协同问题，人仅在关键风险节点做最终决策，或在 AI 遇到超出现有 Skill 边界的问题时，提供顶层指导与 Skill 升级。

3. 3. 多 Agent 协同实现全流程闭环单环节的 AI 提效工具，升级为多角色 Agent 协同的研发系统：需求 Agent、架构 Agent、开发 Agent、测试 Agent、合规 Agent、运维 Agent 各司其职，在统一的 AI 上下文中实时同步信息、自动完成跨环节衔接，全程无需人工干预。例如需求 Agent 拆解完需求，自动同步给架构 Agent；架构 Agent 完成设计，自动同步给开发 Agent 与合规 Agent；开发 Agent 生成代码后，自动同步给测试 Agent，同步完成合规校验，彻底打破传统的职能墙与环节壁垒。

4. 4. 合规与安全从 “事后验证” 变为 “内生嵌入”这是对传统行业 SDLC 最颠覆性的突破：合规与安全不再是每个环节结束后的补充验证，也不是最终交付前的过审动作，而是全程嵌入 AI 的每一步输出中。AI 在生成需求、架构、代码的每一个环节，都会自动调用合规 Skill，对齐行业规范与监管要求，自动生成双向追溯矩阵，全程可追溯、可审计、可验证，从根源上解决了 “效率与合规不可兼得” 的行业百年难题。

演进的核心前提与落地约束

但从 1.0 到 2.0 的跃迁，仍需突破三大核心约束：

1. 1. 合规责任的边界明确：工业级软件的安全责任是终身制的，AI 生成内容的安全事故责任界定，是 AI 从 “辅助” 走向 “主导” 的核心法律前提，其落地必然是渐进式的 —— 先在非安全相关环节落地，再逐步渗透到安全相关领域。

2. 2. 行业 Know-How 的标准化封装：AI 的能力上限，取决于 Skill 的质量。传统行业数十年积累的隐性行业经验、设计规范、安全准则，需要转化为 AI 可理解、可执行、可迭代的标准化 Skill，这是企业落地的核心门槛，也是未来的核心竞争力。

3. 3. 组织架构与研发基建的配套升级：传统的职能型组织架构将彻底失效，取而代之的是 “Skill 中心 + 决策中心” 的新型组织形态；同时需要打通碎片化的研发工具链，构建统一的研发数据平台，为 AI Context 提供完整的数据支撑。

总结

AI 时代的 SDLC 演进，不是对瀑布、IPD、敏捷的否定，而是对经典模型的继承与升维。瀑布模型解决了工业软件的 “可控与合规” 问题，IPD 与敏捷解决了 “效率与灵活” 问题，而 AI 驱动的 SDLC，第一次实现了两者的完美统一。

它没有改变工业级软件开发 “安全优先、合规可控、价值交付” 的核心本质，却彻底重构了实现这个本质的方式 —— 把研发人员从重复、繁琐的执行性工作中解放出来，聚焦于核心的行业 Know-How、规则制定与风险决策，最终实现软件开发效率与质量的量级式跃升。