核心内容摘要
PH中文版：解锁无限可能，开启你的数字新纪元
迄今为止我通常只在现有项目中使用LLM工具。
尽管LLM付出了真诚的努力但通过像Claude这样的智能体LLM以“氛围编程”的方式从零开始创建详细项目的尝试往往会失败。
它经常忘记信息或在非生产性循环中消耗令牌。
GSD扩展助Claude克服LLM“上下文腐烂”通过产品导向提问智能规划项目将模糊想法转为具体路线图及执行计划提升LLM开发效率摆脱“氛围编程”困境。
迄今为止我通常只在现有项目中使用LLM工具。
尽管LLM付出了真诚的努力但通过像Claude这样的智能体LLM以“氛围编程”的方式从零开始创建详细项目的尝试往往会失败。
它经常忘记信息或在非生产性循环中消耗令牌。
在这篇文章中我将探讨流行的Claude扩展GSD[2]以及它如何应对上下文腐烂[3]。
LLM领域的一些腐烂现象区分那些对现有模式的真正改进趋势和那些仅仅是为了规避当前限制的趋势是很重要的。
处理“上下文腐烂”属于后者因此它不应被视为仅仅是反映当前LLM技术现状的临时性解决方案。
但它确实存在。
如今著名的论文“Attention is all you need”[4]指导研究人员开发了能够理解意义并模拟理解句子结构的LLM。
但是研究[5]确实表明无论上下文窗口的大小如何较早的令牌比后来的令牌获得更多的关注。
因此我们遇到了腐烂问题。
对于通常的短提示这完全不是问题。
但对于更长的任务研究指出“注意力稀释”就好像LLM是一个无聊的6岁孩子。
对此的一个解决方案是将问题分解为子代理可以处理的任务同时以某种方式保持整体上下文完整。
那么GSD是什么GSD[6]在本文中我将继续使用这个首字母缩略词在Claude之上添加了一些元编程被描述为一个上下文工程层。
我曾研究过早期的规范驱动系统之一AWS的Kiro[7]但这与它不完全相同。
GSD通过提供一个内部任务规划框架来解决上下文腐烂问题该框架明智地利用了Claude Code中已有的子任务。
我将尝试用它来做一个小项目看看效果如何。
正如我在关于Claude Cowork[8]的文章中描述的那样过于雄心勃勃的项目最终只会变成令牌的篝火。
因此我将坚持我经常要求的功能——一个通过ID查看一组JSON对象的前端就像它们是数据库一样。
如果被问及我将提供JSON模板。
我不会指定特定的前端。
安装与规划我通过npx安装了GSD然后我从我的Warp终端在该目录中启动了Claude然后使用了/gsd:new -project。
请注意我使用的是Claude Pro而不是API计划。
然后在GSD检查其启动条件后审问提问开始了注意底部的绿色百分比进度条我假设它正朝着完成迈进。
GSD启动了一个git仓库——所以我所要做的就是像上面那样定义项目。
它很模糊但足以开始对话。
项目的质量现在显然取决于我对GSD问题的回答质量。
它们大体上是正确的问题但数量很多首先它探讨了目标受众——这很像任何产品的发布。
然而在这种情况下答案恰好是上面的第一个选项。
这是为同事准备的。
我没想到下一个问题答案是多种多样的但从技术上讲它也可以是第一个答案我想避免同事直接处理JSON文件。
同样下一个问题也很有针对性。
我最初刻意的模糊性正在被仔细地揭示出来我没有提到用户是否需要编辑数据。
这显然是好的但可能会大大扩展项目。
然而将其设定为一个期望感觉是合理的。
好的。
因此虽然我从未明确说明该应用程序用于查看我使用了“搜索”一词但GSD智能地捕捉到了我的担忧。
这就是GSD区分需求、阶段和总体规划的方式。
在描述了对象的类型、大致数量以及搜索如何开始之后我们来到了目标平台的问题。
因为我增加了编辑的总体要求从而需要处理一组不一致的文件所以我选择了桌面应用程序。
它推荐了一个Web应用程序如果仅仅用于查看我肯定会同意。
到目前为止我所做的只是回答一个明智的设计师会向一个早上醒来有一个自己无法实现的想法的经理提出的相同类型的问题。
第一个多选问题也间接地与CRUD有关为了易于使用我还将目标操作系统固定为macOS。
最后一个规划问题让我深感好笑这强调了规划一个具有明确目的产品的重要性。
我的同事使用这个应用程序始终是首要考虑。
它创建了一个PROJECT.md[9]文件并且令牌开始如预期般消耗。
那个绿色的百分比行/拨盘似乎仍低于30%这很有趣。
它提交了自己的项目和元文件并继续工作。
我让它“YOLO”即非交互式工作并选择了“快速”规划。
我还让它并行处理计划。
如果你即将问这个过程是否让我更深入地思考了我真正需要什么答案是肯定的。
“我没有选择研究选项只是从规划开始实施。
我也没有费心进行验证步骤。
这些是推荐的但会消耗更多的令牌。
总之我们得到了这样的规划配置然后它创建了一个版本1的计划我将其定义为仅一个查看器包含所有预期的基本查看功能。
无需编辑。
因此我们达成了一套合理的v1要求也可以说如果我自己动手做这件事现在我已经完成了一大半但这就是开发者的困境。
人类的氛围编程并不比让LLM来做更明智。
我记得我最初拒绝了路线图但我认为GSD忽略了我还是制作了一个因此它创建了一个简单的路线图包括阶段、目标、要求、标准和验证步骤。
进度仍只有三分之一但我们现在有了更多的文件。
GSD在不同阶段之间分配注意力根据它从我的回答中收集到的信息创建了一个文档网络。
我们终于进入了执行阶段。
它选择了使用SwiftUI这很好。
并且创建了大量文件。
但本周我们就到此为止。
我从未使用过Swift但这种编程形式的意义在于我的工作仅限于方向和规划而非执行。
这是构建好的内容附带验证步骤。
我们下周将对此进行检查。
结论我们已经看到Claude通过GSD能够进行详细的项目规划从一个模糊的项目中提取出合理的步骤。
不同之处在于这种规划结构直接由GSD管理——它们不是由我定义的。
现在为了推动这个过程我确实需要理解规划是如何工作的但问题显然是以“产品”为中心的。
我们都没有直接提及CRUD等设计原则我也从未明确讨论目标实现平台。
在我的下一篇文章中我们将查看GSD刚刚开发的SwiftUI应用程序并了解其性能。