gstack 火起来,真正该看的不是工具,而是流程

这两天很多人在讨论 gstack。有人觉得它像 AI 软件工厂，有人觉得它不过是一堆 prompt 和 slash command 的包装。

但如果只盯着这些表层，容易看漏重点。

我更关心的是，gstack 把一件事做得很显性：AI coding 开始不只是“让模型帮你写点代码”，而是在形成一条更完整的生产流程。

过去大家最关心的是模型能力。能不能写函数，能不能改 bug，能不能补测试，能不能生成页面。

这些能力现在当然还重要，但已经不是最稀缺的部分了。

先做什么，后做什么，哪一步该发散，哪一步该收敛，谁来 review，谁来 QA，什么时候可以 ship，最后怎么复盘。

也就是说，问题开始从“AI 会不会写”，变成“AI 参与开发这件事怎么被组织起来”。

如果把 gstack 的产品外壳先拿掉，它暴露出来的大致是这样一条链路：

想法 -> 方案 -> 实现 -> review -> QA -> ship -> retro

这条链路本身并不神秘。真正重要的是，它把原来混在一个聊天框里的动作拆开了。

以前很多人用 AI coding，本质上是在一个对话里反复切身份。一会儿让它帮我想需求，一会儿让它写实现，一会儿找 bug，一会儿测页面，一会儿写 PR。

这样当然也能工作，但非常依赖人自己不断切上下文、补约束、做判断。

gstack 这种东西真正提供的，不是某个单独命令，而是把这些动作组织成了一套更像生产线的流程。

这条流程为什么重要

因为它解决的不是“多写几个函数”，而是怎么把 AI 变成一套可重复的交付系统。

对单人开发者尤其如此。一个人做产品，最累的地方往往不是不会写，而是要不停在产品、工程、测试、发布之间切来切去。流程一旦被拆出来，很多切换成本就会下降。

更重要的是，它可以迁移

更重要的是，这套流程不只属于 gstack。

放到 Claude Code、Codex、Cursor 这些工具里，它一样成立。放到团队自己的 agent workflow 里，也一样成立。

甚至再往外推，内容生产、研究、运营，其实也都可以套类似的结构：

定义目标 -> 制定方案 -> 执行 -> 审核 -> 发布 -> 复盘

所以 gstack 真正值得研究的，不一定是“要不要用它”，而是它把一种新的 AI 工作方式提前做得很显性。

为什么有人还是觉得它没用

当然，这也解释了为什么很多人会觉得它没用。

因为很多人根本不需要这么重的流程。

如果你只是想让 AI 帮你补几段代码、修个 bug、解释一段报错，那它当然会显得复杂，甚至像包装过度。

所以争议的重点不是 gstack 到底行不行，而是你现在面对的问题，到底是能力问题，还是流程问题。

如果你缺的是一个更强的模型，gstack 解决不了。

但如果你真正缺的是一套能重复跑、能交付、能检查的 AI 工作流，那它至少提供了一个很清晰的样本。