ARTICLE · 1268378
AI时代,五阶段两专题仍是软件工程的骨架——从“人写代码”到“人定规则与验收”
这是一个非常敏锐且直击本质的问题。在AI（大模型、Agent、Copilot）深度介入软件开发的时代，很多人大呼“软件工程已死”或者“全员都是架构师”。但是我们要用软件设计的“系统思考”和“分而治之”的眼光来看：
结论是：这五个阶段和两个专题不仅需要，而且比以往任何时候都更重要。只是它们的“执行方式”和“交付物形态”发生了根本性改变。
无论AI写代码有多快，软件工程的底层逻辑——管理复杂性、控制风险、做权衡（Trade-off）——永远不会消失。我们可以分维度来看：
一、 核心矛盾没变：为什么这5个阶段不能省？
AI时代，软件开发的瓶颈从“敲代码”转移到了“定义问题”和“系统集成”上。
• 需求分析（阶段一）：业务方的原始需求往往是自相矛盾且充满“伪需求”的。AI可以帮你极速提取概念、画类图，但AI无法代替你去和业务方谈判、对齐目标、砍掉“镀金需求”。如果前置需求错了，AI只会以光速写出一堆符合错误需求的垃圾代码。 • 确定关键需求（阶段二）：AI可以列出所有功能，但 “架构大方向的拍板”必须由人来做。预算只有50万，到底是上微服务还是单体？这种涉及真金白银和组织现状的“制约权衡”，AI没有上下文，也无法承担责任。 • 架构设计（阶段三：概念架构设计）：AI 极擅长快速产出 Mermaid 分层图、子系统划分草图和 2~3 套备选概念方案，甚至能按“单体 / 微服务 / 事件驱动”各生成一版。但概念架构的关键不是画得漂亮，而是大方向的拍板：系统分成哪几个子系统、哪些能力先做、技术选型是否匹配团队与预算。AI 没有组织现状和成本约束的上下文，容易给出“看起来先进但过度设计”的方案。人的职责是做取舍、否决不合适的备选，把概念架构收敛成一张各方认账的蓝图，而不是让 AI 一口气生成十版没人拍板。 • 架构设计（阶段四：细化架构设计）：AI 生成 Spring Boot 骨架、接口契约、DDL、包结构非常快，这部分确实可以大幅提效。但细化架构的真正难点是分层规则和依赖方向：哪些是系统交互层、领域层、基础设施层，谁能调谁、跨模块只能走接口还是可以直连。AI 缺乏稳定的业务语义，容易按“功能表面”堆代码，短期能跑，长期就是职责重叠、循环依赖、边界腐蚀。正确做法是人先定分层和依赖红线，AI 只在既定骨架内填充，再用 ArchUnit、dependency-cruiser 之类的工具把规则写进 CI，违规直接卡住。 • 架构验证（阶段五：架构验证）：AI 可以快速生成质量属性场景清单、架构检查表、关键用例的验证脚本，甚至能按“性能 / 可用性 / 安全性 / 可修改性”各列一套评估提纲，看起来面面俱到。但阶段五的关键不是清单有多全，而是架构是否真的满足了既定的质量属性目标：关键场景走查能不能过、架构决策有没有被验证、风险点有没有兜底方案。AI 没有组织真实的约束上下文，容易给出“纸面正确”的评估结论。人的职责是设定验证目标和通过标准，主持架构评估，对不达标的决策拍板返工，而不是让 AI 生成一份没人核对的验证报告。 • 模块划分推导演练（专题一）：AI 可以很快把用例映射成 package 草稿，甚至画出模块依赖图。但模块边界到底怎么切，依赖深厚的业务领域知识（DDD）：限界上下文要按业务能力切，不按技术分层切；外部依赖要走防腐层（ACL），防止边界被侵蚀。AI 没有业务语义上下文，随意切分的结果就是模块职责模糊、耦合飞起，最后得到一个极其复杂且无法维护的“屎山代码”，连 AI 自己后面都改不动。所以专题一的正确定位是：人类用事件风暴、用例聚类定边界和依赖方向，AI 做映射草稿和反例审查（查循环依赖、跨层调用、边界泄漏），边界决策权始终在人手里。 • 架构验证（专题二：架构验证专题 / PoC 演练）：AI 生成 PoC 原型代码、并发测试脚本、压测断言非常快，这部分确实能大幅提效。但真正的难点是高风险技术点到底扛不扛得住：高并发下会不会超卖？内存会不会溢出？长事务会不会拖垮数据库？AI 没有真实的物理环境去跑压测、去踩坑，它生成的代码“看起来都对”，跑起来才知道哪里不对。所以专题二的正确定位是：人类架构师圈定高风险点、设定压测指标和验收阈值，AI 负责生成原型和脚本，人负责在真实环境里跑、看日志、盯结果，把“看起来对”变成“实测过关”。
二、 执行方式变了：AI时代下，这7个环节是如何运转的？
传统的瀑布流或敏捷开发，是“人写文档 -> 人审查 -> 人开发 -> 人测试”。AI时代，这个过程变成了 “AI生成草稿 -> 人类做高维决策 -> AI快速实现 -> 人类进行质量验收”。
具体到各个环节的变化：
1. 需求与领域建模（阶段一）：从“人写SRS”变成“AI生成需求基线，人类做核对”。你只需要把语音记录或会议纪要扔给AI，它就能在几秒钟内列出用例、找出矛盾点。人的精力放在了“确认哪些是真正要做的”。 2. 寻找分水岭（阶段二）：从“手工筛选”变成“AI模拟推演，人类拍板”。你可以让AI扮演不同角色（CTO、业务老板、运维）进行辩论，生成多套权衡方案，人类只看最终结论。 3. 概念与细化架构（阶段三、四）：从“画图搭架子”变成“AI生成备选方案，人类做架构审查”。AI可以瞬间给出微服务版和单体版的设计，人类只需要基于团队能力去否决那个“过度设计”的方案。 4. 模块划分（专题一）：从“靠经验”变成“AI对齐业务与代码，人类定规范”。AI帮你把用例映射成Package，但“高内聚低耦合”的依赖红线（比如严禁Service层直接写SQL）必须由人类写进Code Review规则里。 5. 开发与验证（阶段五、专题二）：从“人肉写PoC”变成“AI秒出原型代码，人类跑压测”。AI可以瞬间生成并发测试脚本和框架骨架，你只需要在本地跑一下，看看日志报不报错。
三、 AI时代，架构师的角色发生了什么异化？
过去，架构师很多时间在做“翻译”和“画图”的工作。现在，AI把这个环节的耗时压缩了90%。未来的架构师，将变成“系统质检员”和“技术裁判员”。
• 从“怎么做”转向“要不要做”：AI能提供100种方案，架构师的价值在于说“方案B虽然先进，但不符合我们现在的预算和团队水平，砍掉”。 • 从“生产者”变成“约束者”：因为AI写代码太快了，如果不设定严格的架构约束（防腐化红线、接口契约、依赖规则），系统会在几周内膨胀到无法控制。给AI设定“笼子”（架构骨架和规范），比以往任何时候都重要。 • 从“代码审查”转向“演进式验证”：AI生成的代码可能很规整，但业务逻辑经常有幻觉。人类架构师更需要通过端到端的自动化测试、PoC原型和压测来验证系统。
四、 终极答案：AI时代的“不可替代性”
AI可以替代的是： 画图工具、文档编写员、基础脚手架搭建者、重复性代码编写者。
AI无法替代的是： 业务目标的对齐、质量属性的权衡决策、技术风险的兜底、领域复杂度的抽象设计。
这五阶段两专题，在AI时代不仅没过时，反而成了驾驭AI的最高指令集。
如果你不懂这套逻辑，你对着AI输入“给我写一个订单系统”，AI会给你一个能跑但无法维护的玩具；
如果你懂了这套逻辑，你会这样对AI输入：“基于阶段二确定的‘高性能、高可用’目标，按照阶段四的逻辑分层和防腐化要求，为我生成订单模块的DDL、接口契约和Redis分布式锁实现代码，并附带PoC压测断言脚本。”
所以，不需要怀疑：这五个阶段和两个专题，依然是软件建设的骨架。只是以前你是自己盖房子，现在你是指挥一支名为“AI”的超级施工队，而图纸和验收标准，依然掌握在你的手里。
