刷 GitHub Trending 看到这个项目，第一反应是——又一个给 Claude Code 加技能包的工具？点进去一看作者是 Garry Tan，YC（Y Combinator）的现任总裁。好家伙，这身份本身就够有说服力了。他自己在 README 里说，靠着这套东西，在兼任全职 CEO 的情况下，60 天内上线了 3 个生产服务、40 多个功能。

说白了，gstack 想干一件事：把你的 Claude Code 从一个“高级代码补全工具”，变成一个拥有 23 个专家角色的“虚拟工程团队”。 从产品经理拷问灵魂，到架构师画图，再到设计师出稿、QA 测试、安全审计、发布工程师开 PR，全流程用 slash 命令串联。

这听起来有点理想化，但看完了它的技能列表和实现方式，我觉得有点东西。咱们来拆开看看。

核心理念：把 AI 当团队用，而不是工具

个人觉得，这是 gstack 最反直觉也最核心的一点。我们平时用 AI 编码，大多是“我有个问题，AI 给段代码”。但 gstack 定义了一套完整的 “虚拟 Sprint 流程”：Think → Plan → Build → Review → Test → Ship → Reflect。

每个环节，都对应一个或多个 slash 命令，扮演不同的专家角色：

• /office-hours：扮演 YC 式的产品合伙人，对你 idea 进行灵魂拷问，输出设计文档。
• /autoplan：自动串联 CEO 评审、设计评审和架构评审。
• /review：扮演 Staff Engineer，做严格的代码审查，还能自动修复明显问题。
• /qa：更离谱，它能启动一个真实浏览器去跑你的测试环境，发现视觉或交互 bug，然后自己尝试修复。
• /cso：首席安全官，用 OWASP + STRIDE 框架做安全审计。
• /design-shotgun：一次生成 4-6 个设计变体让你对比。
• /ship：发布工程师，同步主分支、跑测试、检查覆盖率、最后创建 PR。

这流程不是摆设。上游命令的产出（比如设计文档），会自动成为下游命令（比如架构规划）的输入。这就模拟了一个真实团队里，文档和需求在角色间流转的过程。

23 个技能命令，到底香不香？

老实讲，光看列表会觉得眼花缭乱。我跑了一下它的 README，挑几个我觉得最有意思的说说。

首先是 /office-hours。 这完全是 Garry Tan 作为 YC 总裁的经验灌注。它不会直接让你写代码，而是像创业导师一样，连珠炮式地问你：用户是谁？解决了什么痛点？为什么现在做？市场规模？增长策略？—— 问到你怀疑人生。但这个过程逼你在写第一行代码前，把产品逻辑想清楚，输出一份扎实的设计文档。对独立开发者或技术创始人来说，这个价值可能比写代码本身还大。

然后是 /review 和 /qa 的组合拳。 大多数 AI 审查停留在代码风格和简单逻辑。gstack 的 /review 号称是“Staff Engineer 级别”，会看架构一致性、错误处理、边界条件。更狠的是 /qa，它真的会用 Puppeteer 这类工具打开你给的 Staging 环境 URL，模拟点击，截图对比。如果发现按钮点不了或者样式崩了，它会尝试定位问题并修复。这已经超出了“代码助手”的范畴，进入了自动化测试领域。

还有个细节是 /learn。 AI 没有长期记忆是个痛点。gstack 的 /learn 命令可以让你教它项目特定的代码模式和偏好（比如“我们这个项目都用 async/await，不用 .then”）。这些“记忆”会跨会话保存，并且通过一个叫 gstack-taste-update 的机制，以每周 5% 的衰减率持续更新。说白了，就是用时间衰减来避免早期“错误记忆”污染后期判断。

当然，东西不错但坑也不少。文档写得有点糙，安装虽然号称 30 秒，但前提是你已经装好了 Claude Code、Git 和 Bun。对于刚接触这整套生态的开发者，搭建环境就得先喝一壶。而且，这种高度依赖特定 AI 编码器（Claude Code）和一套复杂技能的工作流，不适合刚入门的人用，学习成本不低。

怎么用？极简安装与团队模式

安装倒真是简单，如果你环境齐全，在 Claude Code 里粘贴下面命令就行：

# 30 秒安装（在 Claude Code 中粘贴）
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack \
  && cd ~/.claude/skills/gstack && ./setup

更让我觉得有野心的是它的 “团队模式”。

# 团队模式（在项目根目录执行）
(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\"

执行后，gstack 的配置会作为几行 Git 钩子写入你项目的 .claude 目录。之后，任何协作者在这个仓库里启动 Claude Code，都会自动获取并启用同一套 gstack 技能（每小时同步一次）。这相当于为整个项目统一了 AI 辅助开发的“基础设施”和“流程规范”，而且不向仓库注入任何供应商锁定文件。

技术栈与生态：不止是 Claude Code

虽然是为 Claude Code 量身打造，但 gstack 也考虑了兼容性。它支持通过 ./setup --host <name> 来适配其他 AI 编码器，比如 OpenAI Codex CLI、Cursor、Factory 等。而且，它与另一个开源多智能体框架 OpenClaw 深度集成，可以作为 OpenClaw 会话中的一个“技能层”来调用。

它的实现是纯 Markdown（技能描述） + TypeScript（技能逻辑），MIT 协议开源。所有技能文件你都可以 fork 了自己改，理论上你能打造自己公司的“虚拟专家团队”。

为了更直观地理解 gstack 如何串联这些角色，我们可以用 Mermaid 图看一下它的核心工作流：

总结与个人看法

总之，gstack 展现了一个非常前沿的思路：不再满足于让 AI 生成片段代码，而是试图用一套精心设计的规则和角色，来管理和引导 AI 完成一个完整的软件交付周期。 Garry Tan 用自己惊人的“生产力数据”（逻辑代码变更量 2026 年是 2013 年的 810 倍）来背书，确实很有冲击力。

它的优势很明显：

1. 流程化：提供了现成的、经过验证的 AI 协作流程。
2. 角色化：每个命令解决一个专业问题，降低了对使用者全面技能的要求。
3. 可协作：团队模式是亮点，能统一团队的 AI 开发标准。
4. 可扩展：开源且技能可定制，有改造空间。

但你也得接受它的局限：

1. 强绑定：深度依赖 Claude Code，迁移到其他 AI 有成本。
2. 复杂度：23 个命令，需要时间熟悉才能流畅使用。
3. 黑盒性：AI 评审和 QA 的结果，你依然需要最终把关，不能全信。

对于独立开发者、创业团队或者公司里想系统性提升 AI 编码效率的 Tech Lead 来说，gstack 绝对值得深入研究，甚至可以直接套用。但对于偶尔写写脚本、不需要完整开发流程的普通开发者，这套东西可能就有点杀鸡用牛刀了。

最后提一嘴，这类项目的发展速度远超我们想象。今天 gstack 定义了 23 个角色，明天可能就有项目定义 50 个。问题的核心可能不再是“AI 能不能写代码”，而是“我们如何像管理一支团队一样，去高效地管理和信任 AI 的产出”。gstack 给了我们一个挺有意思的参考答案。

参考资料：

1. gstack GitHub 仓库: https://github.com/garrytan/gstack
2. OpenClaw 多智能体框架: https://github.com/openclaw/openclaw
3. Y Combinator 官网: https://www.ycombinator.com/