gstack:把 AI 编程助手变成你的虚拟工程团队

一人成军，一人即团队。从 YC CEO Garry Tan 的开源项目中，能看到 AI 时代软件开发的未来形态。

一、引子：一个人的软件工厂

Garry Tan 是 Y Combinator 的总裁兼 CEO。在过去的 60 天里，他写了超过 60 万行生产代码——35% 是测试——作为日常工作的一部分，每天产出 1-2 万行可用代码。这不是打字错误，而是 AI 时代的新现实。

他说：“十年前，构建你刚才设计的功能需要一个 5 人工程师团队三个月。今天你可以用 Claude Code 在这个周末完成。工程障碍已经消失了，剩下的只有品味——而你刚刚展示了这一点。”

gstack 就是他实现这一切的工具。

这不是又一个 AI 编程助手。这是一套工程方法论，把 Claude Code 从一个”聪明的编码助手”转变为一个你真正管理的虚拟工程团队——一个重新思考产品的 CEO，一个锁定架构的工程经理，一个发现 AI 水货的设计师，一个发现生产问题的偏执审查者，一个打开真实浏览器点击测试你应用的 QA 负责人，还有一个推送 PR 的发布工程师。

十五个专家，六个强力工具，全部是斜杠命令，全部是 Markdown，全部免费，MIT 许可证。

二、gstack 是什么？

2.1 核心定义

gstack 是一个开源的技能系统（Skills System），它为 Claude Code 定义了一系列专业角色（称为 Skills），每个角色都有明确的职责、工作流程和输出物。这些 Skills 通过 Markdown 文件（SKILL.md）定义，Claude Code 在执行时读取这些文件并按照其中的指令行动。

你的 Claude Code     │     ├── /office-hours  → YC 合伙人角色     ├── /plan-ceo-review → CEO/创始人角色       ├── /plan-eng-review → 工程经理角色     ├── /design-consultation → 设计师角色     ├── /review → 资深工程师角色     ├── /qa → QA 负责人角色     ├── /ship → 发布工程师角色     └── ... 更多专家角色

2.2 与普通 AI 编程助手的区别

2.3 技术实现

gstack 的技术架构非常简洁：

1. Skills 定义层：每个 Skill 是一个 SKILL.md文件，用 Markdown 写的工作指令
2. 浏览器层：基于 Playwright 的持久化无头浏览器，让 AI 能”看到”网页
3. 工具层：一系列 CLI 工具，处理遥测、配置、更新等

Claude Code 调用 /browse       │       ▼   CLI (编译后的二进制)       │       ▼ HTTP POST   Server (Bun.serve)       │       ▼ Chrome DevTools Protocol   Chromium (持久化会话)

关键技术决策：

• 使用 Bun 而非 Node.js：编译成单一二进制文件，无需管理 node_modules
• 持久化浏览器会话：登录一次，保持登录状态
• 本地遥测：所有数据存储在本地，隐私优先

三、工作哲学：不做”差不多”先生

3.1 一个简单的问题

假设你需要实现一个用户注册功能。你的 AI 助手给了你两个方案：

• 方案 A：80 行代码，覆盖正常流程，处理邮箱验证
• 方案 B：150 行代码，覆盖正常流程 + 邮箱验证 + 密码强度检查 + 重复邮箱提示 + 网络超时重试 + 防止重复提交

在传统开发中，你可能会选 A——毕竟 B 要多写将近一倍的代码，谁知道什么时候能用上那些边界情况？

但在 AI 辅助下，这个问题变得不同：方案 B 只比方案 A 多花 3 分钟。

这就是 gstack 的核心理念：既然 AI 让”完整”的成本接近于零，为什么还要接受”差不多”？

3.2 湖泊 vs 海洋

当然，不是所有事情都值得追求完美。gstack 用一个比喻来区分：

简单判断标准：

• 这个任务能在一次对话中完成吗？→ 湖泊，做完整
• 需要几周甚至几个月吗？→ 海洋，先做最小可行版本

3.3 压缩比例：AI 到底帮你省了多少时间？

3.4 正确的姿势

❌ 错误：80 行够了，边界情况以后再说✅ 正确：150 行只多 3 分钟，一次性做完整❌ 错误：测试先跳过，等有空再补✅ 正确：测试是最值得"烧干"的湖泊❌ 错误：这个功能要 2 周才能做完✅ 正确：AI 辅助下大约 1 小时

四、工作流：一个完整的冲刺

gstack 是一个流程，不是工具集合。Skills 按冲刺运行的方式排序：

思考 → 计划 → 构建 → 审查 → 测试 → 发布 → 反思

每个 skill 流入下一个。/office-hours写的设计文档被 /plan-ceo-review读取。/plan-eng-review写的测试计划被 /qa接收。/review发现的 bug 被 /ship验证已修复。没有遗漏，因为每一步都知道之前发生了什么。

一个冲刺，一个人，一个功能——用 gstack 大约 30 分钟。但改变一切的是：你可以并行运行 10-15 个这样的冲刺。不同的功能、不同的分支、不同的代理——同时进行。这就是 Garry Tan 如何在做好本职工作的同时每天发布 10,000+ 行生产代码。

4.0 你的虚拟团队

强力工具：

下面，让我们深入了解每个 Skill 的工作方式和背后的思考。

4.1 /office-hours：YC Office Hours 模式

这是每个项目应该开始的地方。在计划之前，在审查之前，在写代码之前——先坐下来，像一个 YC 合伙人一样思考你真正在构建什么。

两种模式：

1. 创业模式（Startup Mode）：六个强制性问题

• Q1 需求真实性：你有什么最强有力的证据表明有人真的想要这个——不是”感兴趣”，不是”注册了候补名单”，而是如果它明天消失会真正感到不安？
• Q2 现状：你的用户现在是怎么解决这个问题的？那个变通方案成本是多少？
• Q3 绝望的具体性：说出最需要这个的真实人类。他们的头衔是什么？什么让他们升职？什么让他们被解雇？什么让他们夜不能寐？
• Q4 最窄的切入点：本周就能有人付真金白银的最小版本是什么？
• Q5 观察与惊喜：你有没有真正坐下来看某人使用这个而不帮助他们？他们做了什么让你惊讶的事？
• Q6 未来适应性：如果 3 年后世界有显著不同——这会发生——你的产品变得更必要还是更不重要？

2. 构建者模式（Builder Mode）：针对黑客马拉松、开源、学习、探索

• 问题更生成性而非审问性
• “最酷的版本是什么？”
• “你能实际使用或分享的最快路径是什么？”

输出：设计文档，保存到 ~/.gstack/projects/，自动流入下游 skills。

示例重框架：

用户说：”我想为我的日历构建一个每日简报应用。”

gstack 回应：

“我要挑战一下你的框架。你说’每日简报应用’。但你实际描述的是一个私人参谋长 AI。”

然后它提取出用户没意识到的五个能力：

1. 跨所有账户监控日历，检测过时信息、缺失位置、权限缺口
2. 生成真正的准备工作——不是后勤摘要，而是董事会会议、播客、融资的准备智力工作
3. 管理你的 CRM——你见谁、关系是什么、他们想要什么、历史如何
4. 优先安排你的时间——提前标记准备开始时间、主动阻塞时间、按重要性排名事件
5. 用钱换取杠杆——积极寻找委托或自动化的方式

这个重框架改变了整个项目。用户本要构建一个日历应用，现在在构建价值十倍的东西——因为 skill 听了他们的痛点，而不是他们的功能请求。

4.2 /plan-ceo-review：创始人模式

这是Brian Chesky 模式。目标不是实现显而易见的工单。目标是重新思考问题，找到那个感觉必然、愉悦、甚至有点神奇的版本。

四种模式：

• 范围扩展：梦想宏大，积极推荐每一个扩展
• 选择性扩展：保持当前范围作为基线，逐个评估机会
• 保持范围：对现有计划最大限度的严格
• 范围缩减：找到最小可行版本

示例：

用户说：”让卖家为他们的商品上传一张照片。”

弱的助手会添加文件选择器并保存图片。

但在 /plan-ceo-review：

“照片上传”甚至不是那个功能。真正的功能可能是帮助某人创建一个真正能卖出去的商品列表。

如果那是真正的工作，整个计划都会改变：

• 我们能从照片识别产品吗？
• 我们能推断 SKU 或型号吗？
• 我们能搜索网络并自动生成标题和描述吗？
• 我们能拉取规格、类别和定价比较吗？
• 我们能建议哪张照片转化最好作为主图吗？
• 我们能检测上传的照片是否丑陋、黑暗、杂乱或低信任度吗？
• 我们能让体验感觉高端而不是 2007 年的死表单吗？

4.3 /plan-eng-review：工程经理模式

一旦产品方向正确，就需要一个完全不同的智能。不再是扩展性的构思，而是让想法变得可构建。

这个模式应该搞定：

• 架构
• 系统边界
• 数据流
• 状态转换
• 失败模式
• 边界情况
• 信任边界
• 测试覆盖

一个令人惊讶的大解锁：图表。

LLM 在被迫绘制系统时变得更加完整。序列图、状态图、组件图、数据流图，甚至测试矩阵。图表强制隐藏的假设浮出水面。它们让模糊的计划变得困难得多。

4.4 /design-consultation& /design-review：设计顾问和评审

这不是选字体。这是研究你领域的现状，提出安全选择和创意风险，生成你真实产品的模型，写 DESIGN.md。

关键洞察：

每个开发工具仪表盘看起来都一样——干净的无衬线字体、柔和的灰色、蓝色强调。它们都很协调。它们都很容易被遗忘。

一个看起来”不错”的产品和一个人们真正能认出的产品之间的区别在于深思熟虑的创意风险：意想不到的标题衬线字体、类别中没人使用的大胆强调色、让你的数据感觉权威而不是空洞的更紧密间距。

安全选择 vs 风险：

安全选择（匹配类别预期）：  - Geist 作为正文——你的用户已经从 Vercel 认识这个字体  - 石板色中性色——温暖的灰色适合数据密集的 UI  - 网格约束的布局——仪表盘需要可预测的对齐风险（你会脱颖而出的地方）：  - Instrument Serif 用于显示标题——开发工具中没人使用衬线字体  - 单一的青色强调色而不是蓝色——这个领域其他人都用蓝色  - 4px 紧凑密度——比 Linear 更紧密，说"我们尊重你的屏幕空间"

4.5 /review：偏执的资深工程师模式

通过测试并不意味着分支是安全的。

/review存在是因为有一整类 bug 可以存活于 CI 并在生产环境中打你的脸。

这个模式不是让梦想更大。不是让计划更漂亮。而是问：

还有什么仍然可以崩溃？

这是一个结构性审计，不是风格挑剔。它寻找：

• N+1 查询
• 陈旧读取
• 竞态条件
• 糟糕的信任边界
• 缺失的索引
• 转义 bug
• 损坏的不变量
• 糟糕的重试逻辑
• 测试通过但错过真正失败模式的测试
• 被遗忘的枚举处理器

4.6 /qa：QA 负责人模式

/browse给代理眼睛。/qa给它测试方法论。

最常见的用例：你在功能分支上，刚完成编码，想验证一切正常。只需说 /qa——它读取你的 git diff，识别你的变更影响哪些页面和路由，启动浏览器，逐个测试。

四种模式：

• Diff-aware：读取 git diff main，识别受影响的页面，专门测试它们
• Full：系统性探索整个应用。5-15 分钟。记录 5-10 个有充分证据的问题
• Quick：30 秒冒烟测试。首页 + 前 5 个导航目标
• Regression：与之前的基线进行比较

自动回归测试：

当 /qa修复一个 bug 并验证它时，它会自动生成一个回归测试来捕获确切的中断场景。测试包括完整的归属追溯回 QA 报告。

4.7 /ship：发布机器模式

一旦决定了构建什么、锁定了技术计划、运行了严肃的审查——就不再需要更多讨论，需要的是执行。

/ship是最后一公里。它用于准备好的分支，不是决定构建什么。

这个模式应该停止像头脑风暴伙伴那样行动，开始像纪律严明的发布工程师：同步 main、运行正确的测试、确保分支状态正常、更新变更日志或版本控制、推送、创建或更新 PR。

自动测试框架引导：

如果你的项目没有测试框架，/ship会设置一个——检测你的运行时、研究最佳框架、安装它、为你的实际代码写 3-5 个真正的测试、设置 CI/CD、创建 TESTING.md。100% 测试覆盖是目标——测试让氛围编码变得安全而不是鲁莽编码。

4.8 /retro：工程经理模式

在一周结束时，我想知道实际发生了什么。不是感觉——数据。/retro分析提交历史、工作模式和发布速度，写一个坦率的回顾。

它在团队级别工作。它识别谁在运行命令，给你自己的工作最深入的处理，然后分解每个贡献者，提供具体的表扬和成长机会。它计算提交、LOC、测试比率、PR 大小、修复比率等指标。

五、安全护栏：让 AI 安全工作

四个 skills 为任何 Claude Code 会话添加安全护栏。它们通过 Claude Code 的 PreToolUse hooks 工作——透明、会话作用域、无配置文件。

5.1 /careful

在接近生产、运行破坏性命令或只是想要安全网时使用。每个 Bash 命令都会被检查已知的危险模式：

• rm -rf/ rm -r— 递归删除
• DROP TABLE/ DROP DATABASE/ TRUNCATE— 数据丢失
• git push --force/ git push -f— 历史重写
• git reset --hard— 丢弃提交
• kubectl delete— 生产资源删除
• docker rm -f/ docker system prune— 容器/镜像丢失

常见的构建产物清理被白名单——日常操作没有误报。

你可以覆盖任何警告。护栏是事故预防，不是访问控制。

5.2 /freeze

将所有文件编辑限制到单个目录。当你在调试计费 bug 时，你不希望 Claude 意外”修复” src/auth/中的无关代码。/freeze src/billing阻止该路径之外的所有 Edit 和 Write 操作。

/investigate会自动激活这个——它检测被调试的模块并将编辑冻结到该目录。

5.3 /guard

完全安全模式——在一个命令中结合 /careful+ /freeze。破坏性命令警告加上目录作用域编辑。用于接触生产或调试实时系统。

5.4 /unfreeze

移除 /freeze边界，再次允许各处编辑。Hooks 为会话保持注册——它们只是允许一切。再次运行 /freeze设置新边界。

六、实战：一个完整的开发周期

让我们通过一个真实的例子看 gstack 如何工作。

场景：构建一个支付功能

用户：“我想给应用添加支付功能。”

Step 1: /office-hours

Claude: 在我们深入之前——你的目标是什么？        - 构建创业公司        - 内部创业——公司内部项目        - 黑客马拉松 / 演示        - 开源 / 研究        - 学习        - 纯粹好玩用户：  创业公司。Claude: 好，让我问一些更难的问题。        Q1：你有什么证据表明有人真的需要这个支付功能？用户：  我们有 500 个候补注册...Claude: 候补注册不是需求。有人会因此失眠吗？        有没有人在我们消失时真正会挣扎？用户：  嗯，实际上有三个用户每周都来问我们什么时候上线支付...Claude: 那才是需求。三个具体的人每周来问。        让我们继续...

（45 分钟后）

Claude: 设计文档已写入 ~/.gstack/projects/myapp/payment-design.md        推荐方案：先做最窄的切入点        - 单一货币（美元）        - 信用卡支付（Stripe）        - 不做订阅，只做一次性付款        这周末就能发布，下周就能有收入。

Step 2: /plan-eng-review

Claude: 锁定架构...        [架构图]        User → API → PaymentService → Stripe API                        │                        ▼                     Database (Payment, Transaction)        [数据流]        1. 用户提交支付 → 验证 → 创建 Payment 记录        2. 调用 Stripe → 获取 client_secret        3. 前端完成 3D Secure → webhook 确认        4. 更新 Payment 状态        [边界情况]        - 并发支付：需要幂等键        - 部分失败：Stripe 成功但 DB 写入失败        - Webhook 超时：重试队列        [测试计划]        - 单元测试：PaymentService 每个方法        - 集成测试：完整支付流程（使用 Stripe 测试密钥）        - E2E 测试：前端支付表单

Step 3: 实现代码（由工程团队/其他代理完成）

Step 4: /review

Claude: [审查中...]        [AUTO-FIXED] app/services/payment_service.rb:47        问题：N+1 查询在渲染支付历史时        修复：添加 .includes(:transactions)        [AUTO-FIXED] app/controllers/payments_controller.rb:23        问题：缺少幂等键，并发请求可能导致重复收费        修复：添加 Idempotency-Key 头部        [ASK] app/services/payment_service.rb:89        问题：webhook 验证使用的是 Stripe 测试密钥，生产环境会失败        建议：使用环境变量配置密钥        你想现在修复吗？用户：  是的，修复它。Claude: [已修复]        审查完成：3 个问题 — 2 个自动修复，1 个询问后修复

Step 5: /qa https://staging.myapp.com

Claude: [探索 8 个页面，测试支付流程...]        QA 报告：staging.myapp.com — 健康分数 85/100        发现的问题：        1. [中等] 支付成功后，页面没有自动刷新        2. [低] 移动端支付表单输入框被键盘遮挡        正在修复...        [已修复] 支付成功后的页面刷新        [已跳过] 移动端问题（需要更大的改动，建议后续 PR）        最终健康分数：92/100

Step 6: /ship

Claude: 预检查...        - 分支：feature/payment        - 基础分支：main        - 测试：通过（42 个测试，0 失败）        - 审查就绪：✓ Eng Review 通过        合并 main...        更新版本：0.1.0 → 0.2.0        更新 CHANGELOG...        推送...        ✓ PR 已创建：github.com/myapp/app/pull/42        PR 内容：        - 支付功能（Stripe 集成）        - 测试：32 → 42 (+10 新增)        - 覆盖率：87% → 94%

Step 7: /retro（一周后）

Claude: 本周回顾        本周你做到了：        - 23 次提交，+1.8k LOC，38% 测试        - 最大发布：支付功能（12 次提交，完整流程）        - 峰值时间：晚上 9-11 点        做得好的：        - 在一次专注的推进中发布了完整的支付功能        - 测试覆盖率从 87% 提升到 94%        - 每个 PR 都在 200 LOC 以下        改进机会：        - 3 天没有提交——是不是被其他事情阻塞了？        - 考虑为 webhook 处理添加更多边界情况测试        连续发布：12 天

七、学习心得与思考

7.1 gstack 教会我的事

角色 > 工具。传统的 AI 助手是工具——你使用它们，它们响应。gstack 的 Skills 是角色——你管理它们，它们思考、质疑、建议、执行。当你调用 /office-hours，你不是在请求一个分析，而是在进行一场对话，对方有明确的观点、会挑战你的假设。

流程 > 零散操作。没有工作流的 AI 编程，每一步都是独立的、没有上下文的。用户必须记得每一步该做什么，必须手动传递上下文。有了 gstack，每一步都知道之前发生了什么——设计文档被审查读取，测试计划被 QA 使用，审查发现被验证。

完整性是可能的。在 AI 辅助下，完整的边际成本接近于零。既然如此，为什么接受”足够好”？

但它不是魔法。它不能替代你做产品决策，不能保证没有 bug，不能理解你的用户，不能替代团队协作。它只能帮你思考更清楚、系统性地减少风险、强迫你具体化你的理解、加速你的工作。

7.2 工作哲学的借鉴与改造

gstack 体现的是 Garry Tan 及其 YC 团队的工作哲学和实践经验——YC Office Hours 的提问方式、产品思考框架、工程审查标准。这些都是真金白银换来的智慧，值得认真学习。

但不可照抄。

原因很简单：

1. 上下文不同。Garry Tan 是 YC CEO，他的工作场景是初创公司、投资人关系、快速验证。你的场景可能完全不同——企业内部项目、开源贡献、学习探索。

2. 团队规模不同。gstack 设计为”一人成军”，适合独立开发者和小团队。如果你在 50 人团队，需要的可能是协作工具而非个人效率工具。

3. 技术栈不同。gstack 的 /ship假设了特定的测试框架和发布流程。你的项目可能有不同的技术选型。

正确的做法是借鉴思路，改造实践：

学习 gstack，是为了学会如何设计自己的工作流，而不是复制别人的工作流。

7.3 学习方法：守破离

日本剑道的学习三阶段——守、破、离——同样适用于 gstack 的学习。

第一阶段：守（遵守）

先用起来，不急着改。按照 gstack 设计的方式完整走一遍：

/office-hours → /plan → 实现 → /review → /qa → /ship → /retro

不要跳步骤，不要质疑”这个有必要吗”。先体验完整流程，理解每个环节的设计意图。这个阶段的目标是：掌握基本功，形成肌肉记忆。

第二阶段：破（突破）

在理解的基础上开始调整。问自己：

• 哪些环节对我特别有价值？
• 哪些环节可以简化或跳过？
• 哪些环节需要增加？

比如，如果你主要做内部工具开发，/office-hours的创业六问可能过于”重”了，可以简化为”用户是谁、解决什么问题、最小方案是什么”三问。

这个阶段的目标是：找到适合自己的节奏。

第三阶段：离（脱离）

不再拘泥于 gstack 的具体形式，而是内化了其工作哲学。你可能会：

• 创建自己的 Skills，针对你的领域
• 设计完全不同的工作流
• 把 gstack 的思想应用到非编程领域（写作、研究、项目管理）

这个阶段的目标是：形成自己的方法论。

守：按 gstack 的方式做，完整走一遍    ↓破：理解后调整，找到适合自己的节奏    ↓离：内化哲学，创造自己的工作流

7.4 更大的图景：工作流系统

gstack 不是孤例。在 AI 辅助开发领域，类似的”工作流系统”正在涌现：

这些项目的共同点是：都在试图把”怎么用好 AI”变成可重复、可传播的方法论。

它们反映出 AI 时代软件开发的一个趋势：

过去：如何写好代码      ↓现在：如何设计好与 AI 协作的工作流

代码本身的重要性在下降——AI 可以写。但设计工作流、定义角色、设定检查点的能力变得越来越重要。

gstack 的真正价值不在于那 15 个 Skills，而在于它展示了一种可能性：如何把一个人的智慧外化成一套可执行的流程。

7.5 它适合谁？

适合：

• 技术型创始人——想快速验证想法、自己动手写代码
• 独立开发者——一人成军，需要虚拟团队
• 学习者——想学习专业的工作流程
• 开源维护者——需要更高效的个人工作流

不太适合：

• 非技术用户——需要理解软件工程概念
• 大型团队——团队协作有更好的工具
• 需要 100% 自定义的场景——Skills 是相对固定的

7.6 它改变了什么

在 gstack 之前：

想法 → [漫长的学习曲线] → [试错] → [可能放弃] → [也许发布]

在 gstack 之后：

想法 → /office-hours → /plan → 实现 → /review → /qa → /ship       30分钟思考      30分钟规划   数小时编码   15分钟审查   15分钟测试   5分钟发布

整个周期从”可能永远不会完成”变成”这个周末就能发布”。

7.7 它没有改变什么

• 你仍然需要品味。AI 可以写代码，但它不能告诉你什么是好的产品。
• 你仍然需要决策。gstack 会给你选项，但选择是你做的。
• 你仍然需要理解。盲目跟随 AI 的建议是危险的。
• 你仍然需要时间。更高效不等于不需要时间。

八、总结：一人即团队

gstack 的真正价值不在于任何一个具体的 Skill。它的价值在于把软件开发的完整生命周期——从产品思考到架构设计到代码审查到测试到发布到回顾——变成一系列可重复、可预测、高质量的步骤。

在过去，一个人要完成所有这些，需要：

• 产品经理的直觉（理解用户需求）
• 架构师的能力（设计系统）
• 工程师的技能（编写代码）
• QA 的耐心（测试边界情况）
• 设计师的品味（关注用户体验）
• 发布工程师的纪律（自动化流程）

而且即使你拥有所有这些技能，你也很难同时扮演所有这些角色。你的大脑会疲劳，你会忽略事情，你会走捷径。

gstack 把这些角色外化了。你不再需要自己扮演所有角色——你管理这些角色。你做决策，它们执行。你提供方向，它们提供专业能力。

这就是 Garry Tan 说的“一人即团队”。

不是因为你变成了超人，而是因为 AI 变成了你的团队。

九、如何开始

1. 安装（30 秒）：

   git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstackcd ~/.claude/skills/gstack && ./setup

2. 尝试你的第一个 office hours：

   /office-hours

   然后告诉它你想构建什么。

3. 体验完整流程：

• /plan-eng-review
• 实现一些代码
• /review
• /qa
• /ship

4. 如果不确定：

• /browse打开一个网页，让 AI “看”看
• /retro看看你的工作统计
• /gstack-upgrade保持最新

“同一个工具，不同的结果——因为 gstack 给你结构化的角色和审查关卡，而不是通用的代理混乱。那种治理是快速发布和鲁莽发布的区别。”

— Garry Tan

gstack 是免费、开源、MIT 许可的。它不会拯救你，但它会让你更强大。

GitHub: github.com/garrytan/gstack