在 AI 编码助手（如 GitHub Copilot 、Claude Code 、Cursor ）普及之前，软件开发遵循 "代码优先、文档次之" 的模式，面临三大核心痛点：
| 痛点 | 具体表现 | 影响 |
|---|---|---|
| 意图与实现鸿沟 | 需求文档模糊、变更频繁，代码与文档长期脱节 | 沟通成本高，重构风险大，维护困难 |
| 协作效率低下 | 团队成员对需求理解不一致，缺乏统一 "事实来源" | 重复工作多，冲突频繁，交付周期长 |
| 质量保障滞后 | 测试在编码后进行，缺陷发现晚，修复成本高 | 产品稳定性差，用户体验受损 |
随着 AI 编码工具的普及，这些问题被进一步放大：AI 能快速生成代码，但缺乏对整体系统架构和业务逻辑的理解，容易产生 "局部正确但全局错误" 的代码；同时，开发者过度依赖 AI 提示词，导致代码质量参差不齐，可维护性急剧下降。
规范驱动开发 (Spec-Driven Development, SDD) 是生成式 AI 时代下适配工程化开发的新型软件开发方法论，核心是先由技术人员定义简洁、可测试、形式化的系统规格说明 (Spec)，将其作为人、团队与 AI 之间的 "动态契约" 和开发过程的唯一事实来源。
SDD 带来三大革命性转变：
SDD 并非全新概念，而是在传统软件工程理论基础上的进化：
以 "XXL-API 项目代码重构" 为例，展示 Spec-Kit 的完整实践流程。
本次改造项目为正式项目，对代码规范性与质量存在要求；另外，该重构需求涉及 “9 个功能模块”、“前后端代码逻辑修改”，累计需要修改 130+ 项目文件，为中型颗粒度需求。本次改造需求存在一定复杂度。
执行如下命令 + 填写功能需求描述，生成 “功能规格（ Spec ）”：
/speckit.specify 针对 XXL-API 项目按照如下要求重构：
1 、按照下面项目规范结构，重构重构项目目录结构：
xxl-api-admin/src/main/java/com/xxl/api/admin
- /framework: 基础框架代码，包含公共的 登录、util 、过滤器等组件。
- /business：业务代码，包含具体业务模块的 controller 、service 、model 、mapper 子分层代码。
xxl-api-admin/src/main/resources/templates
- /framework：基础模板，基础框架实体 对应的。
- /business：业务模板，业务领域实体对应的。
xxl-api-admin/src/main/resources/mapper
- /framework：基础 Mapper 文件，基础框架实体 对应的。
- /business：业务 Mapper 文件，业务领域实体对应的。
2 、业务代码分类判断逻辑：Java 代码部分，当前 com/xxl/api/admin/controller/biz 下除了 UserController 都是 业务领域，保留 User 相关 Java 代码不变，其他按照规范调整。模板部分，当前 help.ftl 、index.ftl 、login.ftl 属于基础框架，其他属于业务领域； Mapper 部分，当前 XxlApiUserMapper.xml 属于基础框架，其他属于业务部分。
执行后将会生成 .specify/specs/001-project-structure-refactor/spec.md 文件，内容如下：
执行如下命令，生成 “技术规划”：
/speckit.plan
执行后将会生成 .specify/plans/001-project-structure-refactor/plan.md 文件，内容如下：
执行如下命令，生成 “任务清单”：
/speckit.tasks
执行后将会生成 .specify/tasks/001-project-structure-refactor/tasks.md 文件，内容如下：
执行如下命令，将会按照拆解任务（ tasks.md ）进行 “代码生成”：
/speckit.implement
Agent 会按照任务清单（ tasks.md ）逐个实现，每个任务完成后自动对照requirements.md检查。
所有任务完成后，人工进行 Review 验收，确认符合要求后合并代码（当前该 PR 已合入 XXL-API master 分支，交付符合预期）。
Spec 完整实践记录见： https://www.xuxueli.com/blog/?blog=ai/speckit
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。