1 这是什么(以及不是什么)
内容基础设施层,而非网站重新设计
这是什么(以及不是什么)
内容基础设施层,而非网站重新设计
范围与目的
两个咨询团队正在参与SCA的数字化建设。本文件的目的是让两个团队都能看到全貌并协调工作——而非主张某一方案优于另一方案。
一个内容基础设施层——定义SCA机构数据结构的模式(schema)、从Webflow迁移到该结构中的内容,以及将内容连接到运营工作流的自动化系统。
这是后端和数据工作。没有进行前端设计。目前存在的Astro网站是一个参考实现——它通过渲染内容来证明内容层可以工作,但它不是最终设计。Shawn团队或任何其他人所做的设计都可以通过API使用相同的结构化数据。
- 不是网站重新设计——没有进行视觉设计工作
- 不是主张Sanity优于WordPress——两者可以共存
- 不是永久员工的工作——Ed的团队和Shawn的团队都是咨询团队;无论如何,学校拥有数据所有权
- 没有锁定——Sanity特定的代码约200-300行查询和客户端配置;如果领导层决定转向WordPress + ACF,模式、内容和自动化方案可在1-2周内迁移
本项工作基于一个论点:将内容组织为结构化数据的学校会获得复合优势。每一条内容都变得可查询、可自动化、可被AI系统访问。每个月持续的数据输入都在积累无法后期快速补上的机构记忆。
这是工作背后的论点。它是否是SCA当前的正确优先事项——这是领导层的决定。本文件披露现有成果,以便该决定能够基于充分信息做出。
内容层采用API优先设计。任何前端——WordPress、Astro、自定义React应用、移动应用——都可以通过GROQ查询或GraphQL从同一数据源获取结构化内容。数据层不关心由什么来渲染它。这意味着设计决策和基础设施决策是解耦的:Shawn的团队可以自由设计而无需等待内容层,内容建模也可以继续进行而无需等待设计。
Ed是一位在结构化内容与AI时代运营交叉领域工作的内容管理从业者。他对维护传统WordPress网站没有兴趣——他的价值在于内容基础设施、模式设计和自动化。这是领导层需要了解的背景:它解释了这项工作的雄心和依赖关系。如果SCA希望维护这套基础设施,就需要具有这种专业方向的人。如果不需要,数据是可移植的。
2 目前已有什么
对已建成、进行中和未开始内容的诚实清单
目前已有什么
对已建成、进行中和未开始内容的诚实清单
当前状态
截至2026年2月核实。这是实际存在的内容——不是路线图。
Sanity CMS,已定义12种文档模式和3种对象类型:
- 文档类型:page(页面)、person(人员)、program(课程项目)、news(新闻)、event(活动)、alumniStory(校友故事)、department(部门)、mediaGallery(媒体库)、boardingFeature(寄宿特色)、admissionsPath(招生路径)、studentProject(学生项目)、siteSettings(网站设置)
- 对象类型:seo(搜索优化)、announcement(公告)、socialLink(社交链接)
这些模式定义了SCA机构数据的结构——存在哪些字段、内容类型之间如何关联、以及执行哪些约束。
- 9个信息页面——已转换为Sanity中的Portable Text格式
- 7个学术课程——包含描述、师资链接、要求等结构化字段
- 13篇新闻文章——带有日期戳、分类和来源追踪
- 87张图片——已上传至Sanity CDN并建立资产引用
教师数据尚未从Webflow中提取。这确实是未完成的部分。
GAM(Google管理)代理从Sanity记录中自动为学生创建Google Drive文件夹。它在专用服务器上由systemd监督运行,可移植到Google Cloud。这是正在运行的系统——不是原型。
部署在Vercel上的Astro网站(web-beta-lilac-27.vercel.app),拥有15个使用SSR动态内容的工作路由。这是一个证明内容层可以工作的参考实现。它具有功能性但没有设计——没有应用视觉设计、品牌或用户体验工作。新路由需要重新部署。
| 组件 | 状态 |
|---|---|
| Sanity模式(12文档 + 3对象) | 已完成 |
| 内容迁移(页面、课程、新闻) | 已完成 |
| CDN上的图片资产 | 已完成 |
| GAM自动化(Drive文件夹) | 已完成 |
| Astro参考网站(15个路由) | 已完成 |
| 教师数据提取 | 进行中 |
| 新路由的生产部署 | 进行中 |
| 前端设计 | 未开始 |
| 自定义域名 | 未开始 |
3 两个团队如何并行工作
内容建模与网页设计独立推进,通过API连接
两个团队如何并行工作
内容建模与网页设计独立推进,通过API连接
并行工作流
两个团队都不需要等待对方。内容建模和数据导入独立于设计进行。网页设计和前端开发按自己的时间表推进。它们通过API连接。
- 模式优化和新内容类型
- 从Webflow迁移内容
- 自动化(GAM、工作流)
- 为任何消费者提供API端点
- 视觉设计和品牌
- 前端开发(WordPress或其他)
- 用户体验和导航
- 准备就绪时从API获取内容
Sanity通过两个接口公开所有内容:
- GROQ查询——Sanity的原生查询语言,当前Astro参考网站使用
- GraphQL API——任何系统都可以使用的标准接口,包括WordPress
WordPress可以将Sanity作为无头后端来获取结构化内容。两个系统也可以共存——WordPress管理自己的内容,同时在需要时从Sanity获取结构化数据。内容层服务于最终发布的任何前端。
- Shawn的团队可以在不接触或依赖Sanity的情况下构建WordPress网站
- Ed的团队可以继续建模内容和构建自动化,无需等待设计
- 当双方都准备好时,连接它们是一项集成任务——通过API调用将结构化数据拉入模板
- 如果领导层决定完全使用WordPress,结构化内容可以迁移到WordPress + ACF。内容建模工作不会浪费——模式可以直接转化为自定义文章类型和字段组
Sanity特定的代码约为200-300行GROQ查询和客户端配置。模式本身是平台无关的概念——"一个课程有名称、描述、教练引用和大学录取摘要"在任何CMS中都适用。内容可以导出为JSON。自动化模式(事件驱动工作流、受监督的代理)是基础设施概念,不是Sanity的特有功能。如果领导层决定整合到WordPress,迁移需要1-2周。这项工作比看起来更具可移植性。
Ed的团队和Shawn的团队都是咨询团队。都不是永久员工。无论使用哪个系统或由谁维护,学校拥有其内容和数据的所有权。本文件是确保所有权明确的一部分,同时确保基础设施有足够的文档,以便任何人都可以接手。