# Office Lab

> 像 GitHub 一样协作办公内容：在同一个 Workspace Repo 中连接需求、Issue、PR、原生内容审阅、交互原型与任务排期。

- Human documentation: [https://docs.univer.ai/zh-CN/overview/examples/office-lab](https://docs.univer.ai/zh-CN/overview/examples/office-lab)

- Agent Markdown: [https://docs.univer.ai/zh-CN/overview/examples/office-lab.md](https://docs.univer.ai/zh-CN/overview/examples/office-lab.md)

- Requested language: `zh-CN`

- Content language: `zh-CN`

- Documentation version: `1.3.0`

- Source: [examples/office-lab.zh-CN.mdx](https://github.com/dream-num/documentation/blob/dev/content/docs/examples/office-lab.zh-CN.mdx)

---

**Office Lab** 把仓库式协作带进产品与研发的日常工作。它基于 **[Univer Office SDK](https://docs.univer.ai/zh-CN/overview.md)** 构建，使用 Workspace 的 Repo 模式，将需求文档、电子表格、可交互原型、Issue 与 PR 放在同一个项目里。进入项目，就能知道大家要解决什么、这次改了什么、哪些成果已经可以使用。

用一个团队邀请功能来体验这套流程：产品经理与研发各自使用熟悉的 Agent 准备和检查资料，人类讨论体验、审阅变更并决定交付。需求不断演进，项目中的文档、数据与原型也跟着一起完善。

[一个项目，两种专业视角](#case-study) · [把发现的问题变成可执行的 Issue](#issues) · [用 Worktree 与 Compare 审阅内容](#review) · [生成、发布和管理 Web App](#web-apps) · [体验 Office Lab](#quick-start)

截图取自真实[云端 Workspace](https://space.univer.ai)，使用虚构英文案例数据；两位角色使用不同 Agent 的过程是建议的协作方式。

## 一个项目，两种专业视角

**Team Invitations** 从一个容易理解的小需求开始：邀请同事加入工作区，选择角色，并明确知道邀请是否成功。重复邀请同一个待加入邮箱，就是串联原型、验收标准、埋点和任务排期的改进点。

| 角色 | 各自熟悉的 Agent | 负责的工作 |
| --- | --- | --- |
| Maya · 产品经理 | 例如 Codex | 定义体验、需求、验收标准和埋点方案，审阅最终效果。 |
| Alex · 研发 | 例如 Claude Code | 阅读需求、体验原型、提出 Issue，准备改进并验证行为。 |

| 项目资料 | 在协作中起到的作用 |
| --- | --- |
| Product brief · 文档 | 产品目标、邀请规则、验收标准与发布条件。 |
| Tracking plan · 文档 | 埋点触发时机、属性和统计口径。 |
| Event catalog · 表格 | 结构化管理事件、负责人和准备状态。 |
| Delivery schedule · 表格 | 工作事项、负责人、时间、进度与工作量。 |
| Invite Prototype / Team Access Console · Web App | 可以直接点击体验的邀请表单原型。 |

```mermaid
flowchart TD
A["Issue"]
B["Maya · 产品经理"]
C["Alex · 研发"]
D["Office Worktree"]
E["PR + Compare"]
F["共享 Office 内容"]
G["Web App"]
H["Pages"]
A --> B --> D --> E --> F
A --> C --> D
C --> G --> H
E -->|Issue| A
```

## 浏览 Repo，把工作资料放在一起

在 Repo 模式打开团队 Space。**Code** 把可编辑文档与应用文件组织在一起，可以搜索、预览并随时返回项目。Issues、Pull requests、Pages 与 Settings 就在资料旁边，讨论和交付围绕同一份项目上下文展开。

Repo 模式是同一个 Workspace Space 的另一种组织方式，沿用其内容和权限。项目首页还可以直接展示选定的 Web App：打开项目，既能读需求，也能立即体验原型。

![浏览 Repo，把工作资料放在一起](https://raw.githubusercontent.com/dream-num/documentation/dev/public/assets/examples/office-lab/cloud-repository-rich.png)

## 把发现的问题变成可执行的 Issue

Alex 体验原型时，发现重复邀请缺少清晰反馈。**Prevent duplicate invitations** 这个 Issue 写明期望提示、被拦截邀请的埋点，以及 QA 需要补充的检查。相关文件直接关联需求文档、埋点说明、事件表和排期。

通过描述、评论、负责人和标签，把下一步要做什么说清楚。Issue 属于团队 Space；Agent 也能通过 Workspace CLI 读取同一个任务与关联资料，再带着具体方案回来。反馈可以留在 Issue 或对应文档的评论中。

![把发现的问题变成可执行的 Issue](https://raw.githubusercontent.com/dream-num/documentation/dev/public/assets/examples/office-lab/cloud-issue.png)

## 通过 PR 提出一组可审阅的修改

PR 将 Workspace Worktree 呈现为一组可审阅的提案：创建任务草稿，加入需要修改的已有文档，完成操作后标记为 Ready。提案有自己的标题、摘要、作者、状态和变更文件列表；草稿完善期间，团队仍能继续查看和使用共享内容。

截图中的 PR 在事件表补上 `invite_duplicate_blocked`，同时调整任务排期中的 QA 安排，并在摘要引用 Issue #1。产品与研发可以各自在独立草稿中工作，再向有权限的审阅者开放，依据同一份源资料检查彼此的成果。

![通过 PR 提出一组可审阅的修改](https://raw.githubusercontent.com/dream-num/documentation/dev/public/assets/examples/office-lab/cloud-pull-request.png)

## 用 Worktree 与 Compare 审阅内容

先读修改摘要，再进入 **Files changed**。**View** 在只读审阅视图中查看完整成果，**Compare** 并排展示正式版本与提议版本，并提供可定位的差异列表。新增了哪个事件、何时触发、谁负责、影响哪段排期，都能放回原生 Office 内容里理解。

[Worktree](https://docs.univer.ai/zh-CN/overview/features/shared/worktree.md) 隔离本次任务的修改，[内容比较](https://docs.univer.ai/zh-CN/overview/features/shared/compare.md) 基于内容模型、Snapshot 与 Changeset 呈现差异。人类可以要求继续修改，也可以在有权限时确认合入。本例截图中的双文件 PR 保持 Ready，尚未合入。

![用 Worktree 与 Compare 审阅内容](https://raw.githubusercontent.com/dream-num/documentation/dev/public/assets/examples/office-lab/cloud-compare.png)

### 把交付影响也放进同一次审阅

同一个 PR 将 Usability and QA 的结束时间从 11 月 9 日调整到 11 月 10 日，工作量从 2 天调整为 3 天。把负责人、日期和状态与埋点变更一起检查，验收时就能同时考虑交付所需的工作。

![把交付影响也放进同一次审阅](https://raw.githubusercontent.com/dream-num/documentation/dev/public/assets/examples/office-lab/cloud-schedule.png)

## 生成、发布和管理 Web App

原型是可以运行的 HTML View。在 **Pages** 集中查看项目已发布的 Web App，打开页面、复制地址或选择首页预览；默认页面的选择仅对当前浏览器生效。文件组织与访问权限继续由 Workspace 管理。

邀请原型进一步扩展为 **Team Access Console**：成员与角色列表、状态筛选、搜索、邀请与取消、最近操作、验收清单和会话内事件计数集中在一个页面。新增示例邮箱会更新列表与待处理数量，重复邀请会被拦截。示例数据仅保存在内存，不发送邮件或上报分析事件；产品经理可以直接验证行为，再把发现的问题变成 Issue。

原生 Office 内容通过 Worktree 审阅与合入；HTML View 使用自己的保存和授权发布流程。本例原型单独发布，文档 PR 仍等待审阅。需要让 Web App 与 Office 数据实时联动时，可以继续了解实验性的[双向绑定](https://docs.univer.ai/zh-CN/overview/features/shared/binding.md)。

[直接体验交互原型](/assets/examples/office-lab/invite-prototype.univer.html)

![Team Access Console：成员、邀请与验收检查](https://raw.githubusercontent.com/dream-num/documentation/dev/public/assets/examples/office-lab/cloud-team-access.png)

## 让团队协作有清晰的边界

**Settings** 将项目名称、描述和可见性与成员管理、回收站组织在一起。拥有者和管理员负责整理访问范围；文档编辑、审阅和合入遵循当前用户的有效权限，项目链接也遵循这些权限。

交付决定保持清晰：产品经理检查体验与验收标准，研发检查实现与埋点，有权限的人确认合入 Office 修改，检查已发布原型，并在任务完成后关闭 Issue。

![让团队协作有清晰的边界](https://raw.githubusercontent.com/dream-num/documentation/dev/public/assets/examples/office-lab/cloud-settings.png)

## 体验 Office Lab

1. 登录[云端 Workspace](https://space.univer.ai)，或打开自己的[私有部署](https://docs.univer.ai/zh-CN/overview/examples/workspace.md#self-host)，创建或打开一个**团队 Space**。
2. 打开 **Application settings → Page theme → Repository (experimental)**。这是同一个 Space 的另一种视图，切换偏好仅保存在当前浏览器。
3. 在 **Code** 浏览文档，通过 **Issues** 跟进问题，在 **Pull requests** 审阅变更，从 **Pages** 打开已发布的 Web App。

![将团队 Space 切换到 Repository 模式，再浏览文档、Issue、PR 和 Web App](https://raw.githubusercontent.com/dream-num/documentation/dev/public/assets/examples/office-lab/cloud-office-lab-tour.gif)

如果希望使用自己的 Agent，按照 [Workspace CLI 接入说明](https://docs.univer.ai/zh-CN/overview/examples/workspace.md#cli-start)连接即可。每个 Agent 使用其用户已授权的账号；下面的任务模板可以直接用于实践。

### 1. 产品经理：建立共享上下文

```text
在 Team Invitations 团队空间中，准备英文需求文档、埋点说明、事件表和任务排期，并创建可交互的邀请 Web App 原型预览。明确负责人、日期和验收标准。原生 Office 内容保留在 Worktree 中，检查内容后返回审阅链接。合入或发布原型前先等我确认。
```

### 2. 研发：提出聚焦的改进方案

```text
阅读 Team Invitations 的需求、事件表、排期与原型，检查重复邀请待加入邮箱的行为。创建包含复现步骤和期望结果的 Issue。在独立 Worktree 中准备原生文档的修改，原型改进使用自己的发布流程。验证结果，在 PR 摘要引用 Issue，并等待人类审阅。
```

### 3. 产品审阅：把变更与验收连起来

```text
审阅 Team Invitations 的提议 PR，用 Compare 检查原生内容差异。核对重复邀请事件、验收标准与 QA 排期，并体验原型。将遗漏行为反馈到 Issue，请作者继续修改。总结哪些已就绪、哪些仍待处理；在我确认前不要合入或发布。
```

## 基于同一套 SDK 与 Skills 继续构建

双方可以使用同一套与版本配套的 Workspace CLI Skills：`core` 负责资料发现与 Worktree，`doc`、`sheet` 负责需求与计划，`html-view` 负责原型。各自的 Agent 可以读取有权限访问的对方资料与 Issue 反馈，人类保留最终交付决定。

Web SDK 提供内容模型、编辑器与 Headless 操作；Server SDK 提供协同、版本与 Worktree 能力；AI SDK 提供内容操作和检查能力。Workspace 在其上组织项目、身份、Issue、Repo 视图和发布流程。沿着这套组合，可以构建产品实验室、研究空间或团队内部的交付工作台。

[了解 Workspace](https://docs.univer.ai/zh-CN/overview/examples/workspace.md) · [源码仓库](https://github.com/dream-num/univer-workspace) · [全部示例](https://docs.univer.ai/zh-CN/overview/examples.md)