面向 Claude Code 的 gstack：其 23 智能体工作流究竟能做什么

gstack Claude Code 是操作系统，而非提示词包

理解它的一个实用思路是，将 gstack Claude Code 视为构建在 Claude Code 之上的工程操作系统。每个工具都会为 Claude 指定角色、流程和预期输出。这些工具共同体现了一套关于软件应如何从想法走向生产环境的主张。

一个通用提示词可能是：

Review my implementation plan.

基于角色的工作流会提出一个范围更明确的问题：

/plan-eng-review

该技能可以引导 Claude 检查架构、依赖关系、故障模式、可测试性、发布风险和实施顺序。面向产品的规划技能可以从用户价值和范围的角度检查同一份计划。面向设计的技能则可以质疑交互细节，而非后端边界。

区别在于可重复性。团队成员不必各自记住一份 40 行的审查提示词，也不必自行编写检查清单。技能承载了这套流程。

其中的取舍同样重要：gstack 将他人的流程引入你的代码仓库。它假设多轮审查、明确的 QA 和结构化的发布工作，值得投入它们所消耗的上下文和时间。这通常适用于生产环境变更，但对于一个拼写错误或两行内部脚本来说，就显得过度了。

这 23 个基于角色的工具实际涵盖哪些工作

仓库中的具体工具列表可能会变化，因此我以检出的 SKILL.md 文件为准，而不依赖截图或发布介绍。其架构的关键在于职责划分。

这就是为什么将 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 <reviewed-commit-sha>
./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 个工具。应从现有流程中信息流失最多的环节入手。

一个合理的评估矩阵如下：

在几次真实变更中运行这部分工具，并记录：

• 哪些发现促成了代码或范围变更？
• 哪些发现是重复的？
• 需要重复提供多少上下文？
• 生成的产物是否始终与实现保持同步？
• 哪些命令需要团队不愿在 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 推送和部署命令的访问或使用。
• 衡量有价值的发现和避免的缺陷，而不是调用的命令数量。
• 只有当流程成本低于它所避免的问题造成的损失时，才采用这套完整的运作体系。