AI Coding SDD开发规范_01_规范与流程
markdown
2026年7月17日5 min read835 words
Updated 2026年7月17日
AI Coding SDD开发规范_01_规范与流程
一、SDD开发模式概述
2.1 什么是SDD（Specification-Driven Development）
SDD = 规格驱动开发
是一种以规格文档（Spec）为核心的AI辅助开发方法论。通过标准化的文档输出，确保AI能够准确理解需求、生成符合规范的代码。
核心原则：规范先行，通过约定存量项目工程的业务规范，引导AI分析当前项目的技术架构与业务架构进行功能设计和编码。
2.2 SDD开发模式的四态流程
需求态 → 设计态 → 开发态 → 测试态
| 形态 | 核心输出 | AI 辅助能力 | 人工职责 |
|---|---|---|---|
| 需求态 | 需求规格文档 | 智能原型设计 | 需求确认 |
| 设计态 | Spec设计文档 | Spec辅助生成、架构合规核查 | 核心逻辑设计 |
| 开发态 | 可运行代码 | 前/后端智能开发、安全扫描、性能优化 | 代码审核 |
| 测试态 | 测试用例/脚本 | Mock数据生成、测试用例生成、自动化测试 | 测试执行 |
2.3 AI Coding 当前重点工作状态
| 工作项 | 状态 | 说明 |
|---|---|---|
| 新功能智能开发 | 🟢 已完成 | 开源技术栈完整支撑 |
| 私有技术栈智能开发 | 🟢 已完成 | 已适配多种私有技术栈 |
| 存量功能智能开发 | 🟡 进行中 | V1.0版本已可用 |
| 四态整体串联 | 🟡 进行中 | 端到端流程已贯通 |
三、SDD开发模式流程详解
3.1 需求态：智能原型设计
核心能力
- 基于 UI-UX-PRO-MAX 等 AI 设计技能与 IDE 工具
- 通过需求描述或手绘低保真图
- 自动解析布局与交互逻辑
- 快速生成可交互原型
UI-UX-PRO-MAX Skill 特性
- 67种UI风格：毛玻璃效果、黏土拟物化、极简主义、粗野主义、新拟物化等
- 161套配色方案：针对不同行业定制
- 57组字体搭配：精选排版组合
- 25种图表类型：数据仪表盘与分析场景
- 15种技术栈：React、Next.js、Vue、Nuxt、Svelte、SwiftUI等
- 99条UX设计指南：最佳实践、反模式、无障碍规范
3.2 设计态：后端Spec设计 + 架构合规
后端Spec设计
开发人员主导编写Spec设计说明书，核心描述由人工编写，部分相对结构化的章节借助编程智能体辅助生成。
设计文档补全流程：
- 下载对应模板（业务方法设计模板 或 业务接口设计模板）
- 人工编写核心章节（方法概述、处理流程）
- AI辅助补全其他章节
- 评审确认后进入开发态
架构合规智能核查
- 结合业界、事业部及项目组架构规范
- 通过编程智能体 Skill 能力
- 实现对项目代码架构的智能合规稽查
- 12维度详细检查清单
3.3 开发态：核心开发环节
前端智能开发
| 开发方式 | 适用场景 | 输入 | 输出 |
|---|---|---|---|
| Figma高保真开发 | 大型项目，UED主导设计 | Figma设计稿 | 可运行产品界面 |
| 需求设计开发 | 小型项目，无需高保真 | 项目规范+需求文档 | 符合规范的代码 |
| 低保真开发 | 快速原型验证 | 手绘简图+设计文档 | 可交互组件原型 |
| 私有技术栈开发 | 存量项目 | 私有框架规范+Skills | 符合私有框架的代码 |
后端智能开发
- 基于 Spec 设计文档
- 结合 Rule 规范、Skill 技能
- 通过 Coding Agent 智能生成后端代码
- 大幅提升开发效率与代码一致性
代码智能安全
完整治理流程：扫描 → 报告 → 修复 → 确认
- 通用代码安全扫描规范
- 事业部安全事件沉淀规范
- 项目级自定义安全规范
- 智能修复 + 人工确认
性能智能优化
- 结合 APM 应用性能监控工具（Druid）
- 前置识别慢SQL、慢接口
- Coding Agent 智能修复性能隐患
3.4 测试态：智能测试辅助
| 测试类型 | 面向角色 | AI 辅助能力 |
|---|---|---|
| Mock数据生成 | 开发人员 | 前端智能Mock、后端接口测试数据 |
| 单元测试生成 | 开发人员 | 后端单元测试自动生成与执行 |
| 测试用例生成 | 测试人员 | 基于Spec文档的智能测试用例设计 |
| UI自动化测试 | 测试人员 | Playwright智能生成可执行脚本 |
四、团队角色与职责
4.1 角色配置
| 角色 | 原角色 | 职责 | 配置人数 |
|---|---|---|---|
| 上下文工程师 | 开发组长/技术骨干转型 | 构建和维护项目组的上下文工程，对上下文质量全面负责 | 1~2人 |
| AI工程师 | 开发人员转型 | 驾驭SDD开发全流程；监控质量、处理待确认项、审核AI产出物、验证结果 | 不限 |
4.2 上下文工程师核心任务
Context Skeleton 初始化
- 安装 gitnexus、openspec、aispec harness
- 生成上下文骨架
Context 知识积累
- 业务对象与领域术语
- 系统架构和模块说明
- 私有技术栈说明
- 开发规范与代码设计原则
- 数据字典和实体关系
项目组上下文维护
- 创建和维护上下文工程 Git 仓库
- 沉淀为 preset 上传到 AI SDD 模板库
- 集成接口测试与 E2E 测试用例生成
4.3 AI工程师核心任务
需求分类分级
- Full-SDD：复杂需求，跨多仓库、状态机流转
- Lite-SDD：简单需求、单模块修改、Bug修复
- Skill Coding：配置变更类需求
- Vibe Coding：简单UI调整、文字修改
需求开发流程
- /ai-new-change：接收需求文档
- /ai-proposal-change + /ai-specs-change：生成提案和规格
- /ai-design-change：生成设计文档
- /ai-tasks-change：拆解为具体任务
- /ai-apply-change：实施代码变更
- /ai-verify-change：验证代码与文档对齐
- /ai-archive-change：归档所有产物
五、AI Coding落地建议
5.1 有效落地的四大关键
流程标准化、工具统一、技术栈统一、持续沉淀优化是 AI Coding 有效落地的关键。
5.2 开源技术栈 vs 私有技术栈
| 维度 | 开源技术栈 | 私有技术栈 |
|---|---|---|
| 技术框架 | Vue3 + SpringBoot | 私有全栈框架 + 私有后端框架 |
| AI支持 | 依赖大模型开源主流框架内生能力 | 需梳理私有组件或开发规范 |
| 适配状态 | 已沉淀，可直接使用 | 已初步实践 |
| 长期建议 | 直接使用 | 引导进行架构治理，逐步升级开源 |
5.3 智能开发建议矩阵
| 需求类型 | 场景 | 推荐方式 | 状态 |
|---|---|---|---|
| 开源技术栈新功能开发 | 配置/查询/接口/定时任务 | SDD规范驱动开发模式 | ✅ 已沉淀 |
| 私有技术栈新功能开发 | 同上 | SDD规范驱动开发 + 已适配私有技术栈 | ✅ 已沉淀 |
| 存量功能修改 | 界面/接口/业务逻辑修改 | 存量系统智能开发V1.0 | 🔄 迭代中 |
| 性能/安全优化 | 代码优化修改 | SDD规范驱动开发模式 | ✅ 已沉淀 |
5.4 工具推荐
| 工具 | 厂商 | 推荐场景 | 模型推荐 |
|---|---|---|---|
| Trae | 字节 | 首选 GUI 开发工具 | Doubao-seed-2.0-Code、DeepSeek-V4-Pro、GLM5.1 |
| Qoder | 阿里 | 日常 GUI 开发 | Kimi-K2.6、GLM5.1 |
| Lingma IDE | 阿里 | IDE 场景 | Kimi-K2.6、Qwen3.6-plus |
| Cursor/Copilot | - | 存量系统上下文构建首选 | Claude |
| Claude Code | Anthropic | 终端 Agent 编码、CI/CD 集成 | claude-sonnet-5、claude-opus-4-8 |
| Codex CLI | OpenAI | 终端代码生成与批量修复 | gpt-4o |
| OpenCode | 开源社区 | 多模型灵活切换、开源场景 | 可配置任意模型 |
六、快速上手指南
6.1 新人上手路径
Day 1: 环境配置
├── 安装 Trae/Qoder/Lingma IDE（GUI工具）
├── 安装 Claude Code / Codex CLI / OpenCode（CLI工具，按需选择）
├── 配置企业账号登录
├── 克隆项目代码
└── 配置项目规则 (rules / CLAUDE.md / AGENTS.md)
Day 2-3: 规则学习
├── 阅读项目规范文档
├── 理解项目技术栈
├── 掌握基本操作命令
└── 尝试简单任务
Day 4-7: 实战练习
├── 选择小型需求
├── 按照SDD流程执行
├── 体验AI辅助开发
└── 总结使用心得
6.2 SDD开发检查清单
| 阶段 | 检查项 | 状态 |
|---|---|---|
| 需求态 | ✅ 需求文档已确认 | ⬜ |
| ✅ 原型/设计稿已输出 | ⬜ | |
| 设计态 | ✅ Spec设计文档已编写 | ⬜ |
| ✅ 核心逻辑已人工确认 | ⬜ | |
| ✅ AI补全部分已审核 | ⬜ | |
| 开发态 | ✅ 项目规则已配置 | ⬜ |
| ✅ 代码已生成 | ⬜ | |
| ✅ 代码已审核 | ⬜ | |
| ✅ 安全扫描已通过 | ⬜ | |
| 测试态 | ✅ 单元测试已生成 | ⬜ |
| ✅ 接口测试已通过 | ⬜ | |
| ✅ 功能测试已验证 | ⬜ |
七、资产沉淀与复用
7.1 资产目录结构
project-root/
├── .trae/
│ ├── rules/ # 项目编码规范
│ │ ├── {projectRule1.md}
│ │ └── {projectRule2.md}
│ └── skills/ # 技能文件目录
│ └── {skills1}/
│ ├── SKILL.md
│ ├── assets/
│ ├── references/
│ └── scripts/
└── specs/ # SDD文档目录
├── {business1}/
│ └── {subBusiness}/
│ ├── design/
│ └── task/
└── {business2}/
7.2 持续优化机制
知识飞轮：需求驱动 → 按需沉淀 → 持续扩充 → 深度覆盖
- 每次需求迭代后，复盘上下文完整性
- 新发现的知识及时更新到项目上下文
- 好的实践总结沉淀为 Skills
- 通过 PR 机制共享项目组知识