2026 年 4 月：Superpowers、GSD 与 gstack 的重流程阶段

5 min read

2026 年 4 月左右，AI 协作开始从单次生成转向更重的流程组合。前一阶段已经通过 Superpowers 建立了计划、边界和验证意识，但项目继续变大以后，单一流程仍然不够稳定。

这个阶段的问题集中在上下文漂移、任务边界松动、前端质量不稳定、发布前检查不足。模型可以写代码，但不能默认理解完整项目，也不能默认替代审查。

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

当时它们解决了什么

Superpowers 提供的是开发默认动作。它不是单个工具，而是把需求讨论、计划、实现、测试、审查和收尾组织成一套流程。它让 AI 协作不再只是“问一句、改一段”。

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

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

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

问题也出在同一个地方。

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

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

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

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

它留下了三个习惯。

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

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

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

这些习惯后来被收进 Trellis、Aegis 和轻量澄清流程里。Superpowers、GSD 和 gstack 不是失败经历，而是 2026 年 4 月前后第一次认真建立开发系统感的阶段。

参考来源：