快速摘要： 用 AI 写代码的人一定遇到过这种痛：刚开始写的时候逻辑清晰、代码规范，写到后面 AI 就开始"失忆"——忘记前面定好的规范、生成矛盾的逻辑、甚至开始胡编乱造。这就是所谓的"上下文衰减"（Context Rot）。 GitHub 上有一个叫 GSD（Get Shit Done） 的开源项目，专门解决这个问题。它通过上下文工程、子代理编排和规范驱动开发三板斧，让 AI 在复杂项目中持续输出高质量代码。目前该项目已获得超过 12,000+ Star，MIT 开源许可证，支持 Claude Code、OpenCode、Gemini CLI 等主流 AI 编程工具。往下看有更详细的原理拆解和操作指南。
莫潇羽@无忆研习社 按：这篇文章是我花了不少时间深入研究 GSD 项目后整理出的详细解读，涵盖了原理分析、安装配置、实战流程等多个维度。如果你正在用 AI 辅助编程，却总被"写着写着就变差"的问题困扰，这篇文章值得你认真看完。转载请注明出处：无忆研习社（www.wuyi.wiki）。
一、先搞懂问题：什么是"上下文衰减"？
在正式介绍 GSD 之前，我们有必要先把它要解决的核心问题讲清楚。
你有没有这样的经历？打开一个 AI 编程助手（不管是 Claude Code、Cursor 还是其他什么工具），一开始跟它对话写代码，效果非常好，逻辑清晰、代码规范、甚至还会主动帮你考虑边界情况。然而随着对话越来越长、给 AI 喂的信息越来越多，它的表现开始明显下滑——开始偷懒、开始遗漏之前提过的需求、甚至开始编造一些根本不存在的 API 调用。
这个现象在技术圈里有一个专门的名字，叫做上下文衰减（Context Rot）。
1.1 上下文衰减的技术本质
上下文衰减并不是一个玄学概念，它有着非常清晰的技术成因。2025 年 Chroma Research 发布了一份针对 18 个主流大语言模型的研究报告（涵盖 GPT-4.1、Claude、Gemini 2.5、Qwen3 等），实验数据揭示了一个令人不安的事实：即便是在极其简单的任务上，随着输入上下文长度的增加，模型的性能也会出现显著下降。
举一个具体的例子：Claude Sonnet 在简单的词汇复述任务中，当输入较短时准确率可以达到 99%，而当输入长度增加后，准确率直接跌到了 50% 左右。注意，这不是一个复杂的推理任务，仅仅是"把你看到的词原样输出"这么简单的操作。
上下文衰减的成因主要有三个方面，它们相互叠加，让问题变得更加严重：
第一是"中间遗忘效应"（Lost-in-the-Middle）。 斯坦福大学 2024 年发表在 TACL 上的研究发现，当关键信息位于上下文的中间位置时，模型的表现比信息在开头或末尾时下降超过 30%。模型的注意力呈现 U 形曲线——对开头和结尾的内容关注度高，对中间的内容关注度低。想象一下，你让 AI 在 8 个文件中找一个函数的定义，结果恰好在第 4 个文件里，这就正好落在了模型的"盲区"里。
第二是注意力稀释。 大语言模型基于 Transformer 架构，其核心的注意力机制要求每个 Token 都要与上下文中的所有其他 Token 进行交互计算。10,000 个 Token 意味着模型需要追踪 1 亿个 Token 对之间的关系；100,000 个 Token 就变成了 100 亿个。当 Token 数量持续增加时，每个 Token 能分配到的"注意力预算"就越来越少，模型对关键约束的把握自然就越来越弱。
第三是干扰项的影响。 在真实的编程场景中，AI 在多步骤任务执行过程中会不断累积上下文——每次读文件、搜索代码、探索死胡同产生的信息都会留在上下文窗口中。等到 AI 终于找到了正确的代码段时，它可能已经带着两三万个无关 Token 的"包袱"了。这些无关信息就像噪音一样，干扰模型对真正重要信息的判断。
1.2 上下文衰减在 AI 编程中的具体表现
如果你经常用 AI 辅助编程，下面这些场景你可能再熟悉不过了：
当上下文使用率在 0%-30% 时，AI 的表现处于巅峰状态，输出的代码考虑周全、逻辑严密、格式规范。当使用率超过 50%，你会发现 AI 开始"赶进度"——输出变得简略，有时候会说"我就简洁一点"，开始跳过一些本该考虑的细节。当使用率超过 70%，问题就真的严重了：AI 开始产生幻觉、遗忘之前讨论过的需求、生成与之前代码矛盾的逻辑。
这种情况在简单的小脚本开发中可能感知不明显，但一旦涉及到复杂项目——多文件、多模块、有完整的架构设计和编码规范——上下文衰减就成了一个绕不过去的坎。
莫潇羽@无忆研习社 说句实在话：我自己在使用 AI 编程工具时也反复遇到过这个问题，特别是在做一些稍微复杂点的全栈项目时。前半段写得好好的，后半段就开始各种跑偏，改完这个 bug 又冒出那个 bug，反反复复效率极低。所以当我看到 GSD 这个项目时，我是带着切身的需求去研究的。
二、GSD 项目概览：它到底是个什么东西
2.1 基本信息
GSD 的全称是 Get Shit Done，翻译过来大概是"把活儿干完"的意思——名字很直白，定位也很直白。它是一个轻量级的元提示工程、上下文工程和规范驱动开发系统，专门为 AI 代码生成工具设计。
以下是项目的关键信息：
- GitHub 仓库地址：https://github.com/gsd-build/get-shit-done
- 开源许可证：MIT License
- npm 包名：get-shit-done-cc
- 支持的 AI 运行时：Claude Code、OpenCode、Gemini CLI、Codex
- 支持的操作系统：Mac、Windows、Linux
- 当前版本：v1.21.0+（持续快速迭代中）
GSD 的作者是一位名叫 TÂCHES 的独立开发者。他的出发点很简单——作为一个独立开发者，他的代码几乎完全由 AI 生成，但他发现市面上其他的规范驱动开发工具（如 BMAD、Speckit 等）要么搞得过于复杂（引入了冲刺会议、故事点、Jira 工作流之类的企业级流程），要么缺乏对项目全局的理解。他需要的是一个系统：底层足够强大和精密，但使用层面极其简单。
2.2 核心定位
一句话概括 GSD 的定位：它是 AI 编程工具的"上下文工程层"（Context Engineering Layer）。
普通的 AI 编程流程是这样的：你描述需求 → AI 生成代码 → 代码越写越差 → 不断修 bug → 陷入循环。
而引入 GSD 之后的流程变成了：你描述需求 → GSD 系统提取所有必要信息 → AI 在精心工程化的上下文中生成代码 → 每个阶段独立验证 → 持续高质量输出。
本质上，GSD 解决的不是"AI 写不了代码"的问题（现在的大模型写代码能力已经很强了），而是"AI 写着写着就写不好了"的问题。它通过一套精心设计的工程化流程，确保 AI 在整个项目开发过程中始终处于"巅峰状态"。
三、GSD 的核心原理：为什么它能解决上下文衰减
GSD 之所以有效，并不是因为它发明了什么新的 AI 模型或算法，而是因为它在"如何使用 AI"这个工程问题上做了一套精巧的系统设计。下面我从四个维度来拆解它的核心原理。
3.1 原理一：结构化上下文管理
GSD 的第一个关键设计是把项目信息拆分成多个结构化的 Markdown 文件，每个文件有明确的职责和边界：
- PROJECT.md：项目愿景和整体描述，相当于项目的"灵魂"文件，每次 AI 启动时都会加载这个文件。
- REQUIREMENTS.md：经过范围界定的需求文档，明确区分了 v1 需要做的、v2 需要做的、以及明确不做的内容，并且每条需求都有可追溯性。
- ROADMAP.md：开发路线图，把整个项目拆分成多个阶段（Phase），标注了每个阶段的目标和完成状态。
- STATE.md：项目状态文件，记录了当前的开发进展、已做的决策、遇到的阻塞点，相当于项目的"记忆"——即使你关掉对话重新开始，通过读取这个文件就能恢复上下文。
- CONTEXT.md：阶段级上下文文件，在每个开发阶段之前通过与用户的讨论生成，记录了该阶段的具体偏好和决策。
- PLAN.md：原子级任务计划，每个计划只包含 2-3 个小任务，并且采用 XML 格式结构化组织，确保 AI 能精确理解每个任务的目标和验证标准。
这种做法的核心思想是"不要把所有信息一股脑地塞给 AI"，而是根据当前步骤的需要，只提供最相关的上下文。每个文件都有大小限制，严格控制在 AI 能高效处理的范围内。这样 AI 在任何时候都不会被过多的无关信息淹没。
用一个类比来理解：如果把 AI 的上下文窗口想象成一张办公桌，传统的做法是把项目的所有文档都堆在桌上，让 AI 自己去找需要的信息。而 GSD 的做法是配了一个专业的文件柜，每次只把当前任务需要的文档放到桌上，其他的都归档整理好。
3.2 原理二：子代理编排（Multi-Agent Orchestration）
这是 GSD 最核心的技术亮点。
传统的 AI 编程工作模式是在一个对话窗口里完成所有工作——讨论需求、研究方案、编写代码、调试问题……随着对话的进行，上下文窗口被各种历史信息不断填充，AI 的表现越来越差。
GSD 采用了一种完全不同的架构：轻量编排器（Thin Orchestrator）+ 专用子代理（Specialized Subagent）。
它的工作模式是这样的：你的主会话（Main Session）只充当"调度中心"的角色，负责接收指令、分配任务、收集结果。真正的"脏活累活"——研究方案、编写代码、验证结果——全部交给独立的子代理来完成。每个子代理都会获得一个全新的、干净的 200K Token 上下文窗口，只加载与当前任务直接相关的信息，不带任何历史对话的"包袱"。
子代理完成任务后，只返回精炼的结果（通常只有 50-200 个 Token 的精准上下文），主会话永远不会看到那些被探索过但最终被放弃的 15 个文件、被否决的 3 个方案、以及其他所有的中间过程。
这种设计的效果非常显著——整个阶段执行完毕后，你的主会话上下文使用率通常只有 30%-40%。哪怕你运行了一个包含深度研究、多个计划创建和验证、数千行代码生成的完整阶段，主会话依然保持快速响应。
Anthropic 自己的研究也证实了这个方向的有效性。他们的多代理架构实验中，一个主代理带着多个子代理的组合，在研究任务上的表现比单个代理高出了 90.2%。原因不是子代理更聪明，而是主代理的上下文始终保持干净。
GSD 中有几类关键的子代理：
- Researcher（研究代理）：负责调查技术方案、生态系统、最佳实践，支持四种研究模式——生态系统研究、可行性分析、实现方案研究和对比研究。
- Planner（规划代理）：负责把研究结果转化为结构化的执行计划。
- Executor（执行代理）：负责按照计划编写代码，每个任务完成后立即提交一个原子 Git Commit。
- Verifier（验证代理）：负责检查执行结果是否满足阶段目标。
- Debugger（调试代理）：当发现问题时介入，采用科学调试方法论（假设-测试-验证循环）进行排查。
- Codebase Mapper（代码库映射代理）：用于分析已有代码库的架构、技术栈、代码规范和关注点。
这些代理之间不直接通信，而是通过 Markdown 文件进行间接协作——一个代理的输出文件就是另一个代理的输入信息。这种"文件即接口"的设计非常优雅，既保证了代理之间的信息传递，又避免了相互污染上下文。
3.3 原理三：XML 结构化提示格式
GSD 的第三个关键设计是用 XML 格式来组织任务计划，而不是用自然语言。
这看起来是个小细节，但影响其实很大。自然语言描述任务时存在大量歧义——"实现一个登录功能"这句话在不同人听来可能有完全不同的理解。而 XML 格式的任务描述则是精确的、结构化的，AI 可以明确地知道每个字段意味着什么。
下面是 GSD 中一个典型的任务计划示例：
<task type="auto">
<n>创建登录接口</n>
<files>src/app/api/auth/login/route.ts</files>
<action>
使用 jose 处理 JWT（不要用 jsonwebtoken，会有 CommonJS 兼容问题）。
校验凭证与 users 表进行比对。
登录成功后返回 httpOnly cookie。
</action>
<verify>curl -X POST localhost:3000/api/auth/login 返回 200 + Set-Cookie</verify>
<done>合法凭证返回 cookie，非法凭证返回 401</done>
</task>注意这个结构中的几个关键字段：<n> 是任务名称，<files> 明确指出了需要操作的文件，<action> 给出了精确的实现指导（甚至指出了要避免的技术坑），<verify> 提供了验证命令，<done> 定义了完成标准。AI 拿到这样的计划后，基本不需要做任何猜测就能精确执行。
3.4 原理四：原子提交与可追溯性
GSD 的第四个关键设计是严格的原子 Git 提交策略。
在 GSD 的工作流中，每完成一个任务就立即进行一次 Git Commit。这意味着一个完整的阶段执行下来，你会看到这样的提交历史：
abc123f docs(08-02): 完成用户注册计划
def456g feat(08-02): 添加邮箱验证流程
hij789k feat(08-02): 实现密码哈希处理
lmn012o feat(08-02): 创建注册接口这种做法的好处很多：首先，如果某一步出了问题，你可以用 git bisect 精确定位到是哪个任务引入的 bug；其次，每个任务的变更都可以独立回滚，不会影响其他已完成的工作；第三，清晰的提交历史也是一种上下文——AI 在后续的开发中可以通过查看 Git 历史来理解项目的演进过程。
3.5 原理五：状态管理与跨会话记忆
上下文衰减还有一个容易被忽视的变体——跨会话遗忘。当你关闭 AI 对话窗口再重新打开时，AI 对之前发生的所有事情一无所知。这意味着每次开始新的对话，你都要花大量时间重新向 AI 解释项目背景、已经做了什么、接下来要做什么。如果你正在开发一个需要几天甚至几周才能完成的项目，这种反复的"重新对齐"成本是非常高的。
GSD 通过 STATE.md 文件解决了这个问题。这个文件是一个持续更新的项目状态快照，记录了当前的开发进度、已经做出的关键决策、遇到的阻塞点以及下一步的计划。每当 GSD 完成一个重要操作（比如完成一个阶段的执行、通过一次验证），它都会自动更新 STATE.md。
更巧妙的是，从 v1.21.0 版本开始，GSD 还引入了 YAML frontmatter 同步机制——在 STATE.md 的头部添加了机器可读的结构化状态信息，方便工具和脚本直接解析。这意味着不仅 AI 可以读懂项目状态，自动化工具也可以。
/gsd:resume-work 命令更是把跨会话恢复做到了极致——你只需要在新的对话中输入这一个命令，GSD 就会读取所有的状态文件，完整恢复项目上下文，让你从上次中断的地方无缝继续。
3.6 原理六：验证驱动的质量保障
很多 AI 编程工具的问题不仅仅是"代码写得越来越差"，还包括"即使写差了也没人发现"。AI 往往会自信满满地表示"已完成"，但实际上生成的代码可能有 bug、遗漏了需求、或者与之前的代码产生了冲突。
GSD 在每个关键环节都内置了验证机制。在规划阶段，Plan Checker 会审查计划是否完整、是否与需求文档一致、是否有明确的验证标准。在执行阶段，每个任务计划中的 <verify> 标签定义了具体的验证命令（比如 curl 请求检查接口返回值、运行单元测试等），执行完毕后会自动运行这些验证。在阶段完成后，Verifier 代理会从"目标反向"的角度来检查——不是问"我们做了什么任务"，而是问"要让这个功能正常工作，哪些条件必须为真"，然后逐一检查这些条件。最后还有用户验收测试（UAT），让你亲自确认功能表现是否符合预期。
这种多层次的验证机制确保了问题在每个阶段都能被及时发现和修复，而不是等到最后一刻才暴露出一堆积累已久的隐患。
四、GSD 的完整架构设计
了解了核心原理之后，我们来看看 GSD 的具体架构是怎么组织的。莫潇羽在无忆研习社发表的这篇文章会尽量把架构讲透，方便你理解每个组件的角色。
4.1 设计哲学：内部复杂，外部极简
GSD 的整体架构遵循一个清晰的原则——"极简交互层 + 复杂内部核心"。
对外面向开发者：只有几个简单的斜杠命令（Slash Commands），比如 /gsd:new-project、/gsd:plan-phase、/gsd:execute-phase 等，学习成本极低。
对内在系统底层：封装了上下文工程、XML 提示格式化、子代理编排、状态管理、验证机制等一整套复杂逻辑。
这种设计的好处是显而易见的——你不需要理解上下文工程的理论、不需要手动管理代理的生命周期、不需要自己写 XML 格式的提示，GSD 把所有这些复杂性都封装起来了。你只需要用几个命令告诉它"我要做什么"，它就能帮你高效地完成。
4.2 目录结构与模块职责
GSD 项目的源码按照清晰的职责分层组织：
get-shit-done/
├── agents/ # 子代理编排核心模块
├── assets/ # 静态资源（Logo、演示图等）
├── bin/ # CLI 可执行入口
│ └── install.js # 主安装脚本
├── commands/ # CLI 命令实现层
│ └── gsd/ # 所有 /gsd:* 命令的定义
├── hooks/ # 钩子脚本（上下文监控/状态反馈/版本检查）
│ ├── gsd-check-update.js # 版本更新检查
│ ├── gsd-context-monitor.js # 上下文窗口使用率监控
│ └── gsd-statusline.js # 实时状态反馈
├── scripts/ # 构建与辅助脚本
├── get-shit-done/ # 核心运行时文件
├── docs/ # 文档
│ ├── USER-GUIDE.md # 用户指南
│ └── COMMAND-REFERENCE.md # 命令参考手册
├── package.json # NPM 包配置
└── CHANGELOG.md # 变更日志下面重点说几个关键模块。
agents/ 目录是 GSD 的"大脑"。这里存放了所有子代理的定义和编排逻辑。每个代理都是一个自包含的专家系统，有完整的提示词、方法论和领域知识。GSD 在 v1.15+ 版本中引入了多个重量级代理：Researcher 代理（约 915 行）具备完整的研究方法论和 4 种研究模式；Debugger 代理（约 990 行）具备科学调试方法论和 7 种以上的排查技术。这些代理的规模说明了 GSD 在"看不见的地方"投入了大量的工程工作。
hooks/ 目录中最核心的是 gsd-context-monitor.js——上下文监控钩子。这个钩子会实时监控 AI 代理的上下文使用率，当使用率超过预设阈值时发出 WARNING 或 CRITICAL 告警。这就像是给 AI 装了一个"内存使用率监控器"，在上下文即将过载之前提前预警。
commands/gsd/ 目录存放了所有用户可以直接使用的命令的实现。这是用户与 GSD 系统交互的直接入口。每个命令本质上是一个 Markdown 文件，包含了完整的提示词和工作流定义——这也体现了 GSD "Markdown 即配置"的设计理念。
4.3 项目级文件结构（.planning/ 目录）
当你在一个项目中使用 GSD 时，它会在项目根目录下创建一个 .planning/ 目录，用来存放所有的项目规划文件：
.planning/
├── PROJECT.md # 项目愿景（始终加载）
├── REQUIREMENTS.md # 需求文档（按版本分范围）
├── ROADMAP.md # 开发路线图（按阶段划分）
├── STATE.md # 当前状态（跨会话记忆）
├── config.json # GSD 配置
├── research/ # 研究成果
│ ├── ecosystem.md # 技术生态调研
│ ├── architecture.md # 架构方案研究
│ └── ...
├── phases/ # 按阶段组织的工作文件
│ ├── 01/
│ │ ├── 01-CONTEXT.md # 该阶段的讨论上下文
│ │ ├── 01-RESEARCH.md # 该阶段的研究结果
│ │ ├── 01-01-PLAN.md # 任务计划 1
│ │ ├── 01-02-PLAN.md # 任务计划 2
│ │ ├── 01-01-SUMMARY.md # 执行摘要 1
│ │ ├── 01-VERIFICATION.md # 验证结果
│ │ └── 01-UAT.md # 用户验收测试
│ ├── 02/
│ │ └── ...
│ └── ...
├── quick/ # 快速模式的任务文件
├── milestones/ # 已完成里程碑的归档
└── todos/ # 待办事项这套文件结构是 GSD 实现"跨会话记忆"的关键。即使你关闭了 AI 对话，下次重新开始时，GSD 可以通过读取 .planning/ 目录下的文件恢复完整的项目状态，就好像它一直"记得"之前发生的一切。
五、安装与配置：从零开始上手 GSD
5.1 环境要求
在安装 GSD 之前，你需要准备好以下环境：
- Node.js：GSD 通过 npx 运行，需要 Node.js 环境。建议使用 Node.js 18 或更高版本。
- AI 编程运行时：至少安装以下工具之一——Claude Code（Anthropic 推出的命令行 AI 编程工具）、OpenCode（开源社区的 AI 编程工具，支持多种模型）、Gemini CLI（Google 的 AI 编程命令行工具）、Codex（OpenAI 的编程工具）。
- Git：GSD 的工作流深度依赖 Git 进行版本管理和原子提交。
5.2 一键安装
GSD 的安装非常简单，一条命令搞定：
npx get-shit-done-cc@latest运行这条命令后，安装器会引导你做两个选择：
第一步：选择运行时（Runtime）。 你需要告诉 GSD 你打算配合哪个 AI 编程工具使用。可以选择 Claude Code、OpenCode、Gemini CLI、Codex，也可以选择"全部安装"。
第二步：选择安装位置。 全局安装（Global）意味着 GSD 会对你电脑上的所有项目生效；局部安装（Local）意味着 GSD 只在当前项目中生效。如果你只是想试试看，建议先选局部安装。
5.3 非交互式安装（适用于 CI/CD 和 Docker 环境）
如果你需要在脚本或自动化流程中安装 GSD，可以通过参数跳过交互式选择：
# Claude Code 全局安装
npx get-shit-done-cc --claude --global
# Claude Code 局部安装（当前项目）
npx get-shit-done-cc --claude --local
# OpenCode 全局安装
npx get-shit-done-cc --opencode --global
# Gemini CLI 全局安装
npx get-shit-done-cc --gemini --global
# Codex 全局安装
npx get-shit-done-cc --codex --global
# 同时安装所有运行时
npx get-shit-done-cc --all --global安装完成后不同运行时的文件存放位置不同：Claude Code 会安装到 ~/.claude/（全局）或 ./.claude/（局部）；OpenCode 安装到 ~/.config/opencode/（全局）或 ./.opencode/（局部）；Gemini CLI 安装到 ~/.gemini/；Codex 安装到 ~/.codex/。
5.4 验证安装
安装完成后，打开你选择的 AI 编程工具，输入对应的帮助命令来验证：
# Claude Code / Gemini CLI 中输入
/gsd:help
# OpenCode 中输入
/gsd-help
# Codex 中输入
$gsd-help如果看到 GSD 的帮助信息输出，就说明安装成功了。
5.5 更新 GSD
GSD 的迭代速度非常快（截至目前已有 757 次提交），建议定期更新到最新版本：
npx get-shit-done-cc@latest也可以在 AI 编程工具中直接使用内置的更新命令：
/gsd:update这个命令会检查更新、安装新版本，并显示变更日志。
5.6 卸载
如果需要卸载 GSD，可以用以下命令，它只会移除 GSD 相关的文件，不会影响你的其他配置：
# 卸载全局安装
npx get-shit-done-cc --claude --global --uninstall
# 卸载局部安装
npx get-shit-done-cc --claude --local --uninstall5.7 推荐配置：跳过权限确认模式
GSD 的工作流设计初衷是尽量自动化。在使用 Claude Code 时，GSD 官方推荐用以下方式启动：
claude --dangerously-skip-permissions这个 flag 的作用是跳过 Claude Code 在执行 bash 命令前的逐一权限确认。因为 GSD 在执行阶段会频繁调用 date、git commit、echo 等命令，如果每次都要手动确认，会严重打断自动化流程。
当然，如果你对安全性有更高要求，也可以不用这个 flag，而是在项目的 .claude/settings.json 中精细配置允许的命令列表：
{
"permissions": {
"allow": [
"Bash(date:*)",
"Bash(echo:*)",
"Bash(cat:*)",
"Bash(ls:*)",
"Bash(mkdir:*)",
"Bash(git add:*)",
"Bash(git commit:*)",
"Bash(git status:*)",
"Bash(git log:*)",
"Bash(git diff:*)",
"Bash(git tag:*)"
]
}
}六、完整实战流程：用 GSD 从零构建一个项目
这是整篇文章的核心章节。莫潇羽@无忆研习社 会结合 GSD 的官方文档和实际使用经验，把完整的开发流程一步一步讲清楚。
6.1 流程概览
GSD 的完整开发流程可以用一个循环来概括：
初始化项目 → 讨论阶段 → 规划阶段 → 执行阶段 → 验证阶段 → 循环 → 完成里程碑每个步骤都有对应的命令，我们一个一个来看。
6.2 Step 0：分析已有代码库（可选但推荐）
如果你不是从零开始建项目，而是在一个已有的代码库上工作，那么在初始化项目之前，建议先运行代码库映射命令：
/gsd:map-codebase这个命令会启动多个并行代理来分析你现有代码库的方方面面——技术栈、架构模式、编码规范、已有的关注点等。分析完成后，后续的 /gsd:new-project 就会基于你已有的代码库来提问，而不是从一张白纸开始。
6.3 Step 1：初始化项目
/gsd:new-project这是整个流程的起点。运行后，GSD 会启动一个系统化的引导流程，按顺序完成以下四件事：
（1）深度访谈。 GSD 会围绕你的项目想法进行深度提问，直到它完全理解你的目标、约束条件、技术偏好和边界情况。这不是一两句话的需求描述，而是一次真正的需求挖掘过程。GSD 会追问细节——你的目标用户是谁？有没有特定的技术栈偏好？有哪些已知的限制？你对性能的要求是什么？
（2）领域研究（可选但推荐）。 访谈结束后，GSD 可以启动 4 个并行的研究代理来调查你要做的领域——有哪些成熟的方案？有哪些已知的坑？技术栈的最佳实践是什么？这些研究结果会保存到 .planning/research/ 目录下，成为后续开发的知识库。
（3）需求提取。 基于访谈和研究的结果，GSD 会自动提取出结构化的需求文档，明确区分：v1 必须做的（MVP 范围）、v2 以后做的（延后特性）、明确不做的（排除范围）。
（4）路线图生成。 最后，GSD 把 v1 的需求拆分成多个阶段（Phase），每个阶段有明确的目标和产出物。你审核并批准路线图后，就可以开始正式的开发了。
这一步完成后，.planning/ 目录下会生成 PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md 等文件，以及 .planning/research/ 目录下的研究资料。
6.4 Step 2：讨论阶段——让 AI 理解你的真实意图
/gsd:discuss-phase 1路线图中每个阶段通常只有一两句话的描述，这远远不够 AI 去正确实现它。讨论阶段的目的就是在动手之前，把你对这个阶段的具体想法充分表达出来。
GSD 会分析当前阶段要做的事情，自动识别出其中的"灰色地带"——那些可以有多种实现方式、需要你来做决定的地方。根据阶段内容的不同，它会关注不同类型的问题：
- 如果是一个视觉相关的功能：GSD 会问你布局偏好、信息密度、交互方式、空状态的处理等
- 如果是一个 API 或命令行工具：GSD 会问你响应格式、命令参数设计、错误处理策略、输出详细程度等
- 如果是一个内容系统：GSD 会问你内容的组织结构、语调风格、深度层次、展示方式等
- 如果是一个组织整理类任务：GSD 会问你分组标准、命名规范、重复内容的处理策略等
你在这个阶段表达得越充分，AI 后续的实现就越贴合你的预期。如果你选择跳过这一步，GSD 也会用合理的默认值来推进，但效果自然不如你充分表达了需求的情况。
这一步的产出是 {phase}-CONTEXT.md 文件，后续的研究和规划阶段都会读取这个文件作为输入。
6.5 Step 3：规划阶段——让 AI 做好功课再动手
/gsd:plan-phase 1规划阶段是 GSD 工作流中技术含量最高的环节之一。它分三步完成：
（1）研究。 GSD 启动研究代理，基于你在讨论阶段的决策来调查具体的实现方案。如果你说"我要用卡片布局"，研究代理就会去调查适合你技术栈的卡片组件库；如果你说"需要无限滚动"，它就会去研究无限滚动的最佳实现方式。
（2）制定计划。 基于研究结果，GSD 创建 2-3 个原子级任务计划。这里有一个关键的设计：每个计划的规模都被控制在一个全新的上下文窗口可以完整处理的范围内。这就是为什么 GSD 要把大任务拆成小任务——不是因为小任务更容易写，而是因为小任务可以在一个"干净的"上
