Webflow/批量CMS更新

批量 CMS 更新

创建或更新多个 CMS 条目，支持全面的验证、细粒度审批和回滚功能。

重要说明

始终使用 Webflow MCP 工具进行所有操作：

• 使用 Webflow MCP 的 data_sites_tool，操作类型为 list_sites 来列出可用站点
• 使用 Webflow MCP 的 data_cms_tool，操作类型为 get_collection_list 来列出 CMS 集合
• 使用 Webflow MCP 的 data_cms_tool，操作类型为 get_collection_details 来获取集合架构
• 使用 Webflow MCP 的 data_cms_tool，操作类型为 list_collection_items 来检索现有条目
• 使用 Webflow MCP 的 data_cms_tool，操作类型为 create_collection_items 来创建条目（草稿或已发布）
• 使用 Webflow MCP 的 data_cms_tool，操作类型为 update_collection_items 来更新条目（草稿或已发布）
• 使用 Webflow MCP 的 data_cms_tool，操作类型为 publish_collection_items 来发布草稿条目
• 使用 Webflow MCP 的 webflow_guide_tool 来获取最佳实践，在开始之前
• 不要使用任何其他工具或方法进行 Webflow 操作
• 所有工具调用必须包含必需的 context 参数（15-25 个词，第三人称视角）

操作指南

阶段 1：站点与集合选择

1. 获取站点：识别目标站点。如果用户未提供站点 ID，请询问。
2. 列出集合：使用 Webflow MCP 的 data_cms_tool，操作类型为 get_collection_list 来显示可用的集合
3. 请用户选择集合：用户指定要操作的集合
4. 获取集合架构：使用 Webflow MCP 的 data_cms_tool，操作类型为 get_collection_details 来检索：
   • 所有带类型的字段定义
   • 必填字段与可选字段
   • 字段验证（最大长度、模式等）
   • 引用字段的目标

阶段 2：数据收集与解析

5. 询问操作类型：明确用户想要做什么：

   • 仅创建新条目
   • 仅更新现有条目
   • 同时创建和更新

6. 接收用户数据：接受灵活格式的数据：

   • 结构化格式（类似 JSON）
   • 自然语言描述
   • CSV 格式数据
   • 项目符号列表

7. 解析并标准化：将用户数据转换为结构化格式

8. 获取现有条目（如果涉及更新）：使用 Webflow MCP 的 data_cms_tool，操作类型为 list_collection_items 来获取当前数据

   重要 - 高效条目查找：

   • 按名称搜索特定条目时，始终使用 name 参数进行过滤（例如，name: "Pikachu"）
   • 按 slug 搜索时，使用 slug 参数进行过滤
   • 永远不要先获取所有条目然后在结果中搜索——这会浪费 API 调用和令牌
   • 仅当需要显示所有条目或不知道要定位哪些特定条目时，才获取完整列表

阶段 3：验证与分析

9. 验证所有数据：
   • 字段名称：检查所有字段名称是否存在于架构中
   • 必填字段：确保提供了所有必填字段
   • 字段类型：验证数据类型是否与架构匹配
   • 约束条件：检查最大长度、模式、允许的值
   • Slugs：确保 slugs 唯一且有效
   • 引用字段：验证引用的条目是否存在
10. 检测冲突：
    • 重复的 slugs（批次内或与现有条目）
    • 缺少必填字段
    • 无效的数据类型
    • 约束违反
11. 分析影响：
    • 计算创建数与更新数
    • 识别哪些字段将更改
    • 计算批次大小和处理时间

阶段 4：预览与细粒度审批

12. 生成详细预览：
    • 显示每个条目及其验证状态
    • 显示任何问题的警告
    • 对于更新，显示差异（旧 → 新）
    • 对于创建，显示所有字段值
    • 为每个条目编号以便选择性审批
13. 提供细粒度审批选项：
    • 允许用户选择要处理的特定条目
    • 选项：“全部”、“无”、特定编号、编号范围
    • 显示预计处理时间
14. 提供发布选项：
    • 立即发布（使用 *_live 端点）
    • 保存为草稿（使用常规端点 + 手动发布）

阶段 5：执行与报告

15. 存储回滚数据：在任何更改之前，保存：
    • 所有更新条目的原始值
    • 时间戳
    • 操作详情
16. 分批处理：
    • 每批最多 50 个条目
    • 显示进度指示器
    • 优雅地处理速率限制
17. 执行操作：根据用户选择使用适当的 Webflow MCP 工具
18. 优雅地处理错误：
    • 在单个条目失败时继续处理
    • 分别跟踪成功和失败
    • 提供详细的错误消息
19. 生成综合报告：
    • 摘要（成功/失败计数）
    • 每个条目的详细结果
    • 已创建/更新条目的 ID
    • 失败条目的错误详情
20. 提供回滚选项：允许用户根据需要撤消更改

示例

用户提示：

添加 2 篇关于 Webflow MCP 的博客文章，并将第一篇博客中的“Best”改为“Top”

步骤 1：站点与集合选择

📋 批量 CMS 更新设置

可用站点：
1. MCP 演示 #1
2. MCP 演示 #2
3. MCP 演示 #3

请选择一个站点（1-3）：

用户选择：1

MCP 演示 #1 中的可用集合：
└── 博客文章（9 个条目）
    字段：名称、slug、正文、摘要、主图、缩略图、特色、颜色

是否继续使用博客文章集合？（是/否）

用户确认：是

步骤 2：数据收集

🔍 集合架构：博客文章

必填字段：
- 名称（纯文本，最多 256 个字符）
- slug（纯文本，最多 256 个字符，仅限字母数字）

可选字段：
- 正文（富文本）
- 摘要（纯文本）
- 主图（图片）
- 缩略图（图片）
- 特色（开关，是/否）
- 颜色（颜色，十六进制格式）

我将解析您的请求：
- 创建 2 篇关于 Webflow MCP 的新文章
- 更新第一篇帖子：“Best” → “Top”

正在生成条目...

步骤 3：验证与预览

📋 预览：批量 CMS 更新

集合：博客文章
操作：创建 2 个条目 + 更新 1 个条目

---

### 🆕 要创建的条目（2 个）

[1] ✓ 新帖子
    名称：“Webflow MCP：网页开发的未来”
    slug：“webflow-mcp-future-web-development”
    摘要：“了解 Webflow MCP 如何革新...”
    正文：“<h1>未来已来</h1><p>...”
    特色：是
    颜色：“#9B59B6”
    ✅ 所有验证通过

[2] ✓ 新帖子
    名称：“为什么 Webflow MCP 将在 2026 年改变您的工作流程”
    slug：“webflow-mcp-transform-workflow-2026”
    摘要：“了解 Webflow MCP 的集成如何...”
    正文：“<h1>改变您的工作流程</h1><p>...”
    特色：是
    颜色：“#3498DB”
    ✅ 所有验证通过

---

### ✏️ 要更新的条目（1 个）

[3] ✓ 更新现有
    条目 ID：69615f84fc6ce1aa444d24d5
    Slug：why-webflow-is-best-2026-ai

    更改：
      名称：“为什么 Webflow 是 2026 年的最佳选择” → “为什么 Webflow 是 2026 年的首选”

    ✅ 所有验证通过

---

**摘要：**
- ✅ 将创建 2 个条目
- ✅ 将更新 1 个条目
- ⚠️ 0 个警告
- ❌ 0 个错误

**发布选项：**
1. 立即发布（推荐）
2. 保存为草稿

您想处理哪些条目？
- 输入“全部”以处理所有 3 个条目
- 输入编号以跳过（例如，“2”跳过条目 2）
- 输入“无”以取消

选择发布选项（1/2）：_
选择条目：_

用户选择：1，全部

⚠️ 您即将执行以下操作：
- 创建 2 篇新的博客文章（立即发布）
- 更新 1 篇现有的博客文章（更改立即发布）

请输入“确认”以继续。

用户确认：确认

步骤 4：执行与结果

🔄 正在处理批量更新...

创建条目：██████████ 100%（2/2）
更新条目：██████████ 100%（1/1）

✅ 批量 CMS 更新完成！

---

### 🆕 已创建的条目（2 个）

✓ [1] “Webflow MCP：网页开发的未来”
       ID：6961640c66de07bed9aacf3e
       Slug：webflow-mcp-future-web-development
       发布时间：2026 年 1 月 9 日，晚上 8:24

✓ [2] “为什么 Webflow MCP 将在 2026 年改变您的工作流程”
       ID：6961640c66de07bed9aacf41
       Slug：webflow-mcp-transform-workflow-2026
       发布时间：2026 年 1 月 9 日，晚上 8:24

---

### ✏️ 已更新的条目（1 个）

✓ [3] “为什么 Webflow 是 2026 年的首选”
       ID：69615f84fc6ce1aa444d24d5
       更改：标题已更新
       发布时间：2026 年 1 月 9 日，晚上 8:24

---

**摘要：**
- ✅ 成功创建 2 个条目
- ✅ 成功更新 1 个条目
- ❌ 0 次失败
- ⏱️ 耗时 3.2 秒

**总条目数：** 11（之前为 9）

📋 回滚可用：
上次更新：刚刚修改了 3 个条目
输入“撤销”在 5 分钟内还原所有更改

替代方案：带验证警告

📋 预览：批量 CMS 更新

[1] ⚠️ 新帖子
    名称：“测试帖子”
    slug：“test”
    摘要：“Hi”
    ⚠️ 警告：摘要太短（少于 20 个字符）- 可能影响 SEO
    ⚠️ 警告：slug 过于通用 - 请考虑更具描述性的 slug
    ⚠️ 警告：缺少正文 - 内容将为空
    ✅ 必填字段已提供（可以继续）

[2] ❌ 新帖子
    名称：“另一个帖子！！！”
    slug：“另一个帖子”
    ❌ 错误：slug 包含空格（必须仅包含字母数字和连字符）
    ❌ 错误：名称包含不允许的特殊字符
    🔴 无法继续 - 请先修复错误

---

**摘要：**
- ✅ 1 个条目可以创建（带有警告）
- ❌ 1 个条目有错误（无法创建）

修复条目 2 还是跳过它？（修复/跳过）

指南

阶段 1：关键要求

站点与集合选择：

• 始终使用 data_sites_tool，操作类型为 list_sites 获取实际的站点列表
• 切勿假设站点 ID
• 显示集合名称和条目计数
• 在接受数据之前显示字段架构
• 与用户确认集合选择

阶段 2：数据解析

灵活的输入格式： 接受多种格式的数据：

1. 结构化（类似 JSON）：

创建：
- 名称：“帖子标题”
  slug：“post-slug”
  特色：是

2. 自然语言：

“添加一篇名为‘入门指南’的博客文章，slug 为‘getting-started’”

3. CSV 格式：

名称,slug,特色
“帖子 1”,“post-1”,是
“帖子 2”,“post-2”,否

4. 项目符号列表：

- 帖子 1：“标题”（slug：title-slug）
- 帖子 2：“另一个”（slug：another-slug）

解析规则：

• 对格式变化保持宽容
• 推断缺失的可选字段
• 如果模糊，请询问澄清
• 切勿假设必填字段值

高效的条目查找： 在获取现有条目进行更新时，使用过滤参数以最小化 API 调用：

# 好 - 当知道条目名称时按名称过滤
data_cms_tool(action: "list_collection_items", collection_id, name: "Pikachu")

# 好 - 当知道 slug 时按 slug 过滤
data_cms_tool(action: "list_collection_items", collection_id, slug: "pikachu")

# 差 - 获取所有条目然后在结果中搜索
data_cms_tool(action: "list_collection_items", collection_id)  # 返回 100 个条目
# 然后在结果中手动搜索 "Pikachu"...

• 搜索特定条目时，始终使用 name 或 slug 参数
• 这减少了 API 调用、响应大小和令牌使用
• 仅在显示所有条目或目标未知时获取未过滤的列表

阶段 3：验证规则

字段名称验证：

• 检查所有字段名称是否存在于架构中
• 区分大小写的匹配
• 对拼写错误建议更正
• 示例：“autor” → 您是指“author”吗？

必填字段：

• name 和 slug 对于 Webflow CMS 始终是必填的
• 从架构中检查集合特定的必填字段
• 清晰列出所有缺失的必填字段
• 如果缺少必填字段则无法继续

字段类型验证：

纯文本：

• 检查最大长度约束
• 如果指定，验证模式
• 不允许 HTML

富文本：

• 必须是有效的 HTML
• 检查未闭合的标签
• 允许常见的 HTML 元素

图片/文件：

• 接受文件 ID 或 URL
• 验证文件是否存在（如果可能）
• 可选的替代文本

开关（布尔值）：

• 接受：true/false、yes/no、1/0
• 标准化为布尔值

颜色：

• 必须是十六进制格式（#RRGGBB）
• 验证十六进制字符
• 示例：#FF5733 ✓，red ✗

引用字段：

• 必须引用现有的条目 ID
• 验证引用的条目是否存在
• 为清晰起见显示引用的条目名称

Slug 验证：

• 关键：必须仅包含字母数字和连字符
• 没有空格、下划线或特殊字符
• 最多 256 个字符
• 必须唯一（对照现有和批次检查）
• 如果缺少，自动从标题建议 slug
• 示例：
  • ❌ “我的帖子！” → ⚠️ 包含特殊字符
  • ✅ “my-post” → 有效

约束验证：

• 最大长度：如果接近限制则警告，如果超过则报错
• 模式：测试架构中的正则表达式模式
• 允许的值：对照枚举选项检查

阶段 4：预览与审批

预览格式：

对于创建操作：

[1] ✓ 新帖子
    字段1：“值1”
    字段2：“值2”
    字段3：“值3”
    ✅ 所有验证通过

对于更新操作：

[2] ✓ 更新现有
    条目 ID：xxx
    Slug：existing-slug

    更改：
      字段1：“旧值” → “新值”
      字段2：（无更改）
      字段3：“旧值” → “新值”

    ✅ 所有验证通过

对于带有警告的条目：

[3] ⚠️ 新帖子
    名称：“标题”
    ⚠️ 警告：缺少可选字段“正文”
    ⚠️ 警告：slug 可能过于通用
    ✅ 可以继续（仅警告）

对于带有错误的条目：

[4] ❌ 新帖子
    名称：“标题！！！”
    slug：“bad slug”
    ❌ 错误：slug 包含空格
    ❌ 错误：名称包含特殊字符
    🔴 无法继续 - 必须修复错误

细粒度审批：

• 为每个条目编号：[1]、[2]、[3]...
• 允许选择性处理
• 接受格式：
  • “全部” - 处理所有内容
  • “无” - 取消操作
  • “1,3,5” - 处理条目 1、3 和 5
  • “1-5” - 处理条目 1 到 5
  • “2” - 仅跳过条目 2，处理其余

发布选项：

• 立即发布：使用 *_live 端点（推荐）
• 草稿模式：使用常规端点

阶段 5：执行与错误处理

回滚机制：

• 在执行任何更改之前存储所有修改的原始数据
• 在发生错误或用户请求时提供一键撤消
• 简洁地显示回滚可用性

错误处理：

• 优雅地处理速率限制（429 错误）
• 对延迟操作失败提供清晰的消息
• 提供重试建议
• 分别跟踪成功和失败的条目
• 继续处理其他条目，而不因一个故障停止
• 在报告阶段提供完整的错误详情

故障排除

常见错误：

• 站点或集合 ID 无效：验证提供的 ID、重新列出集合、重试
• 速率限制：等待推荐的时间后再试、减少批次大小
• 数据验证失败：在重试之前提供明确的错误消息以指导更正
• 网络超时：重试操作、检查连通性、联系支持