AI时代的软件设计:从代码至上到意图驱动

软件工程师恐怕做梦也没想到，AI 编码工具会如此迅速地改变他们的工作方式。当 AI 开始编写代码时，许多人担心自己会被取代。但真正的故事远比这复杂——AI 时代的软件开发不是要淘汰工程师，而是要求他们掌握一种全新的工作范式。

又一次转折

AI 编程的出现和迅速普及，不禁使我想起了上世纪80年代高级程序设计语言替代汇编语言的情形。那时候高级成设计语言在工业界还没有普及，大部分时间程序是机器指令，或者汇编语言编写的。甚至IBM 360大型计算机都是使用汇编语言编写银行交易软件（COBOL 语言在我国并不普及）。后来伴随着PC 计算机的普及，高级程序设计语言开始流行了，先是BASIC ，后来是Pascal，C语言等等。但是那时候人们同样普遍地担忧高级程序设计语言效率不高，会不会不可靠，代码不确定？特别是系统软件，底层驱动和嵌入式程序在很长一段时间还使用汇编语言编写。或者混合编写，部分时间敏感的代码使用汇编完成。直到90年代，高级语言全面替代了汇编，C 语言能编写出完整的Linux OS！

AI 编程的出现，他将取代人类编程，类似于高级语言替代汇编语言。只是人类与计算机交互的语言的升级，这一次直接使用自然语言代替了程序设计语言。当年也有担心，彷徨和沮丧，但是未来一片光明。

权力逆转

几十年来，代码一直是软件开发的绝对核心。我们编写需求文档、设计文档、架构图，但这些最终都服务于代码本身。代码是唯一的真理来源，其他一切都只是辅助材料。一旦开始编码，那些精心准备的文档往往就被束之高阁，随着代码的演进，文档很少能跟上步伐。

但 AI 时代正在颠覆这一切。在规范驱动开发（Spec-Driven Development, SDD）的新范式中，权力结构发生了根本性逆转：规范不再服务于代码，而是代码服务于规范。产品需求文档不再只是实现指南，而是生成实现的源泉。技术方案不再只是指导编码的文档，而是生成代码的精确定义。

这种转变之所以成为可能，是因为 AI 能够理解复杂的自然语言规范，并将其转化为可运行的代码。当规范可以直接生成代码时，规范与实现之间的鸿沟就消失了——只剩下转换。规范成为唯一的真理来源，代码则成为规范在特定技术栈中的表达。

“氛围编码”的陷阱

许多开发者初次接触 AI 编码工具时，会采用一种被称为“氛围编码”(Vibe Coding）的方式——给 AI 一个大致方向，让它自行实现解决方案。这种方法对简单应用确实有效：一个贪吃蛇游戏、一个计算器、一个待办事项列表。

但当面对真正的企业级应用时，问题就暴露了。有团队尝试用 AI 实现 AWS Cognito 安全功能，结果花了 8 小时、200 多美元，尝试了各种提示词，最终仍然一无所获。为什么？因为 AI 工具不擅长读心术，它们只能在明确告知的范围内运行。

适用于简单演示的方法无法扩展到具有多个聚合、复杂业务规则和集成组件的企业应用。没有清晰的规范，AI 只能根据你的意图做出假设，而这些假设往往是错误的。

除了编码，一切留下

有人说，AI 将取代程序员，人人写软件的时代已经到来，甚至叫嚣不要再报考计算机科学专业，以后找不到工作。大多数讲这些话的人都不是计算机领域的专业人员。其实软件开发的过程包括了规划，需求分析，需求定义，设计，开发，测试，部署和维护。这个过程在软件工程中被称为软件生命周期。Coding 只是其中的一部分而已。

几十年来，计算机科学家除了开发出了各种计算机语言以外，还发明了大量软件技术和软件设计方法论，例如：面向对象程序设计，敏捷开发，单一关注点，容器，集群等等，包括AI大语言模型。

当我们进入AI 编程时代，只是不在需要使用某种高级程序设计语言去编写代码。其它都还在。就好吧当年使用高级程序设计语言代替可汇编语言时，我们仍然要写设计方案，画框图，划分子程序，定义接口参数一样。

过去的技术，经验，方法大多数仍然需要，甚至更加需要创新和提升专业水准。AI写程序，与人类写代码是一样的，你需要准确，详细的设计文档。人类程序员编程过程中，文档只是一个指导书，程序员头脑中包含了各种方案论证会的约定，概念，风格的信息，熟悉公司软件架构，UI风格。当你请一个陌生的AI来编代码时，你需要交代的事情更多。

回归“瀑布”，但速度提升百倍

一个反直觉的发现是：AI 工具不是降低了对详尽需求的需求，而是增强了这种需求。当开发团队意识到这一点后，他们做出了一个大胆的决定——采用看似“过时”的瀑布式开发流程，编写详细的文档：

• 使用领域驱动设计（DDD）原则的领域描述

• 清晰分离关注点的系统架构

• 包含用户旅程的功能规格

• 前后端之间的 API 契约

但关键区别在于：从需求文档到最终交付，整个周期现在只需 15 分钟到 1 小时。这不是“尼亚加拉大瀑布”，而是花园里的快速瀑布景观。

更重要的是，这些规范不是孤立编写的，而是与 AI 协同制定。AI 审阅、完善并添加细节，但人类始终参与核实。这种协作让 AI 从生成互不关联的代码片段，转变为生成内聚性强、运行良好且能完美集成的功能。

领域驱动设计的复兴

谁能想到，2003 年由 Eric Evans 提出的领域驱动设计（DDD）会在 AI 时代再次成为前沿技术？DDD 的核心原则——限界上下文、聚合、通用语言——似乎就是为帮助 AI 理解复杂领域而设计的。

领域是需要通过软件解决的问题空间。在 DDD 中，我们不是直接跳入代码，而是深入理解领域本身。就像造船厂的工人专注于船的特定区域，软件开发也需要将复杂领域划分为更小、更独立的模型。

DDD 的几个核心原则在 AI 时代显得尤为重要：

1. 通用语言：创建一种所有人（技术人员、业务人员、AI）都使用的共同语言。这确保每个人对领域概念有清晰一致的理解。

2. 限界上下文：将应用程序划分为不同的部分，每个部分都有其特定的规则和职责。这种清晰的边界让 AI 能够更好地理解系统结构。

3. 聚合：将相关的实体和值对象组合在一起，作为一个整体协同工作。聚合是衡量系统复杂性的良好指标。

通过创建清晰的边界上下文、聚合和命名规则，我们建立了一套 AI 可以应用的共享词汇表。使用清晰一致的命名规则，有助于大语言模型（LLM）始终如一地使用这些名称。

构建 AI 友好的开发框架

成功的 AI 辅助开发需要几个关键要素：

1. 中央上下文文件：创建一个 AI 每次启动时都会读取的文件，包含项目概述、核心领域概念、开发要求和文档参考。这个文件充当 AI 的“最小大脑”。

2. 清晰的架构：采用整洁架构（Clean Architecture）或洋葱架构，通过清晰分离关注点和依赖关系规则，为 AI 理解和维护奠定基础。所有组件采用一致的命名方式（如 BudgetService、TransactionController），这种一致性对指导 AI 找到正确的类至关重要。

3. AI 友好的技术选择：选择流行的、被广泛采用的技术栈。AI 的训练数据基于互联网上现有的代码库，因此遵循最常见的实践和流行技术，AI 的表现会更好。TypeScript 通常比 Java 效果好，React 比 Vue 生成的代码质量更高，这很可能是因为它们在开源项目中被更广泛采用。

从代码至上到意图驱动

我们正在经历一场根本性的转变：从“代码是真理之源”到“意图是真理之源”。在 AI 时代，规范成为真理之源，决定最终构建什么。这不是因为文档变得更重要，而是因为 AI 使规范可执行。

在这个新世界里：

• 软件维护意味着规范的不断演进

• 调试意味着修复生成错误代码的规范和实现方案

• 重构意味着为清晰起见而进行结构重组

• 添加功能意味着重新审视规范并创建新的实现方案

整个开发工作流程围绕规范重组，规范是核心真理来源，实现方案和代码则是不断重新生成的输出。开发团队的意图通过自然语言、设计资产、核心原则和其他指导原则来表达。开发的通用语言提升到了更高层次，而代码则成为最终的实现手段。

质量保证的新范式

当规范驱动实现时，测试也随之改变。测试用例不是在代码编写之后才编写，而是规范的一部分，规范同时生成实现和测试用例。这将开发和测试融合在一起。

生产指标和事件不仅触发紧急修复，还会更新下一轮迭代的规范。性能瓶颈转化为新的非功能性需求，安全漏洞成为影响所有后续迭代的约束条件。这种在规范、实现和实际运行之间不断迭代的动态过程，正是真正理解产生的地方。

开发者的新角色

AI 时代的软件工程师不会被淘汰，但他们的角色正在转变。他们不再是代码的“手工艺人”，而是成为：

• 领域专家：深入理解业务领域，能够准确描述问题空间

• 架构师：设计清晰的系统结构，定义边界和约束

• 规范设计师：编写精确、完整、明确的规范

• 质量把关者：审查 AI 生成的代码，确保符合业务逻辑

• 创新者：通过快速实验探索不同的实现方案

开发团队注重创造力、实验精神和批判性思维。由于规范可以快速生成多个实现方案，团队可以轻松探索不同的技术选择，比较性能、可维护性、用户体验和成本。

为什么是现在

三大趋势使得 SDD 不仅成为可能，而且势在必行：

1. AI 能力的突破：AI 已经能够可靠地利用自然语言规范生成可运行的代码。这不是要取代开发者，而是通过自动化规范到实现的机械转换来提升他们的效率。

2. 软件复杂性的增长：现代系统集成了数十种服务、框架和依赖项。通过手动流程保持所有组件与最初意图一致变得越来越困难。SDD 通过规范驱动的生成提供系统化的一致性。

3. 变化速度的加快：需求的变化速度远超以往。转型不再是例外，而是必然。当规范驱动实现时，需求调整不再是手动重写，而是系统化的重新生成。

实践经历

我已经使用Cursor 编写代码几个月了，其中经历了从将信将疑，到意外惊喜，再到回归专业的过程。我编写的Spec 还是停留在产品需求文档的阶段（PRD）。我的开发过程基本分为几步步

• 写产品需要

包括项目的名称，需求，技术栈等内容，如果是模仿别人的项目，直接写上模仿项目的文档网站地址

• 由Google Gemini 生成PRD

• 由Cursor 生成代码

• 通过对话指导Cursor修改

• 扩展功能重复编写额外的PRD

在项目的目录中添加了design 文件夹，其中包含了所有的PRD，PRD 使用markdowm 格式。Cursor 特别指出，使用markdown 这样的结构化文本，它理解的更准确。

这套方法对于小型的前后端应用而言，还是十分有效个。目前存在的问题还是需求文档不够完善和细致。以前没有养成好习惯，程序都是想到哪里写到哪。甚至设计文件都是代码写完之后再编写的。现在需要学习专业的设计文档的编写。以前看敏捷设计，领域设计，模型设计都觉得的码农的“心灵鸡汤”，现在成为我们的行动指南了。

现在编写规范的时间超过了AI Coding 的时间，往往是写了一个下午的PRD，晚上AI 30分钟就搞定了。

下一步，尝试

• 要进一步提升编写规范的能力。

• 数据模型，API 的格式化描述。

• 尝试Github 代码托管，版本控制，回退。

• 开发多个微服务通过消息队列协作

• AI辅助调试，团队协作

当团队协作时，API，消息格式，数据模块都必须预先设计，生成Spec文档

结语

AI 时代的软件设计不是关于更聪明的提示词技巧，而是关于回归软件工程的基本原则——清晰的需求、良好的架构、明确的规范。讽刺的是，最先进的 AI 工具让我们重新发现了那些“过时”的软件工程实践的价值。

领域驱动设计、整洁架构、详细的需求文档——这些 2000 年代初期的实践在 AI 时代焕发新生。它们不再是负担，而是释放 AI 全部潜力的关键。

软件工程师不必担心被 AI 取代。相反，他们应该拥抱这个机会，从编写代码的“手工艺人”转变为设计系统的“建筑师”。在这个新时代，最有价值的技能不是编写代码的速度，而是理解领域、设计架构、编写清晰规范的能力。

代码至上的时代已经结束。意图驱动的时代才刚刚开始。