Office Lab

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

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

一个项目，两种专业视角 · 把发现的问题变成可执行的 Issue · 用 Worktree 与 Compare 审阅内容 · 生成、发布和管理 Web App · 体验 Office Lab

截图取自真实云端 Workspace，使用虚构英文案例数据；两位角色使用不同 Agent 的过程是建议的协作方式。

一个项目，两种专业视角

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

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

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

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

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

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

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

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

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

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

用 Worktree 与 Compare 审阅内容

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

Worktree 隔离本次任务的修改，内容比较 基于内容模型、Snapshot 与 Changeset 呈现差异。人类可以要求继续修改，也可以在有权限时确认合入。本例截图中的双文件 PR 保持 Ready，尚未合入。

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

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

生成、发布和管理 Web App

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

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

原生 Office 内容通过 Worktree 审阅与合入；HTML View 使用自己的保存和授权发布流程。本例原型单独发布，文档 PR 仍等待审阅。需要让 Web App 与 Office 数据实时联动时，可以继续了解实验性的双向绑定。

直接体验交互原型

让团队协作有清晰的边界

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

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

体验 Office Lab

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

如果希望使用自己的 Agent，按照 Workspace CLI 接入说明连接即可。每个 Agent 使用其用户已授权的账号；下面的任务模板可以直接用于实践。

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

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

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

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

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

审阅 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 · 源码仓库 · 全部示例