葫芦客
1. 背景
手头负责一个项目,因历史原因项目代码不规范，导致后续团队维护困难，痛点如下：
- VO/DTO/DO混在一起,分不清层次
- 缺少清晰的模块边界，牵一发而动全身
- 命名不规范并且存在很多重复对象
- 采用jdk8+springBoot2.5版本非常老旧了
动过重构的念头，可一想到“15 万行 + 零单测 + 业务不能停”，所有人都怂了。
2. AI 试水：为什么总是“帮倒忙”？
最近大模型编程火爆，准备拿AI Coding搞个复杂场景试试，尝试了很多AI工具和方法，效果都不太好：
- 让AI帮忙重构总是跑偏,理解不了复杂的业务约束
- 团队有编码规范,但AI生成的代码各行其是,review起来头大
- 不断重复prompt，一小块小块改，不断确认方案，累成狗，感觉还不如自己写
- 经常被它改错代码，好不容易确认过的代码，要重头再来
一段时间，感觉自己被AI给整蒙子 ，感觉比自己写代码更累，被AI在带着走(Vibe Coding)，脑袋闪过了一阵放弃的念头
3. 转折点：规格驱动开发（Spec-Driven Development）
当我了解到基于AI的Spec Coding方法和理论后，意识到一个问题:不是AI不够聪明,是我们没给它讲清楚"怎么干"，对于复杂需求，缺乏工程化的思维
Specification-Driven Development(规格驱动开发)：让AI严格遵循"明确规格→方案设计→任务分解→代码实现"的完整流程,每一步都有标准化的输入输出
- 推荐几款热门工具 ：
Spec-Kit(64K Star)： https://github.com/github/spec-kit
BMAD-METHOD(31K Star)：https://github.com/bmad-code-org/BMAD-METHOD
OpenSpec(19K Star)：https://github.com/Fission-AI/OpenSpec
PromptX(3.4K Star)：https://github.com/Deepractice/PromptX
Kiro IDE： https://kiro-ide.net/
虽然现还不够完美,但效果已经开始显现，下面实践使用火热的Spec-Kit工具
4. 快速上手:3分钟搞定环境
- 4.1 先装工具:
# linux 推荐用uv (快得多)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# Windows:
irm https://astral.sh/uv/install.ps1 | iex
# 验证安装
uv --version
specify check-
4.2 然后初始化项目:
# 已有工程 specify init . --ai claude -
4.3 初始化后会生成几个指导AI后续干活的重要命令:
/speckit.constitution- 创建项目规范
/speckit.specify- 明确需求
/speckit.plan- 生成方案
/speckit.tasks- 分解任务
/speckit.implement- 执行开发
这几个核心命令都会有他的输入和成果输出，如下图：
5. 实战案例: Spring Boot项目重构全流程
下面将这个真实场景核心过程详细记录一下
5.1 第一步:给项目立规矩(constitution)
这一步很关键。没有规则,AI就像没有规章制度的团队,各做各的。
> /speckit.constitution 这是一个已有的Spring Boot 3.x项目,后续开发和重构都必须按照dm-backend-coding-enriched编码规范
1. VO/DO实体分层,遵循dm规范
2. 命名要按规范来
3. 日期类型处理要符合框架规范,去掉硬编码时区
4. 接口文档用OpenAPI 3.0
5. Feign复用控制器实体
6. 异常处理按规范来
7. 分api和service两个工程
8. system-service实体分好类,控制层提到system-api,DO提到dao,其他用BO执行完后会生成constitution.md文件,这就是项目的"宪法"。
坑点:这一步要投入时间把规则写清楚。别嫌麻烦,"磨刀不误砍柴工",不然后面AI生成的代码还得改。
5.2 第二步:说清楚你要什么(specify)
> /speckit.specify 我要对当前项目重构,需求如下:
1. 只优化控制器、业务层、持久层入参出参,不新增CRUD
2. 按模块分阶段,优先级重构实体
3. 每完成一个模块要编译通过,再下一个
4. 合并大实体时核对字段,保证接口兼容
5. 规范重构但接口命名尽量不动,影响前端的记到变更文件
6. 过程有好的实践但规范没有的,写改进建议到本地文件
7. 全部重构后,用MCP操作浏览器测试核心模块AI会生成specification.md,把所有需求书面化。这样做的价值是:需求清晰了,AI不会瞎猜。
5.3 第三步:补充细节(clarify)
如果前面需求说得不清楚,用clarify让AI主动问:
> /speckit.clarify 补充一些重要需求:
1. 检查所有接口注解按OpenAPI 3.0
2. 控制器实体放到system-api工程vo包下,DO放到system-service的do包,其他放到bo包
3. 日期类型按规范处理
4. 有规范改进建议写到临时文件
5. 按模块改造,逐个通过编译5.4 第四步:让AI出方案(plan)
> /speckit.planAI会生成plan.md,包含技术架构、实施路径、风险点等。
对比传统:以前方案设计得资深架构师花半天,现在几分钟搞定。
5.5 第五步:分解任务(tasks)
> /speckit.tasksAI会把plan拆成详细的tasks.md，用于指导执行和跟踪状态，就像靠谱的PM给你安排工作:
- 清晰的任务编号和优先级
- 每个任务的具体内容非常的细
5.6 第六步:开始编码(implement)
> /speckit.implementAI按任务清单逐个完成:
- 读取任务
- 执行代码修改
- 自动编译测试
- 记录进度
- 有问题的主动问
5.7 我的实战经验分享
用下来的几点心得:
- 规格要清晰:前期多花点时间写规格,比后期返工好
- 别贪多:按模块分批执行,有问题好排查
- 明确验收标准:每个任务完成后要知道"完成"的标准(编译/单测)
- 持续优化宪法:过程中发现规范问题及时更新
- 用版本控制: 让AI及时提交GIT阶段任务,方便错误回滚
6. 总结
SSD的最大革新,是让人和AI回到了各自擅长的位置:
人类:专注于思考和决策
- 业务需求分析和规格定义
- 技术方案的方向把控
- 异常情况的处理决策
- 系统架构的核心设计
AI:专注于规范执行
- 繁琐的代码生成
- 重复的格式化和规范化
- 机械的接口和文档生成
- 大范围的代码扫描和检查
