我做INS矩阵管理系统时，菜单是这样设计的（附设备抽象思路）

本文转载自 51CTO 博客作者「大鹏AI教育」的原创文章《我做INS矩阵管理系统时，菜单是这样设计的（附设备抽象思路）》，原文链接：https://blog.51cto.com/u_12805695/14594576

本文仅作技术学习与自动化方案参考，版权归原作者所有，转载请以原文授权要求为准。

我是张大鹏，专注 AI 应用开发和出海电商自动化多年。

最近在做一个 INS 矩阵管理系统，简单说就是：用一套系统管理几十上百个 Instagram 账号，涉及账号注册、内容发布、自动回复、数据采集等各种运营操作。

在做系统的过程中，菜单怎么设计这个问题困扰了我很久。今天就把我的思考过程分享出来，供大家参考。

背景：踩过的坑

做这种多账号管理系统，很多人第一反应是"简单"——做个账号列表，每个账号绑定一个浏览器配置，然后调 API 操作不就完了吗？

我也是这么想的，直到开始真正动手。

第一版设计：账号直接绑定设备

最早的方案是这样的：

账号A → 绑定 → AdsPower配置001
账号B → 绑定 → AdsPower配置002
账号C → 绑定 → 云手机001
账号D → 绑定 → 云手机002

看起来没问题，但实际用起来要命：

场景1：换设备

运营人员："AdsPower 那个电脑坏了，能不能把账号 A 迁移到云手机上？"

我："...需要改数据库，手动操作，有风险"

场景2：新设备接入

我："我们接入了新云手机平台，要怎么加进去？"

开发："...这个改动比较大，要把整个账号模块重构"

场景3：多设备协同

运营人员："我想让账号 A 今天用 AdsPower，明天用云手机，分时段运营"

我："...这个真做不到"

问题根源

回头看，第一版设计的根本问题是：把账号和设备绑死在一起了。

账号不仅仅是"账号"，它还有：

• 当前登录的设备
• 历史用过的设备
• 设备的指纹信息
• 绑定的代理 IP
• 各种配置参数

当这些全部耦合在一起，换设备 = 改账号 = 牵一发动全身。

核心思路：账号与设备分离

痛过一次之后，我开始重新思考这个问题。

关键洞察：账号是账号，设备是设备，它们之间应该是多对多的绑定关系，而不是一对一。

类比一下更好理解：

餐厅系统：
- 顾客 = 账号
- 餐桌 = 设备
- 顾客坐哪桌 = 绑定关系

今天顾客 A 坐餐桌1，明天换餐桌2，顾客还是那个顾客
今天餐桌1空着，可以安排顾客 B 坐

把这个思路落地到系统设计中：

菜单架构设计

基于"账号设备分离"的思路，我设计了一套菜单结构：

📱 INS矩阵管理系统
│
├── 🖥️ 设备管理              （一级菜单）
│   ├── 全部设备
│   ├── AdsPower 设备
│   ├── 云手机设备
│   └── 添加设备
│
├── 👤 账号管理              （一级菜单）
│   ├── 全部账号
│   ├── 账号分组
│   ├── 批量导入
│   └── 账号详情
│
├── 🎮 设备控制              （一级菜单）
│   ├── 启动设备
│   ├── 批量启动
│   ├── 远程桌面
│   └── 批量执行
│
├── 📝 内容管理              （一级菜单）
│   ├── 发布帖子
│   ├── 定时任务
│   └── 草稿箱
│
├── ⚡ 自动化                （一级菜单）
│   ├── 工作流
│   ├── 任务队列
│   └── 执行日志
│
└── ⚙️ 系统设置
    ├── AdsPower 配置
    ├── 云手机 配置
    └── API 配置

（一）设备管理

这是整个系统的基础模块。

核心功能：

设计要点：

• 设备按类型分组，但列表统一
• 每个设备有唯一 ID，作为调用的标识
• 设备状态实时更新

（二）账号管理

账号管理与设备是独立的。

核心功能：

关键设计：

• 账号不存储设备指纹信息，只记录"当前绑定哪个设备"
• 切换设备是原子操作，一键完成
• 历史绑定记录可查

（三）设备控制

这里是最"硬核"的部分——直接操作设备。

核心功能：

技术实现：

• AdsPower 通过 MCP 协议控制
• 云手机通过厂商 API 控制
• 统一封装成"设备操作层"

（四）内容管理 & 自动化

这两块是运营效率的核心，属于高级功能。

内容管理：

• 帖子发布（文字+图片+视频）
• 定时任务（定时发帖）
• 草稿箱（预存内容）

自动化：

• 工作流编排（定义操作步骤）
• 任务队列（排队执行）
• 执行日志（记录每次操作）

设备抽象层：核心实现

什么是设备抽象层？

设备抽象层是整个架构的核心。它把各种不同设备的操作封装成统一接口：

┌─────────────────────────────────────────┐
│           上层业务逻辑                   │
│   （账号管理、内容发布、自动化）          │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│           设备抽象层                     │
│   ┌─────────┐  ┌─────────┐  ┌────────┐ │
│   │AdsPower │  │云手机   │  │其他设备│ │
│   │适配器   │  │适配器   │  │适配器  │ │
│   └────┬────┘  └────┬────┘  └───┬────┘ │
└────────┼───────────┼───────────┼───────┘
         ↓           ↓           ↓
    AdsPower API  云手机API   其他API

统一接口定义

不管什么设备，对外暴露的操作接口是一样的：

插件化扩展

新增设备类型非常简单：

# 新增云手机适配器
class CloudPhoneAdapter(DeviceAdapter):
    """云手机设备适配器"""
    
    def open(self):
        # 调用云手机厂商 API
        pass
    
    def close(self):
        pass
    
    # 其他方法...

只要实现 DeviceAdapter 接口，就能无缝接入系统。

第一阶段菜单（精简版）

说了这么多，实际第一阶段我只做了这些功能：

📱 INS矩阵管理系统（第一阶段）
│
├── 🖥️ 设备管理
│   ├── 设备列表          ← 显示 AdsPower
│   └── 添加设备
│
├── 👤 账号管理
│   ├── 账号列表          ← 注册成功的账号
│   ├── 账号分组
│   └── 批量导入
│
├── ⚡ 自动化
│   ├── 执行记录
│   └── ➕ 新建任务
│       └── 🔄 批量注册账号  ← 第一阶段核心
│
└── ⚙️ 系统设置
    ├── AdsPower 配置
    └── 注册规则配置

理由：

• 第一阶段目标是"跑通注册流程"
• 菜单能省则省，先有最小闭环
• 后续按需扩展，不需要的功能先不做

总结

回顾整个设计过程，有几点心得：

预告：下一篇文章会详细介绍 INS 账号批量注册模块的设计，包括前端交互、参数配置、执行流程等完整设计。敬请期待。

作者：张大鹏

AI 应用开发 / 跨境电商自动化从业者
专注领域：AI Agent、指纹浏览器、多账号矩阵管理
欢迎交流，有问题可在评论区留言