# **玄圃 Vision & Roadmap**

> **为 Agent 提供一个现场，而不是一个对话框**

**版本**：v1.0\
**日期**：2026-04-21\
**状态**：Active\
**维护者**：@slicenferqin


---

## **0. 这份文档是什么**

这份文档定义了玄圃（Xuanpu Workbench）的产品哲学、核心主张、以及未来 6 个月的演进路线。它不是一份功能清单，而是一把尺子——**未来所有的功能决策都应该被这把尺子量一遍**。

它面向三类读者：

- **玄圃的构建者**（当前是我自己，未来可能是贡献者）——让所有参与者都理解"我们为什么做这个产品、以及不做什么"
- **玄圃的用户**——让他们理解玄圃和 Cursor、Amp、Claude Code、Codex 的本质区别
- **未来的合作者**（Agent 厂商、OS 平台、投资人）——让他们理解玄圃的长期定位


---

## **1. 第一性原理：为什么现在的 AI 产品是错的**

### **1.1 一个被所有人忽略的现状**

截止 2026 年 4 月，Claude Opus 4.7 / GPT-5.4 / Gemini 3.1 Pro 已经在 Artificial Analysis Intelligence Index 上并列第一。模型能力进入 saturation，差异化正在从"模型本身"转向"模型怎么被包装、怎么被嵌入现场"。

但我们打开任何一个主流 AI 产品——Cursor、ChatGPT、Claude Desktop、Codex——会发现它们长得都差不多：**一个输入框，一个聊天流，侧边挂几个工具**。产品之间可以互换 UI，底层模型可以互换品牌，用户在不同产品间切换几乎感受不到"这是两个不同物种"。

**这不是因为大家都做得好，恰恰是因为所有人都陷在同一个局限里。**

### **1.2 输入框是 AI 时代的实体键盘**

iPhone 4 之前，全世界对手机的想象是固定的：屏幕 + 实体键盘。不是因为键盘多么不可替代，而是因为**键盘是"人和设备之间的翻译层"**——用户的意图必须先被翻译成按键序列，设备才能理解。iPhone 真正革命的不是"去掉了键盘"，而是让**手指直接作用于内容**，消灭了那层翻译。

输入框，就是今天 AI 产品的实体键盘。

用户的意图本来就藏在他当下的现场里——他在看哪个文件、他刚才跑了什么命令、他选中了哪段代码、他在哪个 worktree、他上一小时在做什么——这些信息**对人类协作者是天然可见的**，但对 AI 是完全不可见的。于是用户被迫做一件滑稽的事：**把眼前本来就在发生的现场，用自然语言翻译一遍，打字打进一个空白输入框里，喂给 AI**。

这不是"交互设计"，这是交互贫困。

### **1.3 真正的协作，需要共同现场**

人类协作从来不是靠纯对话。两个程序员结对编程的时候，他们之间语言只占协作信息的一小部分——更大的部分是**共享视线、共享指向、共享操作对象**。一个人指着屏幕说"这里"，另一个立刻理解，因为"这里"依附于一个共同现场。

如果把这两个人分开在两个房间，只留一个对讲机，协作会立刻崩溃——不是因为对话消失了，而是**对话所依附的共同现场消失了**。

今天的 AI 产品恰恰是后者。Claude 看不到你的屏幕，Codex 不知道你刚切过 worktree，Cursor 不记得你三天前做到哪里。所有 AI 都被关在一个"没有现场的房间"里，然后我们怪它不够聪明。

### **1.4 玄圃的第一性原理**

> **玄圃存在的意义，是为 AI 和用户之间重建共同现场。**

这不是一句营销口号，而是一把能推导出所有产品决策的尺子。当我们面对任何功能选择时，都问同一个问题：**这个功能让用户和 Agent 更共享现场，还是更分离？**

- 让用户和 Agent 更共享现场的——做
- 让用户和 Agent 更分离的——不做
- 与共享现场无关的——不做


---

## **2. 核心主张：玄圃是什么、不是什么**

### **2.1 玄圃是什么**

**玄圃是一个为 Agent 提供现场的工作台。**

具体来说：

- 它持续感知用户在工作台里的一切行为（哪个 worktree、哪个文件、哪行代码、哪条命令、哪次输出），将这些行为结构化为 **现场事件流（Field Event Stream）**
- 它把这些事件流按时间尺度压缩成 **分层记忆（Working / Episodic / Semantic Memory）**
- 它在 Agent 被调用的每一刻，把当前最相关的现场片段注入 Agent 的输入，让 Agent 像一个在你身边的同事那样理解上下文
- 它允许多个 Agent、多个 Worktree、多个任务在同一个现场里并行运转，并通过 Connections 共享跨 worktree 的上下文

**一句话**：玄圃让 Agent 不再需要"猜用户在干什么"——因为它一直在看。

### **2.2 玄圃不是什么**

**玄圃不是另一个 IDE。**

IDE 的核心使命是"让人编辑文件更方便"。玄圃不追求成为更好的 VSCode / Cursor——那是 Cursor 正在做的事，那条路已经被占满。

**玄圃不是另一个终端 Agent。**

Amp 那条路径的核心是"把现场折叠成 Thread，让人事后审查"。这是一个自洽的选择，但它假设用户已经完全信任 AI。玄圃服务的是另一类用户——**维护复杂项目、并行多任务、需要看过程、不完全信任 AI 的严肃构建者**。对这类用户，现场可视化的价值远大于现场折叠。

**玄圃不是一个 Agent SDK 的壳。**

玄圃不打算自己训练模型，也不打算成为 Agent 本身。Claude Code / Codex / OpenCode / 未来的任何 Agent 都是玄圃欢迎的客人。**玄圃的价值在于"所有 Agent 在玄圃里都比在自己原生环境里更强"——因为它们第一次获得了现场。**

### **2.3 玄圃的差异化坐标**

|产品 |核心定位 |现场处理方式 |服务的用户心智 |
|---|---|---|---|
|Cursor |AI 增强的编辑器 |通过 tool call 事后查询 |"我要写代码，AI 帮我" |
|Amp |极简 Agent 交付 |折叠成 Thread 事后审查 |"我信任 AI，交给它就行" |
|Claude Code / Codex |Agent 的原生终端 |自带环境，session 粒度 |"我在命令行里就是王" |
|**玄圃** |**Agent 的现场提供者** |**持续感知 + 实时注入** |**"我要和 AI 并肩工作"** |


---

## **3. 路线图：从个人工作台到分布式协作网络**

玄圃的演进分为三个同心圆。每一个同心圆都站在前一个的基础上，而不是推翻前一个。

### **3.1 第一圈（2026 年 5-6 月）：让单机现场做到"离不开"**

**战略目标**：用户一旦习惯玄圃理解他的现场，切到任何 CLI 或 IDE 都会感到 **本能的别扭**。

**关键产出**：

- 现场事件流（Field Event Stream）- MVP
- 分层记忆（Working / Episodic / Semantic Memory）
- 现场注入（Field Injection）- 接入 Claude Code / Codex / OpenCode
- 验收证据：一段 60 秒的对比视频，展示"用户说一句'这里为什么挂'，玄圃精准定位，其他工具一脸茫然"

**具体设计**：见 §4.1

### **3.2 第二圈（2026 年 6-8 月）：让任何 Agent 在玄圃里最佳表现**

**战略目标**：玄圃不再是"接入各种 Agent"，而是**"提供一个标准化的 Agent 运行环境"**，让 Agent 厂商为了获得现场感知能力主动适配玄圃。

**关键产出**：

- Xuanpu Field Protocol（XFP）v0.1
- Claude Code / Codex / OpenCode 的 Field Protocol 适配层
- Agent Runtime 的统一抽象
- 推动 XFP 成为 MCP 扩展候选标准

**具体设计**：见 §4.2

### **3.3 第三圈（2026 年 8-10 月）：让现场在设备之间流动**

**战略目标**：用户在 Mac 上开始一个 Session、出门用手机续接、回家在 Linux 工作站收尾——**执行始终在本地，现场跨设备同步**。

**关键产出**：

- Session Hub 协议 v1
- Session Hub 参考实现（开源、可自部署、单二进制）
- 玄圃移动端（PWA 起步）
- 公共 Hub 服务（可选，可商业化）

**具体设计**：见 §4.3


---

## **4. 功能设计**

### **4.1 现场事件流 + 分层记忆 + 现场注入**

#### **4.1.1 现场事件流（Field Event Stream）**

**设计理念**：玄圃里用户做的每一件事，都被结构化为一个事件，沉淀到时间线上。

**事件分类**（按优先级分级实现）：

**P0 事件（第一期必须实现）**：

- `worktree.switch` —— 用户切换 worktree
- `file.open` / `file.focus` —— 打开或聚焦文件
- `file.selection` —— 选中代码（含行号范围）
- `terminal.command` —— 在终端执行命令
- `terminal.output` —— 命令输出（截断头尾）
- `session.message` —— 用户发给 Agent 的消息

**P1 事件（第二期补充）**：

- `file.edit` —— 手动编辑文件（diff 摘要）
- `git.status_change` —— git 状态变化
- `session.approval` —— 用户对 Agent 请求的审批
- `connection.created` / `removed` —— 跨 worktree 连接变化

**P2 事件（选择性实现）**：

- `cursor.position` —— 光标位置（需节流）
- `search.query` —— 工作台内搜索

**数据模型**：

```ts
type FieldEvent = {
  id: string              // UUID
  timestamp: number       // ms since epoch
  worktreeId: string | null
  sessionId: string | null
  type: string            // 事件类型
  payload: Record<string, unknown>  // 类型特定的数据
}
```

**存储**：SQLite 单表 `field_events`，索引 `(worktree_id, timestamp)` 和 `(type, timestamp)`。一天预估 5000-20000 条事件，SQLite 完全扛得住。

**采集策略**：

- 在 main 进程建立 `FieldEventBus` 单例
- 现有 IPC handler 处理完请求后顺手 emit 事件（不改 renderer 代码）
- 高频事件（光标、滚动）在 bus 层做节流（1 秒最多 1 次）

**用户可见性**：

- Settings → Privacy Panel：列出所有事件类型，逐项可关闭
- 新增 "Field Timeline" 视图：让用户看到玄圃"记下了关于我的什么"
- 所有事件仅存于本地，不上传（至少在这个阶段不）

#### **4.1.2 分层记忆**

**设计理念**：借鉴人类记忆的分层机制，不同时间尺度的信息以不同颗粒度保留。

**Working Memory（工作记忆）**：

- 范围：最近 5 分钟或最近 100 个事件
- 形式：原始事件的时间线序列
- 存储：实时从 `field_events` 表查询，无需额外存储
- 用途：每次调用 Agent 时作为"当前现场"注入

**Episodic Memory（短期记忆）**：

- 范围：按 worktree 维护的滚动摘要，覆盖最近数小时到一天
- 形式：Markdown 文档，包含"当前焦点 / 最近工作 / 遗留问题"
- 更新：定时任务（每 30 分钟）+ 关键事件触发，用便宜模型（Haiku / Gemini Flash）压缩
- 存储：`field_episodic_memory` 表，按 worktree_id 一条
- 用途：Session 启动时作为"worktree 近况"注入

**Semantic Memory（长期记忆）**：

- 范围：项目级的持久知识（用户偏好、项目结构、反复出现的约束）
- 形式：`{workspace}/.xuanpu/memory.md` 文件
- 更新：后台 skill agent 定期维护，也允许用户手动编辑
- 用途：Agent 启动时自动 include

**Crystallized Memory（永久记忆，未来）**：

- 跨 workspace 的用户级知识（身份、通用偏好、惯用工具链）
- 暂不实现，等前三层跑通再设计

#### **4.1.3 现场注入（Field Injection）**

**设计理念**：重塑 Agent 的输入协议——从"只接收一句话"到"接收一句话 + 当前现场 + 相关记忆"。

**新的 Agent 输入结构**：

```text
[System Prompt]
你是一个在玄圃工作台里工作的编程助手。以下是你当前的工作现场。

[Long-term Memory] (up to 2000 tokens)
<{.xuanpu/memory.md} 的内容>

[Worktree Summary] (up to 1500 tokens)
<当前 worktree 的 episodic memory>

[Current Field State] (up to 1000 tokens)
Current worktree: feature/auth
Focused file: src/auth/login.ts
Selection: lines 45-58
Last terminal command: npm test auth (5s ago)
Last output (tail): ...

[Recent Activity] (up to 1500 tokens)
10:23:14 Switched to worktree feature/auth
10:23:45 Opened src/auth/login.ts
10:24:02 Selected lines 45-58
10:24:30 Ran npm test auth
  Output: 3 tests failed
10:25:10 User: "这里为什么挂？"

[Conversation History]
...

[User Message]
这里为什么挂？
```

**关键设计**：

- **Token 预算硬上限**：现场部分总共不超过 6000 tokens。对 Opus 4.7（1M 窗口）是毛毛雨，对便宜模型也没压力
- **Dry-run 机制**：发给 Agent 前，先在本地日志完整打印一份 input payload。这是产品构建者的眼睛
- **优雅降级**：新 worktree / 无记忆时跳过对应层级，不阻塞 Agent 调用
- **用户可见**：Session 详情页可以展开查看"这次 Agent 实际收到了什么"——透明化是信任的基石

#### **4.1.4 验收标准**

完成度不由"功能是否实现"衡量，而由以下**四个用户瞬间**验收：

**瞬间 1**：用户只说"这里为什么挂了"——Agent 应当准确定位到用户选中的代码 + 最近的测试失败输出\
**瞬间 2**：用户说"继续上次那个任务"——Agent 应当从 episodic memory 里恢复上下文\
**瞬间 3**：用户切走 20 分钟后回来——Agent 应当知道中间发生了什么\
**瞬间 4**：用户切到 Cursor 或原生 Claude Code——明显感觉"那个 AI 变笨了"


---

### **4.2 Xuanpu Field Protocol（XFP）**

#### **4.2.1 设计理念**

当前所有 Agent 都自带环境——它们各自定义怎么读文件、怎么跑命令、怎么管 context。玄圃接入它们时是在做"委屈的适配"。

**XFP 反转这个关系**：玄圃提供标准化的现场 API，让 Agent 只需要调这些 API 就能拿到比自己瞎找精准 10 倍的信息。Agent 不再需要懂 worktree、不再需要满世界 grep、不再需要问"你说的哪里"。

#### **4.2.2 XFP 核心 API（v0.1 草案）**

```ts
interface XuanpuField {
  // 当前焦点查询
  currentFocus(): {
    worktree: WorktreeInfo
    file: FileInfo | null
    selection: Selection | null
    cursor: Position | null
  }
  
  // 活动历史查询
  recentActivity(opts: {
    minutes?: number
    limit?: number
    types?: EventType[]
  }): FieldEvent[]
  
  // Worktree 上下文
  worktreeContext(worktreeId?: string): {
    summary: string          // episodic memory
    openFiles: FileInfo[]
    recentCommands: Command[]
    gitStatus: GitStatus
  }
  
  // 长期记忆
  longMemory(): string       // semantic memory (markdown)
  
  // 订阅事件流（未来版本）
  subscribe(eventTypes: EventType[], callback: (e: FieldEvent) => void): Unsubscribe
}
```

#### **4.2.3 推广路径**

**Stage 1**：XFP 先在 Claude Code 的 adapter 里跑通——让 Claude Code 在玄圃里的表现**显著好于**它在原生终端里。这是协议的第一个信徒证明。

**Stage 2**：复制到 Codex、OpenCode。三家跑通后，XFP 就有了真实的实现样本。

**Stage 3**：把 XFP 整理成公开规范文档，在 GitHub 开源协议仓库。

**Stage 4**：向 MCP 社区提 XFP 扩展提案。如果通过，XFP 成为 Agent 生态的一个标准。协议红利流向提出者——玄圃成为 "Field-aware Agent" 的事实标准实现。


---

### **4.3 Session Hub**

#### **4.3.1 产品叙事**

> **你在 Mac 上开始一个任务。\
> 出门路上打开手机，看它跑到哪里、给它发个消息。\
> 回家在另一台电脑上打开玄圃，Session 已经在那儿等你。\
> 执行始终在你第一台设备上——没有代码被上传，没有数据离开你的控制。**

这是 2026 年没有任何 AI 产品能提供的体验。

#### **4.3.2 核心架构**

**单写者 + 多读者**（single-writer multi-reader）：

- Session 的**权威来源**永远是"执行设备"（那台跑着 Agent 的 Mac）
- Hub 和其他设备只持有**只读镜像**
- 移动端/远程设备上的用户输入，作为消息回传到执行设备，由执行设备合并后再推送
- 这是分布式系统里最稳的模式，抵抗"让每个设备都能直接写"的诱惑

**数据流方式**：快照同步（v1）

- 执行设备每 5 秒把 Session 最新状态打包推送给 Hub
- Hub 存最新快照
- 其他设备拉快照
- 延迟在 3-10 秒区间，但工程简单、离线友好
- v2 再考虑升级到实时流

**协议栈**：

- 传输层：WebSocket + JSON（跨平台、穿透性好）
- 认证层：Token-based（公共 Hub 发 token，自部署 Hub 自己发）
- **公共版和自部署版严格同构**——只是部署位置不同，协议完全一致

#### **4.3.3 Session Hub 的最小可行形态**

**Hub 服务端**：

- 单一 Go 或 Rust 二进制，无依赖
- `docker run xuanpu/hub` 就能起
- 内置 SQLite 存 Session 快照，可选 Postgres
- 提供一套 WebSocket API

**玄圃桌面端新增能力**：

- Settings → "Connect to Hub" 配置项
- 后台持续推送 Session 快照
- 接收远程消息并合并到本地 Session

**玄圃 WebApp（移动端 MVP）**：

- 用 React + PWA 实现（最大限度复用 renderer 代码）
- 核心功能：Session 列表 / Session 详情 / 发送消息 / 审批请求
- 不追求原生 App 体验——"路上看一眼、回条消息"是核心场景
- 将来视用户行为决定是否做原生

#### **4.3.4 商业模式的种子**

Session Hub 同时是玄圃未来可能的商业化抓手：

- **开源自部署版**：永久免费，对开发者和企业敞开
- **公共 Hub SaaS**：月度订阅，包含跨设备同步、历史归档、团队协作
- **企业版 Hub**：SSO、审计日志、权限控制

但商业化不是现在的目标——**现在的目标是做出来，证明它有用**。商业化模式需要等真实用户数据才能设计。


---

## **5. 非目标（Non-Goals）**

明确记录"玄圃不做什么"，比记录"玄圃做什么"更重要。这一节是对未来路径漂移的免疫接种。

**玄圃不做：**

1. **不训练自己的模型**。玄圃是现场提供者，不是 Agent 本身
2. **不做通用聊天产品**。玄圃的 Session 永远围绕具体任务、具体 worktree
3. **不追求 Cursor 那种"编辑器内一切"的完整性**。玄圃承认自己不是编辑器
4. **不做跨设备的 agent 执行同步**——执行永远在单一设备上，Hub 只同步现场
5. **不做 Windows/Linux 的一等公民**（至少 2026 年内）。macOS 先打磨到优秀，其他平台跟进
6. **不为没有共享现场需求的用户优化**——如果一个用户只想"偶尔用 AI 写几行代码"，他应该去用 Cursor 或 ChatGPT，玄圃不争取这类用户


---

## **6. 决策原则**

1. 当面对不确定的功能选择时，按以下顺序提问：
   1. **这个功能让用户和 Agent 更共享现场吗？**
      - 是 → 进入下一问
      - 否 → 否决
   2. **这个功能能在现有技术栈上实现吗？**
      - 能 → 进入下一问
      - 不能，且迁移成本 <2 周 → 进入下一问
      - 不能，且迁移成本 >2 周 → 推迟到下一阶段重新评估
   3. **这个功能能被当前路线图里的某一期吸收吗？**
      - 能 → 合并进那一期的 scope
      - 不能 → 创建独立提案，进入待评审队列
   4. **做这个功能的机会成本是什么？**
      - 如果要做它，必须推迟路线图里的哪一件事？
      - 如果推迟的那件事更接近核心主张 → 不做这个新功能
      - 如果推迟的那件事离核心主张更远 → 考虑交换

   **反面清单（自动否决的功能类型）**：
   - 任何"让玄圃变成更好的编辑器"的功能（那是 Cursor 的赛道）
   - 任何"让玄圃自己变成一个 Agent"的功能（那是 Claude Code / Codex 的赛道）
   - 任何"让玄圃支持某个底模的炫酷新能力"但不服务于共享现场的功能
   - 任何"因为竞品也在做所以我们也要做"的功能


---

## **7. 成功度量**

玄圃不追求用户数量的野蛮增长。在未来 6 个月里，成功由以下指标衡量：

### **7.1 第一圈（5-6 月）成功指标**
- **验收视频**：一段 60 秒的真实对比视频，展示玄圃对比 Cursor/Codex 在"现场理解"上的明显优势
- **种子用户留存**：10-30 位真实用户，他们在使用玄圃 2 周后，**主动**表示"回不去了"
- **公众号叙事落地**：至少 1 篇 10k+ 阅读的文章，核心观点是"共享现场"这个概念

### **7.2 第二圈（6-8 月）成功指标**
- **XFP 协议草案发布**：GitHub 上有公开的 Field Protocol 仓库
- **三家 Agent 适配**：Claude Code / Codex / OpenCode 在玄圃里的体验**显著优于**原生环境
- **第一个外部关注**：有 Agent 厂商（不一定是大厂）主动联系想讨论 Field Protocol

### **7.3 第三圈（8-10 月）成功指标**
- **Session Hub MVP 上线**：自部署版和公共版至少有一个能跑通"Mac 开始 → 手机查看 → Mac 完成"的完整闭环
- **跨设备用户**：至少 10 位用户在日常工作中跨设备使用玄圃
- **护城河验证**：至少出现一次"有投资人或大厂主动询问玄圃是什么"

**明确不追求的指标**：
- **不追求月活 / 日活** —— 玄圃的用户是严肃构建者，不是普通消费者
- **不追求 GitHub Star 数** —— star 和真实采用几乎无关
- **不追求 Product Hunt 排名** —— 那个流量带来的不是你的目标用户


---

## **8. 风险与对策**

### **8.1 技术风险**

**风险 1：事件流性能不够**\
SQLite 单表如果每秒几十条事件，长期下来可能变慢。
- **对策**：监控 `field_events` 表增长，超过 1M 行启动归档机制（冷数据移到独立表或 parquet 文件）
- **底线**：即使事件流挂了，玄圃降级到"无现场注入"状态，Agent 照常工作

**风险 2：分层记忆压缩质量不稳定**\
Episodic memory 靠便宜模型压缩，有可能丢关键信息。
- **对策**：允许用户手动标注"这个事件很重要"，被标注的事件不会被压缩丢失
- **对策**：在 Semantic Memory 里沉淀"压缩规则"——用户反馈"这类信息不能丢"后，后续压缩会保留

**风险 3：Tauri/Rust 重写诱惑**\
当底座开始显露缺点时，会产生"重写到更高性能栈"的冲动。
- **对策**：除非 Electron 架构**客观上**成为产品迭代的主要障碍，否则不考虑重写
- **对策**：把 Tauri 迁移评估纳入 2026 年 Q4 的 retrospective，不更早讨论

### **8.2 产品风险**

**风险 1：用户嫌"现场注入"太啰嗦**\
如果 Agent 总是先报告"我看到你在哪哪"再回答，会让用户觉得冗余。
- **对策**：现场注入是给 Agent 看的，不是给用户看的。System prompt 里明确要求 Agent "理解现场但不复述现场"
- **对策**：用户能随时看到"这次注入了什么"（透明），但正常对话里不展示

**风险 2：隐私担忧**\
"玄圃一直在看我"这个叙事对某些用户是卖点，对另一些用户是警报。
- **对策**：所有数据本地存储，不上传（Hub 阶段也只上传 Session 元数据，不是全部事件流）
- **对策**：Privacy Panel 是一等公民功能，不是藏在 Settings 深处
- **对策**：公众号里主动讲清楚"玄圃看什么、不看什么、存在哪"——透明化先于用户质疑

**风险 3：新用户冷启动门槛高**\
用户刚装玄圃，没有任何记忆、没有任何事件流，Agent 不会比 Cursor 更聪明。
- **对策**：第一次打开玄圃时，有一个"引导流程"——帮用户创建 workspace、添加 worktree、建立第一个 `memory.md`
- **对策**：把"越用越聪明"作为明确的产品叙事——用户理解前几天体验一般是正常的

### **8.3 战略风险**

**风险 1：大厂下场做同样的事**\
Anthropic 或 OpenAI 自己做出"现场感知"的桌面产品。
- **对策**：玄圃的优势是**中立**——它不绑定任何一家 Agent。大厂做出来的一定是绑死自家 Agent 的产品
- **对策**：XFP 开放协议是护城河——一旦协议被 Agent 生态接受，谁也不能独占

**风险 2：模型能力突破让"现场"变得不重要**\
如果未来某代模型真的能从一句话里推理出所有上下文（不太可能，但假设），现场注入的价值会降低。
- **对策**：这一天到来前玄圃至少能吃 2-3 年红利
- **对策**：就算那一天到来，"多设备现场同步"的价值依然存在——这是 Hub 层的护城河

**风险 3：注意力分散**\
创始人同时在做公众号、维护玄圃、思考战略，精力分散是最大的敌人。
- **对策**：公众号和玄圃是**互相喂养**的关系，不是互相消耗——每一次思考都能落到玄圃，每一次玄圃的进展都能变成公众号素材
- **对策**：每周至少 3 天是"纯玄圃工程日"，不被任何其他事情打断


---

## **9. 执行节奏**

### **9.1 每周节奏**
- **周一**：回顾上周进展，对照路线图调整本周目标
- **周二至周四**：核心工程日
- **周五**：写公众号 / 录屏 / 对外传播
- **周日**：思考 + 阅读 + 和其他 AI 讨论大方向，为下周路线提供方向性输入

### **9.2 每月节奏**
- **月初**：发布一个版本（v1.x 的 minor 升级）
- **月中**：写一篇里程碑文章
- **月末**：Retrospective，回答三个问题：
  1. 这个月我们离"共享现场"更近了还是更远了？
  2. 有没有某个决策违反了决策原则？为什么？
  3. 下个月最重要的一件事是什么？

### **9.3 季度节奏**
- **Q2（5-6 月）**：第一圈完成，验收视频发布
- **Q3（7-9 月）**：第二圈 + 第三圈启动
- **Q4（10-12 月）**：第三圈完成，回顾全年、评估是否需要架构层面的大调整


---

## **10. 致谢与起源**

玄圃起步于对 Hive 的 fork。最初的工作台结构、Worktree / Session / Connections 这些抽象，都受 Hive 的启发。随着产品沿着"共享现场"的方向分化，玄圃逐步走出了自己的路径，但对 Hive 的致谢应当被永久保留。

这份文档也受到了许多人的思考启发：
- 乔布斯关于 iPhone 4 打破"屏幕 + 实体键盘"范式的历史——为玄圃反对"输入框霸权"提供了类比的锚点
- Amp 团队 "The Coding Agent Is Dead" 的激进决策——让玄圃意识到"砍掉什么"和"保留什么"同样重要
- Anthropic 的 MCP 协议设计哲学——为 XFP 提供了开放协议的范本
- Cursor 团队对"AI 嵌入编辑器"路径的充分探索——定义了玄圃刻意不走的那条路


---

## **11. 结语**

玄圃的核心主张可以用一句话概括：

> **当模型能力已经强到 Claude Opus 4.7 / GPT-5.4 / Gemini 3.1 Pro 并列第一的时候，AI 产品的差异化不再来自"我的模型更强"，而来自"我让模型看见更多"。**

玄圃选择的方式是——**重建一个共同现场**。

它不是一个宏大的技术革命，它是一个朴素的判断：**人类协作从来靠的不是纯对话，是对话加上现场。AI 协作不应该例外。**

这份文档写在 2026 年 4 月 21 日——玄圃从一个 Hive 的 fork 出发、经过 68 天 1200+ commits 工程积累、第一次真正找到自己的产品身份的这一天。

接下来的 6 个月，我们把这份主张变成用户能感知的事实。

---

**— END —**

> 这份文档是活的。每一次关键决策、每一次路线调整、每一次主张演进，都应当回到这份文档更新。当你下次打开它时，如果发现它过时了，请修改它——**过时的 Vision 比没有 Vision 更危险**。

---
