5.4 KiB

Raw Blame History

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 结构：

{
  "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 无法参与的原因：

JSON 结构完全私有 — 无任何文档描述各字段含义
组件参数不透明 — ShopComponentsGoods 的 params 字段需要对接前端 JS 组件代码才能理解
无逆向工程路径 — 即使 AI 读取了数据库中的 JSON，也无法推断如何生成合法的配置
前端 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 编辑器并保存。

5.4 KiB Raw Blame History Unescape Escape