site-activity

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Site Activity

站点活动

Query, analyze, and summarize Webflow site activity logs for enterprise sites. Provides natural-language querying of recent changes, filtered summaries by event type or user, and formatted reports for team sharing.
查询、分析并汇总Webflow企业版站点的活动日志。支持以自然语言查询近期变更,按事件类型或用户筛选汇总,并生成适合团队共享的格式化报告。

Important Note

重要说明

ALWAYS use Webflow MCP tools for all operations:
  • Use Webflow MCP's
    data_sites_tool
    with action
    list_sites
    for listing available sites
  • Use Webflow MCP's
    data_sites_tool
    with action
    get_site
    for detailed site information
  • Use Webflow MCP's
    data_enterprise_tool
    with action
    list_site_activity_logs
    for retrieving activity log events
  • Use Webflow MCP's
    webflow_guide_tool
    to get best practices before starting
  • DO NOT use any other tools or methods for Webflow operations
  • All tool calls must include the required
    context
    parameter (15-25 words, third-person perspective)
Enterprise Only: Activity logs are only available for sites on Enterprise hosting plans. If the tool returns an error, inform the user that this feature requires an Enterprise plan.
Tool Parameters for
list_site_activity_logs
:
  • site_id
    (required): The site's unique identifier
  • limit
    (optional): Maximum records to return (max 100)
  • offset
    (optional): Pagination offset for fetching beyond the first page
所有操作必须使用Webflow MCP工具:
  • 使用Webflow MCP的
    data_sites_tool
    ,指定action为
    list_sites
    来列出可用站点
  • 使用Webflow MCP的
    data_sites_tool
    ,指定action为
    get_site
    来获取站点详细信息
  • 使用Webflow MCP的
    data_enterprise_tool
    ,指定action为
    list_site_activity_logs
    来获取活动日志事件
  • 开始操作前,使用Webflow MCP的
    webflow_guide_tool
    获取最佳实践
  • 不得使用任何其他工具或方法进行Webflow操作
  • 所有工具调用必须包含必填的
    context
    参数(15-25个单词,第三人称视角)
仅适用于企业版: 活动日志仅对使用企业版托管计划的站点开放。如果工具返回错误,请告知用户此功能需要企业版计划。
list_site_activity_logs
的工具参数:
  • site_id
    (必填):站点的唯一标识符
  • limit
    (可选):返回的最大记录数(最多100条)
  • offset
    (可选):分页偏移量,用于获取第一页之后的数据

Instructions

操作步骤

Phase 1: Site Selection & Context

阶段1:站点选择与上下文

  1. Identify target site: If the user does not provide a site ID, use
    data_sites_tool
    with action
    list_sites
    . Each site in the response has
    displayName
    ,
    lastPublished
    , and
    lastUpdated
    .
    Sort order:
    1. ⚠️ sites (unpublished changes) before ✅ sites (up to date)
    2. Within each group, most recently updated first (by
      lastUpdated
      descending)
    Truncation: Show the top 10 sites only. If there are more than 10 total, append a line
    …and N more sites. Reply "show all" to see the rest.
    below the list. When the user replies "show all" (or similar), re-present the full list in the same format.
    Present the list in this exact format:
    📋 Site Activity — Site Selection
    
    Available Enterprise Sites:
    
    1. <Site Name> ⚠️  — last published <short date>, updated <short date> (<N> days unpublished)
    2. <Site Name> ✅  — published & updated <short date>
    3. <Site Name> ⚠️  — never published, updated <short date>
    
    …and 4 more sites. Reply "show all" to see the rest.
    
    Which site would you like to review?
    Format rules:
    • Dates: abbreviated ("Mar 6", "Apr 14"). Add the year only if it isn't the current year.
    • Use ⚠️ when
      lastUpdated > lastPublished
      OR
      lastPublished
      is null; ✅ when
      lastUpdated <= lastPublished
      .
    • When
      lastPublished == lastUpdated
      , collapse the right-hand side to "published & updated <date>".
    • Omit the "…and N more sites" line when the workspace has 10 or fewer sites.
    • Do not omit the status flag or the dates — they are required for every site.
  2. Fetch selected-site details: After the user selects a site (or when a site ID was provided up front), call
    data_sites_tool
    with action
    get_site
    once, for the selected site only, to retrieve fields not returned by
    list_sites
    — in particular:
    • Custom domains
    • Locale / localization settings
    • Any additional site metadata needed for the analysis
    lastPublished
    and
    lastUpdated
    are already known from step 1 (or from
    get_site
    if the user provided a site ID directly). Keep these in memory for the pre-publish filter in Phase 3.
  3. Infer intent from the prompt (do not ask a follow-up question if the prompt is clear). Map the request to one of:
    • Recent activity summary ("what changed this week?")
    • Specific user's activity ("what did Sarah change?")
    • Specific activity type ("any CMS changes recently?")
    • Pre-publish review ("what's changed since last publish?")
    • General overview (default when the prompt is ambiguous)
    Only ask a clarifying question if the request is genuinely ambiguous (e.g., "show me activity" with no time window, user, or event type context).
  1. 确定目标站点:如果用户未提供站点ID,使用
    data_sites_tool
    并指定action为
    list_sites
    。返回结果中的每个站点包含
    displayName
    lastPublished
    lastUpdated
    字段。
    排序规则:
    1. ⚠️ 存在未发布变更的站点优先于✅ 已更新至最新状态的站点
    2. 同一组内,按
      lastUpdated
      降序排列(最近更新的在前)
    截断规则:仅显示前10个站点。如果总站点数超过10个,在列表下方添加一行
    …还有N个站点。回复"show all"查看全部。
    。当用户回复"show all"(或类似表述)时,以相同格式展示完整列表。
    请严格按照以下格式展示列表:
    📋 站点活动 — 站点选择
    
    可用的企业版站点:
    
    1. <站点名称> ⚠️  — 最后发布于<短日期>,更新于<短日期>(已<N>天未发布)
    2. <站点名称> ✅  — 已发布并更新于<短日期>
    3. <站点名称> ⚠️  — 从未发布,更新于<短日期>
    
    …还有4个站点。回复"show all"查看全部。
    
    您想查看哪个站点?
    格式规则:
    • 日期:使用缩写格式(如"3月6日"、"4月14日")。仅当年份非当前年时才添加年份
    • lastUpdated > lastPublished
      lastPublished
      为null时,使用⚠️;当
      lastUpdated <= lastPublished
      时,使用✅
    • lastPublished == lastUpdated
      时,右侧内容简化为"已发布并更新于<日期>"
    • 当工作区站点数≤10时,省略"…还有N个站点"这一行
    • 不得省略状态标识或日期——每个站点都必须包含这两项
  2. 获取所选站点的详细信息:用户选择站点后(或用户直接提供站点ID时),仅针对所选站点调用一次
    data_sites_tool
    并指定action为
    get_site
    ,以获取
    list_sites
    未返回的字段——尤其是:
    • 自定义域名
    • 区域设置/本地化配置
    • 分析所需的其他站点元数据
    lastPublished
    lastUpdated
    已在步骤1中获取(如果用户直接提供站点ID,则从
    get_site
    结果中获取)。请将这些信息留存,用于阶段3的发布前筛选。
  3. 从用户提示中推断意图(如果提示明确,无需追问)。将请求映射为以下类型之一:
    • 近期活动汇总(如"本周有哪些变更?")
    • 特定用户的活动(如"Sarah做了哪些变更?")
    • 特定活动类型(如"近期有CMS变更吗?")
    • 发布前审核(如"上次发布后有哪些变更?")
    • 概览(当提示模糊时默认使用此类型)
    仅当请求确实模糊时(例如,仅说"展示活动"但未指定时间范围、用户或事件类型),才提出澄清问题。

Phase 2: Fetch Activity Logs

阶段2:获取活动日志

  1. Fetch activity logs: Use
    list_site_activity_logs
    with the site ID
    • Default to
      limit: 100
      (maximum per request) for comprehensive results
    • The API returns events in reverse chronological order (newest first)
  2. Handle pagination: If the user needs older activity or the results suggest more data exists:
    • Use
      offset
      parameter to fetch additional pages
    • Combine results across pages for analysis
    • Warn the user if going back further than available data
  1. 获取活动日志:使用
    list_site_activity_logs
    并传入站点ID
    • 默认设置
      limit: 100
      (单次请求的最大值)以获取全面结果
    • API返回的事件按时间倒序排列(最新的在前)
  2. 处理分页:如果用户需要更早的活动,或结果表明存在更多数据:
    • 使用
      offset
      参数获取额外页面的数据
    • 合并多页结果进行分析
    • 如果超出可用数据范围,向用户发出警告

Phase 3: Analysis & Summarization

阶段3:分析与汇总

  1. Parse each activity log entry: Each event contains:
    • id
      : Unique event identifier
    • createdOn
      : Timestamp (ISO 8601)
    • lastUpdated
      : Last update timestamp
    • event
      : Event type string (see Event Types below)
    • user
      : Object with
      id
      and
      displayName
      (absent for system events like backups)
    • resourceOperation
      : The operation performed (
      CREATED
      ,
      MODIFIED
      ,
      DELETED
      )
    • resourceId
      : ID of the affected resource (when applicable)
    • resourceName
      : Human-readable name of the affected resource
    • payload
      : Additional event-specific details (see Payload Details below)
  2. Categorize events into human-readable groups (41 event types):
    Page Changes:
    • page_dom_modified
      — Page structure/element changes
    • page_created
      — New page creation
    • page_deleted
      — Page deletion
    • page_duplicated
      — Page duplication
    • page_renamed
      — Page rename
    • page_settings_modified
      — Page settings updates (SEO, slug, etc.)
    • page_custom_code_modified
      — Page-level custom code changes
    • page_settings_custom_code_modified
      — Page settings custom code changes
    Style & Variable Changes:
    • styles_modified
      — Style/class changes
    • variable_modified
      — Single variable change
    • variables_modified
      — Multiple variable changes
    Component Changes:
    • symbols_modified
      — Component/symbol created, modified, or deleted
    Interactions:
    • ix2_modified_on_page
      — Interaction changes on a page
    • ix2_modified_on_component
      — Interaction changes on a component
    • ix2_modified_on_class
      — Interaction changes on a class
    CMS Changes:
    • cms_item
      — Collection item created, modified, or deleted
    • cms_collection
      — Collection schema created, modified, or deleted
    Site Management:
    • site_published
      — Site published
    • site_unpublished
      — Site unpublished
    • site_custom_code_modified
      — Site-level custom code changes
    • backup_created
      — Automatic or manual backup
    • backup_restored
      — Backup restored
    Localization:
    • secondary_locale_page_content_modified
      — Localized page content changed
    • locale_added
      — New locale added
    • locale_removed
      — Locale removed
    • locale_enabled
      — Locale enabled
    • locale_disabled
      — Locale disabled
    • locale_display_name_updated
      — Locale display name changed
    • locale_subdirectory_updated
      — Locale subdirectory changed
    • locale_tag_updated
      — Locale tag changed
    Branches:
    • branch_created
      — Branch created
    • branch_merged
      — Branch merged
    • branch_deleted
      — Branch deleted
    • branch_review_created
      — Branch review requested
    • branch_review_approved
      — Branch review approved
    • branch_review_canceled
      — Branch review canceled
    Library:
    • library_shared
      — Library shared with other sites
    • library_unshared
      — Library unshared
    • library_installed
      — Library installed from another site
    • library_uninstalled
      — Library uninstalled
    • library_update_shared
      — Library update published
    • library_update_accepted
      — Library update accepted
    Note: If an event type not listed above appears, categorize it as "Other" and display the raw
    event
    string.
  3. Apply filters based on user's request:
    • By event category (e.g., only CMS changes)
    • By user (match on
      user.displayName
      )
    • By time window (filter
      createdOn
      timestamps client-side)
    • By resource (match on
      resourceName
      )
    • Pre-publish review: When the user wants to see changes since the last publish, use the site's
      lastPublished
      timestamp (from Phase 1) and filter to events where
      createdOn > lastPublished
      . If
      lastPublished
      is null (never published), all events qualify as unpublished.
  4. Generate insights (include in the Highlights section of the report):
    • Most active user in the time period
    • Event type distribution (which category dominated)
    • Busiest day or hour
    • Single-user concentration (flag when one person made 40%+ of changes)
    • Unpublished changes (count of events where
      createdOn > lastPublished
      )
  1. 解析每个活动日志条目:每个事件包含以下字段:
    • id
      :唯一事件标识符
    • createdOn
      :时间戳(ISO 8601格式)
    • lastUpdated
      :最后更新时间戳
    • event
      :事件类型字符串(见下文事件类型)
    • user
      :包含
      id
      displayName
      的对象(系统事件如备份无此字段)
    • resourceOperation
      :执行的操作(
      CREATED
      MODIFIED
      DELETED
    • resourceId
      :受影响资源的ID(适用时)
    • resourceName
      :受影响资源的可读名称
    • payload
      :事件特定的额外详情(见下文载荷详情)
  2. 将事件分类为易读的组别(共41种事件类型):
    页面变更:
    • page_dom_modified
      — 页面结构/元素变更
    • page_created
      — 新建页面
    • page_deleted
      — 删除页面
    • page_duplicated
      — 复制页面
    • page_renamed
      — 重命名页面
    • page_settings_modified
      — 页面设置更新(SEO、slug等)
    • page_custom_code_modified
      — 页面级自定义代码变更
    • page_settings_custom_code_modified
      — 页面设置中的自定义代码变更
    样式与变量变更:
    • styles_modified
      — 样式/类变更
    • variable_modified
      — 单个变量变更
    • variables_modified
      — 多个变量变更
    组件变更:
    • symbols_modified
      — 组件/符号的创建、修改或删除
    交互变更:
    • ix2_modified_on_page
      — 页面上的交互变更
    • ix2_modified_on_component
      — 组件上的交互变更
    • ix2_modified_on_class
      — 类上的交互变更
    CMS变更:
    • cms_item
      — 集合项的创建、修改或删除
    • cms_collection
      — 集合架构的创建、修改或删除
    站点管理:
    • site_published
      — 站点发布
    • site_unpublished
      — 站点取消发布
    • site_custom_code_modified
      — 站点级自定义代码变更
    • backup_created
      — 自动或手动备份
    • backup_restored
      — 恢复备份
    本地化:
    • secondary_locale_page_content_modified
      — 本地化页面内容变更
    • locale_added
      — 添加新区域设置
    • locale_removed
      — 删除区域设置
    • locale_enabled
      — 启用区域设置
    • locale_disabled
      — 禁用区域设置
    • locale_display_name_updated
      — 更新区域设置显示名称
    • locale_subdirectory_updated
      — 更新区域设置子目录
    • locale_tag_updated
      — 更新区域设置标签
    分支:
    • branch_created
      — 创建分支
    • branch_merged
      — 合并分支
    • branch_deleted
      — 删除分支
    • branch_review_created
      — 请求分支审核
    • branch_review_approved
      — 批准分支审核
    • branch_review_canceled
      — 取消分支审核
    资源库:
    • library_shared
      — 与其他站点共享资源库
    • library_unshared
      — 取消共享资源库
    • library_installed
      — 从其他站点安装资源库
    • library_uninstalled
      — 卸载资源库
    • library_update_shared
      — 发布资源库更新
    • library_update_accepted
      — 接受资源库更新
    注意:如果出现上述未列出的事件类型,将其归类为“其他”并显示原始
    event
    字符串。
  3. 根据用户请求应用筛选条件
    • 按事件类别筛选(例如,仅显示CMS变更)
    • 按用户筛选(匹配
      user.displayName
    • 按时间范围筛选(在客户端过滤
      createdOn
      时间戳)
    • 按资源筛选(匹配
      resourceName
    • 发布前审核:当用户想要查看上次发布后的变更时,使用阶段1获取的站点
      lastPublished
      时间戳,筛选
      createdOn > lastPublished
      的事件。如果
      lastPublished
      为null(从未发布),则所有事件均属于未发布变更。
  4. 生成洞察信息(包含在报告的“重点”部分):
    • 时间段内最活跃的用户
    • 事件类型分布(哪个类别占比最高)
    • 最繁忙的日期或时段
    • 单一用户集中操作(当某用户的变更占比≥40%时标记)
    • 未发布变更(
      createdOn > lastPublished
      的事件数量)

Phase 4: Reporting

阶段4:报告生成

  1. Generate summary report with these sections:
    • Time range covered and total event count
    • Breakdown by activity type
    • Breakdown by user
    • Highlights — call out patterns such as high-frequency changes to a single page/collection, multiple users editing the same resource, unpublished changes (since last publish), and system events vs. user-initiated changes
  2. Answer the user's specific question: If the user asked something specific, lead with the direct answer before the structured report.
  3. Pick the detail level from the prompt:
    • "counts only" / "how many" / "just numbers" → Quick summary (counts by category only)
    • default → Standard report (categorized events with user attribution — see Example 1)
    • "walk me through" / "show every change" / "timeline" → Detailed report (chronological per-event view with payload)
    • "share" / "export" / "for my team" / "summary to send" → Shareable/Export report (see Example 3)
    The detail-level switch is always surfaced as one of the follow-up options in step 13 so the user can request a different level.
  4. Always end every report with a follow-up options section. This is required, not optional. Use the exact format below, tailoring the numbered options to what's relevant for the query just answered:
    ---
    
    Would you like to:
    1. Filter by a specific user
    2. Filter by activity type
    3. Fetch older activity (pagination)
    4. Switch to a quick summary (counts only) or a detailed view (per-event payloads)
    5. Export as markdown or JSON
    If the report was a shareable/export format (e.g., "summary I can share"), place this block outside the shareable content so the user can copy the report cleanly without the follow-up menu in it.
  1. 生成汇总报告,包含以下部分:
    • 覆盖的时间范围和总事件数
    • 按活动类型划分的明细
    • 按用户划分的明细
    • 重点 — 突出显示模式,如单个页面/集合的高频变更、多名用户编辑同一资源、未发布变更(自上次发布以来)以及系统事件与用户发起事件的对比
  2. 回答用户的特定问题:如果用户提出了特定问题,在结构化报告之前先给出直接答案。
  3. 根据提示选择详细程度
    • "仅统计" / "有多少" / "只看数字" → 快速汇总(仅按类别统计数量)
    • 默认 → 标准报告(带用户归属的分类事件——见示例1)
    • "逐步讲解" / "展示所有变更" / "时间线" → 详细报告(带载荷的按事件时间顺序视图)
    • "共享" / "导出" / "给我的团队" / "用于发送的汇总" → 可共享/导出报告(见示例3)
    详细程度切换始终作为步骤13中的后续选项之一呈现,以便用户可以请求不同的详细程度。
  4. 每份报告末尾必须包含后续选项部分。这是必填项,而非可选。请严格使用以下格式,并根据刚回答的查询调整编号选项:
    ---
    
    您是否需要:
    1. 按特定用户筛选
    2. 按活动类型筛选
    3. 获取更早的活动记录(分页)
    4. 切换为快速汇总(仅统计)或详细视图(按事件显示载荷)
    5. 导出为markdown或JSON格式
    如果报告为可共享/导出格式(例如,"我可以共享的汇总"),请将此部分放在可共享内容之外,以便用户可以干净地复制报告而不带后续菜单。

Event Payload Details

事件载荷详情

Different event types include different payload fields:
page_dom_modified
:
  • pageTitle
    : Name of the modified page
  • pageId
    : ID of the modified page
  • count
    : Number of modifications in this batch
  • branchId
    /
    branchName
    : Branch context (null if main)
cms_item
:
  • cmsCollectionId
    : ID of the parent collection
  • cmsCollectionName
    : Name of the parent collection
  • count
    : Number of items affected
  • name
    : Locale name (e.g., "English", "Spanish")
styles_modified
:
  • selector
    : CSS selector (if applicable)
  • variant
    : Breakpoint/pseudo-class variant string
  • parentChain
    : Array of parent style names (combo class chain)
  • type
    : Style type (e.g., "class")
  • branchId
    /
    branchName
    : Branch context
symbols_modified
:
  • branchId
    /
    branchName
    : Branch context
page_settings_modified
:
  • pageTitle
    : Name of the modified page
  • branchId
    /
    branchName
    : Branch context
backup_created
:
  • No payload;
    resourceName
    indicates backup type (e.g., "Automatic backup", "Maintenance backup")
  • No
    user
    field (system-initiated)
不同事件类型包含不同的载荷字段:
page_dom_modified
:
  • pageTitle
    : 被修改页面的名称
  • pageId
    : 被修改页面的ID
  • count
    : 此批次中的修改次数
  • branchId
    /
    branchName
    : 分支上下文(主分支为null)
cms_item
:
  • cmsCollectionId
    : 父集合的ID
  • cmsCollectionName
    : 父集合的名称
  • count
    : 受影响的项数量
  • name
    : 区域设置名称(如"English"、"Spanish")
styles_modified
:
  • selector
    : CSS选择器(适用时)
  • variant
    : 断点/伪类变体字符串
  • parentChain
    : 父样式名称数组(组合类链)
  • type
    : 样式类型(如"class")
  • branchId
    /
    branchName
    : 分支上下文
symbols_modified
:
  • branchId
    /
    branchName
    : 分支上下文
page_settings_modified
:
  • pageTitle
    : 被修改页面的名称
  • branchId
    /
    branchName
    : 分支上下文
backup_created
:
  • 无载荷;
    resourceName
    表示备份类型(如"Automatic backup"、"Maintenance backup")
  • user
    字段(系统发起)

Examples

示例

User prompt:
What happened on my site this week?
Step 1: Site Selection
📋 Site Activity — Site Selection

Available Enterprise Sites:

1. Acme Corp Website ⚠️  — last published Apr 14, updated Apr 16 (2 days unpublished)
2. Acme Blog ✅  — published & updated Apr 10

Which site would you like to review?
Step 2: Activity Summary
📋 Site Activity: Acme Corp Website
   April 10–16, 2026 (93 events)

**93 events this week from 3 team members. 28 are unpublished since the last publish on Apr 14.**

---
用户提示:
我的站点本周有哪些变更?
步骤1:站点选择
📋 站点活动 — 站点选择

可用的企业版站点:

1. Acme Corp Website ⚠️  — 最后发布于4月14日,更新于4月16日(已2天未发布)
2. Acme Blog ✅  — 已发布并更新于4月10日

您想查看哪个站点?
步骤2:活动汇总
📋 站点活动:Acme Corp Website
   2026年4月10日–16日(共93个事件)

**本周共有93个事件,来自3名团队成员。其中28个为自4月14日上次发布以来的未发布变更。**

---

Activity Breakdown

活动明细

📄 Page modifications 34 events 🎨 Class changes 22 events 📝 CMS updates 18 events 🧩 Component changes 8 events 🔤 Variable changes 5 events 🚀 Publishes 3 events 💾 Backups 2 events 🌿 Branch activity 1 event

📄 页面修改 34个事件 🎨 类变更 22个事件 📝 CMS更新 18个事件 🧩 组件变更 8个事件 🔤 变量变更 5个事件 🚀 站点发布 3个事件 💾 备份操作 2个事件 🌿 分支活动 1个事件

Activity by User

用户活动分布

Sarah Chen — 42 events └── Page modifications (18), Class changes (15), CMS updates (9)
Alex Kim — 31 events └── CMS updates (9), Page modifications (12), Component changes (8), Variables (2)
Jordan Lee — 17 events └── Class changes (7), Page modifications (4), Publishes (3), Backups (2), Branch (1)
System — 3 events └── Backups (auto)

Sarah Chen — 42个事件 └── 页面修改(18个)、类变更(15个)、CMS更新(9个)
Alex Kim — 31个事件 └── CMS更新(9个)、页面修改(12个)、组件变更(8个)、变量变更(2个)
Jordan Lee — 17个事件 └── 类变更(7个)、页面修改(4个)、站点发布(3个)、备份操作(2个)、分支活动(1个)
系统 — 3个事件 └── 自动备份

Highlights

重点

  • ⚠️ Unpublished changes: 28 events since last publish (Apr 14)
  • 📊 Busiest day: April 15 (41 events)
  • 👤 Most active: Sarah Chen (45% of all activity)
  • 🧩 8 component changes by Alex Kim — may affect multiple pages

Would you like to:
  1. Filter by a specific user
  2. Filter by activity type
  3. See details for unpublished changes only
  4. Switch to a quick summary (counts only) or detailed view (per-event payloads)
  5. Fetch older activity

**User prompt:**
Show me CMS changes on site 6924868ede9d3fbbc3195eb0

**Response:**
📋 CMS Activity: Acme Corp Website April 10–16, 2026 (18 CMS events)
18 CMS events from 2 users over 5 days. 3 changes are unpublished.

  • ⚠️ 未发布变更:自上次发布(4月14日)以来有28个事件
  • 📊 最繁忙日期:4月15日(41个事件)
  • 👤 最活跃用户:Sarah Chen(占所有活动的45%)
  • 🧩 Alex Kim进行了8次组件变更——可能影响多个页面

您是否需要:
  1. 按特定用户筛选
  2. 按活动类型筛选
  3. 仅查看未发布变更的详情
  4. 切换为快速汇总(仅统计)或详细视图(按事件显示载荷)
  5. 获取更早的活动记录

**用户提示:**
展示站点6924868ede9d3fbbc3195eb0的CMS变更

**回复:**
📋 CMS活动:Acme Corp Website 2026年4月10日–16日(共18个CMS事件)
5天内共有18个CMS事件,来自2名用户。其中3个为未发布变更。

CMS Breakdown

CMS明细

📝 Items modified 11 events ➕ Items created 5 events 📚 Collection changes 2 events

📝 项修改 11个事件 ➕ 项创建 5个事件 📚 集合变更 2个事件

Activity by User

用户活动分布

Sarah Chen — 10 events └── 2 items created, 7 items modified, 1 collection modified
Alex Kim — 8 events └── 3 items created, 4 items modified, 1 bulk publish

Sarah Chen — 10个事件 └── 2个项创建、7个项修改、1个集合修改
Alex Kim — 8个事件 └── 3个项创建、4个项修改、1次批量发布

Highlights

重点

  • ⚠️ Unpublished: 3 CMS changes since last publish (Apr 14)
  • 📊 Busiest day: April 15 (8 events)
  • 📚 Schema changes: 2 collection edits this week (review carefully before publish)

Would you like to:
  1. Filter to a specific collection
  2. Filter by user (Sarah or Alex)
  3. See only the unpublished CMS changes
  4. Switch to a timeline view (chronological per-event) or counts only
  5. Fetch older CMS activity

**User prompt:**
Give me a weekly summary I can share with my team for Acme Corp Website

(Naming the site inline skips Phase 1 step 1. If the user doesn't name a site, run the site-selection list first before producing this report.)

**Response:**
📋 Weekly Site Activity Report Acme Corp Website — Week of April 10–16, 2026

  • ⚠️ 未发布变更:自上次发布(4月14日)以来有3个CMS变更
  • 📊 最繁忙日期:4月15日(8个事件)
  • 📚 架构变更:本周有2次集合编辑——发布前请仔细审核

您是否需要:
  1. 按特定集合筛选
  2. 按用户筛选(Sarah或Alex)
  3. 仅查看未发布的CMS变更
  4. 切换为时间线视图(按事件时间顺序)或仅统计
  5. 获取更早的CMS活动记录

**用户提示:**
给我一份可以和团队共享的Acme Corp Website每周汇总

(直接指定站点可跳过阶段1的步骤1。如果用户未指定站点,请先运行站点选择列表,再生成此报告。)

**回复:**
📋 每周站点活动报告 Acme Corp Website — 2026年4月10日–16日

Overview

概览

  • 93 total changes across 3 team members
  • 3 publishes (Apr 10, Apr 12, Apr 14)
  • 28 unpublished changes pending review
  • Last publish: April 14 at 18:30 UTC
  • 共93项变更,来自3名团队成员
  • 3次站点发布(4月10日、4月12日、4月14日)
  • 28项未发布变更待审核
  • 最后发布时间:4月14日18:30 UTC

What Changed

变更内容

  • 34 page modifications across 8 pages
  • 22 class/style updates
  • 18 CMS content changes (5 new items, 11 edits, 2 schema changes)
  • 8 component updates
  • 5 variable changes
  • 8个页面共34次页面修改
  • 22次类/样式更新
  • 18次CMS内容变更(5个新项、11次编辑、2次架构变更)
  • 8次组件更新
  • 5次变量变更

Team Activity

团队活动

Team MemberChangesTop Activity
Sarah Chen42Page edits, style updates
Alex Kim31CMS content, components
Jordan Lee17Styles, publishing, backups
团队成员变更数主要活动
Sarah Chen42页面编辑、样式更新
Alex Kim31CMS内容、组件操作
Jordan Lee17样式调整、站点发布、备份

Action Items

行动项

  • ⚠️ 28 changes are unpublished — consider reviewing and publishing
  • 🧩 8 component changes may affect shared layouts — verify before publish
  • 💾 Last backup: April 14 — consider creating a fresh backup

Generated from Webflow Site Activity Log

Would you like to:
1. Filter to a specific user's changes
2. Break down unpublished changes in detail
3. Regenerate with a different date range
4. Switch to a quick summary (counts only) or detailed per-event view
5. Export as JSON instead of markdown
  • ⚠️ 28项未发布变更——建议审核并发布
  • 🧩 8次组件变更可能影响共享布局——发布前请验证
  • 💾 最后一次备份:4月14日——建议创建新备份

由Webflow站点活动日志生成

您是否需要:
1. 筛选特定用户的变更
2. 详细拆解未发布变更
3. 按不同日期范围重新生成
4. 切换为快速汇总(仅统计)或详细的按事件视图
5. 导出为JSON格式而非markdown

Guidelines

指南

Enterprise-Only Access

仅企业版可访问

Plan Requirement:
  • list_site_activity_logs
    is available only on Enterprise hosting plans
  • If the API returns a permissions error, clearly inform the user:
    ⚠️ Site Activity Logs require an Enterprise hosting plan.
    This site does not appear to have Enterprise access.
  • Do not retry on permissions errors — the issue is plan-level, not transient
计划要求:
  • list_site_activity_logs
    仅对企业版托管计划开放
  • 如果API返回权限错误,请明确告知用户:
    ⚠️ 站点活动日志需要企业版托管计划。
    此站点似乎没有企业版访问权限。
  • 不要重试权限错误——问题源于计划级别,而非临时故障

API Constraints

API限制

Pagination:
  • Maximum 100 events per request
  • Use
    offset
    to paginate: first call offset=0, second call offset=100, etc.
  • 100 events typically covers approximately one week for an active enterprise site
  • No native date filtering — all filtering must be done client-side after fetching
When to paginate:
  • User asks for more than one week of activity
  • User needs a complete picture and first page returns exactly 100 events
  • Always tell the user how much data you have: "Showing the last 93 events (Apr 10–16)"
Rate awareness:
  • Avoid unnecessary pagination — fetch only what is needed to answer the question
  • If user asks "any publishes recently?" — 100 events is likely enough
  • If user asks "full month of activity" — explain the limitation and paginate up to 300 events maximum
分页:
  • 单次请求最多返回100个事件
  • 使用
    offset
    参数分页:第一次调用offset=0,第二次调用offset=100,以此类推
  • 对于活跃的企业版站点,100个事件通常约涵盖一周的活动
  • 无原生日期筛选——所有筛选必须在获取数据后在客户端完成
何时分页:
  • 用户请求超过一周的活动
  • 用户需要完整数据,且第一页恰好返回100个事件
  • 始终告知用户已获取的数据范围:"显示最近93个事件(4月10日–16日)"
速率注意事项:
  • 避免不必要的分页——仅获取回答问题所需的数据
  • 如果用户问"近期有发布吗?"——100个事件可能足够
  • 如果用户问"整月的活动"——说明限制并最多分页获取300个事件

Error Handling

错误处理

Common errors:
  • 403 / Permission denied: Enterprise plan required — inform user clearly
  • 404 / Site not found: Verify site ID, offer to list available sites
  • Empty results: Site may have no recent activity — confirm with user and check site details
Graceful degradation:
  • If site details fetch fails, still attempt activity logs
  • If pagination fails mid-way, report what was successfully fetched
  • Always show partial results rather than nothing
常见错误:
  • 403 / 权限拒绝:需要企业版计划——明确告知用户
  • 404 / 站点未找到:验证站点ID,提供列出可用站点的选项
  • 空结果:站点可能无近期活动——与用户确认并检查站点详情
优雅降级:
  • 如果获取站点详情失败,仍尝试获取活动日志
  • 如果分页中途失败,报告已成功获取的数据
  • 始终展示部分结果而非无结果