在上篇文章中，我深度解析了 superpowers 这套 skill，没看过的同学可以点此看下。这两天我又关注到有个叫 gstack 的 skill 也非常火爆，也是一个用于 AI Coding 的 skill，我在深度学习后，发现也是一套非常值得推荐的 skill，接下来我们就先来看下 gstack 是什么？它是如何设计的？文末我也会尝试回答下，同为 AI Coding 的 skill，它和 superpowers 这套 skill 有啥异同！
Gstack 是 Y Combinator（简称 YC）总裁兼 CEO Garry Tan 开源的一套 AI 工程工作流，它将 Claude Code 从一个通用的 AI 助手变成了一整支虚拟工程团队：CEO、产品经理、工程经理、资深设计师、安全专家、QA 工程师、发布工程师……应有尽有。可能有些同学不了解 YC，我这里简单介绍一下：YC 是美国知名的创业孵化公司，曾孵化过许多知名企业，比如 Reddit、Dropbox……YC 也曾进军中国市场，当时陆奇负责中国业务，但可能因为水土不服，一年后便退出了中国市场。不过，这并不影响 YC 在创投领域取得的成就。你也应该感受到这个项目的来头有多大了，虚的说完我们来具体看下这套 skill 是如何设计的。
概览
这套 skill 的设计思路很有意思，它不是基于流程来设计的，而是基于角色来设计的。就像一个真实的创业公司，你需要不同的人来负责不同的事情——产品经理想清楚做什么，工程经理想清楚怎么做，设计师保证美观，QA 保证质量，安全官保证不出事，最后发布工程师负责上线。
Gstack 就是把这个团队角色拆成了一个个 skill，让 AI 分别扮演这些角色。更重要的是，这些角色不是孤立的，而是像真实团队一样有协作流程：从创意到产品，从计划到实现，从测试到发布，最后还有回顾复盘。
我把这个流程画了张图，大家可以直观感受一下：
这套 skill 的设计思路已经很清晰了，它是基于角色设计，把一个完整的工程团队”序列化”成了一套可以按顺序调用的技能。每个角色都有自己的职责和专业视角，当你按顺序调用这些技能时，就相当于一个完整的团队在为你工作。
核心 skill 介绍
由于篇幅所限，我没法把所有 skill 都详细介绍一遍。这里依然挑选部分来讲，挑选标准是：看名字不太容易理解用途的，以及比较关键的 skill。至于一些偏开发的 skill，见名知意，我就不再展开；感兴趣的同学可以自行查阅官方 GitHub 文件。
/office-hours：YC 产品门诊
这是整个流程的起点，也是我觉得最有意思的一个 skill。你可以把它理解为 Garry Tan 亲自坐诊的”YC 产品门诊”——它不会顺着你说，反而会质疑你的前提，挑战你的假设。
为什么这个 skill 很重要？
做产品最容易犯的错误就是”解决方案找问题”——你先想到一个功能，然后去给它找用武之地。YC 见过太多创业公司死在这上面了，这个 skill 就是在帮你避免这个坑。
它是怎么工作的？
重构框架：倾听你的痛点，而不是你的功能需求。经常会帮你重新发现产品真正的价值。
比如你说”我要做一个日历每日简报应用”
它可能会告诉你——不，你真正想要的是一个个人首席 AI 幕僚
它会帮你管理日程、准备会议、优先级排序
前提挑战：提出可证伪的前提让你验证，每个接受的前提都会成为产品设计的支柱。
不会听你说”我想做个 APP”
而是会追问”具体谁在什么场景下遇到了什么问题？”
每个问题都要你用具体例子回答，而不是空泛的假设
实现方案：生成 2-3 种具体的实现方案，并给出诚实的工作量估算。
人工团队时间 vs Claude Code + gstack 时间（压缩比通常在 20x-100x）
推荐最窄切入点，让你最快上线从真实使用中学习
两种模式：
创业模式：面向创始人，六个”强迫性问题”，逼着你想清楚真正的痛点是什么
建造者模式：面向黑客松、Side Project、开源，帮助你找到最酷的版本和最快的分享路径
说白了，这一步就是把”我有个想法”变成”这是一个值得做的产品”。最后生成一份设计文档保存在 ~/.gstack/projects/，这份文档会直接输入给后续的 /plan-ceo-review 和 /plan-eng-review。
/plan-ceo-review：CEO 战略复盘
有了设计文档之后，就该 CEO 出场了。这个 skill 扮演的是 Garry Tan 本人的角色——站在创始人视角，重新思考问题。
为什么需要 CEO 视角？
普通的 AI 助手会字面执行你的需求：你说”加个照片上传功能”，它就给你加个文件选择器。但真正的 CEO 会问一个更重要的问题：这个产品到底是做什么的？
这个 skill 也可以称之为 Brian Chesky 模式——重点不是实现显而易见的需求，而是从用户角度重新思考问题，找到那个不可避免、令人愉悦、甚至有点神奇的版本。
举个真实的例子：
你说：”我要给 Craigslist 风格的列表应用增加卖家照片上传功能”。
普通助手：好的，这就加文件选择器。
/plan-ceo-review：等等，照片上传真的是这个功能吗？真正的需求是不是帮卖家创造一个能卖出去的列表？那我们能不能：
自动识别商品是什么？
自动搜索网页拉出规格参数和分类价格对比？
自动生成标题描述？
自动建议哪张照片最适合当首图？
告诉你哪些照片看起来不行（太暗、太乱、低信任）？
让整个体验感觉高级而不是 2007 年的死气表单？
看到了吧？这就是 CEO 视角和普通执行者的区别。它不会只满足于字面需求，而是会问：这个请求背后隐藏的 10 星级产品是什么？
四种模式：
SCOPE EXPANSION（扩围）：大胆梦想，逐个呈现扩展方案让你选择
SELECTIVE EXPANSION（选择性扩围）：保持核心范围作为基线，看看还有什么可能
HOLD SCOPE（保持范围）：在现有范围内精益求精，不随便加东西
SCOPE REDUCTION（缩围）：stripped to essentials，只保留最核心的
这个 skill 最有意思的地方是，它不会只说”好”或”不好”，而是会像真正的 CEO 那样问你：”这真的是用户需要的吗？我们能不能做得更大？或者，我们是不是想得太大了？”每种模式都有清晰的 trade-off，让你做最终决策。
/browse：真实无头浏览器
这是 gstack 的”秘密武器”之一——一个真实的 Chromium 浏览器，可以真正打开网页、点击按钮、填写表单、截图。
为什么这个很重要？
以前 AI 说”我测试过了”，你可能心里打鼓——它真的打开浏览器看了吗？还是在”幻想”测试结果？很多 AI 工具的”测试”都是基于 DOM 结构的模拟，或者更糟——直接编结果。
有了 /browse，你就能确信：是的，它真的测了。
技术原理：
它是一个编译后的二进制，和持久化 Chromium 守护进程通信，基于 Playwright。第一次调用启动浏览器（~3 秒），之后每次调用 ~100-200ms。浏览器在命令之间保持运行，所以 cookie、标签页、localStorage 都会保留。
关键功能：
真实渲染：不是模拟，是真的 Chromium 渲染页面
完整交互：点击、输入、滚动、上传、选择、悬停
断言验证：is visible/enabled/checked/editable
读取信息：text、html、links、console、network
可视化：screenshot、responsive、diff、PDF
快照引用：带 @e 引用的可访问性树，让你不用猜 CSS 选择器
多标签页支持：可以同时打开多个页面
命令链式调用：一条命令接一条，像真实用户操作
从真实浏览器导入 Cookie：通过 /setup-browser-cookies 直接导入
用户交接：碰到验证码/MFA 可以打开可见浏览器让用户解决，之后再恢复
举个实际例子：
你想测试登录流程，以前 AI 可能会说”我点击了登录按钮，然后跳转到了 dashboard”。但有了 /browse，它会真的这么做：
1. 转到登录页
$B goto https://app.example.com/login
2. 查看可交互内容
$B snapshot -i
→ [@e1] Email input
→ [@e2] Password input
→ [@e3] Login button
3. 使用引用填充表单
$B fill @e1 "test@example.com"
$B fill @e2 "password123"
$B click @e3
4. 验证成功
$B snapshot -D # diff 显示点击后发生了什么变化
$B is visible ".dashboard" # 断言仪表板已出现
$B screenshot /tmp/after-login.png
甚至碰到验证码也不怕：
Claude：我在登录页碰到验证码了。打开可见 Chrome 你解决一下，弄好告诉我。
browse handoff "Stuck on CAPTCHA at login page"
你：done
Claude：> browse resume
[浏览器在交接后保留所有状态，resume 之后 AI 能获得你离开位置的新鲜快照]
说白了，这就是给 AI 一双真实的眼睛，让它能看到网页、交互测试、截图证据。以前 AI 说”我测过了”，你可能半信半疑；现在有了 /browse，你可以完全信任——因为它真的看了。
/cso：首席安全官安全审计
安全这东西，平时感觉不到，出事就是大事。这个 skill 扮演的是首席安全官的角色，给你做全面的安全审计。
为什么需要这个？
很多开发者（包括我自己）对安全都是”事后诸葛亮”——平时不注意，被黑了才后悔。但安全问题一旦发生，损失往往是巨大的：数据泄露、声誉受损、法律责任……
/cso 就是在你合并代码前，帮你把这些问题找出来。
审计内容：
注入漏洞：SQL 注入、NoSQL 注入、命令注入
broken 认证：会话管理、密码存储、MFA
敏感数据暴露：PII、密钥、日志中的敏感信息
XML 外部实体：XXE 攻击
破损访问控制：权限提升、水平越权、垂直越权
安全错误配置：默认密码、公开的调试信息、CORS 配置
XSS：反射型、存储型、DOM 型
不安全反序列化：RCE 风险
已知漏洞组件：npm audit、依赖供应链
日志记录不足：审计日志、监控、告警
除此之外，它还会检查：
CI/CD 管道安全：GitHub Actions、GitLab CI
LLM/AI 安全：提示注入、prompt 泄露
技能供应链：扫描安装的 skill 是否有安全问题
密钥考古：检查 git 历史中是否有不小心提交的密钥
关键特点：
零噪音：17 个误报排除规则，8/10+ 置信度门槛——不会给你扔一堆没用的警告
每个发现都包含具体的利用场景：不是只说”这里有个 SQL 注入”，而是会说”怎么利用”、”影响范围有多大”
不是只扔给你一堆问题：而是会告诉你怎么修，甚至自动修复一些简单问题
两种模式：
Daily（默认）：8/10 置信度门槛，零噪音——适合日常使用
Comprehensive（–comprehensive）：2/10 置信度门槛，月度深度扫描——适合安全审计
说白了，这就是你的虚拟首席安全官，在你合并代码前帮你把安全关把好。安全这东西，还是预防为主，别等出事了才后悔。
/ship：一键发布 PR
代码写好了，测试通过了，接下来就是发布。这个 skill 扮演的是发布工程师的角色，帮你一键搞定。
为什么需要这个？
发布这事儿说起来简单，但实际上有一堆琐碎的步骤：同步主分支、解决冲突、运行测试、更新版本、写 changelog、提交、push、创建 PR……每一步都可能出错，而且烦得要死。
作为一个喜欢偷懒的人，我当然不想每次都手动做这些。/ship 就是把这堆琐事自动化，让你一个命令搞定。
自动完成：
同步主分支：git fetch origin main && git merge origin/main
运行测试：自动检测你的测试框架，运行正确的命令
审计覆盖率：从你的 diff 构建代码路径映射，搜索对应测试，生成 ASCII 覆盖率图，缺口自动生成测试
提交代码：bisectable chunks（可二分查找的提交块），每个提交一个独立功能
推送到远程：git push -u origin feature-branch
创建 PR：自动生成 PR 描述，包含 changelog、覆盖率变化、评审状态
测试引导： 如果你没有测试框架，它还会帮你 bootstrap 一个：
检测运行时（Node.js、Python、Ruby……）
找最佳框架（Vitest、pytest、RSpec……）
安装依赖
写 3-5 个真实测试
设置 GitHub Actions CI
创建 TESTING.md
评审关口： 创建 PR 前会检查评审就绪看板，如果缺工程评审会问，但不阻止你。每个分支保存决策，不会重复问。
举个例子，你刚写完代码，想发布：
你：/ship
/ship：
Step 1: Pre-flight — on feature branch, 12 uncommitted changes included
Step 2: Merge base branch — git fetch origin main && git merge origin/main
Step 3: Run tests — bun test ✓ (42/42 pass)
Step 3.4: Test Coverage Audit — Tests: 42 → 47 (+5 new)
Step 3.5: Pre-Landing Review — No issues found
Step 4: Version bump — v0.11.17.0 → v0.11.18.0
Step 5: CHANGELOG — auto-generated from git log
Step 5.5: TODOS.md — 2 items marked complete
Step 6: Commit — bisectable chunks (5 commits)
Step 7: Push — git push -u origin feature-branch
Step 8: Create PR — https://github.com/garrytan/gstack/pull/123
Step 8.5: Auto-invoke /document-release — docs synced
🎉 PR created: https://github.com/garrytan/gstack/pull/123
说白了，就是把”我写完了”变成”这就上线了”。以前发布可能需要 10 分钟，现在一个命令 30 秒搞定。作为一个喜欢偷懒的人，这当然深得我心。
/retro：每周工程回顾
一个好的团队会不断反思，这个 skill 就是帮你做这件事的。它会分析你的提交历史、工作模式、代码质量指标。
为什么需要这个？
不知道你有没有这种感觉：一周忙忙碌碌，感觉干了很多事，但周末回想起来，又好像啥都没干成。这时候你就需要数据——不要感觉，要事实。
/retro 就是帮你做这件事的：用数据说话，看看这周到底发生了什么。
分析内容：
每周提交统计：总提交数、代码行数、测试比例、PR 数量
人均贡献 breakdown：识别不同人的贡献，给出针对性的表扬和成长建议
发布 streak（连续发布天数）：看看你能连续多久保持发布节奏
测试健康趋势：总测试文件、本期新增测试、回归测试提交、趋势变化
成长机会建议：基于数据给出具体的改进建议
团队感知： 它可以识别谁运行的命令，对你自己的工作给出最深处理，然后逐个分解每个贡献者，给出具体的表扬和成长机会。
它会计算各种指标：
提交数、代码行数
测试比例
PR 大小
修复率
从提交时间戳检测编码会话
找到热点文件
追踪发布连胜
识别本周最大贡献
举个例子：
周末你想回顾这一周：
你：/retro
/retro：Week of Mar 1: 47 commits (3 contributors), 3.2k LOC, 38% tests, 12 PRs, peak: 10pm | Streak: 47d
Your Week
32 commits, +2.4k LOC, 41% tests. Peak hours: 9-11pm.
Biggest ship: cookie import system (browser decryption + picker UI).
What you did well: shipped a complete feature with encryption, UI, and
18 unit tests in one focused push...
Where to level up: test ratio dipped to 12% on Wednesday — consider
writing tests before refactoring next time.
Team Breakdown
Alice
12 commits focused on app/services/.Every PR under 200 LOC — disciplined.
Praise: Shipped the entire auth middleware rewrite in 3 focused sessions
Opportunity: test ratio at 12% — worth investing before payment gets more complex.
Bob
3 commits — fixed the N+1 query on dashboard.Small but high-impact.
Praise: That N+1 fix reduced dashboard load from 2s to 200ms
Opportunity: only 1 active day this week — check if blocked on anything.
Top 3 Team Wins
-
Cookie import system shipped
-
Test coverage improved from 32% to 38%
-
No production incidents
3 Things to Improve
1.Wednesday had 5 fix commits in a row — consider reviewing earlier
-
Some PRs were over 500 LOC — try to split more
-
E2E tests only ran once this week
3 Habits for Next Week
-
Run /review before creating PRs
-
Split PRs over 300 LOC
-
Run E2E tests at least twice
甚至可以跨项目全局回顾：
你：/retro global
/retro：Global Retro: 5 projects, 138 commits, 250k LOC across 5 repos
48 AI sessions | Streak: 52d 🔥
🚀 Your Week: xindoo — Week of Mar 1
╔═══════════════════════════════════════════════════
║
║ 138 commits across 5 projects
║ +24.2k LOC added · 2.1k LOC deleted · 22.1k net
║ 48 AI coding sessions (CC: 35, Codex: 10, Gemini: 3)
║ 52-day shipping streak 🔥
║
║ PROJECTS
║ ───────────────────────────────────────────────────────
║ gstack 47 commits +3.2k LOC solo
║ myapp 52 commits +12.8k LOC team
║ other-project 39 commits +8.2k LOC solo
║
║ SHIP OF THE WEEK
║ Cookie import system — 2,457 lines across 18 files
║
║ TOP WORK
║ • Built /retro global — cross-project retrospective
║ • Shipped cookie import in gstack
║ • Refactored auth middleware in myapp
║
║ Powered by gstack · github.com/garrytan/gstack
╚═══════════════════════════════════════════════════
说白了，这就是你的虚拟工程经理，每周给你出一份”团队周报”。不要感觉，要数据——用数据说话，看看这周到底发生了什么，有哪些成长机会。结果还会保存 JSON 快照到 .context/retros/，下次运行能显示趋势。
/careful：危险操作警告
网上已经曝出不少 AI 误删文件的事件了。如果不对 AI 加以约束，确实很容易出问题。这个 skill 的作用是在你准备进行高风险操作前，先把你拦下来提醒一句。
会警告的操作：
rm -rf
DROP TABLE
git push --force
git reset --hard
kubectl delete
你可以选择确认继续，也可以选择停下。说白了，这就是给你的”三思而后行”按钮。
/freeze：目录编辑锁定
调试的时候最烦什么？改着改着这个文件，不小心把那个文件也改了。这个 skill 就是帮你锁定编辑范围的。
功能：
只允许编辑指定目录
目录之外的编辑会被硬拦截
不是警告，是真的不让改
调试的时候，把编辑范围锁定在出问题的模块，就不用担心”误伤”其他代码了。
/guard：完整安全防护
这是 /careful + /freeze 的组合版，一次性开启所有安全防护。
同时开启：
危险操作警告
目录编辑锁定
说白了，就是”最高安全模式”——适合碰生产环境或者调试关键系统的时候用。
/unfreeze：解锁编辑
用完 /freeze 或 /guard 之后，用这个来解锁编辑限制，恢复可以编辑所有目录的状态。
与 superpowers 对比
可以看到，Gstack 与 Superpowers 在设计思路上是完全不同的，前者基于角色设计，而后者基于研发流程设计。
我列了张表格，对比下两者的核心差异：
维度 Gstack Superpowers
设计理念 基于角色（虚拟工程团队） 基于流程（研发流程护栏）
核心类比 一个完整的创业公司 一套资深团队的”作业指导书”
适用场景 从创意到产品的全流程 已有需求的工程化落地
角色覆盖 CEO、产品、工程、设计、QA、安全、发布 架构师、开发者、测试、评审
流程结构 Think → Plan → Build → Review → Test → Ship → Reflect Brainstorm → Plan → Implement → Test → Review → Finish
关键特色 真实浏览器、YC 产品思维、CEO 视角 TDD、系统化调试、验证前置、反谄媚
安全工具 /careful、/freeze、/guard 流程本身就是安全护栏
创始人视角 ✅ Garry Tan 的 YC 经验 ❌ 更偏向工程视角
适用阶段 从 0 到 1，创意阶段 从 1 到 N，工程阶段
共同点
虽然设计思路不同，但两者有一些核心的共同点：
都反对”AI 拿到需求就开干”：都强调先想清楚，再动手
都重视验证：没有证据，不能声称完成
都用流程约束 AI：不让 AI 凭”聪明”乱来，而是用流程保证质量
都适合复杂项目：项目越复杂，价值越明显
都需要人工介入：不是完全自动化，而是人机协作
总结
阅读 Gstack 所有 Skill 的过程中，我也总结出几个有意思的结论：
Garry Tan 真的在实战中用这套东西：README 里晒出了他的 GitHub 贡献图——2026 年 1237 次贡献，最近 60 天写了 60 万+ 行代码。这不是”理论上好用”，是”真的能打”。
这是 YC 方法论的 AI 化：YC 怎么辅导创业公司，Gstack 就怎么辅导你。从 /office-hours 的”挑战前提”，到 /plan-ceo-review 的”找 10 星产品”，这就是 YC 门诊的 AI 版。
真实浏览器是杀手锏：很多 AI 工具的”测试”都是模拟的，但 Gstack 的 /browse 是真的 Chromium。这就从”AI 说它测过了”变成”我确信它真的测过了”。
角色化设计降低认知负担：你不用想”现在该用什么流程”，只要想”现在我需要什么角色”——需要产品思维就用 /office-hours，需要 CEO 视角就用 /plan-ceo-review，需要 QA 就用 /qa。
Gstack 和 superpower 其实不是竞品，更多的时候是相互补齐，Gstack 适合偏向于宏观实现——从创意到产品，从 0 到 1；而 Superpowers 适合实际开发落地——从需求到代码，从 1 到 N。说直白点，一个是老板，一个是底层牛马 [doge]。
不过话说回来，这两个工具其实反映了一个共同的趋势：AI 编程不是”让 AI 替你写代码”，而是”让 AI 帮你组建一个团队”。以前你一个人要干产品、开发、测试、发布的活，现在这些角色都有 AI 帮你扮演，你只需要做最终决策。
这也是为什么我觉得 AI 不会取代程序员，但会重新定义程序员的工作方式。未来的程序员，可能更像是一个”团队管理者”，而不是一个”搬砖工”。
本文到这里就结束了，如果觉得我文章写的还可以，可以关注下我 XINDOO。