GSD工作流实战：解决AI编程中的"上下文衰退"问题

摘要：在 AI 辅助编程中，随着对话轮次增加，AI 会逐渐忘记早期的重要信息，导致代码质量下降。这就是"上下文衰退"问题。GSD (Get Shit Done) 通过结构化的四步循环（Discuss → Plan → Execute → Verify），将隐式上下文显式化，有效对抗这一问题。本文将深入解析 GSD 的核心理念、实施方法和最佳实践。

标签：AI编程 GSD 工作流 上下文管理 Superpowers 工程实践

---

引言：为什么你的 AI 编程越来越"笨"？

你有没有遇到过这种情况：

• 刚开始和 AI 对话时，它表现得非常聪明，代码质量很高
• 但随着对话进行，AI 开始忘记之前确定的变量命名规范
• 实现的接口与之前的设计不一致
• 需要反复提醒 AI 已经说过的约束条件
• 最后生成的代码前后矛盾，需要大量返工

这不是 AI "变笨"了，而是遇到了 上下文衰退(Context Decay) 问题。

今天我要介绍的 GSD (Get Shit Done) 工作流，就是专门解决这个问题的高效方法。

---

一、什么是上下文衰退？

1.1 现象描述

在 AI 辅助编程中，当你与 AI 进行长时间对话时，会发现：

具体表现：

• ❌ AI 忘记项目早期的设计决策
• ❌ 代码风格逐渐偏离既定规范
• ❌ 实现方案出现前后不一致
• ❌ 需要反复提醒 AI 已知的约束条件
• ❌ 随着对话轮次增加，输出质量明显下降

1.2 根本原因

LLM 的上下文窗口有限 
  ↓
旧信息被挤出窗口
  ↓
关键信息丢失
  ↓
输出质量下降

根据社区调研，未经管理的长对话会导致：

指标	影响程度
代码一致性下降	67% 的项目出现风格不统一
返工率增加	平均需要 23% 的代码需要重写
Bug 数量上升	后期引入的 Bug 比初期多 45%
开发效率降低	整体效率下降 30-40%

---

二、GSD 是什么？

2.1 核心定义

GSD (Get Shit Done) 是一个专注于解决上下文衰退问题的结构化工作流系统。

基本信息：

属性	说明
项目名称	GSD (Get Shit Done)
GitHub Stars	37K+
核心定位	结构化工作流程方法论
解决的问题	AI 编程中的上下文衰退
适用场景	中大型项目、团队协作

重要澄清：

❌ GSD 不是另一个 AI 编程助手
✅ GSD 是一套结构化的工作流程
🎯 GSD 的目标是通过强制沉淀关键信息来对抗上下文衰退

2.2 GSD 四步循环

这是一个迭代式的工作流，每个循环都包含四个明确的阶段：

阶段一：Discuss（讨论）

目标：明确需求，达成共识，识别风险

关键活动：

• 与 AI 深入讨论功能需求
• 澄清模糊的需求点
• 识别技术约束和风险
• 确定成功标准

产出物： 需求文档 + 风险评估报告

实战示例：

## Excel 数据解析功能 - 讨论记录

### 功能需求
1. 用户上传 Excel 文件(.xlsx, .csv, .tsv)
2. 系统自动解析并展示预览
3. 支持数据筛选和导出

### 技术约束
- 文件大小限制: 最大 50MB
- 处理时间: < 30秒
- 前端框架: React 18
- 后端: Node.js + Express

### 潜在风险
1. 大文件可能导致内存溢出
   - 应对: 使用流式处理，分块读取
2. 特殊字符编码问题
   - 应对: 统一转换为 UTF-8

### 成功标准
- 50MB 文件在 25秒内完成解析
- 支持 10万行数据的流畅展示
- 错误率 < 0.1%

阶段二：Plan（计划）

目标：制定详细的实施方案，分解任务

关键活动：

• 将大任务拆分为小步骤
• 设计技术方案和架构
• 定义接口和数据流
• 制定测试策略

产出物： 详细实施计划 + 任务分解清单

实战示例：

## Excel 解析功能 - 实施计划

### Phase 1: 基础框架搭建 (预计 2小时)
- [ ] 创建文件上传组件 (30min)
- [ ] 实现后端文件接收接口 (45min)
- [ ] 添加文件大小校验 (15min)
- [ ] 编写单元测试 (30min)

### Phase 2: 解析引擎开发 (预计 4小时)
- [ ] 集成 xlsx 库处理 Excel 文件 (1.5h)
- [ ] 实现 CSV/TSV 解析器 (1h)
- [ ] 统一数据格式转换 (30min)
- [ ] 错误处理和边界情况 (1h)

### 技术方案
- 前端: react-dropzone + ag-grid-react
- 后端: multer + xlsx 库
- 数据处理: 流式读取，避免内存溢出

阶段三：Execute（执行）

目标：按计划实施，保持专注，记录进展

关键活动：

• 严格按照计划执行
• 遇到问题时记录并调整
• 保持代码质量和规范
• 及时更新进度状态

产出物： 可工作的代码 + 执行日志

实战示例：

## 执行日志 - 2026-04-20

### 上午 (9:00 - 12:00)

✅ 已完成:
- 文件上传组件 (实际 35min, 预估 30min)
  - 使用 react-dropzone 实现拖拽上传
  - 添加了文件类型和大小校验
- 后端文件接收接口 (实际 50min, 预估 45min)
  - 使用 multer 处理 multipart/form-data

⚠️ 遇到的问题:
- react-dropzone 的类型定义不完整
  - 解决: 手动补充 TypeScript 类型声明
- multer 默认内存存储不适合大文件
  - 解决: 改用磁盘存储，处理完成后清理

📝 备注:
- 实际耗时比预估多 15%，主要原因是调试类型问题

阶段四：Verify（验证）

目标：验证结果是否符合预期，总结经验教训

关键活动：

• 对照 Discuss 阶段的成功标准
• 执行测试用例
• 检查边界情况
• 总结经验教训

产出物： 验证报告 + 经验总结

实战示例：

## Excel 解析功能 - 验证报告

### 功能验证
- ✅ 文件上传: 支持 .xlsx, .csv, .tsv 格式
- ✅ 自动解析: 50MB 文件在 23秒内完成
- ✅ 数据预览: 支持 10万行数据流畅展示
- ✅ 筛选导出: 功能正常

### 质量指标
- 代码覆盖率: 87%
- 性能: 50MB 文件平均 23秒 (< 30秒目标)
- 错误率: 0.05% (< 0.1%目标)

### 经验总结
✅ 做得好的:
- 流式处理有效避免了内存溢出
- 错误处理完善，用户体验良好

⚠️ 需要改进的:
- 前端表格渲染仍有优化空间
- 缺少国际化支持

💡 下次注意:
- 提前调研库的性能表现
- 预留更多时间用于性能优化

---

三、GSD vs Superpowers：如何选择？

这是大家最关心的问题。让我用一个对比表来说明：

3.1 核心对比

维度	GSD	Superpowers
核心问题	上下文衰退 (Context Decay)	缺乏工程纪律 (Engineering Discipline)
解决方法	四步循环 + 文档化	灵活的工具组合 + 最佳实践
工作方式	严格的结构化流程	灵活的渐进式披露
文档要求	高(每个阶段必须产出)	中(按需文档化)
学习曲线	较陡(2-3周适应)	平缓(1-2天上手)
适用规模	中大型项目 (3个月+)	小到中型项目 (1天-3个月)
团队规模	5-50人	1-20人
GitHub Stars	37K+	100K+

3.2 选择 GSD，如果：

• ✅ 项目周期 > 3 个月
• ✅ 团队规模 > 10 人
• ✅ 需求相对稳定，变更可控
• ✅ 对代码质量和文档要求高
• ✅ 有专门的 PM 或 Tech Lead
• ✅ 合规性或审计要求严格

典型场景：

• 大型 enterprise 项目
• 外包或合同项目（需要完整文档）
• 核心基础设施开发（稳定性要求高）
• 分布式团队（异步协作）

3.3 选择 Superpowers，如果：

• ✅ 项目周期 < 3 个月
• ✅ 团队规模 < 20 人
• ✅ 需求变化快，需要快速迭代
• ✅ 追求开发速度和灵活性
• ✅ 团队成员 AI 素养较高
• ✅ 创业公司或初创项目

典型场景：

• 快速原型开发
• MVP 产品验证
• 个人项目或小团队
• 探索性技术研究

3.4 混合策略

不必二选一！

在实际项目中，可以结合两者：

项目生命周期:

启动阶段 ──────→ 开发阶段 ──────→ 维护阶段
   ↓                  ↓                 ↓
Superpowers      核心模块: GSD      Superpowers
(快速探索)       外围模块: Superpowers  (快速修复)

模块级别选择：

模块类型	推荐工作流	原因
核心业务逻辑	GSD	需要高质量和完整文档
UI/前端页面	Superpowers	快速迭代，频繁调整
工具脚本	Superpowers	简单直接，无需复杂流程
API 接口	GSD	需要严格的设计和测试
数据分析	Superpowers	探索性强，需求不明确
基础设施	GSD	稳定性要求高

---

四、实战应用指南

4.1 如何在项目中引入 GSD

步骤 1：试点项目

不要一开始就在所有项目中推行 GSD。

选择一个试点项目:
- 中等规模 (1-2个月)
- 团队熟悉 (3-5人)
- 风险可控
- 有明确的里程碑

目标: 验证 GSD 是否适合你们的团队

步骤 2：团队培训

培训内容:
1. GSD 四步循环理论 (2小时)
2. 实际案例演示 (2小时)
3. 工具使用培训 (1小时)
4. 实战练习 (3小时)

总计: 8小时 (1个工作日)

步骤 3：工具准备

推荐使用以下工具支持 GSD 流程：

## GSD 工具栈推荐

### 文档管理
- Notion / Confluence: 存储 Discuss 和 Plan 文档
- GitHub Wiki: 与代码仓库关联

### 任务跟踪
- Linear / Jira: 管理 Execute 阶段的 TODO
- GitHub Projects: 轻量级替代方案

### 版本控制
- Git: 代码版本管理
- Commit 规范: 关联到具体的 Plan 任务

### 沟通协作
- Slack / Teams: 日常沟通
- Zoom / 腾讯会议: Discuss 阶段的讨论

步骤 4：制定模板

为每个阶段创建标准化模板（本文后面提供完整模板下载）。

步骤 5：逐步推广

第 1 个月: 1个试点项目
第 2-3 个月: 3-5个项目
第 4-6 个月: 全面推广

每个阶段收集反馈，持续优化流程

4.2 常见陷阱与避免方法

陷阱 1：过度文档化

❌ 错误做法:
- 每个细节都写文档
- 文档长度超过代码
- 花费 50% 时间在写文档上

✅ 正确做法:
- 只记录关键决策和约束
- 文档简洁明了，点到为止
- 文档时间控制在 20% 以内

原则: 文档是为了服务开发，不是目的本身

陷阱 2：流程僵化

❌ 错误做法:
- 严格按流程执行，不允许变通
- 即使小改动也要走完整流程
- 为了流程而流程

✅ 正确做法:
- 根据项目规模调整流程严格度
- 小任务可以简化流程
- 保持灵活性，适时调整

原则: 流程是手段，不是目的

陷阱 3：文档与代码脱节

❌ 错误做法:
- 文档写完后就不再更新
- 代码改了，文档没改
- 文档成为"历史遗迹"

✅ 正确做法:
- 代码变更时同步更新文档
- Verify 阶段检查文档一致性
- 定期审查和清理过时文档

原则: 文档应该是活的，与代码同步

4.3 成功案例分享

案例 1：电商平台重构

项目背景:
- 电商平台的订单系统重构
- 团队规模: 15人
- 项目周期: 6个月

应用 GSD:
- Discuss: 花了 2周时间充分讨论需求和约束
- Plan: 制定了详细的 3阶段实施计划
- Execute: 严格按照计划执行，每周 review
- Verify: 每个阶段结束都进行全面验证

成果:
- 按时交付，无重大延期
- Bug 率比旧系统降低 60%
- 代码质量显著提升
- 文档完整，便于后续维护

关键成功因素:
- 高层支持，资源充足
- 团队培训到位
- 严格执行流程
- 持续收集反馈并优化

案例 2：SaaS 产品开发

项目背景:
- B2B SaaS 产品从 0 到 1
- 团队规模: 8人
- 项目周期: 4个月

混合策略:
- 核心模块(支付、权限): GSD
- UI 页面: Superpowers
- API 接口: GSD
- 数据分析: Superpowers

成果:
- 核心功能稳定可靠
- UI 快速迭代，响应需求变化
- 整体开发效率提升 35%

经验教训:
- 不要一刀切，根据模块特点选择
- GSD 适合核心，Superpowers 适合外围
- 需要良好的模块划分

---

五、常见问题解答

Q1: GSD 会不会太慢？

A: 短期看确实会增加前期投入，但长期来看反而更快。

传统方式:
快速开始 → 中途发现问题 → 返工 → 更慢

GSD 方式:
充分准备 → 顺利执行 → 少返工 → 更快

数据:
- 初期: GSD 慢 20-30%
- 中期: 持平
- 后期: GSD 快 30-40%
- 整体: GSD 快 10-15%

Q2: 小项目也需要用 GSD 吗？

A: 不一定。建议：

项目 < 1周: 不需要，直接用 Superpowers
项目 1周-1月: 简化版 GSD (只做 Discuss 和 Plan)
项目 > 1月: 完整版 GSD

原则: 根据项目规模调整流程严格度

Q3: 如何说服团队采用 GSD？

A: 用数据和案例说话：

1. 展示上下文衰退的危害
   - 引用统计数据
   - 分享团队内部的痛点案例

2. 展示 GSD 的价值
   - 成功案例
   - ROI 分析

3. 从小处着手
   - 先在一个项目试点
   - 用结果证明价值

4. 提供支持
   - 提供培训和模板
   - 帮助团队度过适应期

Q4: GSD 可以和 Agile/Scrum 结合吗？

A: 完全可以！它们不是互斥的。

Agile/Scrum: 项目管理框架
GSD: 具体任务的执行方法

结合方式:
- Sprint Planning: 确定要做的任务
- 每个任务: 使用 GSD 四步循环执行
- Sprint Review: 对应 GSD 的 Verify 阶段

实际上，GSD 可以看作是 Scrum 中 Task 级别的执行方法

Q5: 文档太多，维护成本高怎么办？

A: 这是常见问题，解决方法：

1. 精简文档
   - 只记录关键信息
   - 使用模板，减少重复劳动
   - 控制在必要范围内

2. 自动化
   - 用 AI 辅助生成文档草稿
   - 自动生成部分报告
   - 工具集成，减少手动操作

3. 定期清理
   - 每季度审查文档
   - 删除过时内容
   - 合并相似文档

4. 文化培养
   - 让团队认识到文档的价值
   - 将文档纳入绩效考核
   - 奖励优秀的文档实践

---

六、总结与行动指南

6.1 关键要点回顾

GSD 的核心理念：

通过结构化的四步循环（Discuss → Plan → Execute → Verify），将隐式的上下文显式化，对抗 AI 编程中的上下文衰退问题。

四步循环要点：

阶段	目标	关键产出	时间占比
Discuss	明确需求	需求文档	20%
Plan	制定方案	实施计划	25%
Execute	专注执行	执行日志	40%
Verify	验证结果	验证报告	15%

选型建议：

GSD:
- 解决上下文衰退
- 结构化流程
- 适合中大型项目
- 学习曲线较陡

Superpowers:
- 提升开发效率
- 灵活工作流
- 适合小到中型项目
- 快速上手

选择依据: 项目规模、团队特点、需求稳定性

6.2 下一步行动

立即行动（今天）：

• 收藏本文，标记重点
• 访问 GSD GitHub，了解项目详情
• 下载 GSD 模板包（见下方链接）

短期行动（1周内）：

• 选择一个小型项目作为试点
• 尝试完整的 GSD 四步循环
• 记录使用体验和遇到的问题

中期行动（1个月内）：

• 在团队内分享 GSD 经验
• 收集团队反馈，优化流程
• 决定是否在更多项目中推广

长期行动（3个月内）：

• 建立团队的 GSD 最佳实践
• 形成内部培训材料
• 持续改进和完善流程

6.3 学习资源

官方资源：

• 📖 GSD GitHub: github.com/get-shit-done/gsd
• 📚 官方文档: gsd.dev/docs
• 💬 Discord 社区: discord.gg/gsd

中文资源：

• 📝 CSDN 专栏: 搜索 “GSD 工作流”
• 🎥 B站教程: 搜索 “GSD AI编程”
• 📰 知乎话题: #GSD工作流#

---

附录：GSD 完整模板包

我为你准备了完整的 GSD 模板，可以直接复制使用：

Discuss 模板

# [项目名称] - Discuss 阶段

## 功能需求
- [ ] 需求1: 详细描述
- [ ] 需求2: 详细描述

## 技术约束
- 技术栈: 
- 性能要求: 
- 兼容性: 

## 潜在风险
1. 风险1: 描述 + 应对方案
2. 风险2: 描述 + 应对方案

## 成功标准
- [可量化的验收标准]

## 参与者
- [姓名1]: 角色
- [姓名2]: 角色

## 讨论日期
YYYY-MM-DD

Plan 模板

# [项目名称] - Plan 阶段

## 任务分解

### Phase 1: [阶段名称] (预计 X小时)
- [ ] 任务1: 描述 (X小时)
- [ ] 任务2: 描述 (X小时)

### Phase 2: [阶段名称] (预计 X小时)
- [ ] 任务3: 描述 (X小时)

## 技术方案
- 技术选型及理由
- 架构图(可选)
- 接口定义

## 测试计划
- 单元测试用例
- 集成测试场景
- 性能测试指标

## 依赖关系
- 任务A → 任务B (B依赖A)

## 负责人
- Phase 1: [姓名]
- Phase 2: [姓名]

Execute 日志模板

# [项目名称] - Execute 日志

## [日期] [时间段]

### ✅ 已完成
- 任务1: 完成情况 + 实际耗时
- 任务2: 完成情况 + 实际耗时

### ⚠️ 遇到的问题
- 问题1: 描述 + 解决方案
- 问题2: 描述 + 待解决

### 📝 备注
- 任何观察或思考

### 📊 进度
- 计划完成: X%
- 实际完成: Y%
- 偏差: Z%

Verify 报告模板

# [项目名称] - Verify 报告

## 功能验证
- [ ] 需求1: ✅通过 / ❌未通过 + 说明
- [ ] 需求2: ✅通过 / ❌未通过 + 说明

## 质量指标
- 代码覆盖率: XX%
- 性能指标: [具体数值]
- Bug 数量: X个

## 经验总结

### ✅ 做得好的
- [亮点1]
- [亮点2]

### ⚠️ 需要改进的
- [改进点1]
- [改进点2]

### 💡 下次注意
- [注意事项1]
- [注意事项2]

## 后续行动
- [ ] 行动项1
- [ ] 行动项2

---

写在最后

GSD 不是银弹，但它提供了一套系统化的方法来对抗 AI 编程中的上下文衰退问题。

关键在于：不要盲目追随，要根据实际情况灵活应用。

如果你的项目符合以下条件，不妨试试 GSD：

• 项目周期较长（> 1个月）
• 团队规模适中（5-20人）
• 对代码质量有较高要求
• 愿意投入时间建立规范

记住：最好的工作流，是适合你团队的那一个。

---

参考资料：

1. GSD 官方文档 - https://gsd.dev/docs
2. GSD GitHub Repository - https://github.com/get-shit-done/gsd
3. “Hermes Agent vs OpenClaw：架构差异与最佳应用场景解析” - CSDN
4. AI 辅助开发最佳实践指南

---

关于作者：本文作者是一名 AI 工程化实践者，专注于探索 AI Agent 在实际工作流中的应用。欢迎关注我的 CSDN 博客，获取更多 AI 工程化实战经验。

版权声明：本文为原创技术文章，转载请注明出处。如有错误或建议，欢迎在评论区交流讨论。

互动话题：你在 AI 编程中遇到过上下文衰退问题吗？欢迎分享你的经验和解决方案！👇