Garry Tan 的 Claude Code 工具箱：23 个自定义工具如何改变编码效率

原创。YC CEO Garry Tan 开源了他的 Claude Code 配置文件 gstack——23 个自定义工具让 AI 扮演 CEO、设计师、工程经理和程序员。独立开发者读完可以抄走一半的思路。

2026 年 3 月，Garry Tan 在 GitHub 上开源了 gstack——他的个人 Claude Code 配置文件。项目上线后迅速爆火，两个月内获得超过 10 万颗 Star。

你可能不认识 Garry Tan？他是 Y Combinator 的 CEO，也是创业公司界公认的产品直觉最强的人之一。他早年是设计师出身的程序员，后来做了 Posterous（被 Twitter 收购），再后来成为 YC 的掌门人。

但 gstack 爆火的原因不只是他的身份——而是这个项目确实提供了一种全新的 AI 编码工作方式。

gstack 是什么

gstack 不是一个独立的工具，它是一组 Claude Code 的自定义配置——包括系统提示（system prompts）、工具定义（tool definitions）和设置文件。把这些文件放到你的项目中，Claude Code 的行为就会完全不同。

核心思路是用 23 个自定义工具让 AI 帮你完成传统编码助手做不到的事情：

角色	典型工具	做什么
CEO	`product-strategy`, `competitive-analysis`, `user-persona`	分析市场、定义产品方向
设计师	`ui-critique`, `design-review`, `accessibility-check`	审查 UI、检查可访问性
工程经理	`code-review`, `architecture-review`, `incident-postmortem`	代码审查、架构评审
程序员	`implement-feature`, `refactor-module`, `write-tests`	日常编码工作

关键洞察：不是让 AI 同时扮演所有角色，而是让它在不同阶段切换角色。写代码时它是聪明但听话的程序员；PR 审查时它是有经验的工程经理；定义功能时它是懂市场的产品负责人。

独立开发者能学到什么

1. AI 编码工具不只是写代码的工具

大多数开发者把 AI 编码助手当成一个能自动补全代码的 IDE 插件。但 gstack 展示了一个更广阔的用法：AI 可以是一个团队，而不只是一个程序员。

gstack 的 product-strategy 工具会问这些：

这个功能的用户是谁？
解决了什么具体问题？
为什么不直接买现成的方案？
上线后怎么衡量成功？

作为独立开发者，这些通常是只有自己会在深夜想的问题。现在 AI 可以在几分钟内帮你整理思路、提供替代视角。

2. 系统提示决定上限

gstack 的配置文件中有一段精心设计的系统提示。它不是简单的「你是一个有帮助的 AI」，而是详细描述了：

决策框架：什么情况下应该直接做、什么情况下应该质疑需求
沟通风格：用具体的例子代替空泛的「说人话」
质量门槛：明确列出了什么算「好代码」、什么算「可接受的代码」

这些看似细节的东西，实际效果差距很大。我试过把 gstack 的配置复制到自己的项目里，Claude Code 给出的代码质量确实有明显提升——它会更主动地提出架构问题、更多考虑错误边界、更少写出「能跑但耦合严重」的代码。

3. 上下文就是一切

gstack 的另一个亮点是它的上下文管理策略。它不只是把文件路径传给 Claude Code，而是：

优先提供架构决策记录——为什么选择这个方案，而不是只看到现有代码
自动识别项目类型——根据不同技术栈调整提示
分层上下文——重要信息放在前面，次要信息放后面

对独立开发者来说，这意味着不用花时间重复解释项目背景。配置好之后，AI 能理解你为什么用 SQLite 而不是 PostgreSQL、为什么选择 React 而不是 Vue。

实际体验

我花了几天时间在自己的项目上试用 gstack。

安装

code

# 克隆 gstack 配置
git clone https://github.com/garrytan/gstack.git .gstack
 
# Claude Code 会自动读取项目根目录下的 CLAUDE.md
# 按照 README 的指引，把 gstack 的配置合并到自己的 CLAUDE.md

安装本身很简单，但需要花 15-30 分钟阅读和调整配置——直接照搬别人的系统提示一般效果不好，因为每个人的项目和技术偏好不同。

最有用的功能

产品策略分析：我最近在做一个微小本收入的工具，想让 AI 帮我分析定价策略。gstack 的 product-strategy 工具给出的建议比我预期的要实用——不是泛泛的「考虑免费增值模式」，而是基于我的用户场景和竞争格局给出了三种具体定价方案的对比分析。

代码审查：gstack 的 code-review 工具不只是找 bug，它会从代码可维护性、测试覆盖率和性能影响三个维度给出审查意见。这些意见的质量大概相当于一个中等经验的同事做 code review——不是最好的，但已经比大多数项目完全没有 code review 强太多。

不足之处

配置相对复杂。23 个工具不是每个都对你有用，需要时间筛选和定制。
Token 消耗增加。更多的系统提示和工具定义意味着每次对话消耗更多 token。如果 API 是按量计费，成本会比默认配置高一些。
学习曲线存在。不是装上就能用——你还是要理解每个工具在什么时候用、怎么用。

独立开发者的最佳实践

从 gstack 的思路出发，我为自己的项目整理了一套更精简的配置方案：

第一阶段（新手） 只加两个工具：code-review 和 write-tests。这两个工具的收益最高、配置最简单。

code

## Code Review
每次提交前，运行代码审查：
- 检查逻辑错误和边界情况
- 确认测试覆盖率
- 建议重构点（但只需列出，不自动修改）

第二阶段（进阶） 加入 architecture-review 和 refactor-module。开始让 AI 参与更大范围的决策。

第三阶段（完整） 根据项目需求定制自己的工具集。不一定非要 23 个——4-5 个精心设计的工具比 20 个很少用的工具效果更好。

值得关注的问题

依赖风险。gstack 依赖 Claude Code 的插件系统。如果 Anthropic 修改了插件接口或使用条款，你的配置可能需要跟着更新。对于商业项目，需要评估这种依赖的风险。

不是替代品。gstack 不会替代你作为独立开发者的核心能力——理解用户、做产品决策、建立与用户的联系。它扮演的是放大器的角色：你的项目理解越深、产品直觉越准，它的辅助效果就越强。

开源维护。gstack 是一个个人项目，更新频率和 issue 回复速度取决于 Garry Tan 的时间投入。如果你的项目依赖它，建议 fork 一份自己维护。

总结

gstack 给我的最大启发不是那 23 个工具的具体实现，而是它展示了**「AI 编码工具可以不只是编码工具」**这个观念。

独立开发者的天然劣势是人手不足——一个人要做 CEO、产品、设计、开发、运营、客服全部工作。gstack 的思路是在 AI 成本已经足够低的今天，让 AI 帮你填补这些角色的空缺。你不用真的雇一个产品经理，但可以让 AI 在需要的时候戴上产品经理的帽子。

如果你已经在用 Claude Code 或其他 AI 编码助手，去 GitHub 上看看 gstack，抄几个工具定义放到自己的项目里。就算只用一个 code-review 工具，收益也值得那 15 分钟的配置时间。