用 AI 实现规格驱动开发：一种新方法及其对历史的回望

跳转到内容

软件开发界正热议 AI 辅助编码。Claude Code、Windsurf 和 JetBrains Junie 等工具承诺让我们更高效。但大多数方法都聚焦于更快地生成代码——它们仍然是以代码为中心。

如果我们换一种思路呢？如果我们把需求作为唯一事实来源，让 AI 在下游完成工作，由我们来审查呢？

在构建业务应用多年之后，我开始开发一套方法论，将统一软件过程（RUP）的理念与现代 AI 工具相结合。结果非常显著：更好的业务对齐、可维护的代码，以及从业务需求到实现的完整可追溯性。

以代码为中心开发的问题

传统开发遵循这样的模式：

编写需求文档
编写应用程序代码
添加测试（也许）
更新文档（很少）

问题在哪？代码成了唯一事实来源。需求文档会过时。当出现缺陷或功能需要变更时，我们要翻遍代码才能理解系统原本应该做什么。如果几年后必须对应用进行现代化改造，情况会更糟。

AI 编码工具通过更快地生成代码让情况更糟。我们正加速走向一直以来都存在的维护问题。

以需求为唯一事实来源

我的方法将其颠倒过来。需求始终处于中心，其他一切都由需求衍生：

完整工作流

业务需求目录（手动，与业务干系人共同完成）
业务用例图（AI 生成，然后与业务干系人共同审查）
实体模型（AI 从需求目录推导，由业务方审查）
系统用例图（AI 生成，由开发者和/或业务方修订）
系统用例规格说明（AI 生成，详细的 Markdown，由开发者和/或业务方修订）
应用程序代码（AI 生成，由开发者审查）

关键：每一步都由业务团队审查和修订。他们不仅验证业务制品，还验证实体模型和系统用例。这能在领域建模错误变成昂贵的代码问题之前将其捕获。

一切皆代码，一切皆版本化

所有规格说明都用 Markdown 编写，并与应用程序代码一起存储在 Git 中。用例图以 PlantUML 源代码形式生成。这为我们带来：

可视化差异：准确看到图中发生了什么变化
完整审计追踪：追踪从需求到代码的每一次变更
版本控制：规格说明与代码一起分支管理
协作编辑：业务干系人可以请求具体的变更

AI 作为一致性引擎

当需求变更时，Claude Code 等 AI 工具会自动更新所有下游制品：

更新受影响的用例图
更新实体模型
修改系统规格说明
更新应用程序代码
维护可追溯性链接

无需手动同步。没有过时的文档。无需猜测系统应该做什么。

结构：独立史诗

业务应用很复杂，但这并不意味着它们必须变得繁杂。我把一切组织成独立的史诗：

事件管理：UC-EVENT-001、UC-EVENT-002 等
用户管理：UC-USER-001、UC-USER-002 等
组织管理：UC-ORG-001、UC-ORG-002 等

没有跨史诗依赖。每个史诗都是一个有界上下文，可以独立开发、测试和部署。这既简化了 AI 生成过程，也简化了整体系统架构。

一个真实示例：系统用例规范

以下是系统用例在实践中的样子：

# Use Case: Create Events

**Use Case ID:** UC-EVENT-001  
**Primary Actor:** Manager  
**Goal:** Allow managers to create new events for their organization

## Main Success Scenario
1. Manager navigates to "Events" section
2. Manager clicks "Create New Event" button
3. System displays event creation form
...

## Business Rules
### BR-EVENT-001: Event Date Validation
- End date must be equal to or after start date
- Events cannot be created with start dates in the past

## Technical Notes
### Validation Rules
- Title: Required, 3-200 characters
- Start Date: Required, must be future date
- End Date: Required, must be >= start date

这种详细程度为 AI 工具提供了生成正确、完整实现所需的一切。业务利益相关者可以理解主流程，而开发人员则获得精确的技术需求。

成果

这种方法改变了我构建业务应用程序的方式：

更好的业务对齐：业务利益相关者审查每一个工件，确保系统符合他们的实际需求。

可维护的代码：当需求发生变化时，下游的一切都会一致地更新。文档与实现之间不会出现偏差。

更快的开发：AI 处理生成图表、规范和代码等繁琐工作。业务利益相关者专注于提供需求和审查规范。开发人员专注于业务逻辑和架构。

完整的可追溯性：从业务需求到一行代码，每一个连接都得到维护并且可见。

质量保证：生成的代码包含基于用例规范的全面测试。

为什么这对业务应用程序有效

业务应用程序具有可预测的技术模式，但领域逻辑或多或少较为复杂。Vaadin、Spring Boot 和 jOOQ 等框架提供了稳定的基础（参见 the Simon Martinelli Stack）。真正的复杂性在于正确理解和建模业务领域。

这种方法发挥了双方的优势：

人类专业知识处理业务领域的复杂性
AI 处理一致的技术实现

入门

如果你想尝试这种方法：

从需求开始：不要直接跳到代码。花时间理解和记录业务需求。
让一切皆代码：使用 markdown 编写规范，使用 PlantUML 绘制图表。在 Git 中对一切进行版本控制。
与业务方一起审查：让利益相关者不仅验证业务工件，还要验证实体模型和系统用例。
将 AI 用作一致性引擎：让 Claude Code 等工具处理生成和更新。
保持史诗独立：避免交叉依赖，以简化开发和 AI 生成。

业务应用程序开发的未来

我们正处于一个转折点。AI 可以生成高质量的代码，但前提是我们为它提供高质量的规范。投资于更好需求流程的组织将更快地构建更好的软件。

这并不是用 AI 取代开发人员。而是利用 AI 消除繁琐、易出错的工作，以便我们能够专注于真正重要的事情：理解业务需求并设计能够很好地服务这些需求的系统。

代码是简单的部分。把需求做对才是真正价值所在。
阅读更多：https://unifiedprocess.ai

页面加载链接

返回顶部