gstack 完整流程实战：从安装配置到跑通一个真实项目

这篇文章不是概念介绍，而是把 gstack 从安装、配置、常用命令，到一个完整实例流程串起来。

目标很简单：你看完以后，能自己装起来，并且真的跑完一遍 office-hours -> autoplan -> coding -> qa -> ship。

1. gstack 是什么

一句话说清楚：gstack 是一套强主张的 AI 编程技能集（skills）和工作方法论，它不是单纯补几个命令，而是试图把 AI 编程从"直接写代码"升级成"像一个虚拟工程团队协作"。

它最有意思的地方，不是某一个命令特别神，而是它把不同阶段拆成不同角色：

/office-hours：先逼你把问题讲清楚
/plan-ceo-review：站在产品和 scope 的角度砍方案
/plan-eng-review：站在工程实现和边界条件的角度补坑
/autoplan：自动把多轮 review 串起来
/qa：真的开浏览器跑流程、找 bug、修 bug
/ship：测试、版本、提交、推送、PR 一条龙

如果你是独立开发者、小团队，或者想把 AI 工具真正嵌进"从想法到上线"的流程里，gstack 这套东西会比"只让模型生成代码"更有意思。

2. 安装前准备

根据公开文档，gstack 安装前至少要有这些环境：

Git
Bun v1.0+
如果你在 Windows 上，还建议有 Node.js
对应的 AI host 已安装，比如 Claude Code 或 Codex

如果你是 Windows + Codex 这条线，我实测最少先确认：

bash 复制代码

git --version
bun --version
node --version

如果 bun 没装，可以先装：

powershell 复制代码

powershell -c "irm bun.sh/install.ps1|iex"

装完后，如果当前终端还认不出 bun，重开一下终端；或者临时直接用：

powershell 复制代码

& "$env:USERPROFILE\\.bun\\bin\\bun.exe" --version

3. gstack 安装方式

3.1 全局安装

这是最常见的一种。

bash 复制代码

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup

安装脚本一般会做这几件事：

把 gstack 的 skill 信息写进宿主的说明文件
安装各个 skill 目录
安装浏览器相关依赖（比如 /browse、/qa 需要的部分能力）

3.2 指定 host 安装

如果你不是用 Claude Code，而是用其他 agent，可以显式指定 host：

bash 复制代码

./setup --host codex
./setup --host cursor
./setup --host opencode
./setup --host openclaw

对 Codex 来说，核心就是：

bash 复制代码

./setup --host codex

这会把 gstack 安装到 Codex 对应的 skills 目录，而不是 Claude 的目录。

3.3 Team Mode

如果是团队协作，推荐看 Team Mode。它的思路不是把整份 gstack vendoring 进项目，而是：

每个开发者本机全局安装 gstack
仓库只记录"这个项目使用 gstack"
更新由每个开发者本地自动发生

示例：

bash 复制代码

(cd ~/.claude/skills/gstack && ./setup --team) && \
~/.claude/skills/gstack/bin/gstack-team-init required && \
git add .claude/ CLAUDE.md && git commit -m "require gstack for AI-assisted work"

4. gstack 最值得先掌握的命令

如果你第一次用，不要试图一口气记住几十个命令。先记住这几个最关键的就够了：

4.1 规划类

/office-hours
/plan-ceo-review
/plan-eng-review
/plan-design-review
/autoplan

4.2 执行与验证类

/review
/qa
/qa-only
/browse
/ship

4.3 总结和沉淀类

/retro
/learn
/context-save
/context-restore

5. 一条最实用的完整流程

如果你问我：第一次上手 gstack，最推荐怎么跑？

我会建议你直接按下面这条线走：

text 复制代码

/office-hours
    ->
/autoplan
    ->
正常编码实现
    ->
/review
    ->
/qa
    ->
/ship

这条线的价值在于，它把"想法不清楚""实现有边界漏洞""页面看起来能跑但实际流程有 bug""最后发版手忙脚乱"这几类问题，分别放在不同阶段处理。

6. 实战示例：做一个登录页作品 Demo

下面我用一个非常具体的例子讲这套流程：

目标：做一个适合面试展示的、Notion 风格的作品站登录页。

Step 1：先别急着写代码，跑 `/office-hours`

一开始需求其实很散：

要做用户登录
要记住登录状态
最后又收缩成"先只做登录页"

这时候如果直接写，很容易越做越大。

所以先用 /office-hours 把问题收紧。

最后收出来的版本大概是：

纯前端 demo
目标是面试作品
风格偏 Notion
先只做登录页
但必须做得像真实产品入口

这一步最大的价值，不是 AI 帮你产文档，而是它会逼你不断缩 scope，把"模糊的产品想法"压成"可执行的第一版"。

Step 2：跑 `/autoplan`

有了初始设计方向后，再让 /autoplan 接手。

这一层会做几件事：

检查方案是不是 scope 太散
看缺了哪些状态
判断实现方式是不是过重
把 plan 写成更可执行的设计稿

在这个例子里，审完后最重要的结论其实很朴素：

第一版就做静态单页
不要扩到 dashboard
不要伪装成真实安全认证
必须具备 empty / invalid / loading / success / remembered 五种状态

这类结论特别值钱，因为它们直接影响后面的代码质量和完成度。

Step 3：正常编码实现

有了 plan 之后，再开始写代码。

这个示例最后落成的是一个静态项目：

index.html
styles.css
app.js

功能点很清楚：

表单验证
错误提示
登录 loading 态
登录成功态
localStorage 记住登录态
刷新恢复 remembered session
移动端布局

这一步你可以继续用普通对话让模型写代码，也可以自己改。

Step 4：跑 `/qa`

这是 gstack 里我很喜欢的一层。

很多 AI 编程流程的问题在于：代码"看起来对"，但没人真正点一遍。

而 /qa 的强项就是真开浏览器测。

在这个登录页示例里，QA 实际跑出了两个真实问题：

第一次登录成功时，提示文案写成了"Session restored from this device."

这会让"首次登录"和"刷新恢复"两个状态混在一起。
时间格式在英文界面里混进了中文本地化输出。

功能没坏，但成品感明显掉了。

这两个问题都不算"大 bug"，但都很影响作品质量。

也正是这种问题，最适合交给 /qa 去抓。

Step 5：最后再考虑 `/ship`

/ship 的职责不是单纯 git push，而是把下面这些事串起来：

同步主分支
跑测试
看 diff
版本号
CHANGELOG
commit
push
PR

但有个前提：你得在一个真实 git 项目里跑它。

这一点很关键。

如果你只是在一个 projectless 临时目录里做 demo，那么 /ship 是跑不起来的，因为它依赖：

git diff
git log
远程仓库
分支
PR/MR 上下文

所以最合理的用法是：

在临时目录里先把 demo 做出来
QA 通过
再把它放进真实仓库
然后再跑 /ship

7. 我对 gstack 这套流程的实际感受

7.1 最值钱的不是"写代码更快"

很多人看到 skill，第一反应是：是不是 prompt 封装。

但我自己觉得，gstack 最值钱的地方其实不是"加了几个 slash 命令"，而是它把这些阶段拉开了：

想法阶段
方案阶段
编码阶段
浏览器验证阶段
发布阶段

很多时候，项目不是死在"不会写"，而是死在"没收清楚就开始写"、"写完没人真实验证"、"要发版时才发现上下文不全"。

7.2 `/office-hours` 和 `/qa` 是我最推荐最先用的两个

如果你不想一开始就把整套都引进来，最简单的组合是：

text 复制代码

/office-hours
/qa

为什么？

/office-hours 负责防止你一开始就 scope 爆炸
/qa 负责防止你最后交付的是"能运行，但不好用"的东西

中间的编码和 review 你完全可以渐进接入。

7.3 `/ship` 很强，但它是仓库内工作流，不是临时目录工作流

这一点我建议提前想清楚。

/ship 很适合已经在真实项目里开发的分支，但不适合你在一个随手目录里做完 demo 以后硬跑。

最稳妥的姿势是：

用临时目录做实验
用真实仓库存放要提交的结果

这样你既能享受 gstack 的完整流程，又不会在最后一步卡住。

8. 常见踩坑

8.1 没装 Bun

这是最常见的问题之一。

很多人 git clone 了，./setup 一跑，才发现 bun 根本没装。

8.2 装到了 Claude 路径，但自己实际在 Codex 里用

这也是特别容易踩的坑。

比如你可能已经在：

text 复制代码

~/.claude/skills/gstack

下面装好了，但当前实际用的是 Codex。

这时要么重新用：

bash 复制代码

./setup --host codex

要么手动确认 gstack 在 Codex 对应的 skills 目录里已经可见。

8.3 以为 `/ship` 是"万能发布按钮"

不是。

它是仓库内的发布工作流，不是"任意目录都能一键变成 PR"的魔法按钮。

8.4 过度依赖整套流程

gstack 很完整，但不代表你每次都必须从头到尾全用。

比如：

小 bug：直接修就行
页面小改动：先 /qa 就够了
新功能方向不清：先 /office-hours
准备上线前：再补 /review + /qa + /ship

把它当成一套工具箱，而不是宗教，会更舒服。

9. 给第一次上手的人一个建议

如果你今天刚装好 gstack，不要追求"理解所有命令"。

最实用的第一轮上手方式是：

先找一个非常小的目标

例如：做一个登录页、一个表单页、一个 dashboard 卡片页
跑一次 /office-hours

看看它怎么帮你缩 scope
实现出来
跑一次 /qa

让它真的去点、去测、去抓问题
如果这个东西在真实仓库里，再考虑 /ship

你只要完整跑通一遍，后面自然会知道哪些 skill 值得常驻、哪些只在特定场景下用。

10. 小结

如果把 gstack 只理解成"Claude Code 的一组 skill"，其实有点低估它。

它更像是一套对 AI 编程协作流程的强主张：

先把事情想清楚
再把方案审清楚
然后实现
最后用真实浏览器验证
在真实仓库里完成发布

对独立开发者、小团队、作品型项目来说，这套方法很有参考价值。

它未必适合所有团队，但如果你已经不满足于"让 AI 直接吐代码"，而是想把 AI 真正接到开发流程里，gstack 值得认真试一遍。

参考资料

gstack 实战篇（安装、命令、工作流整理）

https://yudesk.dev/docs/notes/gstack/practice
gstack GitHub 仓库

https://github.com/garrytan/gstack

gstack 完整流程实战：从安装配置到跑通一个真实项目

1. gstack 是什么

2. 安装前准备

3. gstack 安装方式

3.1 全局安装

3.2 指定 host 安装

3.3 Team Mode

4. gstack 最值得先掌握的命令

4.1 规划类

4.2 执行与验证类

4.3 总结和沉淀类

5. 一条最实用的完整流程

6. 实战示例：做一个登录页作品 Demo

Step 1：先别急着写代码，跑 /office-hours

Step 2：跑 /autoplan

Step 3：正常编码实现

Step 4：跑 /qa

Step 5：最后再考虑 /ship

7. 我对 gstack 这套流程的实际感受

7.1 最值钱的不是"写代码更快"

7.2 /office-hours 和 /qa 是我最推荐最先用的两个

7.3 /ship 很强，但它是仓库内工作流，不是临时目录工作流

8. 常见踩坑

8.1 没装 Bun

8.2 装到了 Claude 路径，但自己实际在 Codex 里用

8.3 以为 /ship 是"万能发布按钮"

8.4 过度依赖整套流程

9. 给第一次上手的人一个建议

10. 小结

参考资料

Step 1：先别急着写代码，跑 `/office-hours`

Step 2：跑 `/autoplan`

Step 4：跑 `/qa`

Step 5：最后再考虑 `/ship`

7.2 `/office-hours` 和 `/qa` 是我最推荐最先用的两个

7.3 `/ship` 很强，但它是仓库内工作流，不是临时目录工作流

8.3 以为 `/ship` 是"万能发布按钮"