📌 项目地址：garrytan/gstack | ⭐ 102,359 颗星 | 🔧 TypeScript | 📜 未标注
不是另一套prompt模板
gstack仓库里没有代码。102359个star指向的是一堆Markdown文件。这些文件定义了23个AI角色和8个工具命令，全部通过斜杠在Claude Code里调用。
Y Combinator总裁Garry Tan用这套流程，2026年前四个月（兼职）交付了3个生产服务和40多个功能，贡献了1237次commit。他自称逻辑代码变更量是2013年的810倍——这个数字有争议，但他公开了复现脚本和方法论文档。
核心逻辑：把传统软件工程的角色拆成独立系统提示词。CEO、工程经理、设计师、QA、安全官、发布工程师，每个角色一个模板。AI按角色扮演，流程可git追踪、可code review、可版本管理。
23个角色和8个命令的实际用法
README说得很清楚：gstack把Claude Code变成一个虚拟工程团队——一个重新思考产品的CEO，一个锁定架构的工程经理，一个抓AI粗糙交互的设计师，一个找生产bug的代码审查者，一个开真实浏览器的QA负责人，一个跑OWASP+STRIDE审计的安全官，一个发PR的发布工程师。总共23个角色，外加8个工具，全部是斜杠命令。
我实际用过之后，发现不是每步都要走全。一个典型的新功能流程是这样的：
- 跑CEO角色确认需求方向
- 跑工程经理角色拆任务、定架构
- AI写代码（直接对话）
- 跑审查角色检查代码
- 跑QA角色开浏览器测试
- 跑安全角色做安全审计
- 跑发布角色打包出PR
每个角色有自己的约束条件。比如工程经理不能擅自改需求，设计师必须提具体问题。角色之间有制衡——CEO定的需求工程经理觉得不可行可以拒绝。这对单人+AI的工作流很关键，没人review的话，AI写的bug谁发现？
8个工具命令包括生成实现方案、结构化批评、编写规格文档、生成文档、自动changelog等，按需取用。
为什么有效：Markdown文件作为AI行为配置文件
原理不复杂：给Claude Code换系统提示词。但两个设计让它从玩具变成了工程工具。
第一，角色间有检查机制。不是一次prompt跑到底，而是多次对话，每次切换角色重新评估。这模仿了真实团队中的审批流程。
第二，所有模板是纯Markdown文件。这意味着你可以git diff，可以提交PR，可以回滚。你对AI的行为管理从“玄学”变成了可复现的配置文件。哪天AI表现不对，看一眼哪次commit引入了问题。这个设计让团队协作成为可能——不同成员可以fork、修改、合并AI提示词，像管理代码一样管理AI行为。
810倍效率争议，Garry Tan自己怎么说
README里引用了Andrej Karpathy在2026年3月的一句话：“我大概从去年12月起一行代码都没写，这是巨大的转变。” Garry Tan想复现这种效率。他给出了自己的数据：
- 2013年（单人做YC内部网络Bookface）：772次commit，日均14行逻辑代码变更
- 2026年前四个月：1237次commit，日均11417行逻辑代码变更
- 2026年前四个月累计逻辑变更量是2013全年的240倍
- 日均效率差810倍
他专门写了《On the LOC Controversy》解释统计方法：原始行数被AI膨胀没错，但用逻辑代码变更（去掉空行、注释、格式化噪音）来衡量，真实产出远高于十年前。数据来源是40多个公开+私有仓库，排除了一个demo仓库，有复现脚本可跑。
我个人觉得这个比较不够严谨——2013年他可能在干别的事，2026年AI工具也不同。但他至少公开了方法论，你可以自己评估。
与项目管理工具的区别
gstack和普通prompt模板的区别，在于它引入了角色制衡。传统prompt是一次性输出，没有多轮审查。gstack强制你把开发流程拆成多个决策点，每个点由不同“角色”把关。
这比Jira+Confluence写一大堆文档更轻量——所有定义都在Markdown里。也比直接让AI写代码更可控——至少有一个专门的角色负责找bug。
但gstack不是项目管理工具，它缺少任务分配、进度追踪、依赖管理这些功能。它只解决一个问题：让AI在不同开发阶段扮演不同角色，而不是全知全能的“助手”。
我试了三条建议
第一，别贪多。23个角色看着唬人，实际从3-4个开始就够。我最初只用了工程经理、reviewer、QA三个角色，跑通后再加CEO和设计师。
第二，修改提示词模板。Garry的模板是针对他自己的项目风格写的。CFO角色对财务合规要求高，但小项目没这个需求，可以删掉。把不相关角色的权重调低。
第三，必须用Claude Code。README没有提对其他AI工具的支持。如果Claude自身有逻辑错误，角色扮演也救不了。这是当前的最大限制。
对比：gstack vs 纯AI对话
- 纯AI对话：一次prompt写完整功能 -> 代码可能带着bug上线 -> 没有code review -> 单人盲区明显
- gstack流程：CEO确认需求 -> 工程经理拆任务 -> AI写代码 -> reviewer检查 -> QA测试 -> 安全审计 -> 发布PR
多出来的步骤花时间，但减少后期返工。Garry自己说兼职跑这个流程，两个月做40个功能。你如果全职，节奏可以更快。
谁应该尝试
技术型创始人：你懂代码，但“怎么用AI保证质量”经常凭感觉。gstack把这事标准化了。23个角色不是每次都要全用，但reviewer查bug、QA测功能、安全官做审计这几个步骤能明显提升产出质量。
Claude Code用户：从随意打字升级到流程化开发。你不需要所有角色，但需要一套可控的审查流程。
多人协作的AI编程团队：这些Markdown文件可以git管理，每个角色提示词的变更都有历史。新成员入职直接看文件，不需要口头传授。
不适合：对一切流程化有抵触的人；想一键生成所有功能的用户；非Claude Code用户。
局限性
- 依赖Claude Code。README没有提对其他AI工具的支持。
- 23个角色对小型项目可能过重。从最小可用集开始，别一口气全上。
- 角色间的制衡靠提示词约束，不是硬性规则。AI可能跳过某些检查步骤。
- 纯文本工作流意味着你不能拖拽任务、不能看甘特图、不能自动通知。这些得你自己加。
总结
gstack的价值不在于代码量，而在于把“一个人用AI写代码”的直觉经验，变成了可分享、可审查、可git diff的配置文件。在单人+AI的工作流里，代码审查、测试、安全分析这些环节经常被跳过。gstack把它们强行加回来，用角色制衡减少AI犯低级错误的机会。
MIT许可证，可以随意fork和商用。如果你有Claude Code并且想给自己定一套AI工作规范，gstack是个好起点。把流程写进Markdown，而不是记在脑子里。
标签：AI编程, Claude Code, 工作流配置, GitHub项目