最近在 GitHub 上发现了一个爆炸级别的开源项目,短短时间内就狂揽了 37k+ Star,在开发者圈子里引起了不小的轰动。
项目名字很有意思,叫 GSD——也就是 Get Shit Done,一看就是个实干派。
这个项目的作者是一位独立开发者,名字叫 TÂCHES。他的理念很直接:「我不写代码——Claude Code 写代码」。
但他发现,现有的 AI 编程工具要么太复杂,搞了一堆敏捷仪式、故事点数这些企业级流程;要么就是缺少对项目的全局理解,写出来的代码一到规模就掉链子。
于是他决定自己搞一个。不要复杂的企业级角色扮演,就是一个简单高效的系统,能让 AI 真正靠谱地把事情做好。
这就是 GSD 诞生的初衷。
项目简介
GSD 本质上是一个轻量级但功能强大的元提示、上下文工程和规范驱动开发系统。
它专门为 Claude Code、OpenCode、Gemini CLI、Codex、Copilot 和 Antigravity 等 AI 编程工具设计。
它要解决的问题很明确:上下文腐化(Context Rot)。
什么是上下文腐化?
相信用过 Claude Code 写稍大项目的朋友都有体会:刚开始 AI 还挺清醒,写出来的代码质量也不错。
但随着对话越来越长,上下文窗口被填满,AI 就开始胡言乱语了,一会儿忘了之前的约定,一会儿写出来的代码质量直线下降,甚至前后矛盾。
这就是上下文腐化——当 Claude 的上下文窗口被填满时,输出质量就会严重下降。
GSD 就是专门来解决这个问题的。它通过巧妙的上下文工程、XML 提示格式化、子代理编排和状态管理,让 AI 在整个开发过程中都能保持稳定、高质量的输出。
正如项目 README 里说的:「如果你清楚自己想要什么,这东西绝对能帮你建好。没有废话。」
核心亮点
1、告别繁琐,拥抱简洁
GSD 的设计哲学是「系统复杂,流程简单」。
后台做了大量复杂的工作——上下文工程、XML 提示格式化、子代理编排、状态管理,但用户看到的就是几个简单好用的命令。
不需要搞什么 sprint 仪式、故事点数、利益相关者同步、回顾会议这些企业级流程。
你不需要假装自己在运营一个 50 人的工程团队,你只需要是一个想把东西做出来的创造者。
2、每个任务都是全新的上下文窗口
这是 GSD 最核心的创新之一。
它不会让 AI 在一个越来越长的上下文窗口里一直工作,而是把大目标拆解成多个小阶段,每个阶段再拆解成多个原子任务。
每个任务执行时,都会分配一个全新的独立上下文窗口。
这样一来,AI 永远是在「清醒」的状态下写代码,不会被之前的对话历史干扰。200k 纯令牌,零累积垃圾,质量自然有保障。
3、多代理编排,各司其职
GSD 采用了多代理架构,每个阶段都使用相同的模式:一个轻量级的编排器生成专门的代理,收集结果,然后路由到下一步。
编排器从不做重活,它只是生成代理、等待、整合结果。这样整个阶段执行下来,主上下文窗口只保持在 30-40%,会话始终快速响应。
4、原子 Git 提交,可追溯可回滚
每个任务完成后立即获得自己的提交,格式清晰:
abc123f docs(08-02): complete user registration plan def456g feat(08-02): add email confirmation flow hij789k feat(08-02): implement password hashing lmn012o feat(08-02): create registration endpoint
这样的好处显而易见:Git bisect 能找到确切的失败任务,每个任务都可以独立回滚,未来会话中 Claude 有清晰的历史,AI 自动化工作流有更好的可观察性。
快速上手
GSD 的安装非常简单,一条命令搞定:
npx get-shit-done-cc@latest
支持 Mac、Windows 和 Linux 全平台。
安装程序会提示你选择:
非交互式安装(适合 Docker、CI、脚本):
# Claude Code npx get-shit-done-cc –claude –global # 安装到 ~/.claude/ npx get-shit-done-cc –claude –local # 安装到 ./.claude/
OpenCode(开源,免费模型)
npx get-shit-done-cc –opencode –global # 安装到 ~/.config/opencode/
Gemini CLI
npx get-shit-done-cc –gemini –global # 安装到 ~/.gemini/
Codex(技能优先)
npx get-shit-done-cc –codex –global # 安装到 ~/.codex/ npx get-shit-done-cc –codex –local # 安装到 ./.codex/
Copilot(GitHub Copilot CLI)
npx get-shit-done-cc –copilot –global # 安装到 ~/.github/ npx get-shit-done-cc –copilot –local # 安装到 ./.github/
Cursor CLI
npx get-shit-done-cc –cursor –global # 安装到 ~/.cursor/ npx get-shit-done-cc –cursor –local # 安装到 ./.cursor/
Antigravity(Google,技能优先,基于 Gemini)
npx get-shit-done-cc –antigravity –global # 安装到 ~/.gemini/antigravity/ npx get-shit-done-cc –antigravity –local # 安装到 ./.agent/
所有运行时
npx get-shit-done-cc –all –global # 安装到所有目录
跳过权限模式
GSD 专为无摩擦自动化设计。建议使用以下命令运行 Claude Code:
claude –dangerously-skip-permissions
这是 GSD 的预期使用方式——停下来批准 50 次日期和 git 提交就失去意义了。
如果你不想使用该标志,也可以在项目的 .claude/settings.json 中添加粒度权限配置。
快速模式 /gsd:quick
对于不需要完整规划的临时任务,GSD 提供了快速模式:
/gsd:quick > What do you want to do? "Add dark mode toggle to settings"
快速模式给你 GSD 的保证(原子提交、状态跟踪),但路径更快:
- • 相同的代理——规划器 + 执行器,相同的质量
- • 跳过可选步骤——默认情况下没有研究、没有计划检查器、没有验证器
- • 单独跟踪——存放在
.planning/quick/中,不在阶段中
还有几个有用的标志:
- •
–discuss:在规划前进行轻量级讨论以揭示灰**域 - •
–research:在规划前生成专注的研究员。调查实现方法、库选项和陷阱。当你不确定如何处理任务时使用 - •
–full:启用计划检查(最多 2 次迭代)和执行后验证
标志可以组合使用:–discuss –research –full 提供讨论 + 研究 + 计划检查 + 验证。
完整工作流
GSD 的工作流设计得非常清晰,分为 6 个核心步骤:
第一步:初始化项目 /gsd:new-project
一个命令,一个流程。系统会:
你批准路线图后,就可以开始构建了。这一步会创建 PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md 等文档。
如果已有代码? 先运行 /gsd:map-codebase,它会生成并行代理分析你的技术栈、架构、约定和关注点。
然后 /gsd:new-project 就会了解你的代码库,问题会集中在你要添加的内容上,规划会自动加载你的模式。
第二步:讨论阶段 /gsd:discuss-phase 1
这是你塑造实现的地方。你的路线图每个阶段只有一两句话,这不足以按照你想象的方式构建东西。这一步会在任何研究或规划之前捕获你的偏好。
系统会分析该阶段,并根据正在构建的内容识别灰**域:
对于你选择的每个区域,它会一直问到你满意为止。输出的 CONTEXT.md 会直接馈入接下来的两个步骤:
你在这里挖得越深,系统构建的东西就越接近你真正想要的。跳过它你会得到合理的默认值,使用它你会得到你的愿景。
第三步:规划阶段 /gsd:plan-phase 1
系统会:
每个计划都足够小,可以在全新的上下文窗口中执行。没有质量下降,没有「我现在会更简洁」。
第四步:执行阶段 /gsd:execute-phase 1
系统会:
走开,回来时就有完成的工作和干净的 Git 历史。
波浪执行是怎么工作的? 计划根据依赖关系分组为「波浪」。在每个波浪内,计划并行运行。波浪顺序运行。
独立计划 → 同一波浪 → 并行运行 依赖计划 → 后一波浪 → 等待依赖 文件冲突 → 顺序计划或同一计划
这就是为什么「垂直切片」(计划 01:用户功能端到端)比「水平层」(计划 01:所有模型,计划 02:所有 API)并行化效果更好。
第五步:验证工作 /gsd:verify-work 1
这是你确认它实际有效的地方。自动验证检查代码存在且测试通过。但功能是否按照你期望的方式工作?这是你使用它的机会。
系统会:
如果一切通过,你继续前进。如果有什么坏了,你不需要手动调试——你只需用它创建的修复计划再次运行 /gsd:execute-phase。
第六步:重复 → 交付 → 完成 → 下一个里程碑
/gsd:discuss-phase 2 /gsd:plan-phase 2 /gsd:execute-phase 2 /gsd:verify-work 2 /gsd:ship 2 # 从验证的工作创建 PR … /gsd:complete-milestone /gsd:new-milestone
或者让 GSD 自动找出下一步:
/gsd:next # 自动检测并运行下一步
循环讨论 → 规划 → 执行 → 验证 → 交付,直到里程碑完成。
当所有阶段完成后,/gsd:complete-milestone 归档里程碑并标记发布。然后 /gsd:new-milestone 开始下一个版本——与新项目流程相同但是针对你现有的代码库。
你描述接下来要构建什么,系统研究领域,你确定需求范围,它创建新的路线图。每个里程碑都是一个干净的循环:定义 → 构建 → 交付。
写在最后
GSD 给我们展示了一种全新的 AI 编程方式。
它不是简单地让 AI 写代码,而是通过精心设计的工作流和上下文管理,让 AI 能够可靠、稳定地完成整个项目。
对于习惯用 AI 辅助编程的朋友来说,GSD 确实是一个值得尝试的工具。它能帮我们把天马行空的想法,踏踏实实转化成可靠的项目。
正如作者 TÂCHES 所说:「没有企业级角色扮演的废话。只是一个使用 Claude Code 持续构建酷东西的极其有效的系统。」
如果你也受够了 AI 编程时的上下文腐化问题,不妨去试试 GSD。
GitHub:
https://github.com/gsd-build/get-shit-done
如果本文对您有帮助,也请帮忙点个 赞👍 + 在看 哈!❤️
在看你就赞赞我!
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/255020.html