2026 年 9 月 29 日，OpenAI 在 ChatGPT 更新说明中介绍了 Page 和 Space。按官方的说法，Page 可以从对话、模板或空白页开始，由人和 ChatGPT 修改；Space 把页面、文件和相关工作组织在一起，供人继续使用和协作。这项功能目前面向符合条件的 Pro、Business 和 Enterprise 用户。

在 Chat、Project、Work 和 Codex 都已经存在时，OpenAI 为什么还要增加 Page 和 Space？这项更新值得讨论的，是它给法律工作的哪个环节补上了入口。

我的判断是，Page 的价值在于让持续变化的工作底稿重新成为法律人能直接阅读、修改和复核的对象；Space 则让复杂事项的多张底稿可以长期组织。 这可能改变法律人与 AI 处理长程任务的方式：讨论过程不再是唯一线索，当前成果也有了可返回、可继续工作的地方。下面用诉讼处理和非诉评估两种场景，结合实测，具体看看它意味着什么。

Page 能写字、插表格、放文件和链接，也有评论、编辑与分享入口。单看这些功能，把它称作在线文档没有问题。

我对这个问题敏感，是因为过去在 ChatGPT 里讨论法律事项，聊得越深入，越难回答：哪些事实已经确认，哪些问题还悬着，当前判断到底是哪一版？Chat 时代，AI 的回答停在一条条消息里。我试过把有用内容粘贴到 Notion，也试过把对话链接放进去，好让下次还能找到。

到了我使用 Agent 的阶段，问题又变了一层。Agent 不只回复消息，还会写下一个又一个 Markdown 文件。分析过程、工作规则和阶段判断留在这些文件里，撑起整个工作流；法律人最终拿到、真正要用的，却往往只是最后生成的几个 Word 文档。

这中间有一道不小的距离。律师熟悉的是打开文件，直接改一句事实、批一处意见、在段落旁留评论。可是有多少法律人会习惯打开一组 .md，逐个找到该改的地方？实际协作中，很多修改只好再通过对话告诉 Agent：“把第二部分改一下”“刚才那个事实不对”。人离工作底稿远了，原本直接修改文件的动作，变成了反复描述修改意图，再等待 Agent 转写。

我用过一个办法：通过飞书 CLI 让 Agent 把文档放到飞书，自己在文档评论里写纠正意见，再让 Agent 读取评论、修改文档。这样，飞书文档成了我和 Agent 共同工作的地方。但我仍然常想先写一页笔记，梳理事实、疑点和自己的判断，再拿这页笔记与 Agent 讨论。以 Chat 为起点时，这一步一直缺少顺手的入口。

Agent 擅长连续执行，法律人则需要能直接接手、纠正和定稿的工作底稿。

因此，我在意 Page 的原因并不是它会排版，而是它可能补上这层人可直接参与的工作界面。Page 可以从对话中生成，也可以先由人写起；人能在页面上直接编辑、评论或指向一段文字提出修改，ChatGPT 也能围绕页面继续工作，并引用文件、其他页面和聊天。OpenAI 的 Page 说明

Markdown 仍可以承载 Agent 的内部工作，Word 仍可以是正式交付物。Page 值得试的，是两者之间那份持续变化的工作底稿：法律人看得见、改得动，Agent 也能接着处理。“先写一页笔记，再与 Agent 讨论”因此有了更自然的入口。

如果今天第一次用，可以先做一个很小的实验：

这里的顺序不是“先把所有功能开起来”，而是看工作的成果何时需要一个稳定位置。

OpenAI 的 Space 说明明确写着：Space 与 Project 分开，Project 继续组织聊天、文件和项目说明。放进法律工作里，不妨先看两条虚构事项的工作设计——一件劳动争议诉讼，一项 APP 上线隐私评估；后文再分别展开：

两条路径的共同点是：Project 让每一轮分析围绕同一事项展开，Chat 处理具体问题，Page 留下经核对的当前工作状态；需要多张长期页面时，Space 再把它们组织起来。 诉讼事项最终可能形成法律意见、诉讼文书；非诉评估最终可能形成评估报告和整改清单。这些交付物都要从不断更新的工作底稿中形成。

开头提到的 Work 和 Codex，承担的是另一类任务。按 OpenAI 的产品说明，Chat 适合快速讨论，Work 适合多步骤研究和交付，Codex 侧重软件开发与技术工作。它们可以参与执行；Page 则回答执行之后，人和 AI 要围绕哪份成果继续工作。不是每个法律事项都需要 Work 或 Codex。

为什么这对法律人重要？因为法律结论很少一次形成。诉讼中，新证据会改变事实和策略；非诉评估中，一张新的产品页面或一项 SDK 信息也可能改变风险判断。做了十轮分析后，真正需要回答的是：截至今天，哪些事实已经确认？哪些还没有？当前判断依据什么？

Page 可以承担这份“当前工作状态”。但它不是证据原件，更不能让 AI 自动决定什么是法律上的真实。原始材料和权威来源仍要核查；把哪项判断写成当前版本，仍由负责这项工作的法律人决定。

我用一件完全虚构的劳动争议做了本轮实测。材料里只有一份示例通知，写明某公司在一个日期制作了“书面通知”；它没有证明通知的具体内容、是否发出、何时送达或员工是否签收。这种材料恰好适合测试：AI 会不会把缺失的事实顺手补齐？

一个新事项进来，可以先在侧边栏创建 Project，以事项命名，例如“某公司劳动争议”，不要把不同客户的案件都放进一个“劳动法”Project。接着在“项目设置”写工作规则：

如果希望明确项目内外对话的引用范围，还要检查 Project 的 Memory 设置。官方说明：选择 Project-only memory 后，项目内 Chat 可以引用本项目其他对话，但不能引用项目外对话；项目外 Chat 也不能引用本项目对话，且 ChatGPT Work 当前不能在该 Project 中使用。这控制的是模型可引用的上下文范围，不能替代客户资料的权限与分享检查。OpenAI 的 Project 记忆说明

再把工作拆开：01｜事实与时间线、02｜证据、03｜争议焦点与法律、04｜策略与意见。这样每个 Chat 都在解决一个具体问题，而不是让一条对话无限变长。OpenAI 的 Project 设置说明

接下来建一张“案件工作页”。可以在 Space 中直接新建 Page，也可以在已有对话里请 ChatGPT 整理：

页面本身可以按这个结构写：

这张 Page 的价值不在于格式漂亮，而在于打开它的人能先判断“这是不是已复核的当前版本”。新材料进来时，也知道该改哪一块、哪项旧判断需要重新检查。

我在 Page 中输入 /，看到了表格、提示、文件、页面和聊天等入口。在“证据矩阵”里用表格放证据与事实关系；在相关判断旁插入 Chat 关联，虚构文件上传后也加入了文件链接。这些是来源入口，方便回到材料，并不自动构成法律文书中的精确引证。影响判断的关键事实，还要进一步记录文件名、页码、段落或其他可复核位置。

例如，关于“通知是否送达”，矩阵不能只贴一份《通知书》就写“已送达”。这一行至少应写清：当前状态为待核；现有示例文件只能说明制作过一份书面通知；送达记录尚未提供；下一步是调取发送记录或签收材料。

图：Page 的菜单让表格、提示和来源引用进入同一张工作页。

我还在页面上放了一个“检查结论是否超出事实支持”的 Prompt，点击“发送至聊天”。它指出了四处待核问题，其中一处很典型：材料只写“书面通知”，页面却一度把它当成“解除通知”；内容、发出和送达也没有证据支持。Prompt 没有替我作法律结论，它先把事实与判断之间的跳步暴露出来。

最后，选中一句需要调整的话，点击“提出修改要求”，输入修改意图，审阅界面给出的差异，再决定是否采纳。这和我在飞书文档里用评论纠正 Agent 的经验相通：人把问题指向具体文字，Agent 给出改法，人负责定稿。本次 Page 实测走通的是选中文字后的修改与审阅，尚未测试飞书式的完整评论协作循环。

图：Agent 提议修改，法律人审阅后才决定是否采纳。

同样的方法可以迁移到合规评估。下面是一套可照着搭建的示例结构，本轮没有用真实评估材料执行。

假设要评估一款 APP 上线前的隐私合规问题。Project 中分别放产品需求、页面截图、数据流、SDK 清单、隐私政策和业务访谈；Chat 分开做事实抽取、事实缺口、适用要求、风险和整改建议。

Page 则维护一张“隐私评估工作页”，用表格记录：

这里最重要的改变，是先维护评估底稿，再形成对外报告。业务方补一张页面截图，可能改变一个事实；事实改变后，再看对应要求和结论。Page 帮助人和 AI 回到同一张当前底稿，而不是每次都让 AI 从零生成一份“最终报告”。

一张 Page 能讲清楚的事项，不必急着建 Space。比如一次范围明确的法律研究，有一张工作页，附上材料与待核问题，就可以开始。

当事项长出多张需要长期维护、相互关联或共同协作的页面——案件总览、事实时间线、证据矩阵、法律研究、庭审准备——Space 才体现价值。我打开本次测试的 Space 时，可以看到根页面和“示例案件总览”“示例证据矩阵”两张子页面；总览页还链接到矩阵页。

图：Space 组织一组持续更新的成果页，Page 承载每一项具体成果。

官方还支持分享 Page 或 Space，允许协作者按权限查看、编辑和评论。Page 的访问权也可能来自父页面或所在 Space；把 Page 放进共享 Space，和只分享这一张 Page，涉及的访问范围不同。处理客户事项时，分享前要检查上层继承权限、页面内容和附件。OpenAI 的 Space 协作说明 本次我只查看了分享入口，没有邀请团队成员；因此团队共同维护的效果在本文是官方功能说明与工作方法推演，不是这次实测的结论。

飞书文档已经能承载我和 Agent 的评论、修改往返。Page 不需要靠“编辑能力更强”来证明价值。它更值得观察的，是页面与 ChatGPT 的关系：可以从对话提炼 Page，可以从 Page 发起新的讨论，页面里能留下来源和可再次运行的 Prompt，局部修改也能回到具体文字上。法律人因而有机会直接参与中间工作底稿，而不必只看最终 Word、再靠对话指挥 Agent 修改那些 Markdown 文件。

这意味着 Chat 不必消失。Chat 仍适合探索、质疑和试错；Page 则承担经确认的当前成果。对于法律工作，理想的循环是：

一是把 Space 当成所有案件都要先建的容器。一张 Page 足够时，就先维护好这一张。

二是把 Chat 原样转成 Page。聊天保存探索过程，Page 应当留下经过核对、目前仍有效的内容，也标出未解决的问题。

三是把有引用等同于来源已核实。文件链接、聊天记录和 AI 摘要能帮助回溯；事实是否成立，还要回到材料本身。

四是让 AI 静默更新法律结论。页面可以持续修改，但新材料与旧判断冲突时，需要明确指出变化并由人审阅。

五是把所有“法律内容”都按案件处理。开发法律 Skill 或拿案例跑能力测试，目标是改进通用能力；它需要文件、测试和版本记录，不能只靠一张 Page 说明“已经完成”。

六是忽略 Space 的访问权限。Page 可能继承父页面或 Space 的访问权；分享前要看清谁能查看、编辑或评论，尤其要区分分享单页与分享整个 Space。

这个结构让长程任务同时留下过程和成果。Project 与分题 Chat 保留材料、规则和讨论脉络；法律人确认后，Page 记录当前有效的工作状态。新材料出现时，下一轮分析能找到此前的讨论，也能看清哪项结论需要更新。复杂事项再用 Space 组织多张 Page，正式文书则从经过复核的底稿形成。

所以，Space 和 Page 是不是多了一个“飞书文档”？从界面上看，它确实补上了可编辑、可协作的页面；从法律工作的角度看，更重要的是把“看底稿、改文件、留意见”接回 AI 持续处理事项的过程。法律 AI 工作台既保存讨论如何发生，也保存工作推进到了哪里；既有过程，也有成果。