设计驱动开发实战

设计驱动开发(Specification/SDD Driven Development, 简称 SDD)"

前提:安装OpenSec已完成(SDD介绍)

如果觉得有用,请关注微信公众号:阿呆-bot(

目标:生成多租架构+元数据管理资源的服务,整体安装先设计、后开发的思路。设计时先根据需求描述完成设计文档,进行评审后归档。传递设计完成的文件到开发代码,根据设计的详细文档进行开发,开发中根据实际多次调整,按结果生成代码。

代码目录分两级,实现设计和代码分离管理。

复制代码
├── design/
    ├── 需求描述
        ├── SAAS租户.md
    ├── lowcode
        ├── business        # 业务描述,包括流程、时序等动态设计图
            ├── SAAS租户        # 本次任务或者特性
        ├── information        # 信息描述,包括model等
        ├── md        # 设计文档
            ├── SAAS租户        # 本次任务或者特性
                ├── SAAS租户架构设计.md         # 本次详细设计
                ├── SAAS租户元数据模型设计.md   # 本次详细设计
                ├── SAAS租户API设计.md         # 本次详细设计
                ├── SAAS租户表结构设计.md       # 本次详细设计
    ├── specs/             # 规范文档(当前真实状态         ├── AGENTS.md          # OpenSpec工作流说明          # OpenSpec工作流说明
        ├── project.md         # 项目信息   
└── AiTest/
    ├── design             # 详细并归档的设计
        ├── SAAS租户           
    ├── specs/             # spec文件
        ├── changes       # 任务
            ├── SAAS租户    # 本次详细设计文档
        ├── project.md       # 项目详细信息

基于AI的设计

生成对项目规约的设计

1、将相关的规约、设计管理标准等统一放入设计文件夹中,生成相关project.md的描述

2、相关设计规范均统一记录在project.md文档中,可直接查阅。并可通过AI协助对其进行总结和修改,以生成新的内容。

3、对此进行总结、修改,实现统一的设计规范管理

1、需求描述

复制代码
需求描述:
## version: 1.0.0
当前设计一个SAAS化平台,需要进行多租能力设计,支持按租户进行数据隔离
1、需要一个租户表,描述租户的唯一标识、租户名称、租户描述、租户状态、租户创建时间、租户更新时间
2、需要一个租户用户表,描述租户用户的基本信息,包括用户名、密码、邮箱、手机号、用户状态、用户创建时间、用户更新时间
3、需要一个租户角色表,描述租户角色的基本信息,包括角色名称、角色描述、角色状态、角色创建时间、角色更新时间
4、需要一个租户权限表,描述租户权限的基本信息,包括权限名称、权限描述、权限状态、权限创建时间、权限更新时间
...
10、需要管理组织机构,组织和租户关联,一个租户包括多个组织
在设计资源时,考虑基于元数据来描述:
1、元数据模型包括应用、模块、菜单、按钮、API等。应用和系统功能相关,模块和应用相关,菜单和模块相关,按钮和菜单相关,API和模块相关。菜单支持用户自定义名称配置,支持用户自定义图标配置等
2、应用和租户关联,一个租户包括多个应用,一个应用可以应用到多个租户
3、元数据模型还包括实体、表单、字表单、字段、视图等。实体和表单相关,字表单和表单相关,字段和表单相关,视图和实体相关。实体和租户关联,一个租户包括多个实体,一个实体可以应用到多个租户。其中视图包括页面渲染的DSL,支持用户自定义配置。
4、一个entity会对应流程引擎、规则引擎等,可以根据entity属性进行配置,使得一个entity可以应用多个流程、规则等

2、设计生成过程

在此过程中需要对详细的设计产物比如auth/spec.md等进行调整,在此过程中也可以通过AI进行优化。

  • /openspec-apply add-saas-tenant-multitenancy 生成设计内容,AI将按project.md要求生成内容并放入相关文件夹中,参考如下:

在整个设计中,在MD文件中是架构整体描述,包括架构设计、分层以及技术实现要点、表设计

对于具体的数据模型、流程图等生成使用plantuml和mermaid,并且放入business和information下。

经过AI生成后,基本能满足60%-70%的设计,然后进行相关调整,当然也可以继续通过/openspec-proposal 命令对生成设计信息修改,重新执行/openspec-apply进行调整(还是基于Task进行todo)

文件名称 说明
SAAS租户API设计.md) SAAS多租户平台API接口设计,定义RESTful接口方案、权限和隔离等规范
SAAS租户表结构设计.md SAAS多租户平台表结构设计,包含租户、租户用户、角色、权限等数据模型说明
SAAS租户元数据模型设计.md) SAAS租户元数据模型设计,包括元数据架构设计
SAAS租户架构设计.md SAAS租户架构设计,包括整体的架构说明
SAAS租户资源模型设计.md SAAS租户资源模型设计,包括基于元数据定义资源+权限体系

3、归档

当所有的设计都审核后,执行/openspec-archive 进行归档,生成报告。

基于AI的代码开发

1、生成对项目规约的设计

  • 初始化项目规约
    1、项目代码的规约会根据设计、管理规范、代码规范等方式记录
    2、相关设计规范均统一记录在project.md文档中,可直接查阅。并可通过AI协助对其进行总结和修改,以生成新的内容。
    3、对此进行总结、修改,实现统一的设计规范管理
  • 持续迭代更新规约
    代码规约不是一次性就能完成并且不变的,一定需要根据项目的进行持续迭代
    工程规约不是随便就可以修改的,必须经过严格评审,形成团队统一遵循,必须通过版本管控
    不能完全遵循情况下需要在Project.md中明确说明
    在版本发布后,需要反向刷新Project.md ,同时,在新迭代开始后,需要审视Project.md

2、生成代码设计过程

  • 在cursor中执行/openspec-proposal 租户设计,设计文档地址xx,需要严格按文档描述进行开发。对于数据结构等遵循设计中的字段
  • 根据详细的设计文档生成proposal,质量大幅提升,经过AI分解会议100+任务产生

参考设计:
)

代码生成过程

  • 执行/openspec-apply 租户设计,AI会根据specs中的内容进行生成,在此过程中会有些命令确认,同意即可。生成代码并进行检视,合并代码
  • 对代码进行调整,编译、解决bug

Tips(持续补充)

复制代码
1、代码在生成过程中,如果分解的任务过多过大,可以分步去执行,每次一部分代码生成,完成部分任务
2、完成一部分任务代码后,可以先生成测试用例,测试通过后继续下一步
3、

总结

整体目标:形成以规约为基础的完整AI驱动开发闭环,全流程高效、规范、可追溯、可持续优化。

  • 基于SDD(Spec-Driven Development,规约驱动开发)的AI编程方式可以显著提升设计和代码的正确性和一致性。通过以详细的设计规约为驱动,AI生成的设计和代码能够最大程度符合业务目标和技术标准,避免主观随意,降低返工几率。
  • AI编码显著提升研发效率,但前提是有明确的约束条件和足够清晰的业务/技术描述。只有规约、需求、架构等足够清晰,AI能力才能充分发挥,自动生成高质量设计与代码。模糊或缺乏细节的输入,仍然可能带来方向性偏差,因此应在整个开发周期强化输入规范和评审。
  • 设计与编码各环节需结合PDCA(计划Plan-执行Do-检查Check-行动Act)持续循环优化。每次生成或调整,无论是设计、规约还是代码,都应经过团队复盘、回顾,并结合问题反推设计文档、规约内容不断修订,逐步达到最佳状态。持续反馈、持续评审、持续归档,构建高质量团队知识库和代码资产。

举例说明:

  • 在设计迭代中,应先有详细和标准化的设计规约(project.md及相关设计文档),每次AI生成设计/代码后进行审查和测试,若存在问题,明确反馈并修订规约,循环提升。
  • 项目各阶段(需求、设计、开发、归档)都建议PDCA流程,确保不仅代码、连同设计和规约都始终处于可持续改进过程中。

其他参考(持续增加):

Top1关键点

  • 最重要的提醒:做好备份、做好备份、做好备份!只能尽可能控制AI按既定目标、方式生成设计与代码,不能100%可控
    2、多个关注点
  • project.md什么时候刷新,什么时候生成
  • 建议设计和代码分离,设计环节重点考虑全面和详细;代码阶段一方面生成代码,关注整个团队规则,第二方面关注生成代码质量
  • 生成的代码务必要读懂,不可不检视就提交
  • 在一些复杂的场景、或者紧急bug修复时,不建议AI直接修改,避免越改越乱