YC 创投掌门人Garry Tan开源自己的智能体Skill配置，8000 人点了Star：原来我们在用最低效的方式，挥霍 AI 最强大的能力

打开 Claude Code 或者 豆包，把需求往里一扔，等 AI 给你”生成”代码。结果拿到手的东西，能跑，能过测试，但总感觉哪里不对，像是一栋外表光鲜、内部走线乱成麻花的房子。

这不是 AI 的问题。是我们使用 AI 的方式，从一开始就错了。

几天前，Y Combinator 总裁兼 CEO Garry Tan 悄悄在 GitHub 开源了一套他个人使用的 Claude Code 配置，项目名叫 gstack。

没有大张旗鼓，没有发布会。结果不到一周，Star 数突破 8000，技术社区炸锅了。

为什么一份”个人配置文件”能引发这么大的轰动？因为它击中了每个工程师心里那根最敏感的弦：我们正在用最低效的方式，挥霍 AI 最强大的能力。

第一关：你把 AI 当”万能助手”，就是在主动降智

大多数人用 AI 编程的姿势是这样的——

脑子里有个模糊的需求，打开对话框，开始输入。AI 帮你写，你帮它改，来来回回，最后拼凑出一个”将就能用”的版本。

Garry Tan 管这叫**”模糊通用模式”**（Fuzzy General Mode）。

在这种模式下，AI 不知道你是在做早期验证的产品原型，还是要上线服务百万用户的生产系统；不知道你最在意性能还是可维护性；甚至不知道你这个需求，到底值不值得做。

结果就是：AI 永远给你一个”平均答案”——不出错，但也不出彩。

gstack 的核心洞见只有一句话：不要让 AI 处于模糊的通用模式，要给它设定极度明确的”认知齿轮”。

每个齿轮，代表一个专家角色。每个角色，只做他最擅长的那一件事。

💡 Actionable Tip： 在你下次向 AI 提需求之前，先问自己一个问题：”我现在需要的，是一个产品经理、架构师、还是执行工程师？” 角色不同，提问方式完全不同。

第二关：6 个角色，覆盖软件交付的完整链路

gstack 提供了 6 个”认知齿轮”，我来帮你拆解每一个：

⚙️ /plan-ceo-review（创始人/CEO 模式）

在你写下第一行代码之前，先过这一关。

它不会乖乖执行你的需求，而是以用户的视角重新审视问题：这个功能真的值得做吗？有没有更简单的方案？什么才是这里的”10 星级产品体验”？

很多工程师最大的浪费，是用极高的技术水准，做了一个根本不该做的东西。这个模式，帮你在动手前先刹车想清楚。

⚙️ /plan-eng-review（工程经理模式）

产品方向锁定后，进入技术架构阶段。

它负责敲定骨架——架构边界、数据流向、状态转换、边缘情况，而且强制生成架构图。

为什么要强制出图？因为语言可以模糊，图不能骗人。一旦画出来，所有隐藏的假设和歧义，都会无处遁形。

⚙️ /review（工程师模式）

这个模式不是来挑剔你的代码风格的。

它专门抓那些能通过 CI 测试、但会在生产环境爆炸的致命 Bug：N+1 数据库查询、并发竞争条件、安全信任边界越权……

这些问题，靠人工 Code Review 往往漏掉，靠普通 AI 也发现不了，因为 AI 在通用模式下只会说”代码看起来没问题”。

⚙️ /ship（发布工程师模式）

这是一个纯粹的执行机器。

一句指令，自动同步主分支 → 运行测试 → 推送代码 → 开启 PR，一气呵成。

把那些每天重复十几遍的机械操作，彻底交出去。

⚙️ /browse（QA 测试工程师模式）

这个最有意思——它给 AI 装上了一双”眼睛”。

它会在本地编译一个无头浏览器，实际登录你的应用、点击按钮、截图、检查控制台报错，60 秒内完成端到端的 QA 测试。

再也不用手动点来点去，再也不用猜”用户会不会遇到这个 Bug”。

⚙️ /retro（工程复盘模式）

分析你过去一周的提交历史、工作节奏和交付速度，自动生成团队或个人的敏捷复盘报告。

数据不会说谎。你觉得自己很忙，但生产力到底在哪里？它帮你看清楚。

💡 Actionable Tip： 把这 6 个模式想象成一条装配线，而不是 6 个互相竞争的工具。每个阶段用对应的齿轮，软件质量会有质的飞跃。

第三关：8000 个 Star 背后，真正稀缺的是什么

技术社区里从来不缺工具，缺的是使用工具的哲学。

gstack 之所以引爆关注，不是因为它的代码有多复杂——恰恰相反，它的实现非常简洁。它之所以被疯狂转发，是因为它提供了一套思考 AI 协作的新框架：

从”让 AI 帮我干活”，升级到”让对的专家在对的时机介入”。

这个转变，听起来简单，但背后是一种深刻的认知升级：你需要先想清楚自己在软件交付的哪个阶段，才能激活 AI 最强的那部分能力。

Garry Tan 作为投资过数百家科技公司的人，深知一个道理：工具决定上限，但使用工具的方式，决定你能不能触达上限。

对大多数工程师来说，AI 编程助手的能力早就超过了我们的使用姿势。

我们是时候把姿势升级了。

💡 Actionable Tip： 现在就去 GitHub 搜索 garrytan/gstack，把这套配置 Clone 下来，在你的下一个项目里实际跑一遍 /plan-ceo-review 和 /review，感受一下”有角色的 AI”和”通用 AI”的区别。

回到开头那个问题：为什么我们用 AI 写的代码，总感觉差点意思？

因为我们一直在用”提问者”的姿势，和一个”全能专家”打交道。

gstack 告诉我们：不是要找一个更聪明的 AI，而是要在正确的时机，召唤正确的专家。

这套思路，值得每一个认真用 AI 做产品的人收藏和实践。

开源地址：github.com/garrytan/gstack

转发给你身边还在用”通用模式”写代码的朋友，也许能帮他们少踩几个月的坑。

💬 来聊聊

你现在用 AI 编程最大的痛点是什么？是代码质量参差不齐，还是根本不知道怎么把需求说清楚？欢迎在评论区告诉我，说不定下一篇文章就是为你写的。

本文作者：申导Jacky 优普丰AI智能体敏捷创新培训咨询机构合伙人

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。