Source: https://aiprimetech.io/zh/blog/gstack-claude-code-setup-guide/ 2026 年七月 15 日 · 7 分钟 · 工具 # 面向 Claude Code 的 gstack：其 23 智能体工作流究竟能做什么 A 作者 [AI Prime Tech](https://aiprimetech.io/zh/) · AI 辅助撰写 一个涉及 14 个文件的拉取请求可能通过单元测试，却仍因三个完全不同的原因而失败：产品行为定义不够明确、界面使用不便，以及发布说明遗漏了一个迁移步骤。只运行一次 Claude Code，并让它“审查这个 PR”，会将这些问题压缩到一场负担过重的对话中。 gstack 采用了更有主张的方法。它的 23 个基于角色的工具将软件交付拆分为规划、设计、实现、审查、浏览器 QA、发布工作和文档编写。你无需让一个通用编程助手临时设计流程，而是调用一系列专注于特定任务的 Claude Code 工作流，例如 /plan-ceo-review, /plan-eng-review, /review, /qa，以及 /ship. 这一差别很重要。gstack 不仅仅是一个实用提示词目录，它的“23 个智能体”也不是 23 个持续在后台自主协作的工作者。它们是针对特定角色的 Claude Code 技能，在工程工作流的特定阶段被调用。其价值来自它们所规定的运作模式，大部分额外开销也同样源于此。 ## gstack Claude Code 是操作系统，而非提示词包 理解它的一个实用思路是，将 gstack Claude Code 视为构建在 Claude Code 之上的工程操作系统。每个工具都会为 Claude 指定角色、流程和预期输出。这些工具共同体现了一套关于软件应如何从想法走向生产环境的主张。 一个通用提示词可能是： ``` Review my implementation plan. ``` 基于角色的工作流会提出一个范围更明确的问题： ``` /plan-eng-review ``` 该技能可以引导 Claude 检查架构、依赖关系、故障模式、可测试性、发布风险和实施顺序。面向产品的规划技能可以从用户价值和范围的角度检查同一份计划。面向设计的技能则可以质疑交互细节，而非后端边界。 区别在于可重复性。团队成员不必各自记住一份 40 行的审查提示词，也不必自行编写检查清单。技能承载了这套流程。 其中的取舍同样重要：gstack 将他人的流程引入你的代码仓库。它假设多轮审查、明确的 QA 和结构化的发布工作，值得投入它们所消耗的上下文和时间。这通常适用于生产环境变更，但对于一个拼写错误或两行内部脚本来说，就显得过度了。 ## 这 23 个基于角色的工具实际涵盖哪些工作 仓库中的具体工具列表可能会变化，因此我以检出的 SKILL.md 文件为准，而不依赖截图或发布介绍。其架构的关键在于职责划分。 | 交付阶段 | 代表性工具 | 要求 Claude 完成的工作 | 主要局限 | 产品规划 | /plan-ceo-review, /office-hours | 质疑问题定义、用户价值、范围和产品假设 | 产品判断仍然依赖所提供的客户背景信息 | 工程规划 | /plan-eng-review | 检查架构、数据流、边界情况、测试和发布安排 | 无法验证未记录在文档中的基础设施约束 | 设计 | /plan-design-review, /design-consultation | 审查交互结构、视觉决策和可用性 | 文本和截图不如对真实用户的观察有说服力 | 实施控制 | /careful、防护或冻结类工具 | 限制高风险编辑，并将工作保持在声明的边界内 | 约束可能拖慢合理的跨领域变更 | 代码审查 | /review | 检查差异中的缺陷、回归、安全问题和缺失的测试 | 大型差异仍可能超出实际可投入的审查精力 | 运行时 QA | /qa, /browse | 通过浏览器操作应用，并检查实际行为 | 环境配置和测试数据决定覆盖范围 | 版本 | /ship | 执行发布检查，并协调提交或交付步骤 | 需要审慎控制 Git 和部署权限 | 文档 | /document-release, /retro | 记录已发布的行为、发布背景和经验教训 | 必须对照最终系统核查生成的文字内容 这就是为什么将 gstack 称为“提示词集合”低估了它的价值。规划产出为实施提供依据；实施产生代码差异；审查和 QA 检验这些差异；发布和文档工作则将结果整理交付。 这也解释了为什么“23 智能体工作流”可能具有误导性。调用技能时，实际发生的是 Claude Code 加载指令，并使用当前会话中可用的工具执行相应工作流。除非某项技能明确委派工作，否则并不存在 23 个共享全局状态的持久运行进程。 ### 规划中的冗余是有意设计的 产品、工程和设计审查存在重叠。这是刻意安排的。 以拟议中的“导出所有客户活动”功能为例： - 产品审查会问，用户需要的是完整导出，还是经过筛选的报告。 - 工程审查会问，导出数据能否装入内存，以及重试机制如何运作。 - 设计审查会问，导出状态、失败提示和下载控件应显示在哪里。 - QA 会问，没有记录、链接过期或任务中断时会发生什么。 在实践中，这种职责分离能发现通用实施计划中被忽略的假设。代价是反复加载上下文。如果计划本身已有 8,000 个 token，三轮审查可能会带来高昂成本，并产生重复的意见。 ### 审查和 QA 是不同的工作 /review 主要依据来自代码的证据：差异、类型、测试、调用位置和仓库约定。 /qa 和 /browse 可以从应用本身收集运行时证据。 这种分离是 gstack 较为出色的设计思路之一。代码差异可能看起来正确，但渲染结果却无法使用。反过来，浏览器中的正常流程检查可能通过，但实现却引入了竞态条件或授权绕过问题。 一个实用的执行顺序如下： ``` /plan-eng-review /careful # Implement the approved plan in Claude Code /review /qa /document-release /ship ``` 不要将其视为强制性的流水线。对于数据库迁移，工程审查和回滚规划可能比视觉设计重要得多。对于 CSS 回归问题， /browse、设计审查和 QA 可能就是核心工作流。 ## 在不盲目信任的前提下安装 gstack 典型的用户级安装方式是将仓库放入 Claude Code 的技能目录，然后运行其安装脚本： ``` git clone https://github.com/garrytan/gstack.git \ ~/.claude/skills/gstack cd ~/.claude/skills/gstack ./setup ``` 如果安装后未立即发现新命令，请重启 Claude Code。然后检查已安装的技能，而不要假定公布的数量仍与你检出的版本一致： ``` find ~/.claude/skills/gstack \ -name SKILL.md \ -print | sort find ~/.claude/skills/gstack \ -name SKILL.md | wc -l ``` 一个常见陷阱是，仅因为仓库受欢迎就运行安装脚本，却不阅读它们会修改什么。gstack 包含可执行的工作流机制，并非静态的 Markdown。运行安装脚本之前，先检查它： ``` cd ~/.claude/skills/gstack git status --short git log -1 --oneline sed -n '1,240p' setup ``` 在团队中推广时，应固定到经过审查的提交，而不是悄然跟随仓库的最新状态： ``` git clone https://github.com/garrytan/gstack.git vendor/gstack cd vendor/gstack git checkout ./setup ``` 随着项目发展，具体的安装流程和依赖项可能发生变化。因此，应以仓库当前的 README 和安装脚本为准，而不是照搬旧文章中的命令，包括本文。 ## 用 Claude Code 权限约束工作流 某些 gstack 工具需要较广泛的访问权限，才能检查文件、运行测试、操作浏览器或与 Git 交互。这并不意味着每个工具都应获得不受限制的 shell 和发布权限。 项目级的 .claude/settings.json 可以建立一个保守的基准配置： ``` { "permissions": { "allow": [ "Bash(git status:*)", "Bash(git diff:*)", "Bash(npm test:*)", "Bash(npm run lint:*)" ], "deny": [ "Read(./.env)", "Read(./.env.*)", "Bash(git push:*)", "Bash(git push --force:*)" ] } } ``` 请将其视为策略示例，而不是可通用的即用文件。根据你的包管理器、测试运行器和 Claude Code 版本调整命令。 明确禁止 git push 在评估期间尤其有用。 /ship 仍然可以检查发布准备情况，但最终产生网络副作用的操作仍由人掌控。团队了解工作流后，你可以再决定是否有理由授予范围严格限定的推送权限。 此外，应在预发布环境或预置了测试数据的本地环境中测试面向浏览器的技能。如果工作流点击了破坏性操作控件，使用生产环境会话的浏览器自动化可能会修改真实记录。 ## 先采用部分工具，再采用整套系统 我不会在第一天就向团队引入全部 23 个工具。应从现有流程中信息流失最多的环节入手。 一个合理的评估矩阵如下： | 团队问题 | 优先采用 | 初期暂缓 | 计划遗漏边界情况 | /plan-eng-review | 完整的设计和发布流程 | UI 变更悄然引发回归 | /browse, /qa, /plan-design-review | 产品策略工作流 | 审查不一致 | /review | 自动化发布 | 发布缺少背景信息 | /document-release, /retro | 浏览器工具 | Claude 的编辑范围过大 | /careful 和范围控制 | 端到端工作流采用 在几次真实变更中运行这部分工具，并记录： - 哪些发现促成了代码或范围变更？ - 哪些发现是重复的？ - 需要重复提供多少上下文？ - 生成的产物是否始终与实现保持同步？ - 哪些命令需要团队不愿在 CI 中授予的权限？ - 开发者是否理解何时调用各个角色？ 上下文开销并非理论问题。每个角色都需要仓库状态、需求和此前的决策。分开的会话可能丢失决策依据；一个长会话则可能积累过时的假设。我会将已批准的计划保存在仓库文件中，例如 docs/plans/export-jobs.md，然后要求每个工作流使用该产物。持久保存的文件，比指望对话上下文充当项目记忆更可靠。 ## 文档所述行为与宣传主张 有依据的说法是，gstack 提供了 23 个面向角色的 Claude Code 工具，以及一套贯穿软件生命周期、带有明确主张的工作流。你可以通过阅读已安装的技能，并在测试仓库中执行它们来验证这些行为。 至于大幅提高产出、取代工程团队或将数周工作压缩到数小时等更广泛的说法，在你的环境中得到证明之前，都只是宣传主张。结果取决于仓库质量、测试覆盖率、任务的模糊程度、模型选择、权限，以及监督工作的开发者。 当前的模型阵容也无法消除这些约束。Sonnet 4.6 可能是持续编码工作的实用默认选择，而 Haiku 4.5 可以适用于较轻量的分类或文档任务。Fable 5 的 1M 上下文可以帮助处理规模非常大的材料，gpt-5.6-sol 则在受支持的环境中提供了另一个面向工程的选项。它们都无法将角色提示词变成经过验证的产品知识或生产环境证据。 ## 实践要点 - 将 gstack 视为一套通过 Claude Code 技能实现、带有明确主张的开发流程。 - 将“23 个智能体”理解为基于角色的工具，而不是自动协调的持久运行工作单元。 - 从代码仓库安装，检查 setup，并固定一个经过审查的提交供团队使用。 - 先采用两三个能解决已知交付问题的工作流。 - 将已批准的计划和决策保存在文件中，让各角色共享持久的上下文。 - 将代码审查与运行时 QA 分开；它们能发现不同类型的问题。 - 评估期间，限制对密钥、生产环境会话、Git 推送和部署命令的访问或使用。 - 衡量有价值的发现和避免的缺陷，而不是调用的命令数量。 - 只有当流程成本低于它所避免的问题造成的损失时，才采用这套完整的运作体系。 [编程](/zh/blog/tag/coding/)[Claude](/zh/blog/tag/claude/)[智能体](/zh/blog/tag/agents/)[模型](/zh/blog/tag/models/) A [AI Prime Tech](https://aiprimetech.io/zh/) 本博客由 AI Prime Tech 发布。文章借助 AI 辅助起草；在据此采取行动前，请对照官方文档核实模型 ID、价格和限额等特定版本的细节。 以更低价格接入 Claude API 一个 API 密钥即可使用 Claude Opus 5.5、Sonnet 5、Haiku 4.5 和 Fable 5.1，以及 GPT-6 个模型。按量付费，无需订阅。 [获取 API 密钥 →](/register) AI Prime Tech 是独立的第三方 API 网关。Claude™ 和 Anthropic® 是 Anthropic, PBC 的商标。此处不暗示任何关联或背书。