gstack 是什么：一支可协同的虚拟工程团队

gstack 是什么：把 Claude Code 变成一支可协同的虚拟工程团队

基于 GitHub 仓库 garrytan/gstack 的 README 内容整理与翻译。

如果把最近这一波 AI 编程工具的发展趋势浓缩成一句话，大概就是：

真正拉开差距的，已经不只是“会不会补全代码”，而是谁能把多个 AI 角色组织成一套能持续交付的软件生产流程。

Garry Tan 开源的 gstack，就是围绕这个思路设计的一套工作流。 它不是一个新的编程语言，也不是一个新的 IDE，而是一组面向 Claude Code 等代理式编程工具的技能体系和流程约定。

在作者的描述里，gstack 想做的事很明确：

• 让一个人也能像一个小型高质量团队那样推进产品；
• 不再把 AI 仅仅当作“补全器”，而是当作 CEO、工程经理、设计师、审查者、QA、发布工程师等不同角色的集合；
• 用一套固定顺序的技能，把想法、方案、实现、评审、测试、发布和复盘串起来。

2026 年的 GitHub 提交活跃度

README 中展示了作者 2026 年的 GitHub 活跃度，用来说明“同一个人，在不同工具时代下的交付速度差异”。

2013 年构建 Bookface 时的 GitHub 提交活跃度

作者同时给出了 2013 年的对比图，强调差异并不来自“人变了”，而是工具和工作流发生了变化。

一、gstack 想解决的根本问题

README 一开始引用了 Andrej Karpathy 在 2026 年 3 月播客中的一句话，大意是：他几乎已经很久没有自己手打一行代码了。 Garry Tan 由此追问了一个问题：

为什么现在有人可以几乎单枪匹马，做出过去需要二十人团队才能推进的事情？

他的答案不是“因为模型更强了”这么简单，而是：

• 有了代理式编程工具；
• 更重要的是，有了可复用的角色分工和流程模板；
• 一个会组织 AI 的人，可以获得接近小团队的产能。

所以 gstack 的定位，并不是一组零散命令，而是一座“开源软件工厂”。

二、它不是单个技能，而是一整条冲刺流水线

gstack 最重要的设计理念，是把软件迭代看成一条完整的 sprint，而不是一堆互不相干的小工具。

README 里把这条流程概括成：

Think → Plan → Build → Review → Test → Ship → Reflect

也就是：

• 先重新理解问题；
• 再做产品和工程规划；
• 然后进入实现；
• 接着做代码审查与质量把关；
• 再进行真实测试；
• 最后发布并复盘。

作者强调，这些技能并不是孤立工作的，而是前一个步骤会为后一个步骤产出可消费的结果。 比如：

• /office-hours 会先写出设计文档；
• /plan-ceo-review 会基于设计文档重新挑战问题定义；
• /plan-eng-review 会把技术结构、测试矩阵和失败路径写清楚；
• /qa 会接着读取这些信息去做真实验证；
• /review 会在发布前帮你抓那些 CI 不一定能发现、但上线会炸的缺陷。

这个思路其实很像把“团队协作中的上下游信息传递”显式编码进技能链路里。

三、gstack 把 AI 拆成了哪些角色

README 中，gstack 把不同 slash command 背后对应的“专家角色”讲得非常具体。

其中最核心的几类包括：

1. 产品和方向类

• /office-hours 用 YC 式的追问方式，先挑战你对产品的表述，逼你把需求从“功能描述”重新提炼成真实痛点。
• /plan-ceo-review 用 CEO / Founder 视角重新思考问题，试图找出请求里藏着的“10 星级产品机会”。

作者给的例子很有代表性： 用户一开始说自己要做一个“daily briefing app”，但代理在深入追问后，可能会把它重新定义成“一个个人 Chief of Staff AI”。 也就是说，AI 不是直接照着功能单子做，而是先纠偏问题定义。

2. 工程规划类

• /plan-eng-review 负责把架构、数据流、状态机、边界情况、失败模式和测试计划锁定下来。
• /autoplan 把 CEO、设计、工程三类规划自动串起来，快速形成一份可执行的 reviewed plan。

这类技能的目标，是在真正写代码前，先把“隐藏假设”暴露出来。

3. 设计和体验类

• /plan-design-review 站在高级设计师视角，对设计质量逐维度打分，并指出离“10 分设计”还差什么。
• /design-consultation 从零构建设计系统，研究竞品、提出更大胆的创意方向。
• /design-review 不只是评审，还会直接动手修设计问题。

作者显然非常警惕所谓的“AI slop”，也就是那种看起来能跑、但视觉和体验都过于模板化的产物。

4. 质量与安全类

• /review 从资深工程师视角抓生产风险，自动修掉明显问题，指出遗漏。
• /qa 以 QA Lead 的方式打开真实浏览器、真实点击、真实复测，并为发现的问题生成回归测试。
• /qa-only 只做报告，不改代码。
• /cso 用 OWASP Top 10 和 STRIDE 模型做安全审视。

这说明 gstack 并不把“生成代码”视为终点，而是把后续验证也纳入同一套工作流中。

5. 发布与运维类

• /ship 同步主分支、跑测试、检查覆盖率、推送并创建 PR。
• /land-and-deploy 合并 PR、等待 CI、执行部署并验证线上健康状况。
• /canary 做部署后的监控观察。
• /benchmark 跑页面性能基线和前后对比。
• /document-release 在发布后自动更新项目文档，避免 README 和实际实现脱节。

这类角色设计得很完整，基本把从“代码写完”到“安全落地上线”之间的大部分收尾工作都覆盖到了。

四、gstack 的核心价值，不是命令数量，而是“角色编排”

如果只看 README 里的命令列表，你会觉得这像是一组命令面板。 但真正有价值的，不是它有 20 多个 slash command，而是这些命令背后有明确分工：

• 谁负责挑战需求；
• 谁负责收敛范围；
• 谁负责锁技术方案；
• 谁负责揪生产风险；
• 谁负责做真实浏览器验证；
• 谁负责上线和回归。

这背后其实是一个非常成熟的管理思路：

把团队中本来需要多人完成的“角色职责”，转译成一个人也能顺序调用的 AI 工作流。

从这个角度看，gstack 更像是“AI 时代的软件组织方法”，而不只是“一个技能仓库”。

五、作者推荐的新手入口

README 给出的 Quick Start 很克制，并没有让你一次性把所有技能全用上。 它建议先做几步：

1. 安装 gstack
2. 运行 /office-hours
3. 针对某个功能运行 /plan-ceo-review
4. 在有代码改动的分支上运行 /review
5. 在 staging URL 上运行 /qa

然后就先停下来。

作者的意思很直接： 你不需要第一天就把整套系统完全掌握，只要跑通这几步，就能判断自己是否真的需要这套方法。

这个建议很实用，因为很多工具的问题不在功能不够强，而在于上手成本太高、第一天就想让用户学完整套哲学。

六、它支持 Claude，也支持 Codex、Gemini CLI、Cursor

README 特别提到，gstack 不只服务 Claude Code。 只要宿主代理支持 SKILL.md 标准，它就可以工作。

对于 Codex、Gemini CLI、Cursor 等兼容环境，README 给出了两类安装方式：

安装到单个仓库

git clone https://github.com/garrytan/gstack.git .agents/skills/gstack
cd .agents/skills/gstack && ./setup --host codex

安装到当前用户环境

git clone https://github.com/garrytan/gstack.git ~/gstack
cd ~/gstack && ./setup --host codex

README 还说明：

• repo-local 安装适合跟项目一起分发；
• user-global 安装适合个人长期使用；
• setup --host auto 会自动检测本机上可用的代理环境。

这意味着 gstack 想做的不是绑定某一个 AI 产品，而是成为一层可迁移的“代理工作流基础设施”。

七、它还提供了一组“安全护栏”能力

除了主工作流技能外，gstack 还有几类很务实的辅助工具：

• /careful 在执行高风险命令前先发出警告；
• /freeze 把编辑范围锁定到某个目录，避免误改；
• /guard 同时开启高风险提醒和编辑锁；
• /unfreeze 解锁编辑边界；
• /setup-deploy 为发布和部署流程做一次性配置；
• /gstack-upgrade 更新到最新版并提示变更。

这些能力看起来不起眼，但对真实项目非常关键。 因为随着代理越来越能自主执行，真正麻烦的往往不只是“不会写”，而是“写到了不该碰的地方”。

八、并行代理为什么需要流程，而不只是更多代理

README 后面还提到一个很有意思的方向：Parallel sprints。 也就是多个代理会话并行推进不同任务。

作者在这里给出的判断非常值得注意：

如果没有流程，十个代理就只是十个混乱源；如果有流程，每个代理就知道自己该做什么、何时停下。

这句话其实点到了多代理协同最难的地方。 难点从来不只是“能不能并行”，而是：

• 并行任务之间怎样分工；
• 谁产出文档、谁消费文档；
• 哪一步是探索，哪一步是实现，哪一步是验收；
• 什么情况下应该停止继续写代码、转入审查或测试。

从这个角度说，gstack 最像的不是一个插件合集，而是一套让多代理真正可控运转的作业规范。

九、适合哪些人使用

README 里明确写了三类典型用户：

• 创业者和 CEO，尤其是仍然亲自下场做产品和技术的人；
• 第一次用 Claude Code 这类工具的人，希望先有结构化角色而不是空白提示框；
• 技术负责人和资深工程师，希望每个 PR 都有更严格的 review、QA 和 release 自动化。

如果你平时最头疼的是“怎么写第一版代码”，那你看到的可能只是效率提升。 但如果你更头疼的是“怎么在快的同时不乱、不脆、不失控”，那 gstack 的价值会更明显。

十、我对 gstack 的一个简化理解

如果要用更通俗的话来概括，我会这样理解 gstack：

它不是让 AI 替你写更多代码，而是把一个优秀软件团队原本分散在多人身上的判断动作，重组为一套一个人也能调用的标准流程。

这套思路至少有三点很值得借鉴：

• 不要把 AI 只当成“代码生成器”，而要把它组织成不同职责的角色；
• 不要把“生成完成”误认为“工作完成”，而要把评审、QA、发布和复盘都接进流程；
• 不要迷信更多代理就等于更高效率，先把流程设计清楚，代理数量才会真正放大产能。

结语

gstack 这类项目真正有意思的地方，在于它开始把“AI 编程”从单点工具竞争，推进到“团队流程工程”的层面。

未来开发者之间的差距，也许不只是：

• 谁用的模型更强；
• 谁的提示词更长；

而是：

• 谁更会拆角色；
• 谁更会编排流程；
• 谁能在速度、质量和可控性之间建立新的平衡。

如果你已经在用 Claude Code、Codex 或其他代理式编程工具，并且开始感觉“能写很多代码，但整体仍然容易失控”，那 gstack 至少值得你认真读一遍。 它提供的不只是 28 个技能，更是一套关于“如何组织 AI 成为真正工程团队”的工作方法。

参考来源

• 仓库主页：https://github.com/garrytan/gstack[1]
• README：https://raw.githubusercontent.com/garrytan/gstack/main/README.md[2]
• 作者：Garry Tan

引用链接

[1]https://github.com/garrytan/gstack

[2]https://raw.githubusercontent.com/garrytan/gstack/main/README.md