## `gstack`：把独立复核做成默认能力

<!-- slot: 目标 -->
`gstack` 更准确地说，是一组偏 review、QA 和复核的能力集合。

对这本书最重要的是 3 类用途：

- 方案复核
- 实现 Review
- QA 复核

<!-- slot: 边界 -->
这里不展开 `gstack` 的完整目录，只保留和通用研发协作最相关的复核能力。

开源仓库：[`garrytan/gstack`](https://github.com/garrytan/gstack)

<!-- slot: 提示词 -->
```text
请不要重复原实现思路。
请用独立复核的视角检查这项工作：
1. 需求理解是否偏了
2. 方案是否漏了关键边界
3. 实现是否有回归风险
4. 测试和证据是否足够
```

<!-- slot: 流程 -->
### `gstack` 为什么重要

很多团队已经有实现能力，也有 review 动作，但缺的是“独立复核视角”。

如果评审只是把作者自己的逻辑复述一遍，团队并没有真正获得第二份判断。`gstack` 的价值不在于重复作者思路，而在于从相对独立的视角重新审视目标、边界和证据。

### 它适合放在哪三个阶段

`gstack` 更适合放在 3 个位置：

1. **实现前**：复核技术计划，看目标、边界、数据流、测试思路是否完整
2. **实现后**：复核代码改动，看是否真的完成任务、是否引入回归
3. **交付前**：做 QA 复核，看用户路径、边界场景和验证证据是否成立

这三种位置对应的是三种不同价值：

- 方案阶段：防止计划先天缺口
- 实现阶段：防止代码偏题或回归
- 交付阶段：防止验证证据不足

### 为什么它更像 Reviewer 侧能力

在这本书里，推荐把 `gstack`` 理解成 Reviewer 侧能力，而不是 Worker 的扩展写作能力。

Worker 的职责是把任务实现出来；Reviewer 的职责是以相对独立的立场重新检查结果是否成立。两者可以协作，但不应该在角色上混为一谈。

如果一个 Agent 一边写实现、一边做“独立复核”，往往很难真正摆脱原始路径依赖。

### 输入质量决定复核质量

`gstack` 不是魔法。它对输入质量高度敏感。

如果输入给 `gstack` 的只有 diff，没有目标、范围、风险背景和验收要求，它的判断质量会明显下降。因为它看到的只是改动，不是改动背后的任务约束。

更好的输入通常包括：

- 本次任务目标
- 不在范围内的内容
- 风险点或关注点
- 相关证据或测试结果

### 它给出的是什么结论

`gstack` 给出的不是“最终批准”，而是“独立复核意见”。

它的结论应该被理解成：

- 哪些地方已经成立
- 哪些地方证据不足
- 哪些地方存在风险或回归可能
- 哪些地方需要回流给 Worker 继续修正

这也是为什么在团队阵型里，Review 的意见通常应先回流给 Worker，再由 Worker 修正和收敛，而不是直接把所有判断都甩给 Human 最终消化。

<!-- slot: 配置 -->
| 研发阶段 | 推荐关注的 `gstack` 能力 |
| --- | --- |
| 方案阶段 | plan review / design review / eng review |
| 实现完成后 | review |
| 提交前 | qa / qa-only |

<!-- slot: 异常 -->
如果当前 Runtime 不具备浏览、测试或环境访问能力，`gstack` 需要降级成只读复核；这时结论应明确说明证据边界，而不是假装已经完成完整 QA。

<!-- slot: 审批 -->
`gstack` 给出的结论是独立复核意见，不等于最终批准。是否合并，仍然要由团队流程决定。

<!-- slot: 外部系统 -->
某些 `gstack` 能力依赖浏览、测试或环境访问能力；Runtime 不具备这些能力时，需要先降级成只读复核。

<!-- slot: 验收 -->
读完本章后，读者应该能说明 `gstack` 更适合放在方案、实现后和交付前的哪些位置，以及它为什么是 Reviewer 侧的关键能力。

<!-- slot: 媒体槽位 -->