开发者们正在经历一种新型职业焦虑：和AI结对编程时，聊着聊着它就"失忆"了。上下文窗口被塞满后，AI助手开始胡言乱语，之前确认过的需求反复推翻，代码风格前后矛盾。这种现象被称为"上下文腐烂"（context rot），正在吞噬AI辅助编程的效率红利。

一套名为Get Shit Done（GSD）的元提示框架试图终结这种混乱。它专为Claude Code、OpenCode、Gemini CLI、Codex等AI编程助手设计，用结构化的六阶段工作流替代自由散漫的对话模式。核心思路很简单：每个开发阶段都换用新鲜上下文，不让历史对话成为负担。

打开网易新闻 查看精彩图片

GSD的诞生源于独立开发者的真实痛点。传统工程管理工具——冲刺会议、故事点估算、利益相关方同步——对单人或小团队而言是过度设计。这些流程本是为大型组织协调而生，却拖慢了真正想"把事情做完"的人。GSD选择做减法，砍掉一切不直接产生代码的仪式。

打开网易新闻 查看精彩图片

框架由六个指令驱动，形成闭环：

/gsd-new-project 启动新项目，通过问答完成调研、需求梳理和路线图制定；已有代码库则先用 /gsd-map-codebase 分析技术栈、架构和规范，让后续问题更精准。

/gsd-discuss-phase 1 进入讨论阶段，将模糊的愿景转化为具体决策。路线图在此阶段从高层设想落地为可执行条目，关键设计选择被明确记录。

规划阶段用 /gsd-plan 把路线图拆解为技术规格，执行阶段 /gsd-do 驱动编码实现，验证阶段 /gsd-verify 检查交付物是否符合预期，最终 /gsd-ship 完成部署。每个阶段结束后，上下文被有意"重置"，AI以干净状态进入下一环。

这种"分阶段、清上下文"的设计直击AI编程的隐秘成本：开发者被迫在对话中反复重申已知信息，或眼睁睁看着AI在信息过载后输出质量骤降。GSD把隐性负担显性化，用指令强制隔离阶段边界——本质上是用工程纪律补偿AI的内存局限。

打开网易新闻 查看精彩图片

值得玩味的是GSD的适用范围声明。它不假装解决所有场景，而是坦诚定位为"spec-driven development workflows"（规格驱动开发工作流）的工具。这意味着它假设开发者能产出清晰的需求文档，而非在混沌中探索。这种自我限定反而增强了可信度：承认约束，比夸大承诺更诚实。

框架的流行也折射出AI工具生态的演进方向。早期助手比拼的是模型能力——代码生成速度、语言覆盖度；现在战场转向"人机协作界面"的设计。如何让开发者高效地喂给AI正确信息、如何管理AI的"记忆"、如何防止对话失控，这些曾经属于UX设计的议题，正在变成AI编程的核心竞争力。

GSD的六指令结构本质上是一种"提示工程的产品化"。它把有效的对话模式封装为可复用模板，降低了个体开发者的试错成本。但这也带来一个开放问题：当AI的上下文窗口持续扩大——从4K到128K再到200K——这种分阶段清窗的策略是否会过时？还是说，人类对结构化工作流的需求，独立于技术参数而存在？

至少目前，独立开发者们找到了一个务实的中间地带：不等待完美的AI，用纪律性的方法放大现有工具的价值。GSD的名字本身即是宣言——少谈方法论，多交付代码。