gstack 的虚拟工程团队：23 个角色如何把一个人变成一支队伍
这句话在 AI 工程圈炸开了锅。但很多人忽略了一个前提：Karpathy 能做到这一点，不是因为他用了某个神奇的模型，而是因为他有一套结构化的 Agent 工作流——模型只是引擎，工作流才是车。
目录
gstack 的"虚拟工程团队"：23 个角色如何把一个人变成一支队伍
项目: garrytan/gstack
作者: Garry Tan — YC 总裁兼 CEO
语言: TypeScript | 协议: MIT
今日 Star: +121
一、Karpathy 的那句话
2026 年 3 月，Andrej Karpathy 在一次对话里说：
"我觉得自从去年 12 月以来，我可能没手写过一行代码。"
这句话在 AI 工程圈炸开了锅。但很多人忽略了一个前提：Karpathy 能做到这一点，不是因为他用了某个神奇的模型，而是因为他有一套结构化的 Agent 工作流——模型只是引擎，工作流才是车。
Garry Tan（YC 总裁兼 CEO）的 gstack 就是这套思路的一个完整实现。不是"一个 prompt 解决一切"，而是23 个专家角色 + 8 个工具，把一个人变成一支虚拟工程团队。
二、不是 Skill Pack，是组织架构
gstack 很容易被误读成"又一个 Claude Code skill 库"。它不是。
addyosmani/agent-skills 是通用工程 skill 集合——代码审查、文档生成、测试编写。coreyhaines31/marketingskills 是营销 skill 集合。这些是技能库：你有一个任务，去库里找对应的 skill 来执行。
gstack 是组织架构。23 个角色不是按"技能"分的，是按职能分的：
| 职能 | 角色 | 对应人类岗位 |
|---|---|---|
| 战略 | /plan-ceo-review | CEO：评审功能是否值得做 |
| 设计 | /design | 设计师：出交互方案 |
| 工程管理 | /plan-eng-review | 工程经理：拆任务、排依赖 |
| 编码 | /build | 高级工程师：写代码 |
| 代码审查 | /review | Staff 工程师：审查 PR |
| QA | /qa | QA 工程师：端到端测试 |
| 安全 | /cso | CSO：安全审计 |
| 发布 | /release | 发布经理：版本管理 |
| 文档 | /docs | 文档工程师：写技术文档 |
/office-hours 描述你在做什么，然后各角色按流程介入：CEO 先评审值不值得做，设计师出方案，工程经理拆任务，工程师写代码，审查员审 PR，QA 测试，发布经理上线。三、810×：一个需要拆解的数字
Garry Tan 在 README 里给出了一个惊人的数字：
"In the last 60 days: 3 production services, 40+ shipped features. 810× my 2013 pace."
810 倍。这个数字需要拆解才能理解。
首先，度量单位是"逻辑代码变更"（logical code changes），不是原始 LOC。这是对"AI 生成代码只是 LOC 灌水"批评的直接回应。逻辑代码变更指的是有意义的、可审查的代码修改单元——一个功能、一个 bugfix、一个重构。不是字符数。
其次，分母是 2013 年的 Garry Tan，不是"普通工程师"。2013 年的 Garry Tan 已经是 YC 合伙人，不是初级开发者。他的 2013 年产出水平远高于行业平均。所以 810× 不是"AI 比普通人快 810 倍"，而是"AI 让一个已经很厉害的人快了 810 倍"。
第三，60 天 3 个生产服务 + 40 个功能。这是结果，不是过程。3 个生产服务意味着从设计到部署的完整链路，包括前端、后端、数据库、CI/CD。40 个功能意味着平均每天 0.67 个功能——对一个人来说，这个节奏在没有 AI 之前是不可能的。
810× 这个数字的可信度取决于"逻辑代码变更"的定义有多严格。如果每次 git commit 都算一个，那灌水空间很大。如果要求"通过审查、合并到 main、部署到生产"才算，那含金量就高得多。gstack 的 /review 角色存在的事实暗示了后者——每个变更都要过审查。
四、/office-hours：把"想清楚"前置
gstack 的入口不是 /build，是 /office-hours。
这是一个很反直觉的设计。大多数 AI 编码工具的入口是"描述你要什么，我给你代码"。gstack 的入口是"描述你在做什么，CEO 先帮你判断值不值得做"。
/plan-ceo-review 会问：这个功能解决什么问题？用户是谁？不做会怎样？做了能省多少时间/赚多少钱？只有 CEO 角色通过了，才进入设计阶段。
这把"想清楚"前置到了"动手"之前。在传统团队里，这是通过会议、文档、评审完成的——成本高、耗时长，所以很多小团队跳过这一步直接写代码，结果写了一堆没人用的功能。gstack 把这一步自动化了，成本降到"一次对话"。
Garry Tan 作为 YC CEO 的经验在这里体现得很明显——YC 投资的标准之一就是创始人有没有"想清楚"。gstack 把这个判断内置进了工具。
五、/cso：安全作为一等公民
gstack 里有一个 /cso 角色——Chief Security Officer。这很少见。
大多数 AI 编码工具把安全当成"可选的 lint 规则"——跑一下 SAST 扫描，有漏洞就报，没有就过。gstack 把安全提升到了角色级别：/cso 会在代码审查阶段主动检查 OWASP Top 10、依赖漏洞、密钥泄露、权限模型。
README 里提到 /cso 需要特殊的 Bun 版本和原生工具链——这意味着它不只是跑 lint，而是做真正的安全分析（可能是符号执行、污点分析）。这比"在 CI 里加一个 SAST 工具"重得多。
为什么要把安全做成角色而不是工具？因为安全是一个视角，不是一个步骤。工具是"跑一下看看有没有问题"，角色是"从安全的角度重新审视整个设计"。前者抓已知漏洞，后者质疑架构选择。gstack 选择后者。
六、30 秒安装：工程品味的体现
gstack 的 ./setup 在 4-vCPU Linux 云机器上 31 秒完成，包括二进制构建和 Chromium 下载。
这不是技术奇迹，是工程品味。31 秒意味着：依赖最小化、构建优化、并行下载。很多开源项目的 setup 要跑 5-10 分钟，中间还要手动装一堆系统依赖。gstack 把这个体验做到了"克隆→setup→开始用"的极短路径。
Garry Tan 在 README 里说"Stop there. You'll know if this is for you."——用 30 秒的安装门槛让用户自己判断，而不是写一篇 5000 字的"为什么你应该用 gstack"。这是对用户时间的尊重，也是对产品质量的自信。
七、gstack 的真正门槛
gstack 的门槛不是安装，是认知重构。
用 gstack 意味着接受一个前提：你不是在写代码，你是在管理一个虚拟团队。你需要学会"委派"而不是"执行"——给 /build 一个清晰的任务描述，而不是自己上手写。给 /review 足够的上下文，而不是期望它猜对意图。给 /qa 明确的验收标准，而不是让它自己定义"正确"。
这和传统工程师的工作方式完全不同。传统工程师的肌肉记忆是"打开编辑器→写代码→跑测试→提交"。gstack 要求的肌肉记忆是"打开终端→跑 /office-hours→描述目标→等各角色介入→审查输出"。
Garry Tan 说 gstack 适合三类人： 1. 还在写代码的创始人/CEO——需要快速验证想法 2. 第一次用 Claude Code 的人——需要结构化引导而非空白 prompt 3. 技术负责人/Staff 工程师——需要自动化审查、QA、发布流程
对第一类人，gstack 是"放大器"——让稀缺的工程时间覆盖更多领域。对第二类人，gstack 是"脚手架"——避免在空白 prompt 里迷失。对第三类人，gstack 是"自动化流水线"——把重复的审查和发布工作交给 Agent。
八、从"个人生产力"到"组织设计"
gstack 最值得关注的不是 810× 这个数字，而是它隐含的一个主张：AI 时代的工程组织可能不需要那么多人。
一个 23 角色的虚拟团队，如果每个角色对应一个真人，那是一个中型工程团队（20-30 人）的规模。gstack 让一个人就能运转这个团队——虽然每个"角色"都是同一个 LLM 在不同 prompt 下扮演的，但角色之间的制衡关系是真实的：CEO 评审值不值得做，工程经理拆任务，工程师写代码，审查员审 PR，QA 测试，安全官审计。
这不是"AI 替代工程师"，而是"一个人 + AI 承担更多职能"。被替代的不是人，是"职能之间沟通的摩擦成本"。传统团队里，CEO 和工程师沟通要开会，工程师和 QA 沟通要写文档，QA 和安全官沟通要发邮件。gstack 把这些沟通压缩成了 slash command。