2026 年，软件开发正在经历一场结构性变革。gstack 不是这场变革的全部，但它可能是目前为止最清晰的一面镜子。
先把背景讲清楚
2026 年 3 月 11 日，Y Combinator 现任 CEO Garry Tan 在 GitHub 上开源了一个叫 gstack 的项目。三周之后，61000 Star，8100 Fork，749 个 PR。
这个增长速度在开发者工具领域极其罕见。作为对比，大部分"明星项目"冲到一万 Star 就已经算是社区现象级了，gstack 在头 48 小时就突破了这个数字。
但真正让我想写这篇文章的，不是 Star 数。
而是 gstack 背后折射出的一整套理念转变——从"人写代码"到"人指挥 AI 写代码"，从"一个助手"到"一个团队"，从"单线程开发"到"十几个 Sprint 并行跑"。
这些变化正在 2026 年的开发者社区真实发生，gstack 只是其中最高调的一个案例。
Garry Tan 是谁，他凭什么
先交代背景，不然很多人会质疑"又是一个 CEO 搞噱头"。
Garry Tan 确实不是普通意义上的 CEO。他是 Palantir 的早期工程师和产品经理，Posterous 的联合创始人（后来被 Twitter 收购），还在 YC 内部亲手写了社交网络 Bookface。技术底子是扎实的。
他说自己过去 60 天用 gstack 写了超过 60 万行生产代码，35% 是测试，平均每天 1 到 2 万行。同时还在全职管理 YC，跟上千家创业公司打交道。
在今年 SXSW 的演讲中，他跟 Bill Gurley 说自己每天只睡四个小时，还开玩笑说自己得了"赛博精神病"。虽然是调侃，但你能感受到那种兴奋——他觉得 AI 编程已经到了一个临界点。
当然，TechCrunch 的报道也记录了社区对 gstack 的争议。有创始人直接说"如果他不是 YC 的 CEO，这东西上不了 Product Hunt"。Product Hunt 上也有人评论"这不就是一堆 prompt 吗？"
Garry Tan 自己回应说，gstack 底层跑的是 Bun 运行时，有大量工程实现，比如它能从你 Mac 上所有浏览器安全导入登录 cookies。但争议归争议，项目本身的设计思路确实值得认真分析。
gstack 的核心设计：不是一个助手，而是一个团队
过去两年我们用的 AI 编程工具，不管是 Copilot、Cursor 还是早期的 Claude Code，本质上都是"一个助手"模式——你是开发者，AI 帮你补全代码、写函数、生成测试。你还是那个写代码的人。
gstack 走了一条完全不同的路。它把一个 AI 助手拆成了 23 个角色，每个角色有自己的职责边界和行为规范。你用 slash command 召唤不同角色：
产品层面：/office-hours 模拟 YC 的 Office Hours，6 个 forcing questions 帮你想清楚要做什么；/plan-ceo-review 重新审视产品方向，找需求背后的 10 倍机会。
工程层面：/plan-eng-review 锁定架构、画数据流图、列边界情况和测试矩阵；/review 做 Staff Engineer 级别的代码审查，能自动修的直接修，不确定的标出来问你。
设计层面：/plan-design-review 对每个设计维度打 0-10 分，专门检测 AI 生成的设计"泡沫"；/design-shotgun 生成多个设计变体，在浏览器里开对比面板让你选。
质量层面：/qa 打开真实 Chrome 浏览器，用 Playwright 执行真实的点击、填表、导航、截图，发现 bug 自动修复并生成回归测试；/cso 做 OWASP Top 10 和 STRIDE 威胁建模的安全审计。
交付层面：/ship 跑测试、审计覆盖率、push、开 PR，一条龙；/document-release 自动把 README、ARCHITECTURE 等文档跟代码同步更新。
每个角色都是一个 Markdown 文件定义的 slash command，全部 MIT 开源。技术上没有什么黑魔法，但设计上的巧妙之处在于——这些角色不是孤立的，它们组成了一条完整的 Sprint 流水线。
真正值钱的不是角色，而是流程
如果你只是看到"23 个角色"就觉得"哦，不就是一堆 prompt 嘛"，那确实低估了 gstack。
gstack 真正的价值在于它定义了一套 Sprint 流程：Think → Plan → Build → Review → Test → Ship → Reflect。每个环节的输出是下一个环节的输入：
/office-hours 产出设计文档 → /plan-ceo-review 读取设计文档并审查 → /plan-eng-review 输出测试计划和架构决策 → 开发阶段按照架构决策写代码 → /review 做代码审查 → /qa 按测试计划执行浏览器测试 → /ship 验证所有问题已修复后发布 → /retro 做周回顾统计。
上下文不断传递，每个环节都知道前面发生了什么。这解决了 AI 编程中最头疼的一个问题：上下文断裂。
你让 AI 写代码，它不知道产品需求是什么。你让 AI 做测试，它不知道架构决策是什么。你让 AI 做安全审查，它不知道业务逻辑是什么。gstack 通过流程把这些信息串起来了。
Vercel 今年做过一个有意思的实验，对比了 Agent Skills 和 AGENTS.md 两种方式给 AI 提供上下文。结果发现直接把信息嵌入 AGENTS.md 的方式拿到了 100% 的测试通过率，而 Skills 方式最高只到 79%。原因很简单：嵌入式上下文不需要 AI "决定"要不要去读，它永远在那里。
gstack 的流程设计也是类似思路——每个环节的产出物会被写到项目文件里，下一个角色启动时自动读取。不存在"AI 忘了看上一步的输出"这种情况。
/qa 为什么值得单独讲
所有 23 个角色里，/qa 可能是技术含量最高的一个，也是对开发者最实用的一个。
它不是做静态代码分析，不是跑 linter，不是检查类型。它真的会启动一个 Chrome 浏览器实例，用 Playwright 控制，按照之前 /plan-eng-review 产出的测试计划，逐个流程去跑——点按钮、填表单、导航页面、截图对比。
如果发现了 bug，它会尝试自动修复，然后生成回归测试防止复发。
Garry Tan 说 /qa 让他从同时处理 6 个任务扩展到了 12 个，因为测试环节不再需要人盯了。
这个能力背后依赖的是 Vercel 开源的 agent-browser 项目。它把 Playwright 封装成了一个对 AI 友好的 CLI 工具，用 @e1、@e2 这样的 ref 标识页面元素，让 AI 可以用确定性的方式操作浏览器，而不是靠坐标猜。
另外一个值得注意的命令是 /browse 的 $B connect 功能。它启动你本地的 Chrome，AI 的每一步操作你都能实时看到——浏览器顶部有一道绿色微光标记，告诉你哪个窗口正在被 AI 控制。不是在后台偷偷跑一个无头浏览器，而是你跟 AI 看着同一块屏幕。
这种"可观测性"在 AI 自动化工具中太重要了。大部分人不信任 AI 自动操作浏览器，不是因为 AI 不够聪明，而是因为看不到它在干什么。gstack 把过程透明化了。
跨模型交叉验证：/codex 的思路
gstack 不只能跑在 Claude Code 上，还兼容 OpenAI Codex CLI、Gemini CLI、Cursor 和 Factory Droid。
其中 /codex 命令比较有意思。它直接调用 OpenAI 的 Codex 对同一段代码做独立审查，然后跟 Claude 的审查结果做交叉对比。逻辑很简单：两个不同模型都指出同一个问题，那大概率是真 bug；只有一个模型发现的问题，值得多看一眼。
这个思路在 2026 年的开发者社区越来越流行。根据一篇开发者实践分享的总结，最高效的开发者不是死守一个工具，而是根据任务类型切换不同的 AI——Claude 擅长复杂推理和多文件重构，Codex 擅长确定性的多步任务，Gemini 因为成本低，适合做前期的规划和文档工作。
gstack 的 /codex 把这种多模型策略直接内置成了工作流的一部分，降低了实践门槛。
并行 Sprint：一个人怎么干十几个人的活
gstack 一个人用已经挺好了，但 Garry Tan 真正的玩法是并行。
配合 Conductor（Melty Labs 出品的 macOS 应用），他同时开 10 到 15 个 Sprint，每个跑在独立的 Git worktree 里：一个在跑 /office-hours 探索新想法，一个在做 /review 审查 PR，一个在写功能代码，一个在跑 /qa 测试 staging 环境，其他的在处理不同分支。
Conductor 的核心原理并不复杂——每个 AI agent 在自己的 Git worktree 里工作，互不干扰。worktree 这个 Git 功能从 2015 年就有了，但以前没人在乎。直到 AI agent 需要并行工作，它才变成了一个关键基础设施。
Conductor 的团队之前做了 Melty（一个开源 AI 代码编辑器），他们自己描述过最初的尝试："我们试过把仓库克隆到三个目录，每个目录跑一个 Claude，感觉像是在 Subaru 上绑了个喷气发动机。"所以他们做了 Conductor 来解决编排问题。
并行 Sprint 为什么能跑起来？因为有 gstack 前面那套流程兜底。每个 AI agent 清楚自己该干什么、干到哪里停。没有流程约束的话，10 个 AI 同时跑只会制造混乱。
这种从"单 agent 指挥"到"多 agent 编排"的转变，Google 的 Addy Osmani 在今年的文章里总结得很到位——他把它类比为从"指挥独奏"到"指挥交响乐"的跃迁。开发者的角色不再是写代码的人，而是管理一个 AI 团队的编排者。
安全护栏：让 AI 放心跑起来
让 AI 大面积写代码，安全问题绕不开。gstack 在这个方面设计了几道刹车：
/careful 是最基础的一道。碰到 rm -rf、DROP TABLE、force-push、git reset --hard 这类破坏性命令会先拦住。你说一句 "be careful" 就能激活，随时可以覆盖。常见的构建清理命令（比如 rm -rf node_modules）已经在白名单里了，不会误拦。
/freeze 更精细——把编辑范围锁死在一个目录里。调 bug 的时候最怕 AI "顺手"改了不相关的代码，这个能防住。
/guard 是 /careful 加 /freeze 同时开，最高安全级别，适合在生产环境附近操作的时候用。
/cso 做的是正经的安全审计。OWASP Top 10 加 STRIDE 威胁建模，17 条误报排除规则，只有 8/10 以上置信度的发现才报。Garry Tan 有一条广为流传的推文，说他一个 CTO 朋友用 gstack 的工程审查发现了一个团队都没注意到的 XSS 漏洞。
根据今年行业数据，40% 的企业把安全合规列为 AI 编程采用的首要障碍。gstack 的安全设计虽然不能说完美解决了这个问题，但至少提供了一套可参考的框架。
放在更大的背景下看：2026 年正在发生什么
gstack 之所以引起这么大反响，不仅仅是因为 Garry Tan 的影响力，更因为它踩中了 2026 年 AI 编程领域的几个核心趋势。
趋势一：CLI Agent 成为主流
根据 Pragmatic Engineer 今年的调查，95% 的开发者每周都在使用 AI 工具，75% 的人超过一半的工作由 AI 完成。Claude Code 已经超过 GitHub Copilot 成为最常用的 AI 编程工具，在小型团队中使用率高达 75%。
从 IDE 内的自动补全到 CLI 上的自主 agent，这是一个根本性的转变。AI 不再只是在你写代码的时候给建议，而是可以独立执行复杂任务——理解仓库结构、做多文件修改、跑测试、根据结果迭代。
趋势二：Agent Skills 生态崛起
Vercel 今年 1 月发布了 Agent Skills 规范——一个开放标准，定义了如何给 AI agent 打包可复用的能力。一个 Skill 就是一个目录，里面有 SKILL.md 文件和可选的脚本，AI 在需要的时候自动加载。
这个规范已经被 Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot 等 18 个以上的工具采用。gstack 本质上也是一组 Skills，只不过它比大多数 Skills 更有野心——它不只是给 AI 添加一个能力，而是定义了一整套工作流。
Vercel 还维护了一个叫 skills.sh 的 Skill 市场，你可以按类别、安装量浏览和发现新的 Skills。目前最受欢迎的包括 web-design-guidelines（每周 133K 安装）和 React Best Practices（57 条性能优化规则）。
趋势三：从 Conductor 到 Orchestrator
开发者跟 AI 的关系正在从"一对一对话"变成"一对多管理"。一系列编排工具在 2026 年涌现：Conductor、Vibe Kanban、Claude Code Agent Teams、GitHub Copilot Coding Agent、Claude Squad 等等。
Claude Code 自己也在实验 Agent Teams 功能——设一个环境变量就能让一个 Claude Code session 变成团队 leader，自动在独立的 tmux pane 里创建 teammate。每个 teammate 负责特定的文件范围，防止互相覆盖。
Replit 的创始人 Amjad Masad 说得比较直白："我们不再关心专业编程者了，我们关心的是编排者。"他的公司正在专门招能管理并行 AI 工作流的新人。
趋势四：信任仍然是瓶颈
Fortune 昨天刚发了一篇文章，标题就是"在 Vibe Coding 时代，信任才是真正的瓶颈"。AI 写代码的速度已经超过人类能打字的速度了，但问题是——你敢不敢用？
Claude Code 自己的源码本周还因为一个打包失误被意外泄露了。Apple 也在加大力度打击"Vibe Coding 应用"，把 AI 驱动的应用构建工具 Anything 从 App Store 下架了。
对企业来说，AI 生成的代码不仅要能跑，还要正确、安全、合规。这也是为什么 gstack 的安全护栏设计、交叉模型验证、完整的审查流程，在实际生产环境中比"写代码更快"更有价值。
几个容易被忽略但很实用的细节
聊完大趋势，回到 gstack 本身，有几个小功能我觉得值得单独提：
/learn：跨会话积累项目经验。你踩过的坑、偏好、最佳实践，下次开会话还记得。用得越久越顺手。这个设计跟 Supermemory（目前 AI 记忆领域排名第一的工具）的理念一致——不是简单的 RAG 检索，而是持续追踪和更新。
/retro：周回顾。能跨项目、跨 AI 工具统计你的产出。Garry Tan 说的"一周 14 万行代码"就是 /retro 跑出来的数据。这个功能看起来简单，但对于量化 AI 编程效率非常有用。
/document-release：每次 /ship 会自动调用，把 README、ARCHITECTURE、CONTRIBUTING 这些文档跟代码同步更新。写代码的人最烦更新文档，这个直接帮你干了。
遥测设计：默认关闭，opt-in 才发送，只收集 Skill 名称、耗时和成功/失败。在一个大家对隐私越来越敏感的时代，这种设计值得点赞。
值得思考的几个问题
gstack 的设计很漂亮，但我觉得有几个问题值得保持清醒：
第一，"一个人干二十个人的活"这个叙事要谨慎看待。 Garry Tan 自己说每天 1-2 万行代码，但我们不知道这些代码的复杂度分布。AI 生成的代码中有大量是样板代码、测试代码、文档代码，这些确实可以大量自动化。但核心业务逻辑、架构决策、性能优化，目前还是需要人来把关。
第二，上下文窗口压力是真实的。 Product Hunt 上有人问 gstack 在连续跑多个 Skill 的时候怎么处理上下文压力。这确实是目前 AI coding agent 的一个硬性限制。虽然 Claude 的上下文窗口已经到了 100 万 token，但连续跑 Plan → Build → Review → Test → Ship 整条流水线，累积的上下文还是可能超过上限。
第三，成本问题不能回避。 根据 Gartner 的数据，2026 年企业开发者平均每天花 380 美元在 AI 编程工具上。同时跑 15 个 Sprint，每个都在调用 API，费用会非常可观。对于个人开发者或小团队来说，需要认真评估 ROI。
第四，gstack 的本质还是 Prompt Engineering。 说到底，每个 Skill 文件就是一组精心设计的 prompt。Prompt 的质量高度依赖模型的能力。今天在 Claude Opus 4.6 上跑得很好的 prompt，换一个模型可能表现完全不同。Vercel 的实验也证实了这一点——同一个 Skill 在不同模型上的表现差异很大。
我的实际建议
如果你现在正在做独立开发或者小团队开发，我觉得 gstack 值得尝试，但建议分步走：
第一步：先搭环境。 安装很简单：
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup
第二步：先用单个 Skill 熟悉。 别一上来就 23 个角色全开。先试 /review（代码审查）和 /plan-eng-review（工程审查），这两个对日常开发帮助最大，学习成本最低。
第三步：感受流程。 等你用熟了单个 Skill，试着跑一次完整的 Sprint 流程：/office-hours → /plan-eng-review → 写代码 → /review → /qa → /ship。体验一下上下文传递的感觉。
第四步：谨慎尝试并行。 如果你觉得单线程已经不够了，再去研究 Conductor 或 Claude Code Agent Teams，开两三个并行 Sprint 试试。
第五步：积累 /learn 数据。 用得越久，/learn 积累的项目经验越多，AI 就越理解你的代码库和偏好。这个复利效应是 gstack 设计中最被低估的部分。
写在最后
2026 年的软件开发正处在一个转折点。
两年前，AI 编程是"帮你补全代码"。一年前，是"帮你写函数"。今年，是"帮你跑整个开发流程"。
Andrej Karpathy 说他从去年 12 月起就基本没打过一行代码。Peter Steinberger 用 AI agent 几乎独自打造了 24.7 万 Star 的 OpenClaw。Garry Tan 边当 YC CEO 边日产万行代码。
这些不是 PR 噱头。它们是一个新范式正在成形的信号。
开发者的角色正在从"写代码的人"变成"管代码的人"。想清楚要做什么、做架构决策、判断质量好坏，这些还是得你来。但实际的编码、审查、测试、部署、文档更新，越来越多地可以交给 AI。
gstack 不是这个范式的终极答案——它还太新、太依赖特定模型、太依赖 Garry Tan 个人的工作风格。但它提供了目前为止最完整的一套参考实现。
对于中国的开发者来说，尤其是出海的独立开发者和小团队，gstack 的价值可能比在硅谷更大。因为我们最缺的不是写代码的能力，而是一个人要同时扮演 PM、设计师、工程师、QA、运维所有角色的那种压力。gstack 至少能帮你把其中的大部分交出去。
值不值得花时间研究？我觉得绝对值得。
GitHub 地址：github.com/garrytan/gs…
本文信息截至 2026 年 4 月 3 日。AI 编程领域变化极快，文中提及的数据和工具状态可能已经更新。
