SDLC、过程模型、方法论：AI 时代再审视

面试里问”你们用什么开发模型”，十个有八个回答”敏捷”。继续问”敏捷和 Scrum 什么关系”，不少人就开始眼神飘忽。

瀑布、迭代、敏捷、Scrum、DevOps——这些词不是一回事。它们分属三个层级：软件开发生命周期（SDLC）、软件过程模型、软件开发方法论。搞懂这层关系，选型时才不会瞎套。

而 **2025 年被称为”Agent 元年”**，AI 编程从代码补全正式迈入智能体协作阶段。到 2026 年，Claude Code、Copilot Agent 这类工具已经进入日常开发的深水区。这篇文章先把基础概念理清楚，再深入常见的方法论，最后聊聊 AI 时代下需求分析和系统设计该怎么玩。

一、三个概念，层级不同

1. SDLC：软件的生老病死

SDLC 是软件从诞生到退役必经的阶段：需求分析、系统设计、编码实现、测试验证、部署上线、运维迭代，最后下线。

这些阶段是跑不掉的。不管团队用瀑布还是敏捷，设计、编码、测试一个都不会少。SDLC 只回答一个问题：有哪些事必须做。

2. 过程模型：阶段怎么排

过程模型定义的是这些阶段以什么结构执行。

是像流水线一样直线推进？还是切成小圈反复迭代？抑或是边做边探测风险的螺旋上升？

常见模型：

瀑布模型：线性顺序，前一阶段彻底完成后才进入下一阶段。
迭代模型：把大项目拆成多个周期，每个周期都完整走一遍设计-编码-测试。
增量模型：先交付一个可用的小核心，再一块一块叠加功能。
螺旋模型：每个周期都嵌入风险评估，适合大型复杂系统。
V 模型：瀑布的变体，强调每个开发阶段都有对应的测试阶段。

过程模型回答的是：阶段之间是什么结构关系。

3. 方法论：具体怎么落地

方法论是带人、带规则、带工具的全套打法。它不仅包含流程，还有团队角色、会议机制、技术实践。

方法论回答的是：在人、事、工具的具体约束下，怎么执行。

二、深入常见方法论

很多人把 Scrum、XP、Kanban、RUP 混为一谈，但它们基因完全不同。

Scrum：管事的框架

Scrum 是一个项目管理框架，核心是通过固定时长的 Sprint（通常 2–4 周）来管理和交付产品。

角色明确：Product Owner（定优先级）、Scrum Master（扫障碍）、开发团队（执行）。
仪式固定：每日站会、Sprint 计划会、评审会、回顾会。
变更规则：Sprint 内原则上不改需求，变更放到下一个 Sprint。

适合谁：5–15 人的产品团队，需求多变，需要定期交付可用版本。团队过小（比如 3 人）会被仪式 overhead 拖累；团队过大则需要拆分成多个 Scrum 团队。

XP：管代码的实践

XP（极限编程）关注的是**”怎么写出好代码”**，而不是”怎么管项目”。

核心实践：测试驱动开发（TDD）、结对编程、持续集成、重构、集体代码所有制。
迭代极短：1–2 周一个周期，强调快速反馈。
客户驻场：理想状态下客户和团队坐在一起，随时答疑。

适合谁：1–5 人的精英小队，技术挑战大，对代码质量要求极高。金融核心交易、嵌入式系统、技术债务重的重构项目常用。客户不能常驻、团队成员技术水平参差不齐的话，XP 很难推。

Kanban：管流的系统

Kanban 起源于丰田的精益制造，本质是可视化工作流 + 限制在制品数量（WIP）。

没有固定迭代：任务持续流动，看板上的卡片从左到右移动。
不设特定角色：产品经理、开发、测试都可以直接在看板上协作。
核心指标：周期时间、累积流图，目标是消除瓶颈。

适合谁：运维团队、技术支持、Bug 修复、内容运营发布这类”工作项源源不断、优先级动态变化”的场景。对团队规模几乎没有限制，小团队和大运维团队都能用。

RUP：管过程的重型方法

RUP（Rational Unified Process）是传统的重量级软件工程过程。

用例驱动：一切从用例分析出发，强调 UML 建模。
架构为中心：前期花大量时间做架构设计。
四大阶段：初始、细化、构建、移交，周期长达数月甚至一年以上。
文档厚重：每个阶段都有严格的评审和交付物。

适合谁：16 人以上的大型团队，开发银行核心系统、ERP、政府信息化项目。需求前期可较明确，对文档可追溯性和合规性要求极高。创业公司、互联网产品用它基本是找死。

四者速查表

方法论	核心定位	推荐规模	最佳场景
Scrum	项目管理框架	6–15 人	需求多变的创新型产品
XP	工程实践方法	1–5 人	技术挑战大、追求代码质量
Kanban	流程优化系统	几乎无限制	运维、支持、持续交付
RUP	重型工程过程	16 人以上	大型企业级系统、强合规项目

现实中的组合用法

纯血统的方法论很少见，团队通常取长补短：

Scrum + Kanban（Scrumban）：用 Scrum 的 Sprint 做计划，用 Kanban 看板管日常任务流。
Scrum + XP：用 Scrum 管项目进度，引入 XP 的 TDD、结对编程来保证代码质量。
RUP 轻量化裁剪：缩减文档和阶段周期，向敏捷靠拢（但争议很大，很多人觉得不如直接用 Scrum）。

三、AI 编程时代：需求分析和系统设计怎么变

2024 年 GitHub Copilot 还在以代码补全为主，2025 年 Cursor 和各类 Agent 工具已能跨文件改项目，到 2026 年，Claude Code、Copilot Agent 正式进入”智能体协作”阶段。AI 不再只是补全几行代码，而是能自主规划、执行测试、提交 PR，甚至参与架构讨论。

自然语言成为一等工程输入

以前，需求分析的核心工作是”翻译”——把用户的自然语言翻译成程序员能看懂的需求文档、用户故事、用例图。

现在，AI 能直接理解自然语言，并生成可执行的技术任务。这意味着：

**需求分析从”写文档”变成”对话”**。产品经理和 AI 反复对话，澄清边界条件，AI 自动生成用户故事和任务拆分。
系统设计的入口也在变。描述清楚业务场景和约束条件，AI 可以辅助探索多种架构方案，推荐技术栈，甚至生成架构决策记录（ADR）。

但这不意味着人类可以撒手。恰恰相反，**”准确描述需求”和”系统抽象能力”成了工程师的核心竞争力**。语法熟练度不再稀缺，稀缺的是判断力。

需求分析：从文档驱动到对话-验证驱动

传统瀑布里，需求分析阶段要输出厚厚的《软件需求规格说明书》（SRS），签完字才进入设计。

敏捷里，需求被拆成用户故事，写在卡片或 Jira 里，由 PO 维护。

到 2026 年，需求分析呈现三种新特征：

1. 快速原型验证

AI 能在几分钟内根据一段描述生成可运行的原型。需求不再是”猜出来的”，而是”试出来的”。产品经理和用户在对话中调整描述，AI 实时生成代码验证想法。这大幅缩短了”需求澄清 → 原型验证”的周期。

2. 模糊需求结构化

面对业务方的口语化描述，AI 可以辅助提取实体、关系、业务流程，输出结构化的需求草案。人类需要做的是审查和修正，而不是从零开始翻译。

3. 需求文档贬值，Prompt 工程升值

完美的需求文档不再是瓶颈。真正重要的是：你能不能写出足够清晰、边界明确、可被 AI 执行的 Prompt。Prompt 就是新时代的需求规格。

系统设计：从蓝图到 SPEC-Driven

传统系统设计产出的是架构图、接口文档、数据库设计。2025–2026 年，一种新的模式正在企业里普及：SPEC-Driven 开发。

具体做法：

人类提出设计意图和约束。
AI 生成设计级别的修改方案（含代码片段、可视化说明）。
人类审查、筛选约 60%–80% 的可靠片段。
AI 基于筛选后的 SPEC 生成完整代码。

这种模式的核心在于：AI 不直接乱改代码，而是先输出”设计文档”级别的方案，由人类把关后再执行。

对于系统架构师来说，工作重心从”画每一张图、写每一份文档”转向：

定义清晰的架构约束和边界。
评估 AI 生成的多个方案，做权衡决策。
把关安全、性能、可扩展性等关键非功能性需求。

人机协作的新范式

AI 不会淘汰程序员，但会迅速拉开”会用 AI”和”不会用 AI”的差距。

当前的人机协作已经经历了三个阶段：

人类主导，AI 辅助：Copilot 补全代码。
AI 主导，人类监督：Cursor Agent 自动改多文件代码，人类做最终审查。
人机共生：AI 处理重复性劳动（代码生成、测试、文档、流水线监控），人类专注于创造力、战略判断和复杂架构决策。

2026 年的一个新变化是：多 Agent 协作开始从概念走向落地。架构设计 Agent、代码生成 Agent、测试 Agent、安全审计 Agent 开始分工协作，虽然还不够成熟，但方向已经明确。

对程序员角色的影响很直接：

初级程序员：需求明显减少，大量重复编码工作被 AI 替代。
架构师 / 高级工程师：价值上升，核心能力是定义问题、评估方案、把控质量。
新兴角色：AI 工具专家、Prompt 工程师、AI 输出审查员正在成为标配。

四、如何应用：没有最好，只有最合适

选方法论和过程模型时，别跟风。下面这套判断逻辑在 AI 时代依然成立，只是多了几个新变量。

5 个经典判断维度

维度	瀑布更合适	敏捷/DevOps 更合适
需求稳定性	需求明确，几乎不变	需求模糊，高频变化
项目复杂度	超大型系统，模块强耦合	中小型产品，模块较独立
交付周期	死线固定（如法规生效日）	需快速试错、抢占市场
客户参与度	客户只能按阶段签收	客户愿意高频参与反馈
团队能力	擅长文档、计划、流程管控	自组织、跨职能、响应快

AI 时代新增的 2 个维度

维度	传统方式更合适	AI 增强方式更合适
AI 工具成熟度	团队完全不会用 AI 工具，学习成本高于收益	团队已具备 Prompt 工程和 AI 审查能力
需求可原型化程度	需求极其抽象，无法快速生成原型验证	需求可通过 AI 快速生成原型，边做边澄清