兰 亭 墨 苑

标题 *

URL 别名 *

内容 * (支持 Markdown 格式) 在上篇文章中，我深度解析了 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 1. Cookie import system shipped 2. Test coverage improved from 32% to 38% 3. No production incidents ## 3 Things to Improve 1.Wednesday had 5 fix commits in a row — consider reviewing earlier 2. Some PRs were over 500 LOC — try to split more 3. E2E tests only ran once this week ## 3 Habits for Next Week 1. Run /review before creating PRs 2. Split PRs over 300 LOC 3. 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。

配图 (可多选)

标签