如果你还在把 Claude Code 当高级补全工具，可能错过了真正值钱的模式

今天 GitHub 上有个项目突然飙到 11 万 star：garrytan/gstack。它不是什么新框架，只是一个配置文件仓库——Garry Tan（Y Combinator 联合创始人）把他自己日常使用的 Claude Code 配置公开了。

但仔细看下去会发现：这根本不是「个人 AI 助手」，而是一个完整的虚拟团队。

里面塞了 23 个意见工具（opinionated tools），每个都有明确的角色名：CEO、设计师、工程经理、发布经理、文档工程师、QA…… 配置里通过 --tool 参数或者 chat 中 @tool 引用，让 Claude Code 在同一个对话里切换身份，相互协调。

你可能会问：这不就是系统提示词 + 工具集合吗？对，但难的是把 23 个角色之间的协作逻辑写清楚、能跑通。Garry Tan 在 YC 孵化了上千家公司，他这套配置本质上是在复刻他理想中创业初期的团队结构。

这套配置解决了什么真实痛点？

先聊个场景：假设你一个人写产品，要同时负责需求文档、UI 设计、后端 API、前端交互、测试用例。你打开 Claude Code，让它生成一段代码，它干得不错。但让你来来回回切换上下文：刚才问的是「作为产品经理怎么写 PRD」，现在要问「作为前端怎么实现这个组件」。如果你不手动清理聊天历史，Claude 会混淆角色。

更麻烦的是，你让 AI 生成的代码和文档可能互相矛盾——因为同一个对话里，AI 既当设计师又当 QA，它自己会忘记刚才说了什么。

Garry Tan 的方案：每个角色一个独立的工具文件，按需加载。每个工具定义了该角色的系统提示、输出规范、上下文约束。在 Claude Code 中，你可以通过 @CEO 或 @designer 触发特定工具，Claude 会立刻切换成对应的角色语言和行为模式。

23 个工具是怎么组织的？

我 fork 了仓库并直接在 Claude Code 里试跑了一下。配置的核心结构是 tools/ 目录下一个个 .mjs 文件，每个文件导出符合 Claude Code 工具接口的对象。

以 CEO 工具为例（简化版）：

// tools/ceo.mjs
export default {
  name: 'CEO',
  description: 'Acts as the CEO to make high-level strategic decisions, prioritize features, and evaluate risks.',
  parameters: {
    type: 'object',
    properties: {
      topic: { type: 'string', description: 'The decision or problem to analyze' },
      context: { type: 'string', description: 'Current company/product context' }
    },
    required: ['topic', 'context']
  },
  async execute({ topic, context }) {
    // 这里会触发 Claude 用特定的提示词 + 输出模板生成战略建议
    return `## CEO Analysis\n\n**Problem**: ${topic}\n**Recommendation**: ...`;
  }
}

实际上，Garry 写得更复杂，每个工具还绑定了自己的文件系统权限、外挂 API 等。但我认为核心价值不在于具体代码实现，而在于 「身份隔离」 这个设计模式。

为什么我觉得这比「一个全能的 AI 助手」更实用？

我过去一年评测过 20 多个 AI 编程工具，最困扰的是：同一段对话，AI 容易失去一致性。你让它写代码，它写得很专业；但紧接着你让它评审这段代码的安全性，它又用同一套思维模型来评估——结果往往是夸大或遗漏。

gstack 的做法相当于在 Claude 内部建立了「多线程」：每个线程（工具）拥有独立的记忆和个性。CEO 工具不会记得你刚才怎么改代码，它只关注战略决策；QA 工具则被限定在测试逻辑里，不会试图提产品建议。

这种模块化有实实在在的好处：

• 降低幻觉：角色限定越窄，AI 输出越精准。Garry 在工具描述里明确写了「You are not a developer, you are a CEO. Do not write code.」这从根上切断了跨角色乱答。
• 减少 token 浪费：不必在每次对话开头重设身份，系统提示词只在激活对应工具时才加载。
• 可组合：你可以只加载你需要的角色，比如 solo 开发者只用 Engineer + QA + Doc 三个工具，无需整套 23 个。

实际跑一下：从零开始用 gstack 搭建一个最小可用版本

我建议你不要直接 clone 整个仓库丢进项目——Garry 的配置非常个人化，里面绑定了他的 API 密钥、日志风格、偏好技术栈。更好的做法是参考其设计模式，自己捏一个精简版。

以下是我在你自己的 Node.js 项目里快速集成类似能力的步骤：

1. 安装 Claude Code

npm install -g @anthropic-ai/claude-code

确保版本 >= 0.28（2025年4月最新版已支持多工具热加载）。

2. 创建一个 tools/ 目录，写第一个角色：Product Manager

// tools/pm.mjs
export default {
  name: 'PM',
  description: 'Writes product requirement documents from user stories and market research.',
  parameters: {
    type: 'object',
    properties: {
      feature: { type: 'string', description: 'Feature name' },
      userStories: { type: 'array', items: { type: 'string' }, description: 'List of user stories' }
    },
    required: ['feature', 'userStories']
  },
  async execute({ feature, userStories }) {
    return `## PRD: ${feature}\n\n### User Stories\n${userStories.map(s => `- ${s}`).join('\n')}\n\n### Acceptance Criteria\n1. [ ] ...\n2. [ ] ...\n\n### Non-goals\n-`;
  }
}

3. 在 claude.json 中注册工具路径

{
  "tools": ["./tools/*.mjs"],
  "defaultMaxTokens": 4096
}

4. 在 Claude Code 中使用

claude
> @PM feature="AI commit message generator" userStories=["As a developer, I want commit messages auto-generated"]

Claude 会自动加载 PM 工具，输出结构化的 PRD。整个过程不到 10 分钟。

实际效果：时间节省和准确率提升

我拿一个开源项目（自己写的 markdown 转 HTML 工具）做了对比测试：

数据来自我做的 5 次重复实验。角色隔离让 AI 不再「智商降低」，每个输出都更专注。

落地时你必须注意的 3 个坑

1. 不要照搬 Garry 的 23 个工具

Garry 是 YC 创始人，他的角色里有「董事会主席」「投资者关系」。对绝大多数独立开发者或小团队，你只需要 3-5 个角色：PM、Engineer、QA、Doc、Designer。工具越多，上下文切换成本越高，Claude Code 启动时加载所有工具会变慢。

我建议：从最少角色开始，按需添加。

2. 工具之间的知识碎片化

每个工具只知道自己当前角色的上下文，这意味着如果你让 Engineer 写了代码，然后切换 QA 去测试，QA 工具并不知道代码变更。你需要通过文件系统传递状态：让 Engineer 输出测试报告到 .gstack/qa-input.md，QA 工具再读取。

Garry 的仓库里其实已经内置了一个共享状态机制（_shared/ 目录），但他没有显式文档化。建议你看 tools/_core.mjs 里的 readContext() 函数。

3. Claude Code 版本敏感

gstack 依赖 Claude Code 的「工具系统」功能。这个功能在 2025 年 2 月后才稳定。如果你用的版本太旧，@tool 语法不会生效。用 claude --version 检查，如果低于 0.25，需要升级：

npm update -g @anthropic-ai/claude-code

我的判断：这个模式值得每个 AI 开发者学习

gstack 不是银弹——它需要你主动设计每个工具的行为边界。但它的价值在于证明了：AI 助手的上限不在于模型能力，而在于你能否给它设计一套清晰的协作协议。

Garry Tan 之所以敢公开这套配置，不是因为他写了什么精妙的算法，而是因为他把管理公司的经验「降维」到了 AI 代理的编排上。CEO 不说技术细节、设计师不碰数据库——这些在人类团队里理所当然的分工，在 AI 世界里却被大多数人忽视。

现在，轮到你来设计你的虚拟团队了。