Skills
skills/mercury-api.wepieoa.com/activity-config-migrator

activity-config-migrator

SKILL.md

活动配置迁移工具

基于源活动的需求文档和配置，结合目标活动的需求文档，智能生成满足新需求的 JSON 配置。

核心功能

  1. 需求对比分析 - 识别源活动和目标活动的需求差异
  2. 配置结构理解 - 解析源配置的结构和各字段含义
  3. 智能配置生成 - 根据差异分析，调整配置以满足新需求
  4. 验证与建议 - 提供配置验证检查清单和优化建议

适用场景

  • 迁移活动配置到新活动
  • 复用已有活动配置并适配新需求
  • 批量创建相似活动配置
  • 活动配置模板化

🤖 AI 执行指令

当用户调用此 skill 时，请按照以下步骤执行：

步骤 1：收集必要信息

首先询问用户提供三个必要信息（如果用户已经提供，则跳过询问）：

请提供以下信息以进行活动配置迁移：

1. **源活动需求文档**
   - 飞书文档链接，或
   - Markdown 文件路径，或
   - 直接粘贴需求文档内容

2. **源活动配置 JSON**
   - 配置文件路径，或
   - 直接粘贴 JSON 内容

3. **目标活动需求文档**
   - 飞书文档链接，或
   - Markdown 文件路径，或
   - 直接粘贴需求文档内容

处理用户输入：

  • 如果用户一次性提供了所有信息，直接进入下一步
  • 如果用户分多次提供，记录已提供的内容
  • 验证提供的信息是否完整

步骤 2：读取源数据

根据用户提供的信息类型，采取相应的读取策略：

2.1 处理飞书文档

如果用户提供飞书文档链接，使用 feishu2md skill 转换：

# 调用 feishu2md skill
/feishu2md <飞书文档链接>

注意事项：

  • 确保环境变量 FEISHU_APP_ID 和 FEISHU_APP_SECRET 已设置
  • 如果转换失败，提示用户提供 Markdown 格式或文本内容

2.2 读取本地文件

如果用户提供文件路径，使用 Read 工具读取：

# 读取需求文档
Read tool: /path/to/requirement.md

# 读取配置文件
Read tool: /path/to/config.json

2.3 处理直接文本

如果用户直接粘贴内容，直接使用该内容进行分析。

数据验证：

  • 验证配置 JSON 格式是否正确
  • 验证需求文档是否包含足够的信息
  • 如果数据不完整或格式错误，要求用户补充或修正

步骤 3：需求差异分析

对比源活动需求和目标活动需求，识别关键差异：

3.1 分析维度

基本信息对比：

  • 活动名称、活动 ID、活动时间
  • 活动类型（任务、抽奖、排行榜、签到等）
  • 活动周期（单次、每日、每周、多阶段等）

玩法规则对比：

  • 参与条件变化（等级限制、VIP限制、地区限制等）
  • 任务/目标差异（任务类型、完成条件、数量要求等）
  • 奖励机制变化（奖励类型、数量、发放方式等）
  • 计算逻辑差异（积分计算、进度计算、排名规则等）

配置结构对比：

  • 新增的配置项
  • 删除的配置项
  • 修改的配置项（字段名、类型、含义变化）
  • 嵌套结构变化

业务逻辑对比：

  • 触发条件变化
  • 流程节点差异
  • 状态管理变化
  • 数据统计差异

3.2 输出分析结果

以结构化方式输出分析结果：

## 需求差异分析

### 1. 基本信息变化

| 项目 | 源活动 | 目标活动 | 影响 |
|------|--------|----------|------|
| 活动名称 | [源] | [目标] | 配置中需更新名称字段 |
| 活动时间 | [源] | [目标] | 需调整时间配置 |
| 活动类型 | [源] | [目标] | 可能需要调整配置结构 |
| ... | ... | ... | ... |

### 2. 玩法规则变化

#### 参与条件
- **源活动**：[描述源活动的参与条件]
- **目标活动**：[描述目标活动的参与条件]
- **影响配置**：需要调整 `xxx` 字段

#### 任务/目标
- **源活动**：[描述源活动的任务目标]
- **目标活动**：[描述目标活动的任务目标]
- **影响配置**：需要修改 `tasks` 数组配置

#### 奖励机制
- **源活动**：[描述源活动的奖励机制]
- **目标活动**：[描述目标活动的奖励机制]
- **影响配置**：需要调整 `rewards` 配置

### 3. 配置结构变化

#### 新增字段
- `field1`: [用途说明]
- `field2`: [用途说明]

#### 删除字段
- `old_field1`: [原用途]
- `old_field2`: [原用途]

#### 修改字段
- `field3`: [变化说明]
- `field4`: [变化说明]

### 4. 迁移策略

#### 保留配置（无需修改）
- `基础结构字段`
- `通用逻辑字段`
- ...

#### 调整配置（需要修改）
- `活动基本信息` → 更新为目标活动信息
- `任务配置` → 根据新需求调整
- ...

#### 新增配置（需要添加）
- `新功能配置` → 根据目标活动新增需求添加
- ...

#### 删除配置（不再需要）
- `废弃功能配置` → 移除源活动中已废弃的配置
- ...

步骤 4：配置迁移生成

基于需求分析结果，生成新的配置 JSON。

4.1 迁移原则

  1. 保留可复用配置

    • 对于需求未变化的部分，保留源配置
    • 保持配置项的原始结构和格式

  2. 调整变化配置

    • 根据新需求调整配置值
    • 处理字段重命名、类型变化
    • 更新时间、名称等基本信息

  3. 添加新增配置

    • 为新增需求添加对应配置项
    • 使用合理的默认值或示例值
    • 添加必要的注释说明

  4. 移除废弃配置

    • 移除不再需要的配置项
    • 清理无效的嵌套结构
    • 保持配置简洁

  5. 保持一致性

    • 确保配置项之间的关联正确
    • 验证依赖关系
    • 保持命名风格一致

4.2 配置生成步骤

步骤 4.2.1：解析源配置结构

  • 识别配置的层级结构
  • 理解各字段的业务含义
  • 找出配置项之间的依赖关系
  • 识别可重复使用的配置块

步骤 4.2.2：映射配置到需求

  • 将源配置项映射到源需求的具体功能点
  • 识别哪些配置对应哪些需求
  • 建立配置-需求对应表

步骤 4.2.3：应用差异调整

  • 根据需求差异，逐项调整配置
  • 处理字段重命名：保持语义一致性
  • 处理类型变化：确保数据格式正确
  • 更新关联值：如 ID、名称等

步骤 4.2.4：补充缺失配置

  • 为新增需求添加配置项
  • 参考源配置的结构和风格
  • 使用占位符标注需要人工确认的值

步骤 4.2.5：清理无用配置

  • 移除不再需要的配置项
  • 删除无效的注释
  • 整理配置结构，保持清晰

步骤 5：输出迁移结果

以清晰的格式输出迁移后的配置和说明：

# 活动配置迁移结果

> **源活动**：[源活动名称]
> **目标活动**：[目标活动名称]
> **生成时间**：[时间]

---

## 一、迁移后的配置 JSON

```json
{
  "_comments": "这是迁移后的配置，请仔细检查并根据实际需求调整",
  "activity_id": "目标活动ID",
  "activity_name": "目标活动名称",
  "start_time": "开始时间",
  "end_time": "结束时间",

  // ... 完整的配置内容

  "tasks": [
    {
      "task_id": 1,
      "task_name": "任务名称",
      // ... 任务配置
    }
  ],

  "rewards": [
    {
      "reward_id": 1,
      "reward_type": "coin",
      // ... 奖励配置
    }
  ]
}

二、配置变更说明

1. 保留的配置项

以下配置项从源活动保留，无需修改：

  • 基础结构字段: [说明]
  • 通用逻辑字段: [说明]
  • xxx: [说明]

2. 调整的配置项

以下配置项根据新需求进行了调整：

配置项 原值 新值 调整原因
activity_id [源值] [新值] 目标活动的 ID
activity_name [源值] [新值] 目标活动的名称
start_time [源值] [新值] 目标活动的时间
... ... ... ...

3. 新增的配置项

以下配置项为目标活动新增：

  • 新字段1: [新值] - [用途说明]
  • 新字段2: [新值] - [用途说明]
  • 新字段3: [新值] - [用途说明]

4. 移除的配置项

以下配置项不再需要，已移除：

  • 废弃字段1: [移除原因]
  • 废弃字段2: [移除原因]

三、需要人工确认的配置项

⚠️ 以下配置项使用了占位符或默认值，需要人工确认并调整：

  • activity_id: 请确认目标活动的实际 ID
  • reward_id: 请确认奖励物品的实际 ID
  • task_target: 请确认任务目标数值是否合理
  • time_config: 请确认时间配置是否符合运营计划
  • ...

四、验证检查清单

在使用此配置前，请完成以下检查：

  • 活动基本信息已更新（ID、名称、时间）
  • 玩法规则配置与目标需求一致
  • 奖励配置正确（类型、数量、ID）
  • 时间配置合理（开始时间、结束时间、阶段时间）
  • 关联配置完整（任务 ID、物品 ID、用户 ID 等）
  • 没有遗留的源活动数据
  • 所有占位符已替换为实际值
  • 配置格式正确（JSON 语法无误）
  • 字段类型正确（数字、字符串、数组等）
  • 依赖关系正确（如任务依赖、奖励关联等）

五、优化建议

  1. [建议1]: [具体说明]
  2. [建议2]: [具体说明]
  3. [建议3]: [具体说明]

六、风险提示

⚠️ 迁移风险：

  • [列出可能的风险点]
  • [需要特别注意的地方]
  • [可能影响的其他系统]

生成工具：Claude Code /activity-config-migrator skill


### 步骤 6：后续支持

询问用户是否需要额外的支持：

✅ 活动配置迁移完成！

是否需要：

  1. 保存配置到文件
  2. 进一步优化某个配置项
  3. 解释某个配置的作用
  4. 进行配置验证测试

---

## 特殊情况处理

### 情况 1：飞书文档无法访问

如果飞书文档链接无法访问，提示用户：

⚠️ 无法访问飞书文档

请提供以下替代方式：

  1. 导出文档为 Markdown 并粘贴内容
  2. 提供文档的文本内容
  3. 提供本地 Markdown 文件路径

### 情况 2：配置格式复杂或不规范

如果源配置结构复杂或不规范，询问用户：

⚠️ 源配置结构较为复杂

为确保迁移准确性，请确认：

  1. 配置的顶层结构含义是什么？
  2. 关键字段的业务含义是什么？
  3. 是否有隐藏的依赖关系或特殊逻辑？
  4. 是否有部分配置是冗余的或已废弃的？

### 情况 3：需求差异过大

如果源活动和目标活动差异很大，提示用户：

⚠️ 检测到源活动和目标活动差异较大

相似度评估：约 [X]%

建议：

  1. 仅复用通用配置（如基础结构、时间配置等）
  2. 手动编写核心玩法配置
  3. 或选择更相似的源活动进行迁移

是否继续迁移？


### 情况 4：配置项含义不明确

如果遇到难以理解的配置项，询问用户：

⚠️ 发现以下配置项含义不明确：

  • field_xxx: [当前值]
  • unknown_config: [当前值]

请说明这些配置项的用途，以便正确迁移。


---

## 使用场景示例

### 场景 1：迁移相似活动配置

**用户输入**：

源活动：2025年春节活动 目标活动：2025年情人节活动 两个活动的玩法类似，都是任务+抽奖


**AI 执行流程**：
1. 收集源活动需求、配置和目标需求
2. 识别差异（主要是时间、主题、奖励）
3. 保留任务结构和抽奖逻辑
4. 更新活动信息和奖励配置
5. 输出迁移后的配置和检查清单

### 场景 2：复用活动模板

**用户输入**：

我有一个通用的签到活动配置 想基于它创建一个新的签到活动 新活动增加了连续签到奖励


**AI 执行流程**：
1. 读取通用签到配置
2. 分析目标活动的连续签到需求
3. 保留基础签到逻辑配置
4. 新增连续签到奖励配置
5. 输出完整的配置和使用说明

### 场景 3：批量创建地区活动

**用户输入**：

源活动：美国地区活动 目标活动：欧洲地区活动（5个国家） 玩法相同，只需调整时间和地区限制


**AI 执行流程**：
1. 读取美国地区活动配置
2. 识别需要调整的地区相关配置
3. 保留玩法和奖励配置
4. 批量生成5个国家的配置
5. 输出所有配置和差异说明

---

## 工具使用说明

在执行迁移过程中，你可以使用以下工具：

### 必须使用的工具

- **Read**: 读取本地配置文件或需求文档
- **Write**: 保存生成的配置文件（可选）
- **Skill: feishu2md**: 转换飞书文档为 Markdown
- **AskUserQuestion**: 需要用户确认或补充信息时询问

### 可选使用的工具

- **Grep**: 搜索配置文件中的特定字段（当配置文件很大时）
- **Bash**: 执行 JSON 格式验证（如 `jq` 命令）

### 禁止使用的工具

- **Edit**: 不要直接编辑用户的源配置文件
- **Task**: 不需要启动其他 agent
- **Explore**: 配置迁移不需要探索代码库

---

## 注意事项

### 数据安全

- 不要在配置中包含敏感信息（密钥、密码等）
- 如果源配置包含敏感信息，在输出时用占位符替换
- 提醒用户检查配置中是否有需要保密的数据

### 配置验证

- 生成的配置必须是有效的 JSON 格式
- 所有必需字段都应该有值（或占位符）
- 字段类型应该正确（数字、字符串、数组等）
- 嵌套结构应该完整

### 迁移质量

- 优先保证配置的正确性，其次是完整性
- 对于不确定的配置项，使用占位符并标注
- 提供详细的变更说明，便于用户理解
- 给出明确的检查清单，帮助用户验证

### 用户交互

- 及时向用户反馈进度
- 对于重要决策，询问用户意见
- 用清晰的格式展示分析结果
- 提供可操作的建议和下一步行动

---

## 技术说明

### 支持的配置格式

- ✅ JSON 格式（标准配置格式）
- ✅ 带注释的 JSON（使用 `_comments` 字段）
- ⚠️ YAML 格式（需要转换为 JSON）
- ❌ 其他格式（需要先转换）

### 需求文档格式

- ✅ Markdown 格式
- ✅ 飞书文档（自动转换）
- ✅ 纯文本描述
- ⚠️ Word/PDF（需要用户手动转换）

### 配置复杂度支持

- **简单配置**（< 50 行）：完全自动迁移
- **中等配置**（50-200 行）：自动迁移 + 少量人工确认
- **复杂配置**（> 200 行）：辅助迁移 + 较多人工确认

### 性能说明

- 小配置（< 50 行）：10-20 秒
- 中等配置（50-200 行）：20-40 秒
- 大配置（> 200 行）：40-60 秒

---

## 常见问题

### Q1: 如果源配置和目标需求差异很大怎么办？

**A**: 工具会评估相似度，如果差异超过 50%，会建议：
- 仅复用通用配置部分
- 手动编写差异较大的部分
- 或选择更相似的源活动

### Q2: 生成的配置可以直接使用吗？

**A**: 不建议直接使用，应该：
1. 检查"需要人工确认的配置项"清单
2. 完成"验证检查清单"中的所有项
3. 在测试环境中验证配置
4. 确认无误后再用于生产环境

### Q3: 如何处理配置中的 ID（如活动 ID、物品 ID）？

**A**:
- 如果目标需求中明确了 ID，会自动填充
- 如果未明确，会使用占位符（如 `[ACTIVITY_ID]`）
- 在"需要人工确认的配置项"中会标注所有 ID 占位符

### Q4: 能否一次迁移多个配置？

**A**:
- 当前版本一次只能迁移一个配置
- 如需批量迁移，可以多次调用此 skill
- 未来版本可能会支持批量迁移

### Q5: 如果源配置包含代码逻辑怎么办？

**A**:
- 此 skill 仅处理 JSON 配置
- 代码逻辑部分无法自动迁移
- 会在输出中提示用户需要手动迁移代码

---

🎯 **最终目标**：帮助用户快速、准确地迁移活动配置，减少手动调整工作量，同时确保配置的正确性和完整性。
Installs
2
Source
mercury-api.wep…migrator
First Seen
Apr 13, 2026