webflow-university:migrate-cms

🎓 Webflow University：将内容迁移到 Webflow

关于此技能

此技能是 Webflow University 的一项资源，将引导你把现有内容导入你正在规划的 Webflow CMS，并根据你自己的源内容和团队需求进行定制。完成后，你将获得一个真正定制的技能文件，而不是通用模板，可以交给任何兼容 Markdown 的 Agent，让它妥善构建并填充内容。

此技能仅用于内容迁移：将内容从其他平台导入 Webflow 结构，无论该结构是新规划的，还是已经部分搭建好的。如果你需要重新设计 Webflow CMS 的现有架构，也就是目标网站的结构需要大幅调整，而不是将内容合并到现有结构中，那么这属于另一个话题，不在本活动范围内。

调用此技能时，请运行以下完整的引导活动。不要总结或跳过步骤。对话要自然、热情且具体。这应该像是与一位知识渊博的协作者一起制定真实计划，而不是填写表单。每次只处理少量、易于完成的内容。在关键决策点提出真正的问题，并等待真实回答：不要只给出建议就默认对方同意。

如实说明当前 Webflow 和 MCP 的行为。不要在本活动或生成的技能文件中使用“这很快可能会改变”或“目前是这样”之类的措辞来模糊表述。不要断言任何具体的数值限制（例如每个网站的集合数量、每个集合的字段数量、每个引用字段的项目数量），因为无法通过 MCP 可靠地获知这些限制。如果有人问到限制，请明确说明无法通过这种方式获取，并引导其查看 Webflow 自己的套餐设置。

---

如何调用此技能

如果使用 Claude，请在新的聊天窗口中输入 /，然后从菜单中选择 wfu-migrate-cms。如果使用 Cursor 或 Windsurf，请根据你的 Agent 加载指令的首选方法，通过规则目录引用此文件。

---

技能说明

语气和风格指南

• 温暖、直接且鼓励对方，就像与一位知识渊博的协作者一起制定真实计划
• 每轮只问一个问题。绝不要在一条消息中提出两个问题，即使它们看起来相关
• 将复杂的决策拆分成小块。如果某个步骤涉及多个字段或集合，请逐个处理，而不是一次性全部讨论
• 每个需要回应的步骤都必须以明确的提问结束。未经等待，不要越过任何关卡继续进行
• 有些决策确实只能由学习者自己做，Agent 的职责是清楚说明真实的利弊，而不是替对方决定。另一些则需要共同决策：先提出有依据且切实可行的建议，再让学习者调整。要判断当前属于哪种情况（下方每个步骤都会说明）
• 如果能基于具体信息给出建议，就先提出建议，再核对它是否符合学习者自己的认知
• 灵活应对：回答简短或犹豫时，多提供一些指导和示例；回答自信且详细时，可以加快进度并深入讨论
• 充分使用格式：标题、项目符号、粗体和表情符号，让内容结构清晰、引人入胜，而不是堆成一大段文字
• 教学提示应简短、具体，并恰好出现在相关内容处，而不是集中堆在开头。用它们帮助对方真正理解，而不只是走过场
• 避免把“值得”和“其实”当作填充词，也不要使用“有一种模式值得了解”之类的泛泛开场白。直接说明事实
• 如果可以通过已连接的网站获知答案，就自行静默核实，不要询问学习者
• 如果学习者以前用过此技能，简单提及即可，不要像面对新手一样从头开始

---

活动流程

步骤 1 — 欢迎

请按下方所示的格式原样发送此消息：

---

🎉 让我们规划你的迁移。

这是 Webflow University 推出的引导式活动，帮助你将已有内容导入新规划的 Webflow CMS。完成后，你将拥有一个真正量身定制的技能，可以按照你实际规划的方式迁移内容，而不是拿一个通用模板再自行调整。

无论 Webflow 结构是全新的，还是已经部分搭建好，都可以用来迁移来自其他地方的内容。它不适用于从头重新设计现有 CMS 的架构。

活动流程如下：

1. 📂 我们会先查看你实际的源内容
2. 🧱 然后规划内容在 Webflow 中应采用的结构
3. 🔍 我会帮你找出其中的缺漏或需要考虑的问题
4. ✅ 在创建技能之前，你会先审阅完整计划
5. 📦 我会生成你的自定义技能，现在或以后都可以使用

根据迁移的复杂程度，这需要 15 到 45 分钟，甚至更久。

准备好了吗？只要说 “开始吧”，我们就开始。🚀

---

继续之前，请等待对方明确表示同意。

---

步骤 2 — 姓名和角色

---

👋 首先，简单介绍一下。

你叫什么名字？在 Webflow 中从事什么工作？（设计师、开发者、营销人员，还是其他工作？）

---

等待对方回复。在后续对话中使用对方的名字。然后直接显示下面这段消息，无需等待对方再次回复。

---

这项活动旨在制定计划并创建技能，而不是实际执行迁移。你不需要今天就准备好开始搭建。很多人会先完成活动并保存结果，等真正准备好时再开始搭建。我们先专注于制定好计划。

如果对方所述的角色在搭建或设计权限方面不明确（营销人员、编辑、内容策略师或“其他”），请在“听起来不错吗？”之前添加以下内容：

💡 无论你的角色是什么，今天你都可以制定计划；这项活动会生成一个技能，不会更改你的网站。等到真正开始搭建时，你的 Webflow 角色会影响你能否创建新的 Collections 等事项，不过那是之后再考虑的细节，现在不用担心。

如果对方所述的角色明确拥有搭建或设计权限（设计师、开发者），则完全跳过这段提示，不要提及角色或权限。

听起来不错吗？

---

等待对方确认，然后进入步骤 3。

---

步骤 3 — 连接检查和源内容

---

🔌 连接到你的网站。

尝试调用一个轻量级 Webflow MCP 工具（例如列出站点或获取站点信息），以确定连接器是否已激活。

如果已连接：

[如果工具调用提供了站点或工作区名称，请显示出来。] 这是你今天要规划的站点吗？

💡 现在连接后，我就能查看你的网站上已有的内容、现有 Collection、字段，以及可能影响规划的任何信息。

如果尚未连接：

目前还没有检测到连接，没关系，只需几分钟即可完成。

如果你使用的是 Claude： 前往 Customize Claude → Connectors → 搜索 Webflow → 点击 Connect 并登录。然后回来告诉我 “我已连接。”

如果你使用的是 Cursor 或 Windsurf： 将 Webflow MCP 服务添加到配置中，并通过 OAuth 授权。请参阅 developers.webflow.com/mcp/reference/getting-started 查看分步说明。

---

连接并确认后，先静默检查网站的语言区域配置（get_site → locales），再继续。不要询问学习者的网站是否有次要语言区域，直接检查。如果存在次要语言区域，请询问是否需要从一开始就以多种语言呈现任何迁移内容，因为翻译必须在创建时设置，之后无法添加。如果不存在次要语言区域，则跳过此步骤，不要提及。

随后立即静默检查网站上已有的 CMS Collection（get_collection_list）。每次都要执行此检查。如果网站上没有现有 Collection，不要提及此事，直接像往常一样继续请求分享源内容。只有在实际发现现有 Collection 时，才适用以下内容：

---

我看到这个站点已经有一些 Collection：[逐一列出每个现有 Collection 的名称，并简要说明其字段]。

对于每个 Collection，你希望源内容并入其中、在迁移其他内容时暂时不动它，还是目前还不确定？

如果现有结构包含无法在 Webflow 中直接对应的模式（例如深层嵌套或重复字段，或需要大幅调整结构才能迁移的内容），请指出具体模式，不要只给出笼统警告，并说明将这部分内容单独处理，可能比在一次迁移中将其合并进来更简单。对于结构简单明了的现有 Collection，完全跳过这条说明。

今天不必决定这些。拿到生成的 skill 后，你可以慢慢考虑如何让源内容与现有内容相衔接。

---

等待对方逐个回答每个 Collection 的处理方式（如果有多个）。在步骤 4、7 和 15 中沿用所有决定。如果要并入目标 Collection，映射时必须使用该 Collection 的真实字段名称、类型和 ID（步骤 4 和 7），不要把它当作一个新规划的 Collection 来重新构想。

---

现在，重要的是：分享你的源内容。 可以是导出文件、CSV、电子表格、列出内容类型和字段的文字说明、截图，或任何你手头已有的材料。从这里开始的所有工作都将以实际内容为依据，而不是靠猜测。

---

在继续到步骤 4 之前，先等待源内容。如果对方目前没有任何可导出的材料，请先帮他们梳理需要收集哪些内容（例如 CSV 导出文件、按内容类型列出的字段清单），再继续。

---

步骤 4 — 你的源内容实际包含什么？

这是完整性审查步骤。请有条理地逐项检查，不要凭记忆或印象判断。

拿到源内容后，请系统地逐项检查：按内容类型、按字段逐一梳理。不要只粗略浏览后做总结，而要实际逐项检查。

针对源中的每种内容类型，请确定：

• 它有哪些字段，以及每个字段看起来存放什么内容
• 有没有看起来对应 Webflow 内置字段的内容（例如，标题字段通常会变成内置的 Name 字段）
• 有没有不够明确、需要稍后直接提问的内容

如果此内容类型要合并到步骤 3 中现有的目标 Collection，请先根据该 Collection 实际拥有的字段核对拟议字段。“直接映射”应指映射到真实存在的字段，而不是提议新增一个与已有字段重复、只是名称不同的字段。

---

📂 以下是我在你的源内容中看到的内容。

[以清晰、有条理、便于浏览的格式，按内容类型分组，展示发现的内容类型和字段。不要写成密集的段落。]

这是否符合你的预期？有没有我遗漏或误读的地方？

---

等待对方回答。继续之前，请确认源中的每个字段都已得到以下三种处理之一：已映射、已映射到 Webflow 内置字段，或已明确排除并说明理由，且该理由已与学习者达成一致。不要让任何字段悄无声息地无人处理，“我没注意到”不可以。现在不必把这份完整核对结果单独列给学习者，但在开始步骤 5 之前，必须确实完成核对。

审查源内容时，请默默留意看起来属于 Ecommerce 的内容：产品、变体、SKU、订单、购物车。暂时不要提起，留到步骤 5 再处理。

---

步骤 5 — 这些内容在 Webflow 中应该如何呈现？

此步骤涉及几项实际决策。请按顺序逐项处理，不要一次全部讨论。

5a. Ecommerce 检查（如适用）。

仅当步骤 4 发现了看起来属于 Ecommerce 的内容时才执行。否则直接跳到 5b。

---

🛒 在继续之前，先做一个重要的快速决定。

你分享的部分内容看起来可能属于 Ecommerce：[写出你注意到的具体内容类型]。这是一个真正需要做出的选择，不是小细节：

• Webflow Ecommerce 有自己内置的结构（结账、变体、SKU），直接在 Webflow 中配置，而不是由此技能替你搭建
• 标准 Collections 可以对相同内容进行建模，以供展示、浏览和筛选，但不包含内置结账功能

哪种方式适合你正在构建的内容：带结账功能的实际 Ecommerce，还是不带结账功能的目录／展示网站？

---

等待对方回答。这个决定确实应由对方做出，不要倾向任何一种选项。如果选择 Ecommerce，请说明这些具体内容类型不在此技能的范围内，需要另行进行 Designer／Ecommerce 配置。如果选择标准 Collections，就像处理其他内容类型一样继续处理。

5b. 粒度问题。

---

🧩 一条记录，还是多条？

在开始映射之前，有件事值得先确认：源数据中的一条记录会变成 Webflow 中的一个项目，还是实际上包含了应归入几个不同 Collection 的信息？

例如，一条“客户案例”记录可能实际上包含了案例、客户和行业——三个不同的内容都打包在同一行里。

看看你的内容，有没有类似的拆分情况？

---

等待对方回答。如果适用，这会彻底改变整个计划；不要未经确认就假设两者能干净地一一映射。

5c. 解决含义不明确的字段。

凡是映射确实不明确的地方，都要逐个字段梳理。以下是值得检查的常见模式，但应广泛运用背后的判断，而不只局限于这些示例：

• 类别、类型或部门这类字段可以是纯文本、固定选项字段，也可以是独立的 Collection。若值的集合有限、预先定义，并且仅在当前 Collection 中使用，那么选项字段就合适。如果这些值需要有自己的内容或页面、需要在多个 Collection 中重复使用，或者一个项目可能同时属于多个值（选项字段不支持多选），则应考虑使用独立的 Collection
• 作者这类字段可以引用一个实际的 Collection，也可以只是一个名字
• 图片、图标或徽标这类字段可能本身就是实际图片，也可能以文本形式存储（文件名、图标类名），需要认真判断是否要将其转换
• 不要假设两个不同内容类型中同名的字段指向同一个对象。“博客文章”中的“类别”和“团队成员”中的“类别”很可能是不同的概念

对于每一项，都要直接询问，不要猜测：

---

我想确认几件事，而不是直接做假设。对于 [field name]（属于 [content type]）：[清楚说明存在的歧义和可选方案]。哪种情况符合这里的实际情况？

---

每次都要等对方回答后，再继续处理下一个含义不明确的字段。这一步每次都由学习者决定；要清楚说明权衡，不要替他们选择。

---

第 6 步 — 我们如何区分记录？

---

🔑 你的 Agent 如何匹配记录？

名称和标题可能重复，也可能形式不同；“Acme”和“Acme Inc.”可能指的是同一家公司。如果你的 Agent 每次看到一个看起来略有不同的名称就创建一个新项目，最终得到的会是重复项，而不是一个真正的实体。

你的源数据中有没有稳定的值，例如记录 ID、规范 URL，或其他保持唯一的值，可用于可靠地区分记录？

---

等待对方回答。这只能由学习者提供，因为只有他们真正了解自己的数据。如果没有明确可靠的答案，就直说，并注明可能的重复项需要人工审核，不要假装存在解决方案。

---

第 7 步 — 将字段分成四类

按 Collection 逐个处理，不要一次性处理所有 Collection 中的所有字段。

在规划的目标结构中，每个字段通常属于以下四类之一：

• 可直接映射到源数据中的某项内容
• 需要重构，例如应变成独立 Collection 项目的文本值
• 可根据现有内容创建，例如从较长的正文中撰写摘要
• 需要其他来源或人工审核，因为无法核实

---

🔀 来整理一下 [Collection name] 的字段吧。

[根据第 4 步中实际存在的字段，以及第 5 步中做出的决定，提出第一版整理方案。如果此 Collection 要合并到第 3 步中已有的目标 Collection，请以其实际现有字段为依据，不要把它们重新描述成新规划的字段。]

这样看起来合适吗？有没有你想调整位置的字段？

---

等对方回答后再处理下一个 Collection。这是真正的协作：先提出一份切实可行的初稿，然后一起调整，不要让对方从头开始整理。

整理时有两点需要确认：

跨 Collection 的一致性。 如果多个 Collection 中出现了名称相同或相似的字段，请确认它们是否代表同一个概念，再判断它们是否应指向同一个目标。

无法顺利迁移的双向关系。 如果源系统有双向关系（每一方都会自动显示另一方），请指出 Webflow 的多引用只支持单向关系。询问哪一方向对内容的使用方式更重要，因为这将决定关系的构建方向。

帮助文本是为字段编写的，应在本步骤中随每个字段一起确定，而不是留到之后：

💡 帮助文本是给之后在 Webflow 中编辑此 Collection 的人看的，不是迁移备注。应说明字段的用途及使用方式，绝不要提及旧系统。“在列表页面上显示的简短摘要”很好。“从旧摘要字段迁移而来”则不合适。

---

第 8 步 — AEO 字段

---

🔍 目标平台是否需要源系统中没有的字段？

答案引擎只能利用公开页面上的内容，看不到 Collection 在后台的设置方式。源内容可能根本没有作者信息、内容新鲜度、相关内容或元数据字段，这很正常。与其等内容都迁移完成后再添加，不如现在就处理。

我们会逐项查看这些字段。准备好了吗？

---

等对方确认后，再逐项继续。

作者信息。 专门的作者字段，而不是仅在正文中提到姓名。这对 AEO 很重要，因为答案引擎会将内容背后的作者视为可信度信号。如果这看起来不太适用，请介绍一下你的内容，我可以帮你一起梳理。源系统中有这个字段吗？还是需要添加？

---

等对方回答后，再处理下一个字段。每个字段都先用一句简短的话说明其作用机制，以及答案引擎或读者为何会关注；如果是否适用不明确，再用一句话邀请对方一起斟酌。保持简洁：每个字段的背景说明最多两句话，不要写成一段。若对方决定不添加，应记录为经过考虑的选择，而不是默默跳过。

内容新鲜度。 最近审核日期，与源系统中的原始发布日期分开记录。这对 AEO 很重要，因为可能过时的内容需要提供“截至某日期仍然准确”的信号，供读者和答案引擎参考。源系统中有这个字段吗？还是需要添加？

相关内容。 用于关联相关条目的引用字段。这对 AEO 很重要，因为它能构建更清晰的内容图谱，答案引擎可以沿着相关条目了解上下文和内容是否完整。源系统中有这个字段吗？还是需要添加？

元数据。 元描述和 Open Graph 图片通常正是答案引擎用来概括页面的内容。这比其他 AEO 字段更需要仔细考虑，因此应先给出简短建议，而不是简单地让对方二选一：为每个 Collection 显式添加字段能提供更多控制，适合核心 Collection 和推动转化的 Collection；对于辅助内容，Webflow 内置的 Collection 模板 SEO 设置通常已足够。可以提议一起梳理哪些 Collection 属于哪一类。

---

第 9 步 — 字段分组

---

🗂️ 还有一件实用的事：整理你的字段。

随着 Collection 中的字段越来越多，字段组可以让你直接在 Collection 设置中将它们整理到带标签的分区中。

例如，博客文章 Collection 可以分为：

• 内容： 摘要、正文、缩略图
• SEO： Meta Description、Open Graph Image

根据你预计的字段数量，你觉得这对你的某个 Collection 有用吗？你希望我推荐一些分组方式吗？

---

在此步骤之前，请默默检查此计划中的任何 Collection 是否为已连接网站上现有的 Ecommerce Products 或 SKUs Collection。这里不支持字段组，甚至不能创建空分组。只有确实适用时才提及。

等待对方回答。如果他们希望获得建议，这件事的影响比本活动中的大多数决策都小；字段组纯粹用于展示，之后调整也无需付出代价。因此，你可以比在其他方面更有把握地提出建议：根据已经收集的字段，按照示例中的内容／发布／SEO 逻辑提出分组。

---

步骤 10 — 图片和其他资源

---

🖼️ 图片和文件将如何处理？

本地图片文件或通过路径而非公开 URL 引用的文件，Agent 无法直接访问。工作流如下：先将文件上传到 Assets 面板，然后在条目中引用该文件，之后即可清理原始上传文件。这既适用于专用图片字段，也适用于正文内容中嵌入的图片。

你的来源包含本地文件、公开托管的文件，还是两者都有？

---

等待对方回答，并在生成的技能中记下答案。将其作为明确事实陈述，不要说成附带条件；机制就是如此，并非不确定。

---

步骤 11 — 构建顺序

---

🧭 这些操作需要按什么顺序进行？

建立关联之前，必须满足两个条件：被引用的 Collection 必须存在，被指向的特定条目也必须存在。因此，实际顺序是：

1. 创建被引用的 Collection，并先导入其中的条目
2. 创建引用它们的 Collection
3. 先关联并检查几个条目，再处理其余条目

根据我们规划的内容，你的 Collection 具体应该按什么顺序处理？

---

等待对方回答，并根据步骤 7 中确定的关联确认或纠正顺序。这是确定的技术事实，不是主观判断；应明确说明，并一起确认具体顺序，而不是把它当作开放式问题。

---

步骤 12 — 还有其他需要规划的事项吗？

---

📈 在敲定计划之前，我们先把视角拉远一些。

关于这些内容未来可能如何增长或变化，有什么尚未讨论的吗？例如，之后会从同一来源导入更多内容；或者有一种你暂时还不迁移、但以后可能需要迁移的内容类型；又或者有什么你确实拿不准的地方。

有任何此类事项，都可以在这里提出，即使你还不知道该怎么处理也没关系。

---

等待对方回答。如果确实是对未来的考虑，将其作为“待重新审视事项”记入生成的技能中。如果这会改变已经做出的决定，则提出现在返回并调整。如果没有其他事项也没关系，不要追问。

---

步骤 13 — 完整性检查（内部）

向学习者展示任何内容之前，请先默默对照此清单检查已汇总的计划。不要向学习者展示此清单。

• 源中的每个字段都有明确的处理结果：映射、映射到内置字段，或说明排除原因
• 已检查粒度问题，而非想当然
• 如果适用 Ecommerce 分支，应由学习者而非 Agent 作出决定
• 每个含糊不清的字段类型都已通过提问确认，而非猜测
• 已确定匹配键，或明确说明不存在匹配键
• 每个字段都有不引用源系统的帮助文本
• 已检查各集合之间的字段名称一致性
• 已标出双向关系，并选择了一个方向
• 已处理字段组，即使结论是“暂不需要”
• 已清楚说明图片和文件的处理方式
• 已明确构建顺序，并与计划中的实际关系一致
• 如果站点有其他语言区域，已处理多语言区域需求
• 步骤 12 中标记的所有事项都已反映在计划中，或记录为后续重新审视的事项
• 如果上述任何事项缺失，请返回并先行询问

---

步骤 14 — 提交计划供审批

---

✅ 这是你的计划。

[清晰地展示汇总后的完整计划：集合及其用途、以通俗语言说明的关系规则（包括选定的方向）、每个集合的四类字段分类及帮助文本、AEO 字段、字段组、匹配键、图片处理方式、构建顺序，以及步骤 12 中标记的任何事项。]

如果步骤 3 中的任何集合将与现有集合合并，或在现有集合旁新建，请明确列出一张表：哪些集合将新建，哪些现有集合将作为合并目标（注明其真实的 Collection ID）。这是 create-vs-reference 逻辑（创建还是引用）进入步骤 15 前的可见安全检查点；务必让学习者在此处看到并确认，而不是只把它藏在生成的技能中。

如果确实要合并到任何集合中（而非仅引用或保持不变），请将此项作为独立检查点，另行列出，与下面的一般计划审批分开：

---

🔍 还有一项明确确认，因为这会涉及现有内容。

以下是 [现有集合名称] 将发生的全部变更：[清楚列出每个新增字段、重命名项和新增关系]。这里不会删除或更改此集合中任何现有内容，也不会更改其类型；只会添加内容。

在我们敲定完整计划前，请确认这是否正确？

---

在继续之前，请等待学习者明确确认此项具体内容；此确认应与下面的一般“这是否符合需求”问题分开。如果没有集合将被合并，请完全跳过此检查点，也不要提及。

请花点时间再次核对名称，包括集合和字段的名称。在将此计划变成技能之前，有什么需要说得更清楚的吗？

这是供你确认的计划框架，并非技能本身。生成的技能将包含远超上述摘要的内容，包括确切的字段类型、构建顺序和详细的执行指令，供你的 Agent 实际遵循。因此，你在此审批的是计划的大致结构，而非完整的指令集。

这符合你的实际需求吗？还是在我生成技能之前，还有什么需要调整的？

---

等待对方回复。根据需要调整后再继续。只有在对方明确确认后，才生成输出技能。

---

第 15 步 — 生成输出技能

获得批准后，生成一个独立的 Markdown 技能文件。这与第 14 步中展示的计划不是同一份文档：那份计划是写给人阅读和批准的，而这个文件是写给 Agent 执行的，内容应是清晰、按顺序排列的指令。请将获批计划改写成这种形式，不要原样复制。

如果计划包含要合并到的任何第 3 步集合，生成的技能文件中自己的集合创建步骤必须明确按集合分支：对于真正全新的集合，选择 新建；对于要合并到的现有集合，选择 合并到现有集合（完全跳过创建，使用规划期间记录的真实集合 ID）。切勿尝试重新创建已存在的集合。在生成的技能文件自己的计划部分中，重现第 14 步中的新建与引用对照表。

输出技能必须按以下顺序包含：

1. 简短的介绍部分，说明此技能要迁移什么，并确认学习者已审核并批准计划
2. 执行前先总结的检查。 如果此技能是在新会话中加载，或由未参与原始规划对话的人加载，必须先向当前阅读者完整总结整个计划，并确认他们已准备好继续，然后才能采取任何行动
3. 完整的自定义计划，以可供 Agent 执行的形式重写，其中包括第 12 步中任何“需要重新审视的事项”说明。在计划自身的验证步骤之后，立即加入一个步骤：先迁移一小批真实记录，这批记录应尽可能涵盖计划中的关系；清楚汇报创建了什么以及结果如何；只有在学习者确认无误后，才继续完整迁移。这是真实内容，不是占位内容，因此无需清理步骤，只需在批量执行前设置继续或停止的检查点
4. 下方完整的技术执行基础内容，按原文重现。 不要总结、压缩或改述其中任何部分
5. 结尾提示，询问是否现在继续迁移，还是先到此为止，让学习者与团队一起审核文件

展示生成的文件前，请默默确认下方基础内容中的每一项都已逐字出现在输出中。

在同一条回复中一并交付两项内容：向学习者简短确认技能已准备就绪，并说明该技能是根据他们刚批准的计划生成的；以及实际生成的技能文件本身。另加一行简短说明：如果文件没有立即显示，刷新对话通常可以解决问题。

---

第 16 步 — 收尾

---

📦 你的技能已准备就绪。

这是一份真正定制的 Markdown 技能文件，围绕你的实际内容和刚刚批准的计划编写，而不是通用模板。

如果你现在准备好了，我们可以直接在这里一起开始构建。或者，你也可以保存文件，之后随时使用：稍后将它加载到你的 Agent 中，将它添加到共享技能库，或发送给需要执行同一迁移任务的队友。

想现在一起开始构建，还是想先保存下来以后再用？

---

如果他们想现在开始构建，就按照生成技能文件中的执行基础内容逐步推进，每次实际操作都先规划并征得批准。如果他们想稍后再用，就友好地结束，并提醒他们无论何时、何处加载该文件，都可以按相同方式使用。

---

技术执行基础

根据第 15 步的要求，每个生成的输出技能都必须逐字重现本节全部内容。本节不会因学习者的计划而变化。内容基于真实且经过测试的 Webflow MCP 行为。切勿将任何具体数字上限（集合数、字段数或引用字段中项目数）说成事实，因为 MCP 无法可靠地提供这些信息；请检查实际行为，不要自行假设某个数字。

不可妥协的规则

1. 无法通过此技能撤销创建 Collection 的操作。 通过 MCP 没有可用的删除 Collection 操作，这一点已根据当前 Webflow MCP 工具集确认。只有当 Collection 中没有任何项目时，才能由人工直接在 Webflow 中删除它。创建 Collection 前务必获得明确确认。

2. 创建后无法更改字段类型和 slug。 之后只能编辑显示名称、帮助文本和必填状态。第一次就要选对类型。

3. 项目始终以暂存状态创建，不会直接上线。 上线始终是单独的后续步骤，可以发布指定项目，也可以发布整个站点；发布整个站点会一次性发布所有暂存项目。

4. 全新的 Collection 必须先发布一次，才能发布其中的单个项目。 尝试发布从未上线过的 Collection 中的指定项目时，会返回普通错误。解决方法：先完整发布一次整个站点。

5. 绝不要把计划限制说成事实。 无法通过 MCP 读取站点的 Collection、字段或项目数量限制。如果有人问到限制，请明确说明无法通过这种方式查询，并指引他们查看 Webflow 自己的计划设置。

6. 如果站点有次要区域语言，每个步骤都必须考虑到它们。 创建项目时必须指定翻译，之后无法为现有项目添加翻译。

7. 每次写入后都要读取并验证。 有些操作成功时不会返回有用的确认信息。绝不要因为没有报错就假设写入成功。

8. 删除存在入站引用的项目时，必须按依赖关系的逆序操作。 如果某个项目仍被其他项目引用，就无法删除；API 会返回冲突错误，并指出仍在引用它的项目。请按依赖关系建立顺序的逆序删除。

每个 Collection 都包含两个内置架构字段，以及自动生成的项目元数据

name 和 slug 是每个 Collection 中真实存在的架构字段，会显示在字段列表中。不要创建同名自定义字段，也不要提议将源数据中的“title”字段迁移到新字段中，它几乎总是会变成内置 Name 字段。

此外，每个项目还带有自动生成的元数据：createdOn、lastUpdated 和 lastPublished。它们不是架构字段（不会显示在 Collection 的字段列表中），但存在于每条项目记录中。也不要创建重复这些元数据的自定义字段。

有一项值得了解的迁移相关功能：更新项目时，可以直接设置 createdOn、lastPublished 和 lastUpdated，而不只是读取它们。如果源系统中有值得保留的真实创建日期或发布日期，这或许能避免所有迁移的项目都显示为今天创建。依赖此功能进行完整迁移前，请先在小规模测试中验证其是否按预期工作。

字段类型

只能使用以下准确的类型名称。即使只是猜得接近，也会失败：

内容	使用此类型
标题、简短标签、长篇纯文本	PlainText
带格式的正文内容	RichText
单张图片	Image
图片库	MultiImage
可下载文档	File
视频嵌入	VideoLink（不是 Video）
外部 URL	Link（不是 URL）
电子邮件地址	Email
电话号码	Phone
数字、计数、评分	Number
日期	DateTime（不是 Date）
开/关标记	Switch（不是 Boolean）
品牌或主题颜色	Color
固定选项集	Option（不是 Dropdown 或 Select）
关联到其他位置的一个项目	Reference
关联到其他位置的多个项目	MultiReference

关系机制

• 被引用的 Collection 必须先存在，才能创建指向它的字段。始终先创建被引用的 Collection 并填充其中的项目，再建立任何关联。
• Collection 可以引用自身。这是常见且受支持的模式，而且不会自动形成双向关系：将 A 连接到 B，不会自动将 B 连接到 A。源系统中的双向关系在 Webflow 中会变成单向关系，请按规划时选定的方向建模。
• 对于单个 Collection 中使用的有限预定义值集合，选项字段是合适的选择。如果这些值需要拥有自己的内容、需要在多个 Collection 之间重复使用，或需要同时选择多个值，则应改用 Collection。
• MCP 可以创建选项字段，但字段更新操作不支持更改其选项元数据。通过 Agent 添加或编辑选项可能需要采用其他方法、重新创建字段，或直接在 Webflow 中手动编辑，而不是原地更新。
• 选项字段的值可以通过名称或底层 ID 写入，但筛选或查询时只能使用 ID，不能使用名称。
• 必须根据正确的 Collection 检查引用字段的目标。不存在的 ID 和来自错误 Collection 的有效 ID 可能返回相同错误，因此应直接确认目标 Collection，不要仅凭错误推断。
• 每个 Collection 最多可以有 50 个字段组。这是实际的工具级限制，并非规划限制，可以直接说明。

迁移内容：匹配与重复项

• 创建传入记录之前，使用规划阶段确定的稳定匹配键检查该记录是否已存在。切勿仅依赖名称或标题来检测重复项，因为这些字段最容易冲突，或以略有不同的形式出现。
• 创建项目时，如果其 slug 与现有项目冲突，不会报错，而是会静默地为新项目追加随机后缀。切勿假设发送的 slug 已被实际保存，应从响应中读取 slug。
• 更新项目时，如果 slug 与现有项目冲突，操作会被直接拒绝；如果一个更新批次中的某个项目发生冲突，整个批次都可能失败。谨慎处理更新中的 slug 变更，如果确实存在冲突风险，请逐个处理。

字段创建失败

如果字段创建调用失败，请稍等片刻后重试一次。如果再次失败，请记录下来，并继续处理剩余字段，而不要停止。最后报告所有失败，以便学习者直接处理。

操作顺序与批处理

• 按依赖顺序构建：先创建被引用的 Collection 及其项目，再创建指向它们的 Collection 和字段，最后建立关联并填充内容。
• 如果两个 Collection 需要相互引用（确实存在循环关系），请先创建两个 Collection，但暂不添加循环引用字段；等两个 Collection 都存在后，再添加这些特定字段。
• 自引用 Collection（指向自身类型的 Collection）必须先创建，然后才能向其中添加自引用字段。
• 一次创建大量项目时，新项目可以使用较大的批次。更新时应使用较小的批次，因为更新批次中的单个错误条目可能导致整个批次被丢弃，而不只是该条目。

报告与验证

• 执行任何批量操作后，都要重新检查实际的当前状态，而不要只相信响应。
• 清楚报告实际创建、更新或建立关联的内容，并指出任何未按预期进行的情况。
• 如果有内容被跳过，例如某个语言区域或未通过验证的项目，请如实说明。
• 新创建的 Collection 或项目可能不会立即显示在 Webflow 自带的界面中。如果学习者表示看不到刚创建的内容，建议先刷新页面或标签页，再判断是否失败。

每次实际操作前先制定计划

在创建、连接或填充任何内容之前，说明具体计划并等待批准。将结构、连接和内容生成视为三个独立的审批环节，而不是一次性批准所有事项。

不要发布

此技能绝不能触发整站发布。要让更改在线上生效，需要进行发布，但是否发布应由运行此技能的人决定，而不是由此技能决定。

---

参考资源

• CMS Collections | The Webflow Way — 关于常规结构设计和迁移顺序的指导
• 选项字段概览
• 引用字段概览
• 嵌套 Collection 列表
• Collection 字段
• CMS 字段类型与项目值
• Webflow MCP 服务概览
• 如何将内容导入 Webflow CMS？

---

备注

此技能是 Webflow University 的一项资源，旨在以单个 .md 文件的形式分发，与用于从头构建新 CMS 的配套技能一起，附在「使用 MCP 构建和扩展 CMS」课程中。

参与者具备以下条件时，使用效果最佳：

• 支持 Webflow MCP 的 AI Agent
• 已授权在目标迁移站点上使用的 Webflow MCP
• 实际源内容、导出文件、CSV，或对源内容的清晰文字说明
• 对 Webflow Collections 的基本了解

本活动的输出是第二个独立的技能文件，根据每位学习者自己的计划重新生成。该文件是一个独立完整的 Markdown 文件：可在不同会话、由不同 Agent 或完全不同的人加载；在执行任何操作前，它会先总结自身内容并确认已准备就绪。