站点设置只能有一份：Sanity 单例与媒体库之后的内容基础设施验收
单例（singleton）是指导航、站点设置、首页这类「系统里只应存在一份」的文档类型。结合 Sanity 2026 年 11 月 9 日正式发布说明，以及 Media Library 与组织级活动导出文档，本文按 DAM·Knowledge Base·CMS/Website 给出验收与 30 天清单：先在系统层锁住唯一类型，再划清资产库的写边界，并把审计范围写清楚。
浏览 4
巴克励步
单例（singleton），指的是导航、站点设置、首页这类在系统里「只应存在一份」的文档类型。Sanity 在 2026 年 11 月 9 日发布的 Hello November: Singletons, Media Library + MCP server, App SDK TypeGen, and activity feed export 里，把它升级为一等公民能力（目前为 beta），并把组织级 Media Library 的写入通道、以及选定 Enterprise 方案上的 Activity Feed Export 放到同一个发布窗口。
这三条信号合在一起，给出的不是「要不要再买一个媒体库」，而是更硬的验收题：体验配置必须在系统层锁成唯一份；资产库一旦对自动化开放，就要分清哪些写入进草稿、哪些立即生效；组织级活动导出也并不自动覆盖文档与资产变更。 本文把它映射到 Baklib 所强调的三层职责——数字资产管理管资产、知识库管已审批知识、CMS/Website 管体验——并给出跨品类选型与 30 天落地清单。它与近几篇「解耦并不消灭工作量」「工作面可以多态，真相源不能分裂」「隔离的是内容空间，不是资产库」互补：那几篇分别讨论解耦后谁来接手预览与路由、多工作面如何共用资产真相源、环境隔离不要误伤资产库；这篇讨论当唯一类型和工作面上的资产写入同时被产品化时，验收应当先锁什么、再开放什么。
一、单例要靠系统登记，不能靠隐藏按钮
11 月 9 日的发布说明把单例写得很直白：它是 exactly one instance 的文档类型，典型例子就是导航、站点设置和首页。在此之前，Studio 仍会在这些类型上提供「添加」和「复制」，团队往往自己写代码去隐藏按钮；一旦这段代码失效，或者根本没人写过，编辑就可能得到第二份站点设置。
官方做法是在 Studio 配置的
document.singletons 中登记这些类型。登记之后，Studio 会隐藏面向多文档的界面，并把该文档呈现在结构构建器中。Sanity 在 站点设置单例指南 中补充了更细的产品行为（该能力自 Studio 6.17.0 起提供专用 API）：- 单例配置写在 Studio 配置里，而不是写在 schema 类型上；schema 本身仍是普通文档类型。
- 登记后，系统会为该单例生成专用初始值模板，并把它从所有可创建文档的入口拿掉，包括全局创建菜单、结构面板和引用输入。
- 系统会移除「复制」文档动作，默认内容列表不再把该类型当成普通列表，并在编辑器中加上 “Singleton” 徽章。
- 若团队已经用自定义代码或第三方插件做过单例，官方提供迁移技能，把它迁到一等公民 API；旧的手工接线方式仍然可用，现有实现不必立刻重写。
对买家更有用的，不是这段配置怎么写，而是它暴露的验收原则：「这份设置只能有一份」必须是平台能力，而不能是界面上的约定。 靠 CSS、权限口头约定或临时隐藏按钮，都不能保证引用输入和复制动作不会再造出第二份。
二、媒体库进入同一工作面：先分清草稿与立即生效
同一篇发布说明的第二条，是 Sanity MCP server 现在可以在组织已启用 Media Library 的前提下操作这份媒体库。官方列出的能力包括：从公开 URL 或本地文件上传资产（上限 50 MB）；按 aspect、类型、文件夹或标题查询；编辑标题与 aspect 值（保存为草稿）；以及变更可见性和集合（立即生效）。写入会对照媒体库 schema 做校验，并以登录用户的权限执行。工具不能删除资产或集合、不能改 aspect 定义、也不能把资产放进文件夹，从而限制误操作的爆炸半径。
配套文档 Use Media Library with AI agents 把写边界写得更清楚，这也是验收时最该盯住的部分：
- 媒体库属于组织，而不是单个项目。 账号必须是组织成员且对库有相应权限；工具只能看见或更改该账号本身看得见、改得了的资源。
- 标题和 aspect 值的修改一定进草稿，不会直接写到已发布资产。团队可以在 Media Library 应用里审核，再选择发布或丢弃。
- 可见性（公开/私有）变更会立即生效，不创建草稿。 集合的创建、改名和收纳资产同样立即生效。
- 在替换资产前，可以列出组织内各项目中引用该资产的文档，避免「换了一张图，却不知道哪些页面还指着旧文件」。
- 每次写入都会先对照库的 schema（含 aspect 定义）校验；不合法则拒绝写入。版本历史、资产类型、只读 aspect 以及删除资产/集合，都不在可改范围内。
这里的要点不是「自动化能不能上传一张图」，而是：资产层一旦对工作面开放，就必须把「进草稿的写」和「立即生效的写」列成动作目录，并指定谁来确认。 可见性和集合会立刻改变资产的可达范围与分组，若把它们和标题润色当成同一类操作，治理会在第一周就出现缺口。
三、可导出的审计，并不等于内容变更审计
第三条信号是 Activity Feed Export 在选定 Enterprise 方案上正式可用。根据发布说明与 导出文档：组织管理员在 Manage 的 Settings > Activity feed export 中连接自有 Google Cloud Storage 存储桶，并授予页面显示的服务账号 Storage Object Creator 角色后，Sanity 会在每个整点后 5 分钟（UTC）开始导出上一个完整小时的管理活动。文件为 gzip 压缩的 NDJSON，字段映射到 OCSF 1.9.0，每个批次带有事件计数和 SHA-256 校验清单。
覆盖范围同样写得很明确：成员与角色变更、API 令牌生命周期、安全配置，以及项目与数据集管理。文档和资产的内容变更不在范围内。官方限制条款还指出：导出不包含文档或资产的创建、编辑、发布、取消发布、删除、读取或下载；目的地目前是 GCS，不提供原生 SIEM 连接器；记录可能重复或乱序，需用
metadata.uid 去重；接入目的地也不会自动补齐历史导出。这正好构成一条容易被忽略的验收项：有了组织级活动导出，并不等于你已经拥有内容与资产变更的审计轨迹。 采购和安全团队应把它与项目级日志、内容版本历史分开盘点，避免在合同和内控清单里把「管理活动可导出」误写成「全部变更可追溯」。
四、映射到 DAM · Knowledge Base · CMS/Website
平台视角下，11 月这组发布并不是三个彼此无关的功能点，而是同一套内容基础设施的三道门闩：
- CMS / Website 管体验，也管「只能有一份」的体验配置。 站点标题、导航、首页、全局 SEO 与页脚不属于可以平行增殖的内容类型。它们应在 CMS 里被系统级登记为单例，从创建、复制和引用入口一并收住。这与站内对 内容管理系统 和 DXP 的理解一致：体验层既要装配页面，也要保证全局配置不会分叉。
- DAM 管资产。 组织级媒体库是主视觉、产品图、演示视频和可下载文件的真相源。对工作面开放查询、引用和上传可以减少「打开应用才能改标题」的摩擦，但批准态、版权/aspect 信息、可见性以及引用关系仍属于资产治理，而不是编辑器里的临时字段。立即生效的可见性与集合变更，更应被当成权限事件，而不是普通润色。这与站内 DAM 定义一致：资产要可搜索、可权限、可版本、可复用。
- Knowledge Base 管知识。 产品口径、品牌主张、对比说明和政策条文，不应因为站点设置或资产元数据里也能写两句，就在三处各留一份。单例锁住的是体验配置，媒体库锁住的是资产及其方面值；可引用的主张仍应先在知识库形成审批态，再被官网、资源中心与帮助中心引用。
用一句话概括：先锁住唯一类型，再开放资产写入；先写清审计范围，再把自动化放进生产路径。 这也是 Content Ops 要统一的地方——工作面可以变快，但站点设置、批准态资产和已审批口径不能各自长出第二份。
五、内容基础设施验收清单
下面清单不绑定某一家供应商，但每条都能对照 Sanity 11 月 9 日发布说明及其公开文档自检。
- 盘点必须唯一的类型。 站点设置、导航、首页、全局活动页是否在系统中登记为单例，而不是靠隐藏按钮或口头约定？
- 关闭第二份的入口。 创建菜单、结构列表、引用输入和「复制」动作是否都被拿掉？抽检一次：普通编辑能不能再新建或复制出第二份站点设置。
- 把资产写入分成两本账。 哪些动作进草稿（如标题、aspect），哪些立即生效（如可见性、集合）？立即生效的动作由谁确认、如何回滚？
- 替换前先看引用。 更换 Logo 或主视觉前，能否列出哪些文档/站点仍引用该资产？没有引用视图就不要开放批量替换。
- 权限跟账号走，而不是跟脚本走。 自动化或编辑助手只能看见账号本身有权看见的库和字段；组织级媒体库的成员资格要单独盘点。
- schema 校验是写入的前门。 不合法的方面值应被拒绝，而不是事后清理。只读方面、资产类型和删除权必须保持关闭。
- 分清两类审计。 组织管理活动（成员、角色、令牌、安全配置、项目/数据集）能否导出到自有存储，格式和校验清单是否可被安全团队接收？文档与资产的创建、编辑、发布、删除是否另有版本历史或日志，而不是误用管理活动导出顶替。
- 口径不要写进三处。 站点设置里的品牌一句话、资产描述里的卖点和知识库里的主张，必须有唯一审批源。
六、30 天落地清单
- 第 1 周：锁唯一类型。 列出官网、多语言站点、资源中心里所有「只应有一份」的配置文档，在现有 CMS 中完成系统级登记或等价约束，并做一次「新建/复制」反例测试。
- 第 2 周：画出资产写边界。 对照媒体库文档，把查询、上传、改标题、改可见性、改集合、看引用、链接到页面分成「草稿」和「立即生效」两列，补上确认人和回滚办法；能关的删除与定义变更权先关上。
- 第 3 周：跑通一条真实样例。 选一次主视觉或产品图更新：从入库、补全 aspect/版权、草稿审核、检查引用，到在 CMS 页面中引用已批准资产，记下仍靠网盘直传或口头确认的步骤。
- 第 4 周：对齐审计范围。 向现有或候选平台确认：组织管理活动如何导出、覆盖哪些事件、是否包含内容与资产变更、目的地与保留策略由谁控制。把缺口写进验收表，而不是写进「已经有日志」的空勾选。
七、收束：唯一性是能力，不是约定
Sanity 2026 年 11 月 9 日的公开发布，并没有改变内容基础设施的基本分工，只是把三件长期靠变通来完成的事产品化了：用系统登记锁住单例，让组织级媒体库可以在受 schema 和权限约束的前提下被工作面使用，以及把组织管理活动导出到买家自己的存储桶。对采购和运营团队，真正要带走的验收语很短——站点设置只能有一份；资产写入必须分清草稿与立即生效；可导出的管理日志，替代不了内容与资产变更审计。
若你正在评估 Headless CMS、DAM 与官网体验层如何协同，可以用「唯一类型有没有被系统锁住、资产写边界清不清楚、审计范围有没有被说破」做验收题，而不是只问「能不能自动改标题」。Baklib 的产品方向，正是让资产可管、知识可复用、体验可运营，在同一内容基础设施里把这三道门闩收在一起，降低「界面上看起来只有一份、库里却已分叉」的风险。
想要了解更多?
数字内容新基建白皮书
常见问题
什么是单例文档类型？
指导航、站点设置、首页这类「系统里只应存在一份」的文档类型。Sanity 在 2026-11-09 的发布说明里把它定义为 exactly one instance，并提供一等公民配置（目前为 beta）。
为什么不能继续靠隐藏「新建」按钮？
在官方支持之前，Studio 仍会提供「添加」和「复制」；若自定义隐藏逻辑失效或从未写过，编辑就可能得到第二份站点设置。系统级注册才能从创建菜单、结构面板和引用输入里一并拿掉这些入口。
Media Library 对自动化开放后，哪些写入是草稿、哪些立即生效？
按官方文档：标题与方面（aspect）值的修改会保存为草稿，需在媒体库中审核后再发布或丢弃；可见性（公开/私有）和集合（collection）的变更会立即生效，不创建草稿。
Activity Feed Export 能代替内容变更审计吗？
不能。该导出覆盖成员与角色变更、API 令牌生命周期、安全配置以及项目与数据集管理等管理活动，文档和资产的创建、编辑、发布、删除等不在范围内。
30 天内最该先做什么？
先盘点站点设置、导航、首页等必须唯一的类型，并在系统层锁住；同时列出资产写入里「进草稿」与「立即生效」的动作目录，补上内容层自己的变更审计，而不是把组织管理日志误当成内容审计。
