轻量 · 高效 · 把事办妥 ------ 用规范驱动开发,让自动化真正可靠
一、为什么需要 GSD?
你是否遇到过这些问题?
❌ "AI 写的代码前后不一致,改完 A 功能,B 功能就崩了"
❌ "上下文太长,生成质量断崖式下降"
❌ "每次都要重复解释项目结构、技术栈、编码规范"
❌ "想快速加功能,结果被问一堆无关问题"
GSD(GET SHIT DONE)就是为解决这些问题而生:
✅ 原子化任务:每个功能拆成独立小任务,全新上下文执行,杜绝上下文衰减
✅ 自动验证:每步生成可测试交付物,失败自动诊断修复
✅ 状态记忆:通过 PROJECT.md、STATE.md 等文件持久化项目上下文
💡 核心理念:GSD 不是取代你,而是把你从重复劳动中解放出来,专注真正重要的设计与决策。
二、快速入门:我该从哪开始?
新手决策树(5 秒选对命令)
| 你的场景 | 使用命令 |
|---|---|
| ✅ 全新项目(从零开始) | gsd-new-project |
| ✅ 已有代码库,要加新功能/模块 | 先 gsd-map-codebase,再 gsd-new-project,然后 gsd-new-milestone "功能名" |
| ✅ 修 Bug / 改配置 / 小调整 | 直接 gsd-quick |
⚠️ 前提:项目根目录已初始化 Git(GSD 依赖 git commit 追踪变更)
三、核心工作流:里程碑闭环
GSD 以里程碑(Milestone) 为单位组织开发。每个里程碑代表一个可交付的功能集,其完整流程如下:
-
初始化项目
-
全新项目:
gsd-new-project -
已有代码:
gsd-map-codebase→gsd-new-project
-
-
创建里程碑
bashgsd-new-milestone "用户登录"→ 定义本次要完成的目标范围
-
讨论阶段(关键!)
bashgsd-discuss-phase 1-
系统提问:UI 风格?API 响应格式?错误处理方式?
-
输出
CONTEXT.md,直接影响后续规划 -
可随时输入
done跳过剩余问题
-
-
规划阶段(可人工干预!)
bashgsd-plan-phase 1-
自动生成原子任务计划(存储于
.planning/phase-1/PLAN.md) -
如果你不认可计划:直接编辑
PLAN.md -
重新运行
gsd-execute-phase 1即可生效
-
-
执行阶段(全自动)
bashgsd-execute-phase 1-
按依赖关系分"波次"(Wave)并行执行
-
每个任务使用全新上下文,避免信息污染
-
每完成一个任务 → 自动
git commit
-
-
验证工作(人工兜底)
bashgsd-verify-work 1-
系统列出可测试项:"你能用邮箱登录吗?"
-
你回答 是 / 否 或描述问题
-
-
里程碑管理(版本级闭环)
当功能集完成时:
bash# 检查是否达成目标 gsd-audit-milestone # 若通过,归档并标记发布 gsd-complete-milestone-
gsd-complete-milestone不会删除任何文件 -
它将当前
.planning/归档到.planning/archive/v1.0/,并生成发布日志
-
四、完整主干流程图
✅ 逻辑顺序:先 gsd-new-project,再 gsd-new-milestone,然后进入阶段闭环。
五、高频命令速查制
| 场景 | 命令 |
|---|---|
| 初始化项目 | gsd-new-project |
| 分析已有代码 | gsd-map-codebase |
| 启动新功能周期 | gsd-new-milestone "功能名" |
| 快速修复小问题 | gsd-quick |
| 查看当前进度 | gsd-progress |
| 暂停/恢复工作 | gsd-pause-work → gsd-resume-work |
六、总结:高效开发心法
-
用对流程:新功能走完整五步,小任务用
gsd-quick -
信任但验证:必须执行
gsd-verify-work -
敢于干预:不认可计划?直接编辑
PLAN.md! -
闭环管理:用
gsd-complete-milestone和gsd-new-milestone管理版本
🌟 记住:GSD 给你掌控感,而非替代你。你可以全自动跑完全程,也可以在任何环节插手干预------它始终是你手中的工具。