GStack Browser V0：以 Claude Code 为运行时的 AI 原生浏览器——设计文档与源码实证

GStack Browser V0：以 Claude Code 为运行时的 AI 原生浏览器——设计文档与源码实证

【免费下载链接】gstackUse Garry Tan's exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack

这篇技术文章基于 gstack 仓库中的设计文档 GSTACK_BROWSER_V0.md，系统拆解 GStack Browser 的核心命题（"给 AI Agent 一个浏览器视口"，而非"给浏览器加 AI"）、已交付的 Phase 1a macOS 应用形态、五阶段演进路线与九大能力愿景，并结合 browse/ 目录下的真实源码、构建脚本 与 Side Panel 架构文档，还原从.app打包到 Browse Server 命令面、认证模型、无头/有头守护进程的完整实现。读完后，你将理解一个"AI 原生开发浏览器"的架构分层、关键命令与配置项（GSTACK_CHROMIUM_PATH、BROWSE_EXTENSIONS_DIR、/health认证、BROWSE_IDLE_TIMEOUT等），以及它在当前仓库中的真实落地程度与源码级依据。

一、核心命题：Agent 是主体，浏览器是画布

设计文档开宗明义地指出：其他 AI 浏览器（Atlas、Dia、Comet、Chrome Auto Browse）都是先有一个消费级浏览器，再把 AI "外挂"上去；GStack Browser 把这层关系颠倒过来——

It starts with Claude Code as the runtime and gives it a browser viewport. The agent is the primary citizen. The browser is the canvas. Skills are first-class capabilities.

用文档自己的话说：这不是"一个带 AI 辅助的浏览器"，而是"一个能看见网页并与其交互的 AI"。代码住在终端里，产品住在浏览器里，AI 同时横跨两者——"What Cursor did for text editors, GStack Browser does for the browser." 文档将其定位为"后 IDE 时代的 IDE"。

这一命题直接决定了架构走向：浏览能力不是扩展插件，而是以 CLI + HTTP Server（browse server）形态存在，Agent 通过 Bash 工具调用约 70 个命令来驱动 Chromium。这一点在当前仓库 BROWSER.md 中有完整参考：编译后的 CLI 是薄客户端，读状态文件、发 HTTP 请求、把纯文本打印到 stdout，每次调用约 100–200ms，零上下文 token 开销。

二、Phase 1a（已交付）：一个双击即用的 macOS 应用

设计文档对 Phase 1a 的定义是：一个可双击的 macOS.app，内部包裹 Playwright Chromium 并内置 gstack Side Panel 扩展。打开后，Claude Code 可以看见你的屏幕、导航页面、填写表单、截图、检查 CSS、清理页面浮层，并运行任意 gstack skill——全程不碰终端。

2.1 .app 的三层结构

设计文档给出的包体结构：

GStack Browser.app (389MB, 189MB DMG) ├── Compiled browse binary (58MB) — CLI + HTTP server ├── Chrome extension (172KB) — sidebar, activity feed, inspector ├── Playwright's Chromium (330MB) — the actual browser └── Launcher script — binds project dir, sets env vars

启动链路为：Launch → Chromium 带侧边栏打开 → 扩展自动连接 browse server → 约 5 秒内 agent 就绪。

对照仓库中的构建脚本 scripts/build-app.sh，文档中的每一层都有对应实现：

• Step 1：bun build --compile src/cli.ts --target=bun将 browse/src/cli.ts 编译为独立二进制（即文档中的 58MB browse binary），输出到Contents/Resources/browse；
• Step 2：从~/Library/Caches/ms-playwright下最新的chrome-mac-arm64缓存中定位 Playwright Chromium 并复制进Contents/Resources/chromium/；
• Step 3：复制 extension/ 目录作为内置侧边栏扩展，并主动删除.auth.json——注释明确写着 "auth now via /health endpoint"，与设计文档 Implementation Status 表中 "Auth via /health：SHIPPED，替代 .auth.json 文件方案、服务器重启自动刷新" 一一对应；同时复制browse/src/整个源码目录与package.json，供启动器以bun run server.ts子进程方式拉起服务器；
• Step 3b（重新品牌化）：用PlistBuddy把捆绑 Chromium 的CFBundleName/CFBundleDisplayName改写为 "GStack Browser"，替换 Dock 图标，使得 macOS 菜单栏、Dock、Cmd+Tab 里显示的都是 GStack 品牌而非 "Google Chrome for Testing"。这与 BROWSER.md 中 "GStack Browser 是重新品牌的 Chromium（.app 名、Dock 图标、托盘，而非 UA 字符串）" 的描述一致。

.app的Info.plist由脚本直接生成：Bundle ID 为com.gstack.browser，可执行文件为gstack-browser启动脚本（位于 scripts/app/gstack-browser），最低系统版本 macOS 12.0，应用类别标记为public.app-category.developer-tools。若跳过 DMG（./scripts/build-app.sh --no-dmg），只产出.app；否则用hdiutil create -format UDZO压缩成 DMG 并附带/Applications快捷方式。

2.2 启动器与自定义 Chromium：GSTACK_CHROMIUM_PATH

设计文档 Implementation Status 表中，GSTACK_CHROMIUM_PATH标记为 SHIPPED，用途是"支持自定义 Chromium 二进制"——这正是.app启动器的核心职责：让浏览器管理器使用捆绑在Contents/Resources/chromium/里的 Chromium，而不是 Playwright 缓存里的那份。

源码层面，这一机制集中在 browse/src/browser-manager.ts：

• isCustomChromium()通过两级信号判断当前是否指向自定义构建：优先GSTACK_CHROMIUM_KIND=custom-extension-baked，回退到检查GSTACK_CHROMIUM_PATH路径是否包含GBrowser/gbrowser子串（见文件头部注释，约 L30–L43）；
• headless 启动路径（约 L604）直接读取process.env.GSTACK_CHROMIUM_PATH作为executablePath。CHANGELOG 中记录的修复（PR #1614）说明早期该自定义路径只在有头launchPersistentContext()生效，headlesslaunch()会回退到捆绑 Chromium，后来被镜像到 headless 路径，"Custom Chromium honored everywhere"；
• 一个重要契约：GSTACK_CHROMIUM_PATH提供的捆绑包属于宿主/嵌入方，守护进程的自愈逻辑（browse/src/xprotect-heal.ts，处理 macOS XProtect 更新 SIGKILL 掉固定 Chromium 的场景）永远不会删除或重装这个外部捆绑包——测试 browse/test/poisoned-bundle-probe.test.ts 与 browse/test/xprotect-heal.test.ts 专门锁定了这条 "embedder scope contract"。对.app形态而言，这条契约保证了用户重新打开应用时内置 Chromium 不会被守护进程误清理。

同理，BROWSE_EXTENSIONS_DIR在 browse/src/browser-manager.ts（约 L382、L432）中被读取：它指向一个解压态的 Chrome 扩展目录，通过launchPersistentContext预加载进每个 browse 会话——.app 正是靠它把 extension/ 注入捆绑 Chromium。

2.3 服务器形态、命令面与生命周期

设计文档架构图中的 Browse Server（:34567，HTTP + SSE，命令goto / click / fill / snapshot / screenshot / css / inspect / eval等）在仓库中完全落地：

• 端口：browse/src/cli.ts（约 L1574）中BROWSE_PORT的默认值即'34567'，与设计文档一致；
• 命令面：BROWSER.md 的 "Command reference" 一列了约 70 个命令，覆盖读取（text/html/links/forms/accessibility/media/data）、检查（css/attrs/inspect/console/network/ux-audit/cdp）、导航、交互（click/fill/select/hover/type/press/upload/dialog-accept）、样式与清理（style/style --undo/cleanup）、视觉（screenshot五种模式/pdf/responsive/prettyscreenshot）、Cookie 与请求头、Tab 与 iframe、快照（snapshot带@e引用）、服务器生命周期（status/stop/restart/connect/disconnect/focus/state save|load/memory）、手工接管（handoff/resume）以及 browser-skills 运行时（skill list|show|run|test|rm）。设计文档说 "All via simple commands through the browse server"，这就是那套命令面的全貌；
• 空闲超时：设计文档 Implementation Status 中 "No idle timeout (headed) — SHIPPED，窗口开着浏览器就一直活着"。源码中 browse/src/server.ts（约 L132）定义IDLE_TIMEOUT_MS = parseInt(process.env.BROWSE_IDLE_TIMEOUT || '1800000', 10)，即默认 30 分钟，每分钟检查一次（idleCheckTick，约 L717）；无头模式 30 分钟无命令自动关停（BROWSER.md "Daemon lifecycle" 详述），而有头 connect 模式下浏览器随窗口存活，二者通过模式区分共存；
• 认证：root token 写入<project>/.gstack/browse.json（chmod 600），每个状态变更命令都要求Authorization: Bearer <token>；侧边栏扩展通过POST /extension-token以固定 Origin（chrome-extension://<GSTACK_EXTENSION_ID>，由 extension/manifest.json 的key字段钉住扩展 ID，推导脚本为 browse/scripts/extension-id.ts）换取 token——这即是文档所说的 "Auth via /health 替代 .auth.json" 的落地形态：/health本身只做 liveness，永不携带 token。

三、演进路线：从 Phase 1b 到 Phase 5

Phase 1b：开发者体验（设计文档标记为 "next"）

• 命令面板（Cmd+K）：签名交互。打开模糊过滤的 skill 选择器——输入/qa启动 QA 测试、/investigate调试、/ship创建 PR。关键细节：skills 是从 browse server 拉取的，不是硬编码，面板是通往一切能力的入口；
• 快捷截图（Cmd+Shift+S）：截取当前视口并带着 "What do you see?" 上下文管道进侧边栏聊天，AI 分析截图给出可操作反馈——"一次击键完成视觉 bug 报告"；
• 状态栏：每个页面底部常驻 30px 条，显示 agent 状态（idle/thinking）、工作区名、当前分支与自动检测的 dev server，点击 dev server 药丸即导航；
• Dev Server 自动探测：启动时扫描常见端口（3000、3001、4200、5173、5174、8000、8080），恰好发现一个就自动导航过去。

Phase 2：BoomLooper 集成

侧边栏不再接本地claude -p子进程，而是接 BoomLooper 的 Phoenix/Elixir API，获得四项能力：多 agent 编排（5 个 agent 并行，各占一个浏览器标签页，一个跑 QA、一个做设计审查、一个盯回归）、Docker 隔离（每个 agent 独立容器，容器内浏览器测 dev server，无端口冲突、无状态泄漏）、会话持久化（浏览器重启后对话仍在）、团队可见性（队友实时观看你的 agent，"pair 是 5 个 AI agent，你是指挥"）。

Phase 3–5：工具化、Chromium 分叉与原生外壳

• Phase 3：browse 二进制成为 BoomLooper 中的 MCP 工具，容器内 agent 用 browse 命令测 dev server、截图、填表、验证部署，需要跨平台编译（linux-arm64/x64）；
• Phase 4（触发门控）：当扩展侧边栏触到硬 API 限制、对外发布、构建基建就位且业务上维护成本可证明时，才 fork Chromium——参照 Brave 的chromium_srcoverride 模式，用 Claude Code 做 6 周 rebase（2–4 小时 vs 人工 1–2 周），约改 20–30 个文件；
• Phase 5：SwiftUI/AppKit 原生外壳 + 隔离 Chromium 服务；若 Phase 4 的 Chromium fork 自带原生侧边栏，Phase 5 可能被取代。

四、愿景：AI 浏览器能做什么（九大能力）

设计文档用 "Today / Next / Future" 三层节奏描述了八项能力加工作区模型，这是全文最有引用价值的部分。

1. 看见你所见（See What You See）

浏览器是 AI 的眼睛——不是靠截图，而是 DOM 访问、CSS 检查、网络监控与可访问性树解析。

• Today：snapshot命令返回任意页面的可访问性树表示，AI "看见"每个按钮、链接、表单字段与文本元素；元素引用（@e1、@e2）让 AI 可以点击、填写、交互。
• Next：实时页面观察——页面变化、控制台新错误、网络请求失败，AI 主动发现而非被动应答。
• Future：视觉理解——前后截图对比捕捉视觉回归，像素级设计审查（"按钮左移了 3px，字号从 14px 变 13px"）。

这一机制的实现细节在 BROWSER.md "Snapshot system" 一节：snapshot基于 Playwright 的无障碍树 API（page.locator(scope).ariaSnapshot()），快照解析器为每个元素分配@eN引用并构建Locator（getByRole+ nth-child），引用→Locator 映射保存在BrowserManager上；SPA 无导航改 DOM 会导致引用过期，resolveRef()先做异步count()检查，元素数为 0 立即报错提示重跑snapshot，约 5ms 快速失败而不是等 Playwright 的 30 秒超时。扩展能力还包括-D（与上一快照 diff 校验操作是否生效）、-a（注入临时覆盖层截图标注引用）、-C（扫描 ARIA 树漏掉的cursor:pointer/onclick/tabindex元素并分配@cN引用）。

2. 对所见的采取行动（Act on What It Sees）

• Today：click、fill、select、hover、type、scroll、上传文件、处理对话框、导航、管理标签页，全部通过 browse server 的简单命令完成；
• Next：多步用户流——"登录，进设置，改时区，验证确认信息"，AI 每步命令链都带验证；
• Future：自主 QA agent——"测这个页面的每个链接、填每个表单、设法弄坏它"，无需脚本即可穷举交互测试，找到人类测试员想不到的组合。

3. 边浏览边写代码（关键差异化）

AI 既能在浏览器里看到bug，又能同时在代码里修它：

• Today：侧边栏聊天接 Claude Code。你说 "这个按钮错位了"，AI 读 CSS、定位问题、提出修复；/design-reviewskill 截图 → 识别视觉问题 → 提交修复并附前后证据；
• Next：Live reload 循环——AI 改 CSS/HTML，浏览器自动刷新，AI 视觉验证。简单视觉修复无人参与，"修掉这个页面所有间距问题"变成 30 秒任务；
• Future：全栈调试——浏览器里看到 500，AI 读服务端日志、追到出错行、写修复、浏览器验证。一条指令："这页坏了，修好它。"

4. 理解整个技术栈

浏览器不只是视口，而是应用健康的窗口。Today 已具备（均可在 BROWSER.md 命令表中找到对应命令）：

• 控制台日志捕获——每条console.log/console.error/warning（console [--clear|--errors]）；
• 网络请求监控——每个 XHR、fetch、websocket 与静态资源（network [--clear]）；
• 性能指标——Core Web Vitals、资源时序、paint 事件（perf）；
• Cookie 与存储检查——读写 localStorage/sessionStorage（cookies、storage [set]）；
• CSS 检查——计算样式、盒模型、规则级联（css <sel> <prop>、inspect [sel] [--all|--history]，后者经 CDP 拿完整级联，即侧边栏 CSS Inspector 的后端）。

Next：网络请求重放、性能回归检测（"这页比昨天慢 200ms"）、依赖审计（"此页加载 47 个第三方脚本"）、可访问性审计。Future：全应用遥测（CPU/内存/GPU 实时）、跨浏览器测试、真实用户监控关联（"此 bug 影响 12% 生产用户"）。

5. 工作区模型（The Workspace Model）

浏览器就是工作区，不是工作区里的一个标签页。Today：每个浏览器会话绑定一个项目目录，侧边栏显示当前分支，状态栏显示探测到的 dev server。Next：多项目支持——不关浏览器切换项目，每个项目独立标签组、独立 agent、独立上下文（"浏览器版的 VSCode workspaces"）。Future：团队工作区——多人共享浏览器工作区，互看对方 agent 工作，协同调试。

6. Skills 即浏览器能力

每个 gstack skill 都变成一项浏览器能力（设计文档原表完整保留）：

命令面板（Cmd+K）是枢纽：你无需知道这些 skill 存在，输入你想要的，模糊过滤器找到正确的 skill，AI 以浏览器为上下文执行它。当前仓库中这些 skill 均以目录形态存在（如 qa/SKILL.md、design-review/SKILL.md、investigate/SKILL.md、cso/SKILL.md、ship/SKILL.md、canary/SKILL.md），命令面板从 browse server 拉取 skill 清单的设计正是让这张表在浏览器内可发现、可调用。

7. 设计循环（The Design Loop）

AI 驱动的设计是循环，不是交接：

生成 mockup (GPT Image API) → 浏览器中评审（与线上站点对比） → 带反馈迭代（"把 header 加高"） → 确定方向 → 生成生产 HTML/CSS → 浏览器预览 → 用 /design-review 精修 → 发布

浏览器弥合了 "Figma 里长什么样" 与 "生产环境长什么样" 的鸿沟，因为 AI 能同时看见两者。

8. 安全循环（The Security Loop）

在真实浏览器里做 CSO 审查，而不只是静态分析：

• 向每个输入字段注入 XSS 载荷，检查是否执行；
• 从不同 origin 重放请求测 CSRF；
• 导航到构造的 URL 检查开放重定向；
• 验证 CSP 头是否真的被强制（而非仅存在）；
• 实时操纵 cookie 与 token 测试认证流；
• 把站点加载进 iframe 检查点击劫持。

文档总结："静态分析抓模式，浏览器测试抓现实。" 这与 cso/SKILL.md 的审查清单、browse/src/content-security.ts 的反向注入防护（L1–L3 内容安全层）构成攻守两侧。

9. 监控循环（The Monitoring Loop）

部署后 canary 监控，在真实浏览器中执行：

部署 → 浏览器加载生产 URL → 截图基线 → 每 5 分钟：截图、对比、查控制台 → 告警：视觉回归、新控制台错误、性能下降 → 检测到关键错误时自动回滚

这是带 AI 判断的合成监控：不只问 "页面是否返回 200"，而是问 "页面看起来对、行为对吗"。

五、架构：设计与仓库实现对照

设计文档的架构图（原文保留）：

+-------------------------------------------------------+ | GStack Browser | | +------------------+ +---------------------------+ | | | Chromium | | Extension Side Panel | | | | (Playwright) | | ├── Chat (Claude Code) | | | | | | ├── Activity Feed | | | | ┌────────────┐ | | ├── Element Refs | | | | │ Status Bar │ | | ├── CSS Inspector | | | | └────────────┘ | | ├── Command Palette | | | +--------┬──────────+ | └── Settings | | | │ +-------------┬--------------+ | +-----------┼────────────────────────────┼─────────────────+ v v +---------┴-----------+ +-----------┴-----------+ | Browse Server | | Sidebar Agent | | (HTTP + SSE) | | (claude -p wrapper) | | :34567 | | Runs gstack skills | | Commands: | | Per-tab isolation | | goto, click, fill | | Future: BoomLooper | | snapshot, screenshot| | GenServer agents | | css, inspect, eval | +-----------┬-----------+ v v +---------┴-----------+ +-----------┴-----------+ | User's App | | Claude Code | | localhost:3000 | | (reads/writes code) | +---------------------+ +-----------------------+

对照当前仓库源码，有几个值得注意的演化点（设计文档写于 Phase 1a 阶段，部分组件其后已重构）：

• Browse Server（:34567，HTTP + SSE）：对应 browse/src/server.ts，命令集与文档所列一致且已扩展到约 70 个（见上文）；活动流走 SSE（/activity/stream），认证除 Bearer token 外还接受 30 分钟 HttpOnlygstack_sse会话 cookie，使扩展无需在扩展存储中保存 root token；
• Sidebar Agent：设计文档中是 "claude -pwrapper"。按 docs/designs/SIDEBAR_MESSAGE_FLOW.md，这条路径已经演化为交互式claudePTY（Terminal pane）：编译后的 browse 服务器不能posix_spawn外部可执行文件，因此 browse/src/terminal-agent.ts 以独立非编译bun run进程运行，拥有claude子进程；旧的一次性 chat 队列路径（claude -p）在 PTY 验证通过后被移除。这解释了 CHANGELOG.md 中 "PR #1216 拆除了pickSidebarModel/chat 状态" 的记录——设计文档状态表里的 "Model routing SHIPPED（Sonnet 执行动作、Opus 做分析）" 属于 v0 设计阶段特性，其后随 chat 路径一同被移除；
• WebSocket 认证的细节：浏览器 WebSocket 客户端无法设置Authorization头，方案利用Sec-WebSocket-Protocol：POST /pty-session（Bearer AUTH_TOKEN）换取短时会话 token，扩展以new WebSocket(url, ['gstack-pty.<token>'])携带，agent 校验Origin 与 token 之后才升级连接，且必须回显 protocol（否则 Chromium 直接关闭连接）。严格的双 token 分离防止 SSE/页面内容 token 泄漏升级为 shell 访问；
• 扩展侧组件：extension/sidepanel.js、extension/sidepanel-terminal.js、extension/background.js、extension/content.js 与 extension/manifest.json（key字段钉住扩展身份）。侧边栏页脚的一键 Cookie 导入按钮跳转/cookie-picker路由（browse/src/cookie-picker-routes.ts 提供服务端，对应状态表 "Cookie import button SHIPPED"）；
• 多工作区隔离：每个项目根（git rev-parse --show-toplevel探测）拥有独立的 daemon、随机端口（10000–49151，刻意避开 macOS 临时端口池）、状态文件（<project>/.gstack/browse.json，chmod 600）、cookie 与日志——这从底层支撑了设计文档 "每个浏览器会话绑定一个项目目录" 的工作区模型；
• 崩溃与忙判定：Chromium 崩溃时 daemon 直接退出、不自愈；HTTP 无响应但进程存活判为 "busy" 而非 "dead"，CLI 给/health约 8 秒恢复窗口，绝不杀活 pid，只有显式--force-restart才替换（标签页、cookie、登录态会丢失）。

六、竞争定位与设计系统

设计文档的竞争分析表（原文保留）：

文档的立场清晰：GStack Browser 不与消费级浏览器竞争，它竞争的是"在浏览器和编辑器之间来回切换"这个工作流，目标是让这次切换消失。

设计系统（引自 DESIGN.md）：主强调色 Amber-500（#F59E0B，agent 激活态、焦点态、脉冲动画）；背景 Zinc-950（#09090B）到 Zinc-800（#27272A），暗色、高信息密度；字体 JetBrains Mono（代码/状态）+ DM Sans（UI/标签）；圆角 8px（md）/12px（lg）/全圆（药丸）；动效为 agent 激活时脉冲、200ms 过渡；布局为右侧边栏 + 底部状态栏 + 居中浮层命令面板。

七、实现状态与 12 个月愿景

设计文档的实现状态表（原文保留，行项目均对应仓库中的真实交付物）：

需要注意的适用前提：上表是设计文档撰写时点（2026-03-30，Phase 1a 已交付、Phase 1b 进行中）的状态快照。当前仓库已明显向前推进——例如 Model routing 的pickSidebarModel已随 chat 路径移除（见第五节），有头/无头的空闲超时策略也在 browse/src/server.ts 中由BROWSE_IDLE_TIMEOUT（默认 30 分钟）统一管理。引用本表时应以文档时点与 CHANGELOG.md 为准。

12 个月愿景的时间轴（原文保留）：

TODAY (Phase 1) 6 MONTHS (Phase 2-3) 12 MONTHS (Phase 4-5) ───────────── ────────────────── ──────────────────── macOS .app wrapper BoomLooper multi-agent Chromium fork OR Extension sidebar Docker containers Native SwiftUI shell Local claude -p agent Team workspaces Cross-platform Single project Linux/x64 browse Auto-update Manual skill invocation Autonomous QA loops Skill marketplace Performance monitoring Plugin API Real-time collaboration Enterprise features

12 个月理想态：打开 GStack Browser，它探测你的项目、启动 dev server、跑测试套件、报告哪里坏了；你说 "fix it"，AI 修掉每个 bug、视觉验证每个修复、创建 PR；你在同一个浏览器里评审 PR、批准，AI 部署并监控 canary——全部在一个窗口里完成。"That's the browser as AI workspace. Not a browser with AI bolted on. An AI with a browser bolted on."

八、跨模型评审：这份设计是怎么过的

设计文档末尾记录了自己的评审史，这也是 gstack 工作流的一个样本案例——该计划经历了 4 轮评审：

1. CEO Review（/plan-ceo-review，SELECTIVE EXPANSION）：9 项范围提案，3 项接受（Cmd+K、Cmd+Shift+S、状态栏），5 项推迟，1 项跳过；
2. Design Review（/plan-design-review）：评分 5/10 → 8/10，新增 9 项设计决策，生成 2 张获批 mockup；
3. Eng Review（/plan-eng-review）：发现 4 个问题、0 个关键缺口，产出测试计划；
4. Codex Review（外部声音）：9 项发现，抓住 3 个关键缺口（服务器捆绑、auth 文件位置、项目绑定），全部解决。

文档的结论是：Codex 评审抓住了此前 3 轮评审都漏掉的 3 个真实架构缺口——跨模型评审是有效的。这三类 skill 在仓库中均为独立目录：plan-ceo-review/SKILL.md、plan-design-review/SKILL.md、plan-eng-review/SKILL.md。

总结：从设计文档到仓库实证的落地地图

把设计文档与仓库源码放在一起，可以得到一张清晰的落地对照：

• 命题与形态（Agent 为主体、浏览器为画布；.app 三层结构）→ docs/designs/GSTACK_BROWSER_V0.md + scripts/build-app.sh（编译、捆绑、重新品牌化、DMG 全链路）；
• 能力面（snapshot/@e引用、约 70 个命令、控制台/网络/CSS 全栈可见）→ BROWSER.md、browse/src/snapshot.ts、browse/src/cdp-commands.ts、browse/src/network-capture.ts；
• 运行时（:34567 服务器、随机端口守护进程、多工作区隔离、root/setup/scoped 三型 token、BROWSE_IDLE_TIMEOUT）→ browse/src/server.ts、browse/src/browser-manager.ts、browse/src/token-registry.ts；
• 侧边栏（PTY Terminal、双 token 认证、活动流 SSE、/cookie-picker、/extension-token固定 Origin 发放）→ docs/designs/SIDEBAR_MESSAGE_FLOW.md、browse/src/terminal-agent.ts、extension/；
• 安全（隧道 26 命令白名单、拒登日志、L1–L4 提示注入分层防御）→ browse/src/content-security.ts、docs/REMOTE_BROWSER_ACCESS.md；
• Skills 即能力（/qa、/design-review、/cso、/ship等）→ 各 skill 目录及 browser-skills/ 的确定性 Playwright 脚本运行时。

GStack Browser 的价值不在于它 "又是一个带 AI 的浏览器"，而在于它把 AI agent 确立为一等公民，把浏览器降级为 agent 的眼睛、手和验证环境——设计文档、构建脚本、约 70 条 browse 命令、多层认证与跨模型评审记录，共同构成了这条路线从命题到可交付 macOS 应用的完整证据链。

【免费下载链接】gstackUse Garry Tan's exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack