# ShopXO AI 参与可行性分析

> 调研日期：2026-04-14
> 目标：评估 AI 参与 ShopXO 可视化搭建的可能性边界

---

## 一、ShopXO 页面系统分类

ShopXO 的前端页面分两类，AI 可参与度截然不同：

| 类型 | 描述 | AI 可参与度 | 原因 |
|---|---|---|---|
| **DIY 拖拽页面** | 首页、专题页、楼层展示 | ❌ 极低 | JSON 配置私有，无文档，拖拽生成 |
| **代码页面** | 商品详情、订单、用户中心、插件页 | ✅ 完全可行 | PHP 模板 / Vue 组件，完全可控 |
| **CustomView 页面** | Ace 编辑器生成的自定义页面 | ✅✅ 极高 | 纯 HTML/CSS/JS，AI 可直接生成 |

---

## 二、AI 完全无法参与：DIY 拖拽系统

### 2.1 为什么 AI 无法参与

DIY 系统生成的页面配置存储在 `sxo_diy.config` 表，格式为**私有 JSON 结构**：

```json
{
  "global": { "title": "首页" },
  "params": { ... },
  "items": [
    {
      "id": "uuid-xxx",
      "componentName": "ShopComponentsGoods",
      "moduleName": "goods",
      "params": {
        "isotopeItem": false,
        "layout": "leftright",
        "goodsCount": 6,
        "theme": "red"
      }
    },
    {
      "id": "uuid-yyy",
      "componentName": "ShopComponentsCustom",
      "moduleName": "custom",
      "params": {
        "html": "<div>自定义内容</div>"
      }
    }
  ]
}
```

**AI 无法参与的原因**：
1. **JSON 结构完全私有** — 无任何文档描述各字段含义
2. **组件参数不透明** — `ShopComponentsGoods` 的 `params` 字段需要对接前端 JS 组件代码才能理解
3. **无逆向工程路径** — 即使 AI 读取了数据库中的 JSON，也无法推断如何生成合法的配置
4. **前端 Vue3 组件硬编码** — 组件面板定义在前端 JS（`public/static/diy/js/entry/index-*.js`），后端无法感知可用组件

### 2.2 结论

> DIY 拖拽系统是 ShopXO 为**运营人员**提供的低门槛工具，不适合 AI 参与。
> 这是产品定位问题，不是技术问题。

---

## 三、AI 完全可参与：代码层（核心区域）

### 3.1 AI 可参与的区域

| 区域 | 技术栈 | AI 参与方式 |
|---|---|---|
| **商品详情页** | PHP 模板 + Hook 注入 | AI 写 Hook 注入票务选座 UI |
| **用户中心** | PHP 模板 + Hook 注入 | AI 写 Hook 注入票夹/订单列表 |
| **插件开发** | PHP | AI 写插件 Service + Controller |
| **CustomView 页面** | HTML/CSS/JS | AI 直接生成 Ace 编辑器内容 |
| **API 接口** | PHP Controller | AI 写新的 API 端点 |
| **后台管理页** | PHP + Smarty | AI 写后台插件管理页面 |

### 3.2 关键发现：CustomView 是 AI 参与的黄金入口

ShopXO 内置 **CustomView**（Ace Playground Web Component），路径 `/index/customview/index?id=xxx`。

**CustomView 的优势**：
- 三栏编辑器：HTML + CSS + JavaScript，实时预览
- 支持 ThinkPHP 模板语法（`{{$data.xxx}}`）
- 页面内容直接存储在数据库，可通过 API 操作
- **AI 可以直接生成 CustomView 的页面内容**

### 3.3 插件系统：AI 参与的最佳载体

```
app/plugins/vr_ticket/
├── config.json              ← 配置文件（AI 可写）
├── BaseService.php          ← 核心逻辑（AI 可写）
├── view/
│   ├── Goods.php           ← 商品页 Hook（AI 可写）
│   └── User.php            ← 用户中心 Hook（AI 可写）
├── Admin/
│   ├── Controller/         ← 后台管理（AI 可写）
│   └── View/               ← 后台模板（AI 可写）
└── api/
    └── Controller/         ← API（AI 可写）
```

**所有文件都是标准 PHP，AI 可完全掌控。**

---

## 四、AI 参与边界决策矩阵

| 代码可控程度 | 是否有公开文档 | 结果 |
|---|---|---|
| 可直接改 | 有 | ✅ 完全可行 — API/插件/CustomView |
| 可直接改 | 无 | ✅ 完全可行 — 商品页 Hook/用户中心 Hook |
| 只能读/生成 | 有 | ⚠️ 有限可行 — 订单通知/邮件模板 |
| 只能读/生成 | 无 | ❌ 不可行 — DIY 拖拽配置/主题布局 |

---

## 五、AI 参与路线图

### Phase 1: AI 100% 主导（无人工干预）

- 插件 Service 层（BaseService.php、事件监听器）
- 票务专用 API（场次查询、QR 生成、核销）
- CustomView 页面（票务介绍、活动说明等静态页面）
- 后台管理页（插件配置界面）

### Phase 2: AI + 人工协作（50/50）

- 商品详情页 Hook：AI 生成票务 UI 组件，人工选位置调试
- 用户中心票夹：AI 生成票夹列表，人工测试交互
- 微信小程序页面：AI 生成票务页面代码，人工 HBuilderX 编译发布

### Phase 3: 人工为主，AI 辅助

- DIY 页面布局：人工拖拽，AI 生成自定义组件内容
- 主题配色：人工选择，AI 生成自定义 CSS
- 营销活动页：人工设计，AI 生成内容填充

---

## 六、核心结论

> **DIY 拖拽系统是运营工具，不是开发接口。AI 无法也不应该参与 DIY 搭建。**

> **AI 的主战场是代码层：插件、Hook、API、CustomView、uni-app 页面。** 这些占票务项目开发工作量的 80%，AI 可以完全主导。

**分工建议**：
```
人工：DIY 页面编排、主题配色、运营配置
AI：  插件代码、前端页面、API、核销逻辑
```

**验证方式**：访问 `/index/customview/index` 创建页面，让 AI 生成 HTML/CSS/JS 填入 Ace 编辑器并保存。
