网站迁移 — 内容架构

在 Webflow 中，一篇新闻文章是一个视觉布局。而在结构化内容系统中，一篇新闻文章是数据：它有标题、发布日期、正文、分类、作者和图片——每个都是独立的、有类型的字段。同一篇文章可以在网站上渲染、出现在电子邮件通讯中、响应API查询，或被AI助手读取。内容只需编写一次，就可以在各处使用。

我在 Sanity CMS 中定义了12种文档类型和3种可复用对象类型，对 SCA 的运营进行建模。文档类型是主要内容——页面、新闻、项目。对象类型（SEO元数据、社交链接、公告）是嵌入在多种文档类型中的可复用结构，确保一致性。完整模式详情见附录。

这些类型之间有关联关系——项目可以引用其教练（人员），人员属于某个部门，页面有父子层级。这就是使数据可以以扁平页面无法实现的方式进行查询的关键。

四个架构决策塑造了这项工作。这些反映了SCA的机构需求——如何在WordPress中最佳实现，正是平台专业知识的发挥之处。

1. 使用 Sanity 作为内容层。Sanity 提供实时API、代码定义的类型化模式，以及编辑人员无需开发人员帮助即可使用的内容工作室。内容可通过HTTP访问——任何能发送GET请求的系统都可以读取。
2. 使用 Astro 构建参考前端。我构建了一个有意简约的参考网站来验证内容层的工作效果。它将所有结构化数据渲染为真实页面，但视觉设计有意退居次要——因为架构使数据和展示完全独立。任何前端都可以用不同的设计消费相同的内容。
3. 先提取内容再重建。我没有手动重新创建内容，而是程序化地从 Webflow 网站提取了所有内容——页面文本、项目描述、新闻文章、图片——并以结构化数据的形式导入 Sanity。这项工作无需重复。
4. AI可读设计。网站输出静态HTML，包含JSON-LD结构化数据和语义标记。阅读任何页面无需JavaScript。任何具有网络访问能力的LLM——ChatGPT、搜索引擎爬虫、潜在家长的AI助手——都可以直接解析内容。公开API意味着AI代理也可以程序化查询学校数据。

以此作为范围参考。绿色 = 同等或更好。黄色 = 部分完成（数据模型存在，前端未完成）。红色 = 未开始。当前网站不具备的新功能单独标注。

12种内容类型可直接转换为WordPress Custom Post Types + Advanced Custom Fields（或等效方案）。每种类型都有定义好的字段和关联关系：

• 项目（Programs）含类别、级别、描述、教练引用、升学数据 → CPT + ACF字段 + Person关联
• 人员（People）含角色、简介、部门引用 → CPT + 分类法或关联字段
• 页面（Pages）含父子层级、富文本、SEO字段 → 原生WordPress页面 + 自定义字段
• 新闻、活动、学生项目、校友故事 → 各为独立CPT，使用类型化字段而非自由排版的页面构建器内容

所有字段和关联关系的完整模式详情见附录。这可以作为CPT注册和字段组设置的起点——欢迎基于WordPress实施经验提出优化建议。

• 所有文本内容已从Webflow程序化提取——页面文本、项目描述、新闻文章——存储为结构化数据。可直接导入WordPress或通过API消费。
• 87张图片已下载并托管在Sanity CDN。可重新导入WordPress媒体库。
• WordPress可以直接实现此模型（CPT + 字段），与现有内容API集成，或采用混合方案——欢迎提出最佳方案建议。

• Google Drive自动化。学生项目系统在创建项目时自动配置Drive文件夹。独立于网站前端。
• 编辑工作流。来源追踪（手动、Instagram、外部）和导入内容QA标记。
• 新内容类型（校友故事、媒体画廊、寄宿特色、招生路径）模式已定义但尚无内容。

• 联系表单——需标准WordPress表单实现。
• Gradelink集成——网站设置中已有URL字段；注册按钮需连接到前端。
• 教职工数据迁移——需手动导入或针对Webflow照片网格格式的自定义解析方案。模式已准备好接收数据。
• 图片关联映射——资产已提取并托管；与特定内容条目的关联将在WordPress迁移期间完成。
• 社区/参与页面——后端模式完成；前端实现待设计决策。

无论从基础阶段还是基础设施阶段开始，目标是可演进的架构。基础阶段（专业网站展示）是可行的起点，前提是能够在不推倒重来的情况下迁移到基础设施阶段（结构化内容）。需要管控的具体风险不是页面构建器本身，而是内容被锁定在专有短代码或特定布局格式中，导致后续无法干净提取。我不执着于任何特定的WordPress模式——重要的是内容保持可移植性。

构建Custom Post Types + 自定义字段，复制12种内容类型。内容直接导入WordPress。Sanity作为内容模型的参考；WordPress全面接管。

• 标准WordPress架构：CPT + ACF（或等效方案）+ 模板
• 内容从Sanity导出导入或手动重新录入
• 模式设计、字段定义和关联关系已记录，可直接实现
• 所有前端工作（主题、表单、插件、SEO）在WordPress中完成

这代表基础设施阶段路径。内容模型定义了"项目"、"人员"和"活动"对SCA的含义，使WordPress构建从清晰的数据架构开始，而非从空白开始。如果从基础阶段使用常规主题开始，架构应将内容保存在标准WordPress结构中（文章、页面、原生字段），而非嵌入页面构建器短代码或专有块格式——这样迁移到CPT时是数据操作，而非内容重建。一个值得讨论的问题：是否存在WordPress直接消费Sanity API更合理的场景，还是原生CPT实现更适合SCA的需求？欢迎对此提出意见。

以下是希望获得专业意见的领域：

• 鉴于这些内容关联关系，WordPress架构建议
• 平衡编辑易用性与结构完整性的方法
• WordPress内容可导出性的最佳实践
• 如从基础阶段开始：哪些主题架构最有利于未来迁移到CPT？如从基础设施阶段开始：推荐的CPT架构方案
• 自定义字段的标准方案：ACF、块，或其他选项
• 性能/SEO基线：Core Web Vitals、图片、缓存

Angelene对SCA AI优先定位的愿景可以通过渐进阶段实现，具体取决于实施范围和时间线：

基础阶段聚焦于专业网站展示，包括视觉优化、移动端适配和基础内容管理。内容通过成熟的WordPress主题呈现。此阶段可以使用页面构建器工具快速部署，但前提是内容将在基础设施阶段迁移到结构化CPT。目标是可桥接的架构，而非永久的页面构建器依赖。这可以立即交付机构价值，并为未来增强做好准备。

基础设施阶段实现本文档中描述的完整结构化内容模型——CPT配合定义好的字段、内容类型之间的可查询关系、API可访问性，以及AI就绪架构。这将实现自动化内容工作流、多渠道发布，以及区分SCA定位的完整AI优先能力。

两个阶段都服务于SCA的发展旅程。问题是现在就实施完整的基础设施，还是先建立基础，在后续阶段演进到完整结构。

以下描述SCA基础设施阶段的目标——完整的结构化内容架构。这些并非全部是第一阶段的要求。基础阶段可以使用常规主题和人工维护作为可行的起点，逐步向目标架构演进。目标包括：

• 内容以结构化数据存储。CPT配合定义好的字段。一个"项目"有名称、类别、教练和描述作为独立的可查询字段。
• 内容类型之间的关联关系可查询。项目引用其教练（人员）。人员属于部门。页面有父子层级。这些连接必须在代码中可导航。
• 内容可导出、可移植。如果SCA未来更换平台，所有内容和关联关系都能干净地提取出来。
• AI可读输出。静态HTML配合语义标记和结构化数据（JSON-LD）。解析内容无需JavaScript。这是潜在家长的AI助手、搜索引擎和SCA自身AI工具与网站交互的方式。

我不打算指定WordPress的实施细节——那是平台专业知识的领域：

• 主题架构、插件选型、托管环境
• 自定义字段方案——ACF、原生块，或其他模式
• 编辑工作流和内容管理用户体验
• 性能优化、缓存策略、部署流程

为确保满足SCA的机构需求，以下是我希望我们达成一致的成果。实施选择将决定如何在WordPress中实现这些目标：

• 教职工、项目、新闻和活动从结构化数据模板驱动生成——而非手动组装的页面
• 内容关联关系得到保留（项目→教练，人员→部门，页面层级）
• 网站渲染语义化HTML，AI工具和搜索引擎无需执行JavaScript即可解析
• 内容可随时导出为JSON或其他可移植格式

本文档描述的结构化内容架构的价值不仅限于当前的网站迁移。一旦内容以类型化、关联性数据存储：

• AI工具可直接查询机构内容——回答家长问题、生成营销材料、支持招生工作流
• 内容可从单一来源发布到多个渠道（网站、移动应用、印刷材料、社交媒体）
• 机构知识作为可查询数据保存，而非锁定在页面布局中
• 未来平台迁移变为数据迁移，而非内容重建

无论基础设施阶段何时实施，这些能力都将可用。架构是前提条件，时机是组织决策。

我提供内容架构、业务需求和AI就绪战略。实施专业知识指导WordPress特定决策。如果基础阶段是起点，我可以确定哪些当前决策有助于日后向基础设施阶段过渡。我的首要任务是确保我们不会关闭通向Angelene完整愿景的大门。

每种文档类型都是具有类型字段和关系的结构化内容定义。您可以通过公共API查询其中任何一种（见下方试用API）。

这些是嵌入在文档类型中的可复用结构——不是独立内容。它们确保系统的一致性。

系统中现有的实际内容（实时数据，可通过API查询）：

内容API对读取操作是公开的。您可以将这些URL粘贴到任何浏览器中查看实时数据。无需设置、无需令牌、无需插件。

这是标准HTTP。WordPress可以用wp_remote_get()消费这些端点。任何支持HTTP的语言都可以使用。

参考前端使用设计令牌——颜色、排版和间距的命名值——而非临时样式。这是一个起始词汇表，而非完整的设计系统。价值在于方法本身：令牌可以映射到任何CSS框架、WordPress主题或设计工具，AI工具可以系统性地迭代。更改视觉设计无需更改内容。

要查看所有实际效果：访问参考网站。设计系统以CSS自定义属性（设计令牌）实现——任何开发者都可以在浏览器的DevTools中检查它们。

对于熟悉WordPress的开发者，以下是Sanity概念的对应关系：