Garry Tan 的私人编程军火库:gstack 把 Claude Code 变成了 23 人的虚拟工程团队
YC CEO Garry Tan 把自己的 Claude Code 配置开源了。23 个 slash 命令覆盖从产品定位到安全审计的全流程。2026 年他个人业余时间搞的产出量是 2013 年的 810 倍。这不是又一个 AI 编码工具是一套完整的软件工厂方法论。 这个项目解决什么问题用过 Claude Code 的人都有同一个感觉很强但每次都要重说一遍上下文。你是谁、你想干嘛、代码风格偏好、测试策略、部署流程……每天重复四五遍跟每次开新项目都得重新招人似的。gstack 的创始人 Garry TanYC CEO前 Palantir 早期员工、Posterous 创始人过去 60 天用自己这套配置业余时间发布了 3 个生产级服务和 40 个功能。他公开的数据显示2026 年到 4 月 18 日为止逻辑代码产出量已经达到了 2013 年全年的 240 倍。这不是 AI 写代码变快了——Claude Code 大家都能用。差别在于你给 AI 输入的 prompt 质量。gstack 的做法是让 Claude Code 扮演 23 个不同的专业角色CEO 角色专门挑战产品假设、工程师角色锁定技术架构、设计师角色审查 UI 表现、QA 角色打开真实浏览器做端到端测试、安全角色跑 OWASP 和 STRIDE 审计。每个角色有一套独立的思维框架和输出规范互相不干扰。对比传统工作流你打开 Claude Code → “帮我写个用户系统” → AI 写代码 → 你 review → 部署。gstack 的工作流/office-hours拆解需求 →/plan-ceo-review验证产品假设 →/plan-eng-review定架构方案 → 实现代码 →/review审查代码质量 →/qa浏览器真机测试 →/land-and-deploy自动发布。每步都有专职角色把关。这就不是一个工具是一套从想法到上线的完整作业流程。 快速上手要求很简单机器上有 Claude Code 和 Git。在 Claude Code 终端里粘贴这一行git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack cd ~/.claude/skills/gstack ./setupsetup 脚本自动检测 Claude Code 配置、注册全部 23 个 slash 命令、生成初始化 CLAUDE.md。30 秒全部搞定。装完后试试这几条/office-hours → 输入你的产品想法CEO 角色追问 6 个关键问题 /plan-ceo-review → 把设计稿/prd 拿给 CEO 角色挑战 /review → 当前分支代码审查自动加载工程规范 /qa https://stg.xxx → 打开真实浏览器做交互测试 /cso → 安全审计包含 OWASP Top 10 和 STRIDE团队协作场景可以用./setup --teamrepo 里的队友打开 Claude Code 时自动同步最新配置零手动升级。⚠️踩坑提示macOS 用户确保 Bun 已装brew install oven-sh/bun/bunWindows 用户需额外装 Node.jsOpenClaw 用户可在 AGENTS.md 里配置 gstack 集成让子代理会话自动加载 gstack首次使用建议先跑/office-hours再跑/plan-ceo-review不要直接跳到代码生成——gstack 的设计哲学是想清楚再动手⚙️ 技术原理核心机制角色即 prompt 模板gstack 底层没有黑盒 API没有特殊运行时。整个仓库只有 7MB核心是 23 个 Markdown 文件每个对应一个 slash 命令。以/office-hours为例prompt 包含 6 个 forcing questions你描述的痛点是你亲身经历过的还是你猜的这个想法最窄的可发布版本是什么——删掉 80% 功能后还剩什么你怎么客观地判断做对了衡量指标是什么前 10 个真实用户是谁怎么找到他们不做这件事的真实代价是什么这个想法 6 个月后还重要吗每个问题后面跟着多轮对话脚本。这六问的目的不是让 AI 产代码而是先排雷——Garry Tan 的原话是“大多数糟糕的产品不是因为代码差是因为在错误的东西上花了太多精力。”为什么 23 个角色而不是 1 个超级 prompt这是 gstack 最聪明的架构决策认知任务分离。单一 prompt 让 AI 同时扮演 CEO、架构师、QA 三个角色会导致输出漂移——AI 会在回答到一半时切换到另一个角色的语气给出不一致的建议。gstack 的每个角色是独立的 Markdown 文件调用时只加载一个角色上下文。一句话需求/office-hours需求拆解 6问/plan-ceo-review产品假设验证/plan-eng-review架构方案定稿人工 AI 实现/review代码审查/qa浏览器端到端/land-and-deploy自动发布比如/cso首席安全官加载完整的 OWASP STRIDE 审计框架和/design-review的视觉检查 prompt 零重叠。竞品对比维度gstack裸 Claude CodeCursor Agent角色定制23 个独立角色无全靠手写 prompt有限自定义指令QA 测试✅ 真浏览器打开测试❌有限安全审计✅ OWASPSTRIDE❌❌团队共享✅ auto-update❌❌安装成本一行命令零配置商业产品跨平台10 种编码工具仅 Claude仅 Cursor核心差异不在技术在经验的形式化表达。Garry Tan 把他 20 年从 Palantir 到 Posterous 到 YC 的产品经验提炼成 23 套对话框架。学过的人读每个 skill 文件都能感受到——这不是教科书式的最佳实践是真摔过跟头后的经验总结。810× 的真实来源很多人看到810 倍会觉得是 AI 生成代码的速度。Garry Tan 自己在文档里做了澄清原始 LOC 会被 AI 膨胀所以他的统计口径是逻辑代码变更量logical lines of code change用 git diff 去除非逻辑变更。但即使扣掉 AI 膨胀因素他的产出量级仍然是传统方式的数十倍。真正的效率来源不是打字快是减少了方向错误的浪费。office-hours 的六问在项目开始前就拦掉了大量其实不需要这个功能的情况。️ 架构分析gstack/ ├── bin/ ← setup 安装脚本、工具命令 ├── skills/ ★ 核心23 个独立角色 .md │ ├── office-hours.md │ ├── plan-ceo-review.md │ ├── plan-eng-review.md │ ├── review.md │ ├── qa.md │ ├── design-review.md │ ├── cso.md (安全审计) │ └── ... ├── lib/ ← TypeScript 工具函数 ├── docs/ ← 方法论文档 各 Host 安装指南 ├── setup ← 入口脚本 └── CLAUDE.md ← 自动加载配置CLAUDE.md 自动加载setup 注册 skillsskills/ 目录23个角色 promptlib/ 工具集connect-chrome真浏览器 QAland-and-deploy发布管道guard保护分支 lint/office-hours 6问框架/plan-ceo-review产品四象限分析设计亮点每个 skill 独立可插拔。想只装 office-hours 不装 QA没问题。想自己写第 24 个角色新建一个 .md 文件就行。gstack 没把你锁死在特定工作流里。不够好的地方严重依赖 Claude Code 生态——虽然 setup 支持 10 种宿主工具但核心体验深度绑定 Claude Code23 个角色之间没有显式的调度依赖——新手上手不知道该先跑哪个命令/office-hours到/ship的完整流程需要人工决策不是全自动管道——gstack 是助手不是自动驾驶对国内开发者来说setup 脚本需要 git clone GitHub网络环境不稳定的情况下可能一次装不完整✅ 优缺点 适用场景3 个优点经验密度极高——每个 skill 背后是真实产品的教训不是教科书式最佳实践。读一遍/plan-ceo-review.md相当于上了一节 YC 的产品课零学习成本——一行命令装完slash 命令命名直观到不需要文档。这本身就是设计哲学“好的工具不需要说明书”可扩展性强——拷贝任意 skill 文件修改即可你的第 24 个角色就是一个新的 .md 文件2 个缺点生态绑定——23 个角色里像/qa、/connect-chrome这类需要真实浏览器的技能依赖 Claude Code 的 MCP 协议换到其他编码工具就直接降级为纯文本 prompt不是银弹——gstack 假设你已经有工程基本功git、CI/CD、测试。如果团队还没有这些基础设施加 gstack 也不会飞出 810× 的产出谁应该立刻试试已经在用 Claude Code 的开发者受够了每次重写 prompt独立开发者和小团队一个人干所有角色的活想学习 Garry Tan 产品方法论的人——skill 文件本身就是教材谁应该再等等刚接触 AI 编码先在裸 Claude Code 里写点东西练手那 23 个角色你已经手写过对应 prompt并且运转良好——那就没必要为了用而用团队有成熟 AI 工程流程的大型组织已有自己的 agent orchestrator