Blog By Quartex
搜索
关于

笔记：开发流程（SDD）

|
访问
本文共1,608字。

我今天学到新东西了

前言

最近用AI做出来了一个之前构想的音游，不得不感叹在如今AI大行其道的环境下，在创作方面我们可能不止需要注意力，还需要创造力了。个人只要有想法都可以成为创作者和开发者

唯一的问题是他思考了两个小时才写出来，看了下思考过程有很多冗余。我在制作该游戏用了GLM 5.3 Flash编程，DeepSeek 4.1 Flash做善后。

Flash模型已经如此，如果用的是大的模型会很浪费token，所以不得不反思是不是哪里出了问题。

昨天将我的demo发到群里之后和群友聊了一下，记录一下聊天记录讨论到的内容

现在我在让openspec写我的需求，就顺便写一下所学到的东西

SDD

什么是SDD

规格驱动开发（Spec-Driven Development, SDD） 是一种以“规格说明”为核心驱动力的软件开发方法。

它强调在编写任何代码之前，先编写一份清晰、完整、无歧义的规格说明，然后将这份规格作为唯一的“真相来源”（Single Source of Truth），指导后续的技术设计、任务拆解和代码实现。

这种方法特别适合与 AI 辅助编程工具结合使用，能有效避免“凭感觉编码”（Vibe Coding）带来的不确定性和返工。

上面那段是AI告诉我的，也就是说，写几个规格说明文件来防止AI乱搞。

我感觉这也算prompt engineering的范畴了，因为本质上他和CLAUDE.md的约束文件是一样的。只不过是AI来帮我写prompt，而且是写多个在不同发展阶段的文件。而我需要做的只是给他一个大概的指令

考虑到我自己应该写不出个什么东西出来，所以在群友的推荐下，我下载了一个openspec，他是一个轻量化的spec生成文件，并且可以调用我的tools，仅靠描述就帮我生成一份细致的spec

四个阶段

SDD分为四个阶段，指定——计划——任务——实现

指定（Specify）

你要做什么？

这就是这个阶段需要考虑的。

我要做什么？我想做个游戏，他应该有什么功能，他的基本思想是什么。

下面这个是一个用AI写的示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 提案：创建基础节奏游戏

## 背景
希望开发一款轻量级网页音乐游戏，玩家通过键盘与音乐节奏互动。

## 目标
- 实现一个下落式音符的节奏游戏
- 支持键盘操作（D、F、J、K 四键）
- 根据击打准确度进行判定和计分

## 范围
**包含：**
- 一首内置练习曲目
- 基础的音符下落动画
- 判定系统（Perfect / Good / Miss）
- 分数与连击显示

**不包含：**
- 歌曲选择界面
- 在线排行榜
- 自定义谱面导入

可以看到，他给出了

每个阶段都会有一份markdown文档作为约束的具象化。例如在这一个阶段将会生成一个proposal.md的文档，

计划（Plan）

在这一阶段，需要明确的是技术方案，例如基于什么技术栈，采用什么架构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 技术设计：基础节奏游戏

## 架构概述
- 使用 HTML5 Canvas 渲染游戏画面
- 使用 Web Audio API 加载和播放音乐
- 使用 requestAnimationFrame 驱动游戏主循环

## 技术栈
- 语言：JavaScript (ES6+)
- 渲染：Canvas 2D
- 音频：Web Audio API
- 测试：Playwright (E2E)

## 关键设计决策
- **音符轨道**：4 条垂直轨道，分别对应 D、F、J、K 键
- **判定窗口**：Perfect ±50ms，Good ±100ms，超过 100ms 为 Miss
- **时间同步**：使用 AudioContext.currentTime 作为唯一时间源

生成的产物可能叫plan.md或design.md

任务（Tasks）

将项目分解成一个个小的任务。每个任务都应该足够小，以便能够独立开发和测试。

产出物是一份有序的任务清单 tasks.md，它指导着后续的编码工作

1
2
3
4
5
6
7
8
# 实现任务

- [ ] 1. 搭建 Canvas 画布和 4 条轨道的基础渲染
- [ ] 2. 实现 Web Audio API 加载和播放音乐
- [ ] 3. 实现音符数据结构与下落逻辑
- [ ] 4. 实现键盘输入监听与判定逻辑
- [ ] 5. 实现分数、连击和判定结果的 UI 显示
- [ ] 6. 编写 Playwright E2E 测试，覆盖 Perfect / Good / Miss 场景

实现（Implementation）

依据规格、计划和任务清单进行代码编写。每完成一个任务，都需要对照最初的规格进行验证，确保实现完全符合预期。产出物是经过测试、满足原始需求的可用代码。

这一阶段将不会有产物，而是根据之前所给出的tasks.md进行逐一核对

软件开发注意

Compact

考虑到AI有上下文，compact确实是一个很有用的功能。如果不进行压缩，那么过长的上下文会拖慢AI思考速度，浪费记忆，还会遇到上下文污染。在实际的操作时，我就遇到了在思考后期思考已经思考过的内容的情况，这应该就是上下文污染

之前我的方法一直都是在一个阶段停下，并让AI重新对思考内容进行总结，不过搜了一下才知道Claude Code原来点一下那个圈就可以总结了。

视觉参考

我的项目基于一个现有的项目，所以可以找一个可以识别图片的模型。反正都是造轮子，可以省点token

让AI问我

血泪教训，不要为了省事就开启Auto模式。我的Prompt中提到以一款已经发行的游戏的判定范围作为参考，结果不知道为什么，AI对于判定范围这件事纠结了很久很久。由于我开的自动模式，所以我是挺难在中间打断他并对他进行解释的。

AI可能会很强大，但是如果问他过于细致或很有指向性的领域，他很可能无法反映过来或者理解

所以之后如果我还要用AI做任务，一定要让他在他不懂的环节记得问我

skill

待完善

共0条搜索结果。