我为什么曾经走向 Superpowers、GSD 和 gstack

5 min read

在刚开始做完整项目时，我对 AI 编程的理解还比较朴素：把需求讲清楚，让模型写代码，再让它修 bug。

等到项目变大以后，这种方式开始暴露问题。上下文容易散，任务边界容易漂，模型也会在没有充分理解项目的情况下直接动手。那时我开始寻找一套更像工程团队的流程。

Superpowers、GSD 和 gstack 就是在这个阶段进入我的工作流的。

当时它们解决了什么

Superpowers 给我的是一套更完整的开发默认动作。它不是单个工具，而是把需求讨论、计划、实现、测试、审查和收尾都组织成一套流程。对当时的我来说，这很有吸引力，因为它让 AI 协作不再只是“问一句、改一段”。

GSD 更偏向 spec-driven 的任务推进方式。它提醒我，不要直接把模糊想法交给模型执行，而是先把目标、上下文和验收方式写清楚。

gstack 则更像一个虚拟工程团队。它把设计、工程、发布、文档、QA 等角色拆开，让复杂任务可以从多个角度被检查。

这套组合真正带给我的，不只是工具能力，而是一种工程化意识：任务需要计划，计划需要边界，结果需要验证，复杂问题不能只靠一次生成。

问题也出在同一个地方。

这些流程本来就是为复杂任务准备的。当它们被放到日常小任务里，成本会很快超过收益。

一个很小的文案修改，也可能被拉进完整计划。一个局部 bug，也可能触发过长的前置讨论。流程没有错，只是它更适合复杂任务，而不是所有任务的默认入口。

我后来开始有意识地做减法。小任务直接处理，复杂任务再引入计划和审查。重复的澄清不再每次完整展开，而是沉淀到项目规则和轻量边界里。gstack 也从默认主流程退到外置专项工具箱，只在浏览器 QA、设计复查、性能检查这类场景里保留价值。

这套重流程没有被我完全丢掉。

它留下了三个习惯。

第一，执行前先确认边界。哪些文件能动，哪些行为不能改，哪些信息不能公开，这些都要提前收住。

第二，复杂任务要保留中间证据。计划、检查结果、构建输出、截图、日志和 diff 都是后续判断的依据。

第三，不同任务需要不同重量的流程。轻量任务不该被流程拖慢，重型任务也不能只靠一句提示词硬冲。

后来我把这些习惯收进 Trellis、Aegis 和自己的轻量澄清流程里。对我来说，Superpowers、GSD 和 gstack 不是一段失败经历，而是我第一次认真建立开发系统感的阶段。

参考来源：