反思软件工程，超越Vibe Coding

关注腾讯云开发者，一手技术干货提前解锁👇

01

新范式转移---从 Vibe Coding 到 Vibe Engineering

站在"上帝视角"审视软件开发的历史演变，我们实际上是在见证 "人类意图"与"机器实现"之间鸿沟的不断缩减。 从问题空间到解决方案空间，前人尝试过声明式DSL、RAD工具，尝试过模型驱动工具。但仍局限于定制或细分于领域。

现在，结合全知全能的大模型像打开了盒子，AI 的介入让软件工程快速进入了"意图驱动"的时代。 我们正处在软件工程史上最剧烈的变革期------从"人写代码给机器看" 转向"人表达意图给AI听，AI实现给机器看"。

如果传统编程像是拿着精密蓝图、亲手切割并组装每一块木板来建造房子；那么Vibe Coding更像是对着一个神奇的建筑机器人描述你想要的"氛围"（比如"我想要一个通透、有现代感的起居室"），机器人会立刻堆砌出房屋。你不需要知道梁柱是如何受力的，只需不断告诉机器人"窗户再大一点"或"颜色再暖一点"，直到你满意为止。但一旦墙内电线走火，你可能根本不知道从哪里拆起。

Vibe Coding趋势如此之快，业界探讨热烈。它适用哪些场景？传统开发模式和开发方法会如何演进？

1.1 Vibe Coding (氛围编程)

• 起源：由 Andrej Karpathy 等人推广，指利用 LLM 的超强生成能力，通过高频 Prompt 快速得到结果的编程方式。

• 模式：单人游戏模式（Single-Player Mode）

• 策略："提示、粘贴、祈祷"

• 特征：直觉驱动，极速打样，但容易产生不可维护的代码。

• 本质：AI 时代的"极限编程"。基于直觉和高频 Prompt 快速试错。

• 结果：快速原型，但隐藏着巨大风险。

观察业界，趋势加速越来越快，代码的产生速度和成本逐步在发生巨大变化：

1.2 Spec-Driven Development (规范驱动开发)

从Vibe-Coding高速产生代码带来的眩晕之后，原型是可用的，但如何让氛围生成的代码真正支撑起大规模生产级别的应用成为挑战。 接下来，社区演化出来的Spec-Driven开发方法的策略是以规范为中心来控制交付的节奏和颗粒度。

Spec-Driven Development，规范驱动开发方法：

• 起源：开源社区出现，如Github Spec-Kit

• 模式：团队协作模式（Team-Player Mode）

• 策略："Specify，Plan，Task，Implement"

• 特征：意图优先于语法，开发人员专注于What/Why，AI负责How，规范成为结构化文档。

• 结果：可持续的开发速度和专业掌控力

有一种观点认为这将是 AI 时代的终极形态：Specification is the New Code (规范即代码)。

• 工程师的角色从"写作者"转变为"建模者"与"指挥家"。

• 核心转变：你不再教 AI "怎么写代码"，而是定义严密的业务规范 (Spec)，由 AI 代理（Agents）在规范的护栏内自主实现。

1.3 Vibe Engineering (氛围工程)

在2025年后的软件工程语境下，Vibe Engineering（氛围工程） 被视为"Vibe Coding"的专业演进版。它不仅是简单的对话式编程，而是一套将自然语言意图转化为工业级代码的结构化方法论。 **Vibe Engineering 与 Spec-Driven Development (SDD) 并不是对立的关系，而是演进与互补的关系。

简单来说，SDD 是 Vibe Engineering 的工程化底座。

• Vibe Engineering（氛围工程）： 是一种宏观思维模式。它强调开发者作为"意图导演"，利用自然语言和 AI Agent 快速探索想法、原型设计和功能迭代。

• SDD（规格驱动开发）： 是一种微观落地方法。它是为了解决 Vibe Engineering 过于随意（容易产生难以维护的"屎山"代码）而提出的结构化框架。它通过将自然语言转化为"可执行规格说明（Executable Spec）"，确保 AI 生成的代码符合架构预期。

1.3.1 Vibe Engineering起源

• 概念萌芽（2024-2025）： 最早由 **Andrej Karpathy 提出。他描述了一种"放弃对代码细节的执着，完全投入到与AI对话的'氛围'中"的新开发模式。

• 词汇爆发（2025-2026）： 由于其极高的生产力，"Vibe Coding" 被《柯林斯英语词典》评为 **2025年度词汇。

• 工程化转型（2026）： 随着企业发现纯粹的"氛围感"会导致难以维护的代码，社区开始将其规范化，形成了 **Vibe Engineering------即在保持AI高效协作的同时，加入架构守卫和规范约束。

1.3.2 Vibe Engineering的过程

Vibe Engineering 的核心在于从"随性提问"转变为意图设计。其标准工作流（Lifecycle）通常分为三个阶段：

1. 前期准备（Prework）： 并非直接写代码，而是定义系统架构、安全守卫规则（Guardrails）和交互原则。

2. 规划与意图设计（Planning）： 开发者编写高度结构化的规格说明书（Spec）或提示词，将其作为"活的代码"进行迭代。

3. 自主执行与验证（Execution）： AI Agent 根据规格说明自主生成、测试并修复代码。开发者此时的角色是系统指挥家和验证者，通过工具快速预览并持续调整意图。

1.3.3 核心理念

• AI成为团队成员：不仅仅是助手，而是拥有明确职责和能力的协作者

• 验证驱动开发：通过测试保障和自动化反馈循环系统地确保质量

• 结构化工作流程：最大限度发挥人工智能能力并同时规避其局限性的架构模式

• 持续知识捕获：通过持久记忆系统确保人工智能交互过程中上下文信息的完整性

• 人类战略指导：将人类专业知识集中应用于架构设计和关键决策点

1.3.4 闭环流程图

1. 意图结构化 (Structured Intent)：使用 Markdown 或 DSL 编写规范。

2. 规范校验 (Verification)：明确验收条件，利用 AI 审查规范中的逻辑冲突或极端情况。

3. 自动化合成 (Synthesis)：基于规范生成领域模型、接口契约及测试用例。

4. 反馈进化 (Feedback Loop)：通过测试结果和运行日志自动驱动 AI 修正。

1.3.5 对比分析表

|----|-----------------------------|-------------------------|
| 维度 | Vibe Coding | Vibe Engineering |
| 背景 | LLM 零样本代码生成能力爆发 | 意识到纯对话生成无法应对复杂逻辑 |
| 方法 | 直觉驱动：反复调整 Prompt，看代码运行的"感觉" | 规范驱动：强调系统化指令、架构约束和自动化验证 |
| 效果 | 0 到 1 极速爆发，但易产生"代码屎山" | 规模化、高质量交付，实现长期可维护性 |

AI成为队友，软件研发的工程模式引发变革，团队角色划分也出现融合。 乐观的看，AI的不确定性的将会更稳定、AI的世界知识会更丰富，AI应用的成本会降低，现有的工程方法和流程将深度重构。

上述工程方法做所的，是准备好详细需求，并分解任务；设定实施规则，并测试验证。以更有效的交付可用的软件。 这与传统软件工程的关键环节有哪些异同？这个过程有些似曾相识？ 我们有必要重新回顾软件工程的挑战，探索如何让AI放大能力，更稳定更敏捷的合作。

02

回顾反思---软件工程的本质追求

2.1 回顾软件工程

软件工程（Software Engineering）的本质是在给定资源（时间、人才、预算）的约束下，通过系统化的方法构建和维护高质量软件的学科。

如上，软件工程是应用系统化、规范化、可量化的工程方法和原则来设计、开发、测试、部署和维护高质量、高效率的软件产品，旨在解决软件开发中的复杂性，确保软件按时、按预算且满足用户需求，涵盖了软件生命周期中的所有活动，如需求分析、设计、编码、测试及项目管理等，是将工程化应用于软件开发的全过程学科。

如果说编程是一门手艺，那么软件工程就是一场大规模的协作实验。交付优质的软件，关键挑战在哪里呢？

即使流程持续加速和轮转，但仔细看其本质问题，仍然是：

• 定义"做什么"：需求工程

• 规划"怎么做"：设计与实现

• 确认"做对了"：验证与确认

显然，在AI加持的状态下，"怎么做"将逐渐被AI代理。我们将重点聚焦在定义"做什么"和确认"做对了"。

2.1.1 核心矛盾：本质与偶然

定义"做什么"是需求。 确认"做对了"是验收。 这是一个闭环。

从需求、设计实现，到验收。回到了软件工程针对的核心矛盾上。 仅从成熟业务上看，需求是稳定的，用户的业务是稳定的； 但从新型业务上看，需求是模糊到清晰的过程，业务是高速发展、扩张甚至调整的。

Fred Brooks 在《人月神话》中指出，软件开发的困难源于两类复杂性：

• 本质复杂性 (Essential Complexity)：业务逻辑本身固有的复杂性（如金融清算的幂等性、复杂的税务规则）。这部分无法消除，只能通过建模来管理。

• 偶然复杂性 (Accidental Complexity)：由工具、流程、语言或沟通障碍引发的麻烦（如繁琐的配置、不一致的 API、环境搭建）。

本质复杂性就像是你要攀登的高山本身的高度和地形，这是自然界给定的，无法改变。而偶然复杂性则像是你背负的沉重且漏水的旧水壶或不合脚的鞋子。软件工程的目标是脱掉那双不合脚的鞋（消除偶然复杂性），并学会使用绳索、挂钩和团队协作（利用模块化和抽象管理本质复杂性），从而安全、高效地登顶，而不是幻想能把大山铲平。

这里，软件工程的核心使命： 通过工具和流程演进，将"偶然复杂性"降至最低，从而让开发者能够集中精力攻克和治理"本质复杂性"。

区分必要复杂性（Essential Complexity，又称本质复杂性）与偶然复杂性（Accidental Complexity）的核心在于其来源、可消除性以及与问题领域的关系。

本质复杂性（Essential Complexity）：问题的本质

必要复杂性是指软件所要解决的问题本身所固有的、无法避免的复杂程度。

• 来源：它直接源于问题领域（Problem Domain），反映了用户需求的复杂性、业务规则、算法逻辑和功能规范。

• 特性：它是不可削减的（Irreducible）。这意味着，只要你试图解决这个特定的问题，这种复杂性就必须存在于软件的概念结构中。

• 实例：如果一个银行系统必须处理30种不同的监管法律，或者一个会计程序必须计算复杂的工资逻辑，这些需求本身就是复杂的；如果你去掉其中任何一部分来降低复杂性，你就无法再满足用户的核心需求。

偶然复杂性（Accidental Complexity）：实现的副作用

偶然复杂性是指在将抽象问题转化为运行软件的过程中，由开发者的选择、工具的使用或设计缺陷所引入的非必要困难。

• 来源：它源于实现过程中的技术细节、糟糕的设计决策、紧耦合的架构、不必要的依赖关系或过度设计。

• 特性：它在理论上是可以被避免或修复的。它是由于人类的不完美、工具的局限性或环境约束（如低级编程语言、低效的开发流程）而产生的额外负担。

• 实例：在汇编语言中手动分配内存、配置复杂的构建工具链、使用难以理解的迂回代码逻辑，这些都是偶然复杂性。当开发者切换到高级语言或采用更合理的模块化设计时，这部分复杂性可以被大幅消除。

2.1.2 如何在实际开发中进行区分？

• 目标性测试：询问"如果这个部分被简化或移除，系统的业务功能是否还会受损？"。如果受损，则该复杂性往往是本质的；如果移除它反而让系统更清晰且功能依然正确，则它是偶然的,。

• 抽象层次评估：必要复杂性通常涉及系统的概念构建（要解决什么问题），而偶然复杂性则涉及代码表达（用什么技术去解决）。

• 逻辑一致性：良好的架构设计旨在准确反映必要复杂性，同时通过成熟的设计原则（如SOLID、DRY）和质量文化来最小化偶然复杂性,。

这两者的核心区别在于其来源、可消除性及对系统的影响：

|------------------|------------------------------------|--------------------------------------------|
| 特征维度 | 本质复杂性 (Essential Complexity) | 偶然复杂性 (Accidental Complexity) |
| 来源 (Origin) | 固有的问题领域；源于业务规则、功能规范和数据逻辑。 | 实现过程中的技术细节；源于设计缺陷、工具限制、过度的工程或糟糕的代码结构。 |
| 性质 (Nature) | 不可削减的 (Irreducible)；只要问题存在，它就必须存在。 | 可避免或修复的；是由人类的不完美或环境约束引入的额外负担。 |
| 系统影响 (Impact) | 决定了系统的核心价值；处理不当会导致功能失效或不满足业务需求。 | 阻碍扩展性、增加维护难度、降低性能并增加运营成本。 |
| 典型示例 (Examples) | 银行系统需处理30种监管法律；会计程序中的复杂工资结算逻辑。 | 手动内存管理、复杂的构建工具链配置、紧耦合的架构、冗余的代码。 |
| 解决方案 (Solution) | 需求精炼、增量开发、购买方案、培养伟大设计师、领域建模。 | 遵循设计原则（SOLID/DRY）、自动化测试、重构、采用高级语言、利用现代IDE。 |
| 演进趋势 (Evolution) | 随着对领域理解的加深而增加。 | 随着技术进步（如高级语言、低代码平台）逐渐被消除或抽象掉。 |

2.2 管理复杂性

如上所述，本质复杂性（Essential Complexity）是问题领域本身固有的、不可削减的挑战，只要试图解决该特定问题，这种复杂性就必须存在于软件的概念结构中。 为了有效管理这种复杂性，核心策略在于"拥抱本质复杂性"，通过深入领域、保持专注以及调整组织来应对。

处理本质复杂性（Essential Complexity） 与处理偶然复杂性有根本的不同。 本质复杂性源于问题领域本身（如业务规则、逻辑关系、算法和功能规范），只要你试图解决这个特定的问题，这种复杂性就是不可避免的。

2.2.1 本质复杂性可以消除吗？

结论是：本质上无法完全消除，但可以被"驯服"、最小化或重新分配。

1. 不可削减性：本质复杂性是不可削减的，它是"由要解决的问题所导致的，没有任何东西可以消除它"。

2. 定义的完整性：如果一个银行系统需要处理30种监管法律，这就是其本质复杂性；如果你去掉其中任何一部分来降低复杂性，你就无法再满足用户的核心需求，或者说你是在解决一个"不同的、更简单的问题"，而不是原有的问题。

3. 水床理论：本质复杂性往往遵循"水床理论"，即如果你把系统一部分的复杂性推开，它会在另一个地方弹出来,。你无法魔术般地消除难题的内在复杂性，只能对其进行转移或重新分配。

2.2.2 处理本质复杂性

虽然无法消除，但可以通过以下策略有效管理并降低其对开发效率和系统质量的负面影响：

• 精炼需求与快速原型设计：识别核心：识别构成本质复杂性的核心元素。通过快速原型设计让用户及早测试发现真需求

• 增量开发：提倡软件应通过增量开发有机地"生长"。先构建可运行的框架，然后逐个添加功能模块。更早地发现本质困难。

• "Buy/购买"而非"Build/构建"：利用成熟方案：最彻底的方法是根本不去构建它。利用已有软件分摊成本并缩短交付时间。

• 培养与重用"顶尖设计师"：软件构建是创造性过程，顶尖设计师的产出比普通设计师的差距甚至超越一个数量级。

• 领域驱动设计与组织优化：限界上下文（Bounded Contexts）+匹配通信结构：通过划定清晰的知识和责任界限，让团队专注深耕特定领域，避免被其他领域的复杂性淹没。根据康威定律，软件结构往往反映组织结构。建立扁平、开放的团队，消除沟通障碍，有助于更好地处理概念构建中的复杂性。

注："新奇预算"的概念由 Mark Wotton 提出，其核心思想是在项目启动前，预先决定项目能够承受多少"新奇度"，并将其分配到能产生最大回报的地方。

每引入一种新技术或新模式都会带来隐性成本，包括：

• 即时成本：学习新技术所需的时间和集成该技术的精力。

• 持续成本：长期维护、调试以及应对该技术未知缺陷的开销。

2.2.3 处理偶然复杂性

软件工程对偶然复杂性的应对，是持续提升抽象层次的过程。 从命令式语言到声明式语言，都是抽象的过程：

偶然复杂性在理论上是可以避免或修复的，AI加持的开发模式彻底压缩了偶然复杂性的空间。 基于"意图理解"+"已知的解决方案模式"，大模型将AI开发模式下的目光，全部聚焦到业务本身。 Cursor自动化配置环境，构建和交付，让曾经的编程语言问题、构建环境问题、交互界面问题统统被Agent自己包了。

但，回归到问题域，本质复杂性如何有效应对或驯服？ 无论是前述的Vibe、还是Spec，目前均呈现出一些问题和风险。结合曾经的经验，我们需要探索有哪些好的办法 。

2.3 传统软件工程的应对

为应对各种复杂性和风险，经典软件工程方法经历了从"强控制"到"渐进式交付"的演变。演化过程中产生出各类开发方法轮，但核心流程基本相近。

区别于问题域的稳定性和实施方对问题的理解深刻程度，软件开发的方法论趋于"预测性"与"适应性"演化（下图：右上）。 其中，瀑布、迭代、敏捷三种方法最为典型，其它方法基本上是基于SDLC核心流程在某些方面的延伸和侧重不同。 有些是应对变化，有些是为了控制风险、成本。有些是强调自动化。

如上图，面对复杂性和变化的挑战。传统软件工程通过 建模 研究问题域，保证深入业务并理解到位，并挖掘业务本质以应对业务变化。

业务建模（Business Modeling） 是对问题域中业务过程进行抽象和建模的行为，其核心目的在于分析、改进并可能实现业务流程的自动化。 它通过创建一个复杂现实的简化视图，帮助开发者消除无关细节，聚焦于业务目标、流程、资源和规则等关键要素。

• 驱动需求规格说明与用例识别：业务建模是识别软件系统功能性需求的基础。能有效弥合沟通鸿沟，并识别用例。

• 指导软件架构设计与微服务划分：业务架构直接决定了软件架构的稳定性和可扩展性。

• 显性化管理业务规则：有效管理业务规则（Business Rules）以提高灵活性；通过建模将业务规则（如计算逻辑、访问控制、约束条件）从基础架构中分离出来。

• 验证系统价值与目标达成：业务模型提供了一个验证软件"是否做对了"的基准。通过将业务的高层目标分解为可衡量的子目标，确保最终交付的软件真正解决了业务痛点，而非仅仅实现了技术功能。

• 跨职能协作与知识管理：业务建模需要全团队的共同参与。模型作为一种战略资产，捕获并保存了企业的业务知识，这在人员流转或系统重构（如遗留系统现代化）时尤为重要。

因此，广义的业务建模本身就是在定义业务是什么（分析），如何做（设计）的基础，所以本质在回应"做什么"和"怎么做"。 主流的建模方法论更是提供了问题分解、职责分配、设计细化的模式化方法。

面对需求，输出分析模型（1）；面向实现，定义设计模型（2）； 针对验收，做足测试验证（5）；应对变化，记录原因并管理变更（6）；

总之，应对复杂性需要综合的工程纪律。 因为专业的软件开发是一种系统性的方法，需要综合考虑成本、进度、可信性问题，以及客户和生产者的需求。包括：

1. 需求工程：理解和定义"为什么"和"是什么"

2. 业务和系统的建模：创建清晰的抽象，以沟通和分析

3. 架构设计与精确实现：做出影响深远的结构性决策，将设计转化为健壮的代码

4. 测试验证：建立对系统质量的信心

5. 工程管理：引导整个过程，管理风险、人员和进度

6. 持续演进：确保系统在变化的世界中持续创造价值

2.4 回到Spec/Specification

在 AI 驱动的开发模式（如 Vibe Coding 或 Vibe Engineering）中，开发者往往通过口头描述、自然语言提示（Prompt）和迭代反馈来快速构建应用。这种模式极大地缩短了"想法"到"运行代码"的距离。

然而，作为软件工程专家和架构师，我们需要清醒地认识到：AI 加速的是"实现"，而非"思考"。 即使在 Vibe Coding 时代，业务建模不仅没有过时，反而成为了区分"玩具应用"与"企业级系统"的核心分水岭。

我们思考传统的开发方法，需求工程、建模、测试验证正是AI协同开发的关键。 Spec规范的目标，是期望清晰的 定义"做什么" 和 确认"做对了"。

在传统研发中，建模是为了沟通和文档化；在 AI 时代，建模的价值转向了约束与对齐。

从"模糊意图"到"精确提示词"的语义桥梁 ：Vibe Coding 的核心挑战是自然语言的歧义性。业务建模（如领域驱动设计 DDD 中的通用语言）提供了底层语义骨架。没有模型（完整的意图对齐）的 Vibe Coding 是在"碰运气"，而有模型的开发是基于确定的本体论进行生成。

管理 AI 生成的"架构熵" ：AI 倾向于给出局部最优解，如果不受模型约束，多次迭代后的代码库会演变成"大泥潭"。业务模型为 AI 划定了边界上下文（Bounded Context），确保 AI 生成的代码遵循一致的逻辑实体和状态流转。

解决 AI 的"上下文窗口"局限 ：随着项目复杂度增加，AI 无法一次性理解所有代码。业务模型（如类图、序列图、状态机）是极佳的知识压缩手段，便于阅读和规范。将模型作为 Context 输入给 AI，比投喂万行乱序代码更高效。

对比业务建模 vs. Spec (规格说明) vs. Vibe氛围编程，这三者在当前扮演着不同的角色，我们可以通过下表进行对比：

|-------------|--------------------------|---------------------|---------------------------|
| 维度 | 业务建模 (Business Modeling) | 规格说明 (Spec/PRD) | AI 工程方法 (Vibe/Prompt Eng) |
| 关注点 | 本质复杂性（事物的关系与逻辑） | 表现复杂性（功能点、UI、流程） | 生产效能（生成的准确性与速度） |
| 稳定性 | 最高，业务本质很少随技术变迁 | 中等，随需求变更而变 | 最低，随模型版本迭代而变 |
| 在 AI 流程中的位置 | 内核：决定了 AI 理解业务的深度 | 输入：作为 RAG 或提示词的原始素材 | 手段：将输入转化为产出的技术路径 |
| 失败后果 | 逻辑漏洞、系统无法扩展 | 功能缺失、用户体验差 | 幻觉、代码坏味道、难以维护 |

建模 vs. Spec：Spec 告诉 AI "要做什么"（What），而有了建模会告诉 AI "这是什么"（What it is）。在 Vibe Coding 中，Spec 正在被 AI 强大的理解能力弱化，但建模提供的逻辑一致性无法被取代。

2.5 AI 时代建模的实践

在 Vibe Engineering 的背景下，建模的形式正在发生变化：

• 表现形式转向"轻量化"：传统建模方法需要专业工具，但现在倾向于使用 Markdown 格式的结构化文本描述。

• 出现模型驱动的 Prompting (Model-Driven Prompting)：未来不仅是写 Prompt，而是先构建元模型 (Meta-Model)。

设想： 不要对 AI 说："帮我写个电商后台。" 而是说："这是我的领域模型：包含 Aggregate Root (Order), Entity (LineItem), Value Object (Address)。请基于此模型生成对应的 Repository 和 API。"

• 实时建模与动态演进：在 Vibe Coding 中，建模不再是开发前的静态阶段，而是伴随 AI 生成后的逆向整理。架构师的角色变成了：观察 AI 生成的逻辑 -> 提炼业务模型 -> 修正并固化模型 -> 反哺 AI 以进行后续开发。

示例：业务模型：分销佣金内核 (Commission Kernel)1. **核心实体 (Entities)**:   - Account: 账户（余额、冻结资金）   - Order: 订单（基础金额、状态）   - Relation: 拓扑关系（上级 ID、等级路径）2. **值对象 (Value Objects)**:   - Strategy: 佣金策略（比例、固定值、触发条件）3. **领域事件 (Events)**:   - OrderPaid -> 锁定预估佣金   - OrderCompleted -> 佣金转入余额   - OrderRefunded -> 佣金冲抵/回收4. **不变性约束 (Invariants)**:   - 任何单笔订单的总分发佣金不得超过订单利润的 40%。

示例：将上述模型作为 **System Prompt** 或 **Context File** 喂给 AI，并给出如下指令：
"请基于上述 `Commission Kernel` 模型，使用 C++ 实现一个佣金计算服务。 
**要求**：
1. 代码必须严格遵循实体定义的边界，不允许在 Order 实体中直接操作 Account 余额。2. 实现一个 `StrategyFactory` 来处理不同层级的计算。3. 生成对应的单元测试，重点测试 '不变性约束' 是否被违反。"

通过小的尝试，我们可以看到建模在 AI 开发中发生的异同点：

异：从"手写逻辑"变为"定义契约" 在传统流程中，建模后我们要手写全部代码。在 Vibe 模式下，模型变成了"契约"。AI 就像一个极速的"契约履行者"，它负责填充 StrategyFactory 的繁琐实现，而你只需盯住模型边界（Invariant）是否被突破。

同：本质复杂性依然需要"降维" 无论 AI 多强大，分销系统中的"退款重算"和"层级裂变"逻辑依然复杂。通过建模，我们将复杂的现实问题简化为 Entity + Event + Invariant。

如何判断模型是否有效？ 在 AI 辅助开发环境下，一个好的业务模型应当具备 "可解释性" 和 "可测试性"：

• 模型解释性：如果 AI 能够根据你的模型描述，准确地复述出业务边界，说明建模成功。

• 模型可测试性：利用 AI 快速生成基于模型的边缘 case 测试。如果 AI 能自动发现你的模型在"并发退款"场景下有逻辑漏洞，说明模型正在发挥研究本质复杂性的作用。

对于架构师而言，AI 屏蔽了繁琐的语法实现，这反而要求我们必须具备更强的抽象能力。 当 AI 可以处理所有代码实现时，你唯一的护城河就是对业务本质复杂性的洞察与建模能力。

03

破解失控---AI 协同开发实践

当我们将"上帝视角"聚焦于从问题域 (Problem Space) 到 解决方案域 (Solution Space) 的映射过程时，AI 的介入不仅是工具的改良，更是软件工程底层逻辑的重构。

我们要探讨的是：在 AI 能够以前所未有的速度生成代码时，我们如何防止"偶然复杂性"的失控，并精准捕捉"本质复杂性"。

3.1 问题域：本质复杂性与 AI 的角色

从本质复杂性 (Essential Complexity) 和偶然复杂性 (Accidental Complexity)来看

3.1.1 本质复杂性的"提取"与"澄清"

本质复杂性源于业务逻辑本身（例如：金融支付的对账规则、物流调度的高并发约束）。

• 传统痛点： 需求文档与真实意图之间存在巨大的语义鸿沟。

• AI 时代的变化： AI Agent (如 Claude Code) 扮演了"高阶咨询顾问"的角色。它不只是被动接受指令，而是通过上下文 (Context Probing) 主动询问边界条件。

• 优势： 缩短了从"模糊想法"到"结构化定义"的距离。AI 的理解能力让它能识别出业务规则中的逻辑矛盾。

3.1.2 偶然复杂性的"坍缩"

偶然复杂性源于技术实现（如：环境配置、样板式代码、API 粘合、版本兼容性）。

• 现状： Vibe Coding 和 Cursor 类的工具正在让偶然复杂性趋于零。

• 变化： 我们不再需要精通每一种库的语法，AI 填补了"实现细节"的坑。开发者从"人机翻译"转变为"意图策划"。

3.2 映射过程：从问题分解到解空间的重构

在将问题分解并映射到解空间的过程中，AI 正在重塑经典的工程方法论：

3.2.1 分解逻辑的升级：从"层级拆解"到"意图分解"

• 经典模式 (Waterfall/Agile)： 靠人脑进行模块化（WBS），层层向下。

• AI 模式： 采用分层推理 (Hierarchical Reasoning)。人给出全局 Vibe（如：我想要一个能处理千万级流量的任务系统），AI 辅助进行功能分解，并实时沟通问题分解策略，并生成模块化的处理目标。

• 最佳实践： 结合 DDD (领域驱动设计)。利用 AI 快速识别限界上下文 (Bounded Context)，将大问题拆解为 AI 可以闭环处理的微小意图。

支付系统简单示例：

|--------|--------------------------|--------------------------|
| 维度 | 传统层级拆解 (WBS/SOA) | AI 时代意图解耦 (Intent-Based) |
| 拆解逻辑 | 按技术层：UI层 -> 业务层 -> 数据层 | 按业务意图：支付意图、账务意图、清算意图 |
| 沟通方式 | 接口文档（RPC/Restful） | 语义规格 (Spec)+ 领域契约 |
| AI 介入点 | 辅助写单体函数 | 独立完成整个意图模块的闭环实现 |
| 复杂度管理 | 靠人的经验防止代码腐化 | 靠Invariant（不变性）约束 AI 的行为 |

3.2.2 映射路径的缩短：Spec 作为"活代码"

• 过去： 问题 -> 需求文档 -> 技术方案 -> 代码。

• 现在（Spec-Driven）： 问题 -> 语义规格 (Spec) -> AI 实时实现。

• 核心变化： 映射不再是单向的、长周期的，而是实时反馈的闭环。Spec 不再是陈旧的文档，而是驱动 AI 生成和校验的指令集。

支付系统简单示例：

### 支付交易域核心意图： 处理用户"想付钱"的动作，编排支付路径。
**Spec 约束：**幂等性： 无论调用多少次，同一 OutTradeNo 只能产生一笔成功的支付。状态机： INIT -> PROCESSING -> SUCCESS / FAIL（严禁逆向流转）。
**AI 任务：** 生成路由逻辑（如：余额不足自动切换到银行卡）。
### 账务核心域**核心意图：** 记录资金变动的绝对真相。这是支付系统的"本质复杂性"所在。
**Spec 约束：**    会计恒等式不变性： 任何交易必须满足复式记账法：∑Credits=∑Debits账户余额校验： CurrentBalance=InitialBalance+∑Transactions    
**AI 任务：** 实现严谨的复式记账逻辑，确保并发下的数据强一致性。

3.3 再看 Vibe Coding 到 Vibe Engineering 的升级

"Vibe Coding"虽然极速，但若没有"Engineering"的约束，最终会演变成难以维护的"代码泥潭"。 我们需要超越它，进入 意图指引+规范控制 的融合阶段。

3.3.1 方法论的深度融合

|----|------------------------------|------------------------------------------------------------|
| 阶段 | 传统方法论最佳实践 | AI 时代的演进与优势 |
| 分析 | DDD 领域建模、Ubiquitous Language | LLM 作为语言共识器：利用 AI 维护统一语言，自动检查命名是否符合业务语境。 |
| 设计 | 设计模式、SOLID 原则 | 模式注入：在 Spec 中显式规定"使用策略模式实现"，AI 会瞬间完成代码骨架。 |
| 实现 | TDD (测试驱动开发) | Test-Driven Prompting：先描述期望的 Test Case，让 AI 填充实现，极速缩短反馈路径。 |
| 测试 | 手动测试用例、自动化脚本 | Self-Correction 闭环：AI 自行运行代码、发现错误、修复错误，形成无人值守的修复流。 |

3.3.2 在AI协同下高质量交付的支柱

强化"问题域"的建模能力

AI 虽然能写代码，但它无法替你思考"为什么要写这个软件"。

开发者应学习和掌握业务分析设计方法。区分问题域和解决方案域。为问题划清范围边界。

即便 AI 辅助，也要把系统拆解成高内聚、低耦合的模块。给 AI 的 Context 越清晰，生成的质量越高。

建立规范化意识

不要只写 Prompt，要逐步建立 Spec 文件（如 .cursorrules, mdc 或 Markdown 文档）。

它规定了系统的架构准则、代码风格、数据结构规范。这是防止 AI "放飞自我"的缰绳。

构建闭环自动化验证能力

在 AI 时代，代码量产是极廉价的，验证代码的正确性才是最高成本。

策略：构建自动化的"意图校验器"。在让 AI 写功能代码前，先让它根据需求生成全覆盖的测试用例。

只有通过了测试的代码，才是真正的"交付"。只有通过测试的"Vibe"才被允许合入主干。

持续重构，不断改进

AI 极其擅长重构。 策略： 利用 AI 每周对现有系统进行一次"架构审计"。它能以人类无法比拟的速度识别代码中的异味（Code Smell），并根据最新的 Spec 进行全量重构，保持系统"永远年轻"。

3.4 超越Vibe Coding---实践可控的AI协同开发

现代软件工程以优化学习、管理复杂性为主旨。这也是现代软件工程师的两大核心修炼：

• 精通学习：软件开发本质上是探索和发现的过程。为了高效学习，我们必须采用人类最强大的学习工具：科学方法。

• • 将开发过程视为一系列小型、低风险的科学实验。以最快速度的验证和证伪我们的想法。
  • • 迭代：允许错误修正，逐步逼近目标。
  • • 反馈：快速、高质量地验证我们的行为和产出。
  • • 增量：逐步构建和交付价值，而非一次性完成。
  • • 实验：将"猜测"转化为可验证的"假设"。
  • • 经验主义：决策基于真实世界的证据，而非先验推理。

• 精通复杂度管理：我们构建的系统极其复杂。有效管理复杂度是交付高质量、可持续软件的前提。

• • "编程的艺术就是组织复杂度的艺术"--Edsger Dijkstra
  • • 模块化：将系统分解为独立、可替换的组件。
  • • 高内聚：确保模块功能专注且相关。
  • • 关注点分离：每个部分只解决一个问题。
  • • 信息隐藏与抽象：隐藏实现细节，暴露稳定接口。
  • • 松耦合：最小化模块间的依赖。

结合现代软件工程的思想，AI时代的工程框架建议的核心原则提炼如下：

3.4.1 加速学习，提升个人能力

• 在做中学：不要依赖AI，我们不仅是在打造软件，还在打造个人能力

• 明确边界：人是决策者，AI负责执行，不能把思考交给AI！

• 控制节奏：精细的规划，有意识的迭代，保持理解以有力的掌控。

3.4.2 科学规划，系统化执行

把AI做为团队成员（或一批成员），在 AI 写下代码前，你做人类架构师如有效完成以下工作，将有助于你按规划实施。注意，这些过程可以与你的AI队友一起探索、澄清及细化。

1、确立愿景：定义主项目规范和技术上下文。就像让一位新人快速的熟悉环境，找对方向。

• 将模糊的想法转化为完整的结构化主项目规范，闸明问题、用户、功能、范围和工作流程

• 明确说明正在解决的问题、哪些用户会遇到这个问题，以及你的软件提供的核心价值。

• 明确问题的范围边界，并提炼问题的基本解决方案和业务流程，确认哪些是必备的，哪些是可选的。

• 说明技术背景信息，它会如何运行，用户如何使用，会连接哪些系统？

2、功能识别：将需求拆解为原子化的功能清单。比如用例清单就是一种方法。

• 从主项目规范中，识别和提取功能单元，并分级和分类，并评估复杂度。

• 确认每个功能的边界，需要哪些基础能力

• 确认每个功能如何处理输入，需要哪些处理过程，输出结果是什么

• 对于交叉横切的需求，可以提炼出来：安全、日志、配置等等

3、规范开发：为每个功能编写原子规范（Spec：用户故事 + 技术蓝图）。

• 与Agent探索每个功能的价值、确认契约（输入、逻辑、输出）

• 定义每个功能契约的验证标准，明确需要验证的情况（正常、异常，边界，安全等）

• 定义测试验证方法，将每个场景转化为结构化验证逻辑（如触发条件、预期结果）

• 验证功能的原子性，不断拆解以最小化精确定义和验证它。同时识别功能之间的依赖关系 。

4、依赖分析：通过依赖矩阵消除循环依赖，确定开发顺序。

• 建立功能视图，梳理功能之间的依赖关系，找出公共部分并明确统一规则。

• 消除功能之间的循环依赖。

5、实施计划：序列化功能开发，确立各阶段完成准则。

• 组织好各功能单元的实现顺序，找出关键路径；

• 分层分秩序排序，形成实施路线图；

• 识别并行开发机会，将底层叶子功能独立实现，定义阶段完成标准；

• 按阶段验证情况，分阶段推进。

• 验证一组功能的集成效果，做好版本管理和变更控制

3.4.3 实施循环与错误反馈

在实施阶段，AI Agent也需要像人一样需要看、听、读。 如果为AI装备多感观的"感知能力"将有效加速循环，为Agent建立完整的循环：编码、执行、感知

看：视觉感知，比如系统日志等

用：触觉感知，比如交互响应等

• 上下文装配：精准调配 Spec 和依赖代码，避免无关干扰。

• 多维反馈：

• • UI 感知：通过浏览器工具/MCP获取截图校验样式与布局（如：Playwright）。
  • 系统感知：监控数据库状态、API 响应与日志流。
  • 日志与错误：捕获流式日志和堆栈信息。
  • API 响应：验证契约一致性。
  • 分析反馈：AI 自主分析错误并依据 Spec 进行自我纠错。

仔细思考，对比我们人类多角色协作的工程项目，哪些是必须由人掌握的，哪些可以交给Agent执行。 相关流程有哪些可以细化的，可以进一步深入提炼。找到你最适合的方法。

04

总结---AI 时代软件工程师的思考

在这一场AI带来的生产力革命中，我们应当坚守以下原则，这也是现代软件工程师需要的思维模式：

• 怀疑+实证：以学习为中心，将每一次编码、每一次发布都视为学习和验证假设的机会。

• 拥抱不确定性：承认不足并有信心的在探索中找到答案。

• 务实：专注于寻找高效、经济的解决方案，而非追求理论上的完美或技术上的炫耀。

在这场从 "写作者"到"指挥家" 的转变中，总结以下核心思路：

1：聚焦本质复杂性，外包偶然复杂性

将样板代码、配置、测试补全交给 AI。人类的智慧应当保留在对业务领域逻辑死角的建模和系统边界的划定上。

2：掌握业务灵魂（领域模型），以规范（Spec）为核心资产

代码在 AI 时代会成为易耗品。结构化的业务模型与规范是需要精心管理。

如果规范定义正确，你可以随时要求 AI 用 Go 替换当前的 Java。高质量的结构化规范才是你真正的资产。

3：将AI当成队友，引导它，帮助它，管理它

不要只看 AI 生成的代码。要通过自动化测试、UI 截图、性能监控等"感官"数据，建立端到端的验证闭环，确保系统在工程纪律下演进。

软件工程并没有消失，它只是变得更加纯粹。 我们正在步入与AI合作的时代，需要我们细心引导，建立共知共识，协同步入由人定义意图、由 AI 完美执行的"氛围工程"新纪元。

---

参考:

1. Vibe Coding：https://en.wikipedia.org/wiki/Vibe_coding

2. Tomasz Lelek, Artur Skowroński：Vibe Engineering

3. David Farley：Modern Software Engineering

4. Revenge of the junior developer | Sourcegraph Blog：https://sourcegraph.com/blog/revenge-of-the-junior-developer

5. Vibe coding vs traditional programming - Graphite：https://graphite.com/guides/vibe-coding-vs-traditional-programming

6. Evans, Eric：Domain-driven design_ tackling complexity in the heart of software

7. Frederick P. Brooks：Mythical Man-Month, The Essays on Software Engineering

注：图均是结合Google NotebookLM聊出来的。

-End-

原创作者｜stanleyluo

感谢你读到这里，不如关注一下？👇

📢📢来抢开发者限席名额！点击下方图片直达👇

你对本文内容有哪些看法？同意、反对、困惑的地方是？欢迎留言，我们将邀请作者针对性回复你的评论，欢迎评论留言补充。我们将选取1则优质的评论，送出腾讯云定制文件袋套装1个（见下图）。1月28日中午12点开奖。