我用 Claude Code 写代码有一阵子了，越用越顺手，也越用越心虚。顺手是因为它写得快，心虚是因为全凭感觉：想到哪写到哪，设计靠脑补，review 靠眼力，上线靠运气。gstack 吸引我的地方就在这里：它不给你换一个更强的模型，而是直接给你配了一支“虚拟团队”——CEO、设计师、工程经理、发布经理、文档工程师、QA，各就各位，全是斜杠命令。
这套东西是 Garry Tan 开源的，他是 Y Combinator 的总裁兼 CEO，这是他每天真正在用的 Claude Code 配置，不是写出来做样子的。今天一天它就涨了 600 多星，总星数已经快 14 万。安装就两行命令，克隆到 ~/.claude/skills/gstack 再跑 ./setup，官方说 30 秒，前提是你已经装了 Claude Code、Git 和 Bun 1.4.2 以上。装完不用学什么新工具，在 Claude Code 里敲斜杠命令就行，全部是 Markdown 写成的技能，MIT 协议，免费，没有高级版。
上手我建议先跑三个命令，就能摸到它的脾气。第一个是 /office-hours：你描述要做的东西，它不急着写代码，先反问你六个问题，挑战你的想法本身。README 里那个例子我印象很深：你说想做个“每日简报应用”，它听完你的痛点直接说，你做的根本不是简报应用，是一个私人幕僚长 AI——它听的是你的痛苦，不是你的功能清单。然后它会写一份设计文档，后面的技能都接着读这份文档。第二个是 /review：扫一个有改动的分支，专门找那些能过 CI、却会在生产环境炸掉的 bug，明显的直接帮你修好，拿不准的列出来等你点头。第三个是 /ship：跑测试、核对覆盖率、检查文档，最后推上去开 PR。
真正让我觉得它不一样的，是流程是串起来的，不是一堆散命令。想清楚、定计划、写代码、做评审、跑测试、发版、复盘，每一步的产出都是下一步的输入，/office-hours 写下的设计文档，/plan-ceo-review 会接着读；/plan-eng-review 定好的测试计划，/qa 会拿去执行。另一点是它有护栏：/careful 会在 rm -rf、删表、强制推主分支这类危险操作前拦你一下，主分支强制推送和删根目录是直接拒绝的；/freeze 能把编辑范围锁在一个目录里，调试时不怕改错地方。这些东西平时感觉不到，出一次事就知道值多少钱。
坑我也列清楚。第一，Windows 只是最低限度支持，核心技能能用，别的都不保证；Aside 浏览器只在 macOS 上有，Linux 和 Windows 的浏览器技能走它自带的 Chromium，Ubuntu 24.04 以上还可能要加环境变量关沙箱。第二，Bun 版本卡得很死，低于 1.3.3 安装直接拒绝，先把 Bun 升上去再装。第三，外部评审默认是开着的，/review 这类技能会把你的代码发给 Codex 或 Claude Code 复核，用的是你自己的登录，第一次会弹提示，介意的人先在配置里关掉。第四，这项目膨胀得很快，介绍里还写着 23 个工具，技能表里如今已经有四五十个，别想着一次全学会，先用 /office-hours、/review、/ship 这三个，顺了再慢慢加。
适合谁？我觉得是三类：每天用 Claude Code 写代码、已经觉得“光会写不够了”的人；技术出身还想自己下场写代码的创始人；带小团队、想把 review 和发版流程固定下来而不是靠人盯的技术负责人。反过来，如果你只是偶尔让 AI 写个小脚本，或者根本不用 Claude Code，那这套东西跟你没关系。另外提醒一句，Garry Tan 的流程很“YC 味”——强势、爱反问、逼你把问题想清楚，喜欢自由发挥、不爱被流程管着的人，用起来会觉得啰嗦。
上手建议：先别碰团队模式，就在自己的一个项目上跑一圈——/office-hours 聊一个真实需求，/review 扫一个分支，/ship 发一个 PR。这三步都顺手，你再决定要不要让团队模式自动给队友也装上。
