引言：一个人何以成为一支团队
Garry Tan 是 Y Combinator 的总裁兼 CEO，也是 Palantir 最早的工程师之一。2026 年，他公开了支撑自己生产力的核心工具 ——gstack。这个开源工具链将 Claude Code 扩展为一只虚拟工程团队：23 个专业化角色工具、8 个安全与效能工具，全部通过 slash 命令驱动，全部免费，MIT 许可证。
本文聚焦 gstack 的多角色编排工程实现，而非其使用体验。我们从角色的分类逻辑、角色间的数据流转、跨模型审查机制，以及持久记忆与安全模型四个维度，解析这套工具链如何在单个 AI 编程会话中模拟出一个完整工程组织的决策流程。
一、三层角色体系与 Sprint 生命周期
gstack 的 23 个角色并非随意堆叠，而是严格遵循一个 Sprint 生命周期的顺序组织：Think → Plan → Build → Review → Test → Ship → Reflect。每一层的输出自动成为下一层的输入，从而在会话内部形成无需人工干预的数据管道。
1.1 思考层：重新定义问题而非实现它
/office-hours 是所有 Sprint 的起点。它模拟 YC 合伙人的产品审视方法，用六条 "强制问题" 重构用户的原始需求。Garry Tan 在 README 中给出一个真实案例：用户说 "我想建一个每日简报应用"，/office-hours 经过追问后将其重新定义为 "个人首席助理 AI"，后者包含了 CRM 整合、时间优先级排序和预备工作生成 —— 这是用户最初完全没想到的维度。
关键机制：输出不是答案列表，而是一份设计文档，写入 ~/.gstack/projects/。这份文档的格式经过精心设计，包含产品重新定义、验证前提、实现路径与代价估计，可直接被下游技能读取。
/plan-ceo-review 承接设计文档，进入 "创始人模式"。它不是问 "如何实现"，而是问 "这个产品的 10 星版本长什么样"。Garry Tan 明确说这是 "Brian Chesky 模式"—— 设计思维的原始驱动力。它提供四种作用域策略（扩展、选择性扩展、保持范围、缩减），并将用户的决策持久化到 ~/.gstack/projects/，使其在会话之间存活。
1.2 计划层：技术可行性与设计完整性并行
/plan-eng-review 将产品方向转化为可构建的技术方案。它要求模型像资深工程经理一样工作：架构图、数据流图、状态机、测试矩阵、失败模式分析。所有图都是 ASCII 格式嵌入 Markdown，避免了对外部图表工具的依赖。更重要的是，它强制隐藏假设浮出水面——LLM 在被迫画图时必须承认自己还不清楚的地方。
/plan-design-review 则从另一个方向补全规划：信息架构评分（0-10）、交互状态覆盖（4 个 UI 特性 × 5 个状态 = 20 个状态规格）、AI Slop 风险检测。七轮审查后，设计评分从初始状态提升到目标水平。值得注意的是，它对 AI Slop 的检测不是泛泛警告，而是具体到 "渐变英雄图 + 三列图标网格 + 均匀圆角" 这类可识别的 AI 生成痕迹，并要求替换为有意图的设计选择。
设计文档完成后，/design-consultation 可以从零构建一套完整的设计系统：视觉方向、字体层级（三套字体各有角色）、调色板（含具体 hex 值）、间距系统和动效策略。每一项推荐都附带 "安全选择" 和 "创意风险" 的明确区分 —— 前者保持与品类的语言一致性，后者是产品获得独特面孔的机会。
1.3 构建与审查：自动修复与严格门控
/review 的核心设计理念是：通过了 CI 不代表代码安全。它的审查清单包含 N+1 查询、竞态条件、信任边界漏洞、缺失索引、转义缺陷、枚举处理器遗漏等高危模式。关键在于它的 Fix-First 策略：明显的机械修复（死代码、陈旧注释、N+1 查询）由模型自动应用，用户只看到 [AUTO-FIXED] file:line Problem → what was done；而模糊的架构决策才上浮到用户面前。
/investigate 执行严格的 "无调查不修复" 铁律：追踪数据流、匹配已知 bug 模式、逐个测试假说，三次修复失败后停止并质疑架构本身。这直接针对 AI 编程中最常见的 "再试一个方法" 螺旋。
1.4 测试与发布：浏览器作为 QA 眼睛
/qa 的核心突破在于将浏览器真正引入 AI 会话。它使用 Playwright 驱动的 Chromium 守护进程，第一次调用启动浏览器约 3 秒，之后每次调用仅 100-200 毫秒。浏览器保持持久状态 —— 登录会话、Cookie、Tab 在命令之间不会丢失。/qa 自动从 git diff 推断受影响的页面，无需用户提供 URL。
它在发现 bug 后自动生成回归测试，每个测试包含完整溯源信息，指向 QA 报告。
/ship 将发布流程机械化：同步主分支、运行测试、覆盖率审计、推送、创建 PR。如果项目没有测试框架，它会检测运行时、研究最佳方案、安装框架、编写 3-5 个真实测试、配置 GitHub Actions CI/CD。/land-and-deploy 进一步自动化部署管道：合并 PR、等待 CI、等待部署完成、运行金丝雀检查，一个命令从 "已批准" 到 "生产验证完成"。
二、跨模型审查与多智能体协同
gstack 的审查并非单一模型独断。它引入了一个关键的工程化设计：跨模型第二意见。
/codex 调用 OpenAI Codex CLI 对同一份 diff 进行独立审查，提供三种模式：标准代码审查（通过 / 失败门控，任何 P1 发现即失败）、对抗性挑战（主动寻找边缘情况、竞态条件和安全漏洞）、开放咨询（带会话连续性的自由对话）。当 /review（Claude）和 /codex（OpenAI）都审查了同一分支，系统自动生成跨模型分析报告：重叠发现表示高置信度，各自独有的发现则揭示各自盲点。
/pair-agent 实现跨智能体协调。当用户在 Claude Code 中需要另一个 AI（如 OpenClaw、Codex、Cursor 或 Hermes）同时查看同一网站时，/pair-agent 启动一个共享的 GStack Browser 窗口，两个智能体各占一个 Tab，互不干扰。ngrok 隧道自动建立，允许远程机器上的智能体参与。每次配对使用 scoped token（而非 root token），命令 allowlist 严格限定，Tab 隔离，活动可归因。
/autoplan 是另一种编排模式。它串联执行 CEO → Design → Eng 三层审查，用六条编码原则自动做出决策（偏好完整性、匹配现有模式、选择可逆选项、沿用用户过去的相似决策、推迟模糊项、升级安全问题），只在品味决策（边界范围扩展、模型分歧）处暂停请用户确认。一次命令，完整审查的计划输出。
三、持久记忆与上下文跨会话传递
gstack 的记忆系统通过 /learn 和 GBrain 两层实现。
/learn 管理会话内学习的积累：模式、陷阱、偏好、架构决策。每一项学习带有置信度评分、来源归属和引用文件。技能在做出推荐前自动检索相关学习，并显示 "Prior learning applied" 标记。学习按项目存储在 ~/.gstack/projects/$SLUG/learnings.jsonl，并可导出与团队共享。
GBrain（独立的 YC 项目）是持久知识库，为 AI 智能体提供跨会话记忆。它通过 gstack 的 /setup-gbrain 一键安装，支持三条路径：已有 Supabase URL、PGLite 本地（约 30 秒零账户启动）、或 Supabase 自动配置（约 90 秒端到端）。/sync-gbrain 从任何仓库重新索引代码，写入 CLAUDE.md 的 ## GBrain Search Guidance 块，引导智能体优先使用 gbrain search 而非 Grep。
信任策略按仓库粒度设置：read-write（可搜索并写入）、read-only（仅搜索）、deny（完全拒绝），决策在各分支间保持一致。
四、安全模型：从 Cookie 到侧边栏的全栈防御
gstack 处理的最敏感数据是浏览器 Cookie。其安全模型围绕五个层次设计：
第一层：本地绑定。HTTP 服务器绑定到 127.0.0.1，不暴露到网络。Cookie 解密在进程内完成，使用 PBKDF2 + AES-128-CBC，从 macOS Keychain 获取密钥。Cookie 值从不写入磁盘，始终驻留在内存，服务器关闭后缓存立即清除。Cookie 导入的数据库副本是只读的，复制到临时文件以避免与运行中的浏览器发生 SQLite 锁冲突。
第二层：双监听器隧道架构（v1.6.0.0）。本地监听器（LOCAL_PORT）服务于完整命令集，ngrok 隧道监听器（TUNNEL_PORT）仅暴露受限 allowlist（/connect 用于配对、/command 仅限 scoped token 且命令白名单、/sidebar-chat）。物理端口分离防止隧道调用者访问 /health 或 /cookie-picker。
第三层：侧边栏提示注入防御。Chrome 侧边栏 AI 读取敌意网页，是系统中最暴露的部分。五层防御叠加：L1-L3 内容安全层（数据标记、隐藏元素剥离、ARIA 正则、URL 黑名单、信任边界包装）；L4 ML 分类器（22MB TestSavantAI BERT-small ONNX 模型，本地运行，无网络调用，可选 721MB DeBERTa-v3 集成）；L4b 转录分类器（Claude Haiku 通过对话整体形状判断）；L5 金丝雀令牌（随机令牌注入系统提示，若泄漏到输出则终止会话）；L6 集成裁判（BLOCK 需两个 ML 分类器在 ≥ 0.75 置信度下达成一致，防止单模型对 Stack Overflow 类指令页的误报）。
第四层：WIP 连续检查点。gstack-config set checkpoint_mode continuous 启用后，技能在执行过程中自动提交，WIP 前缀加上结构化的 [gstack-context] 正文（决策、剩余工作、失败尝试），在崩溃和上下文切换中存活。/context-restore 从这些提交中重建会话状态。/ship 执行 filter-squash 保留非 WIP 提交，使 bisect 保持干净。
五、关键工程参数与实现约束
理解 gstack 的角色编排机制，有几个关键的实现参数值得关注。
浏览器状态持久化的取舍：gstack 选择守护进程模型而非每命令启动浏览器，因为 Playwright 启动约 3 秒、20+ 命令的 QA 会话累积 40+ 秒开销，且状态完全丢失。但守护进程模型意味着 Cookie 和 localStorage 在命令间持久化 —— 这既是功能也是安全边界，需要 Keychain 级别的访问控制来保障。
Ref 系统避免 DOM 注入：gstack 的 @e1、@e2 引用系统使用 Playwright 的 page.accessibility.snapshot() 构建 ARIA 树，而非注入 data-ref 属性。这避免了 CSP 阻断、框架水化冲突和 Shadow DOM 穿透问题。解析时通过 count() 检查元素存在性，缺失元素时在～5ms 内失败，而非等待 30 秒超时。
命令分类驱动的调度：服务器将命令分为 READ（不修改状态）、WRITE（修改状态非幂等）、META（服务器级操作），不同类别进入不同的处理器，实现了关注点分离。
模板系统保证文档与代码同步：SKILL.md 由 gen-skill-docs.ts 在构建时从源代码元数据生成，人类撰写的流程和示例部分保持手写，命令参考部分从 commands.ts 自动填充。这避免了文档漂移，同时保留人类判断的叙事价值。
结语
gstack 展示了一条将 AI 编程工具从 "强化版的自动补全" 进化为 "虚拟工程团队" 的路径。其核心不是更多的 prompt 技巧，而是一套结构化的角色编排：问题重定义层、技术可行性层、视觉设计层各司其职；跨模型审查防止单一视角盲点；持久记忆让每次会话都能从前一次中断处继续；安全模型覆盖了从 Cookie 到提示注入的完整威胁面。
对于在生产环境中使用 AI 编程工具的团队，gstack 的设计提供了一种参考：与其依赖模型自我约束，不如用明确的角色边界、数据流转管道和门控机制，将 AI 的能力引导到更可预测、更可审计的方向。
资料来源：本文所有技术细节来自 garrytan/gstack GitHub 仓库（架构文档、技能深度指南）以及 Garry Tan 在 README 中公开的生产力数据。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。