> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # gstack：Claude工程团队 - URL: https://www.hubwiz.com/blog/gstack-cloud-engineering-team/ - Published: 2026-03-17T01:39:46.000Z - Updated: 2026-03-17T01:39:46.000Z - Description: gstack 是一个很好的起点，也是 Claude Code 上独立开发者和小团队的强默认选择。 - Author: admin - Tags: TOOL, GSTACK, #Import 2026-10-14 14:41 Garry Tan 开源了他的个人 Claude Code 配置 gstack。 六个斜杠命令，每个都锁定特定的工程角色，旨在用一种映射真实工程组织运作方式的方式来取代单一的模糊模式问题。 Garry 对此非常认真，以下是今天的发布说明： 这显然不是一堆 markdown 文件，发布后立即引起关注：一位 CTO 朋友在发布后不久给 Tan 发短信说 > "你的 gstack 太疯狂了。这就像是上帝模式。你的代码审查发现了一个我甚至不认为我团队意识到的跨站脚本攻击。" 让我们来分解 gstack 的作用以及它与其他工作流的定位。 我希望你们能清楚地了解这是否属于你们的工具栈，更重要的是，**为什么**这种基于角色的 AI 开发正在成为行业中的一个趋势。 ## 1、单一模式问题 与 Claude Code（或 Cursor、Copilot）的典型开发者交互是将其视为一个能做一切事情的能力很强的伙伴。 它**确实**能做一切，这就是问题所在。 当你让同一个模型，在同一个对话中，规划你的功能、实现它、审查它、发布它，你在对抗一个非常人性化组织事实：**软件开发的**不同阶段需要**根本不同的认知模式**。 - CEO 思考要构建什么以及为什么。 - 工程经理思考架构、数据流和边缘情况。 - 进行代码审查的资深工程师在寻找代码在生产环境中会如何崩溃的方式。 - QA 工程师想知道它是否真的*能正常工作*。 - 发布经理想要部署检查清单被勾选。 这些不是相同的工作 gstack 是关于 AI 如何映射到软件构建方式的一个结构性声明。 TurboDocx 的人在 gstack 发布三周前写了自己的 Director/Manager/Team 模型，当他们看到 gstack 时，他们的反应是"这是趋同进化"。 相同的思维模型但不同的实现，这就是为什么我们要讨论它。 ## 2、什么是 gstack？ [gstack](http://github.com/garrytan/gstack?ref=hubwiz.com) 是一个 **技能包**，八个固执己见的斜杠命令，你安装到 Claude Code 中，每个都有自己独立的系统提示、自己的优先级、自己的"完成"定义。 设置是一个单独的粘贴命令，它通过将技能安装到你的 `.claude/skills/` 目录中来工作。 以下是完整的分解： 每个技能都被限制在一个车道内，不能漂移。`/plan-ceo-review` 不关心你如何实现它。`/review` 不关心产品战略。 它们是刻意狭隘的*。* ## 3、角色分离优于一刀切 Garry Tan 对为什么存在 gstack 的表述很直白："我不希望 AI 编程工具困在一种模糊的模式中。" 这个解决方案概念上简单，执行起来困难：给开发的每个阶段自己的代理角色，有自己的使命。 这与 2026 年初更广泛的 Claude Code 社区中涌现的趋势是一致的。 自定义 CLAUDE.md 文件、基于角色的系统提示和斜杠命令库都指向同一个发现：当你给 AI 编程工具一个清晰的车道时，它们的工作效果会显著更好。 ## 4、杀手级技能：/plan-ceo-review 我认为 `/plan-ceo-review` 是整个包中最被低估的东西。 Tan 将其描述为"Brian Chesky 模式"，以 Airbnb 首席执行官对 10 星体验的现在著名的执着命名。 在你写任何一行代码之前，强制自己问：如果这个功能做得非常好，以至于用户会告诉其他人，那它会是什么样子？ 它解决了我在代理工作流中经常遇到的一种失败模式。当你给 Claude 一个 Jira 工单并说"实现这个"时，模型会优化你陈述的需求。 它会精确构建你描述的内容，如果你描述的东西是错误的（根据我的经验，往往是部分错误），你会得到一个执行得非常漂亮但错误的结果。 `/plan-ceo-review` 短路了这一点。 它强制 AI 在执行开始之前进入一个具有挑战性的角色。 我发现自己更愿意质疑需求，因为这个步骤会显示我原本不会主动询问的产品级替代方案。 这确实很有用，特别是当我正在开发业务逻辑仍然模糊的功能时。 ## 5、我实际会使用的模式 对于我自己的工作，我发现最有用的模式是： 1. **每个功能都从** **`/plan-ceo-review`** 开始，即使是小的工单。尤 其是小工单。在写任何代码之前捕捉到"我们在构建错误的东西"的 ROI 是巨大的。 - **在实现之前运行** **`/plan-eng-review`** ，将 ASCII 图输出作为实际架构文档。它强制模型承诺一个你可以追究其责任的结构。 - **在任何 PR 打开之前运行** **`/review`** ，作为没有参与实现对话且没有上下文锚定到现有代码的对抗性通过。 - **对于任何涉及 UI 或认证流程的更改使用** **`/browse`** ，持久化的 Chromium 守护进程是这里的差异化因素。终端中的视觉回归检查优于 Slack 中的"看起来不错"。 - **让** **`/ship`** **处理 git 仪式，** 同步 main、运行测试、推送、打开 PR。这个在你一天手动做十次之前感觉很小。 - **在每个 sprint 结束时运行** **`/retro`** ，这个是我以前没有做过的，提交分析输出对于发现工作实际去向的模式比我预期的更有用。 另一种运行方式是使用 Conductor。 > [Conductor](https://conductor.build/?ref=hubwiz.com) 并行运行多个 Claude Code 会话——每个都在自己隔离的工作区中。这意味着你可以有一个会话在 staging 上运行 `/qa`，另一个在 PR 上做 `/review`，第三个实现功能，另外七个在其他分支上工作。所有同时进行。 新功能经常添加，正如你从发布说明中看到的，它正在成为另一个你可以在工作流中实验的代理操作系统。 ## 6、结束语 gstack 是一个很好的起点，也是 Claude Code 上独立开发者和小团队的强默认选择。 如果有复杂的审查要求，添加通过。 如果有强大的构建约定，添加构建技能。 但不要等到你有了"完美"的系统。 安装它，在下一个进入你队列的工单上运行 `/plan-ceo-review`，看看会发生什么。 --- 原文链接: [Garry Tan's gstack: Running Claude Like an Engineering Team](https://agentnativedev.medium.com/garry-tans-gstack-running-claude-like-an-engineering-team-392f1bd38085?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处