如果你关注过 AI 编程助手,大致率听说过 Claude Code。Garry Tan——YC 创始人之一——在 GitHub 上开源了他个人使用的 Claude Code 配置,叫 gstack,包含 23 个工具,覆盖 CEO、设计师、工程经理、发布经理、文档工程师和 QA 六大角色。一下子涌进来 11 万星标,不少程序员想照搬这套配置,觉得能一步到位提升效率。但实际装上用一下,情况没那么简单。
配置长什么样
gstack 本质上是一个精心组织的 Claude Code 配置文件(.claude 目录),里面定义了 23 个自定义工具,每个工具对应一个 shell 命令或脚本,通过 JSON 描述告知 Claude 何时调用、怎么调用。这些工具被分到六个角色标签里,列如“CEO”角色下有个 gen_summary 工具,用来生成项目摘要;“QA”角色下有 run_tests 和 lint 工具。你可以直接克隆仓库,把配置复制到自己的项目里,或者在全局安装后让 Claude 加载这些工具。
仓库文档说得很清楚:这些工具是“opinionated”——带有强烈个人偏好。Garry Tan 根据自己的工作流设计了这些工具,列如他习惯用 bun 运行 JavaScript,用 fd 搜索文件,用 bat 预览代码。如果你平时不用这些工具,就得额外安装,否则配置没法跑。
照搬后的实际体验
拿一个中等规模的 TypeScript 项目测试,克隆 gstack 后按文档执行初始化脚本,它会自动把工具注册到 Claude Code 的配置里。之后打开 Claude Code,输入“帮我写一个用户登录模块”——Claude 会尝试调用 gstack 里的 gen_summary 先了解项目结构,然后调用 read_files 读取现有代码,再调用 write_code 生成代码。整个过程比默认配置多了一步信息收集,Claude 生成的代码更贴合项目现有风格,由于它先看了项目摘要。
但问题也来了:许多工具在实际对话中很少被 Claude 主动调用。列如 gen_prd(生成产品需求文档)和 gen_design_doc(生设计文档),在纯粹编码任务里根本不会触发。只有当你明确要求“写一个 PRD”时,Claude 才会用它们。另外,部分工具依赖的命令在 Windows 上不兼容,列如 fd 和 fzf,Windows 用户得自己找替代版。
还有一个坑:工具数量多,每次对话 Claude 都要花时间解析所有工具的 JSON 定义,响应速度比默认配置慢 1-2 秒。如果你的项目不大,这个开销不明显,但大型 monorepo 里,每次调用工具前的解析时间会累积。
哪些工具值得保留,哪些可以删掉
我测试后认为最实用的是这几类: – 文件操作类:read_directory、read_files、edit_files 这些让 Claude 能更准确地读写代码,减少幻觉。 – 搜索类:grep_search、fd_search 替代了 Claude 内置的模糊搜索,结果更准。 – 测试类:run_tests、lint 让 Claude 在生成代码后自动跑测试,发现错误立刻修正。
不太常用的包括:gen_tweet(生成推文)、gen_brainstorm(头脑风暴)、gen_marketing_copy(营销文案)——除非你的项目需要这些,否则只是占位。还有 simulate_user(模拟用户操作)依赖 Puppeteer,安装起来很重,且多数场景用不上。
提议保留 10-15 个核心工具,其余关掉。在 .claude/settings.json 里可以把不需要的 enabled 设为 false,或直接删除对应的工具 JSON 文件。这样 Claude 启动更快,也减少误调用。
不适合什么人
- Windows 用户:许多工具依赖 Unix 命令,需额外安装 WSL 或替代工具,体验打折。
- 只用默认 Claude Code 的用户:如果你觉得默认配置已经够用,gstack 带来的改善有限,反而增加了复杂度。
- 追求极简的项目:一个小工具库或脚本集合,不需要这么多角色和工具,自己写几个自定义工具就够了。
这套配置最大的价值不是直接复制,而是展示了一个高级用户如何通过自定义工具让 Claude 更懂自己的工作方式。你可以参考它的思路,为自己的项目写少量针对性工具,而不是全盘照搬。
总结
gstack 是一个方向正确的尝试,但“硅谷明星创始人的配置”不等于“你的配置”。花一小时装完后,我删了一半工具,只保留了文件操作、搜索和测试相关。目前的 Claude Code 响应更快,也更贴合我的日常编码流程。如果你有闲心折腾,不妨一试,但别抱太高期望。