vr-shopxo-plugin/docs/05_AI_PARTICIPATION.md

157 lines
5.4 KiB
Markdown
Raw Normal View History

# ShopXO AI 参与可行性分析
> 调研日期2026-04-14
> 目标:评估 AI 参与 ShopXO 可视化搭建的可能性边界
---
## 一、ShopXO 页面系统分类
ShopXO 的前端页面分两类AI 可参与度截然不同:
| 类型 | 描述 | AI 可参与度 | 原因 |
|---|---|---|---|
| **DIY 拖拽页面** | 首页、专题页、楼层展示 | ❌ 极低 | JSON 配置私有,无文档,拖拽生成 |
| **代码页面** | 商品详情、订单、用户中心、插件页 | ✅ 完全可行 | PHP 模板 / Vue 组件,完全可控 |
| **CustomView 页面** | Ace 编辑器生成的自定义页面 | ✅✅ 极高 | 纯 HTML/CSS/JSAI 可直接生成 |
---
## 二、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 ← 商品页 HookAI 可写)
│ └── User.php ← 用户中心 HookAI 可写)
├── Admin/
│ ├── Controller/ ← 后台管理AI 可写)
│ └── View/ ← 后台模板AI 可写)
└── api/
└── Controller/ ← APIAI 可写)
```
**所有文件都是标准 PHPAI 可完全掌控。**
---
## 四、AI 参与边界决策矩阵
| 代码可控程度 | 是否有公开文档 | 结果 |
|---|---|---|
| 可直接改 | 有 | ✅ 完全可行 — API/插件/CustomView |
| 可直接改 | 无 | ✅ 完全可行 — 商品页 Hook/用户中心 Hook |
| 只能读/生成 | 有 | ⚠️ 有限可行 — 订单通知/邮件模板 |
| 只能读/生成 | 无 | ❌ 不可行 — DIY 拖拽配置/主题布局 |
---
## 五、AI 参与路线图
### Phase 1: AI 100% 主导(无人工干预)
- 插件 Service 层BaseService.php、事件监听器
- 票务专用 API场次查询、QR 生成、核销)
- CustomView 页面(票务介绍、活动说明等静态页面)
- 后台管理页(插件配置界面)
### Phase 2: AI + 人工协作50/50
- 商品详情页 HookAI 生成票务 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 编辑器并保存。