软件开发模型过时了吗?但当AI接手编码,如何定义并选择软件开发模型

今天要说的是被称为 Ninety-Ninety Rule（九九法则）的这条格言，后续成为软件工程领域最著名的幽默格言之一。这句话翻译过来就是：前90%的代码花掉90%的时间，剩下10%的代码再花掉90%的时间。核心意思总结下来就一句话：项目永远比预期多花 80% 的时间。

为什么软件项目总是高估了把东西做出来的速度，低估了把东西做对的代价？

01

七大软件开发模型

还是先说一下什么是软件开发模型，担心时间太长都忘记是什么了。软件开发模型本质上是开发活动的组织蓝图，它决定了你在什么阶段做什么事、产出什么、谁来验收。

没有开发模型的项目是什么样？需求来了直接写代码，写一半发现需求不对，改代码，再写一半发现架构撑不住，重构，越改越乱，最后交付一个能用但谁也不敢动的东西。

有开发模型的项目呢？起码你知道此刻我应该干什么、下一步是谁接盘。

七个模型全景图大概是这样：

它们其实本质上回答了同一个问题：怎么把不确定的软件开发过程变得可控？ 只是每个模型选择了不同的应对策略。

1.1 瀑布模型

瀑布模型基本上大家都比较熟悉，它最大的贡献不是它有多好用，而是它让所有人第一次意识到软件开发需要一个过程。大致内容是这样：

1.2 V模型

V模型接触的比较少，它是瀑布的带质检版，每个开发阶段都配了一个对应的测试阶段。核心大概就是：早测试、早验证。在需求阶段就想着验收测试怎么写，设计阶段就想着集成测试怎么测。大概是这样：

1.3 原型模型

原型模型也比较好理解，当需求说不清楚时，别花三个月写需求文档，先花一周做个能点能看的Demo。主要就是适用于：用户界面不确定、业务流程模糊、创新产品探索。主要分下面两种：

1. 抛弃式原型：做完给用户看，确认需求后扔掉，正式开发

2. 演进式原型：原型就是第一版，反复迭代到最终产品

1.4 增量模型

增量模型就是先做核心功能上线，再一点点加功能。不是一次交付全部，而是分批交付价值。它的思想对软件工程发展很有借鉴作用，它是第一次让软件可以分期付款成为可能。不是一次性投入所有开发成本，而是每个增量交付一期价值。大概过程是这样：

1.5 螺旋模型

螺旋模型是一个风险驱动模型。每个循环不是完成需求→设计→编码→测试，而是识别风险→消除风险→做风险最低的事→评审→进入下一轮。它的价值是：第一次明确告诉行业，不是所有项目都适合先写需求再编码，风险才是决定开发策略的第一因素。

1.6 喷泉模型

喷泉模型是面向对象时代的过程模型，基本上符合OO的特性。它的特点是无间隙，分析、设计、编码之间没有明确边界，对象可以在各阶段自由流动。适合OO项目的迭代开发。

1.7 敏捷模型

敏捷是当前我们最主流的选择的开发模式，如果说前面六个模型都试图用结构化的流程来管理不确定性，那敏捷走了相反的路，它放弃了对流程的精确控制，转而拥抱变化本身。敏捷提出来了四条价值观：

敏捷理念把Scrum、XP（极限编程）从实践层面补充了结对编程、TDD、持续集成等手段。算是一个发展集大成的开发模型，从增量模型继承了分批交付，从螺旋模型继承了迭代审视，从原型模型继承了快速验证。它不是凭空出现的，而是把前面模型的精华做了减法。后续可以继续聊一下敏捷的深度体验，这里不做过多展开。

02

编码速度起飞后，开发模型还管用吗

这是我们AI时代所面临的挑战之一，瀑布模型假设编码阶段是瓶颈，所以要花大量时间在编码前把设计和文档做充分。现在呢？AI 10秒能写的代码，人可能要写一天。编码不再是瓶颈了。瓶颈向前移到设计和需求，向后移到测试和验收。

现在的软件研发流程大概是这样：

那问题来了：

1. 设计能跟上AI编码速度吗？

答案是肯定的，我们需要把设计和编码整体来看待，如果还是分开，就会出现设计只画了个粗略的框图，AI就开始生成代码，生成出来的东西大概率是对但没对上需求。AI编码越快，设计越细节的需求就越迫切。

2. 测试能跟上吗？

AI一天生成一万行代码，人工写测试用例的速度完全跟不上。测试必须同步AI化，AI生成的代码由AI来测，人只负责验收测试策略。

3. 螺旋模型的风险驱动思想反而更契合AI时代

为什么这么说？因为AI项目最大的不确定性不是能不能写出来，而是写出来能不能用，幻觉、安全、合规……这些都是典型的技术风险。螺旋模型在每个循环中都要求先识别风险再开发，这个思路在AI时代反而更适用了：先评估这段逻辑让AI写风险有多大，再决定要不要AI写。

那么上面各大过程模型在AI时代的适配性大概是这样：

03

如何让开发模型真正用起来

下面跟大家分享一下在场景的几种开发模型中如何能让AI增强实操：

3.1 瀑布模型中AI加速设计

传统瀑布中，概要设计文档写一周，详细设计文档再写一周，才能开始编码。AI辅助做法：

这样做效果：设计文档阶段从两周缩短到两天，人负责决策和终审，AI负责草稿生成。

3.2 螺旋模型中AI做风险分析

螺旋模型落地最大的难点是，每个循环都要做风险识别和分析，费时费力，很多团队做着做着就放弃了。AI可以这样辅助：

螺旋循环启动  → AI读取当前需求与设计文档  → AI识别可能的技术风险（如这个模块依赖AI生成代码，幻觉风险高）  → AI输出风险影响-概率矩阵  → 团队在AI分析基础上补充领域特定的风险  → 决定本轮开发策略

3.3 原型模型中AI一键出原型

以前做一个可交互原型需要UE/UI同时介入，至少1-2天。

现在可以换一种方式：把需求描述给AI → AI生成HTML/CSS交互原型 → 放在线预览给用户点 → 用户反馈 → 修改Prompt → 新原型。一个需求探索循环从3天缩短到30分钟。

这三种场景的应用，核心逻辑是：AI没有淘汰过程模型，而是让每个模型的瓶颈点发生了变化。 选模型时不再只看团队规模和项目复杂度，还要看AI能在这个模型的哪个环节发挥最大价值。

04

总结

回到开头提到的九九法则，为什么剩下10%的代码要花90%的时间？是因为那10%的代码本身难写吗？大概率不是的，而是因为在整个研发交付过程没管好，需求漏了、设计没覆盖到、测试没跟上，所有问题都堆积到了最后，然后体现出来的一个结果。

七个模型，本质上都是同一个问题的七种解法：让不可预测的软件开发过程变得可预测。

AI时代的来临，没有改变这个目标，但它改变了实现目标的路径。当编码不再是瓶颈时，过程模型的重心从管好编码阶段转移到管好编码前后的事，需求如何清晰、设计如何跟上、测试如何并驾齐驱、风险如何提前识别，如此而已。

我们面临的问题：模型没有过时，只是需要适应+运用AI这个加速器。

AI进来之后，在实际项目研发/交付中，你们调整过哪个环节？哪个环节最需要调整？欢迎聊聊。

👆👆👆tips：敬爱的读者朋友，原创文章不易，如果您对企业架构、系统架构设计、软考高级系统架构师等技术领域感兴趣，可以点赞+关注，欢迎留言讨论，我们一起进步~