# USER ERP 0-1需求重构 - 06 VibeCoding页面验证记录 v1

## 文件信息

- 文件名称：`20260527_USER_ERP_0-1需求重构_06_VibeCoding页面验证记录_v1.md`
- 项目路径：`C:\XCODE\USER`
- 输出位置：`C:\XCODE\USER\output\docs`
- 当前版本：`v1`
- 最近更新：`2026-05-27`
- 所属阶段：Stage 1 完整业务需求
- 负责人：产品负责人 / 前端观察员
- 核心参与：业务负责人、USER运营、客服主管、渠道负责人、KOC/KOL负责人、技术负责人
- 文件目的：把现有 Vibe Coding / AI 原型作为需求验证材料，记录已覆盖能力、暴露缺口和 Stage 2 高保真模型输入。

## 验证原则

1. 原型不是生产代码，不作为正式系统底座。
2. 原型用于发现页面、字段、按钮、状态和流程缺口。
3. 验证重点不是“页面能不能打开”，而是“需求是否完整、业务对象是否统一、每日操作是否可执行”。
4. 阶段1必须记录原型未覆盖的需求域，特别是 KOC/KOL、客服管理、需求计划匹配和复盘口径。

## 验证材料

| 材料 | 用途 | 结论 |
| --- | --- | --- |
| `C:\XCODE\USER\input\user-review-system` | React/Vite原型，含计划、测评人、订单、客服、渠道、风险、看板；入口参考 `src\App.tsx`、`src\config\routes.tsx`、`src\config\menu.tsx` | 覆盖面较广，可作为页面/字段参考 |
| `C:\XCODE\USER\input\user-review-system\docs\review-order-PRD.md` | 回评/测评订单详细PRD | 订单页面细，但只是局部，不足以代表ERP主流程 |
| `C:\XCODE\USER\input\user-review-system\docs\review-order-architecture.md` | 订单页面技术架构 | 可参考组件拆分和待确认问题 |
| `C:\XCODE\USER\src\user_erp_mvp_admin_prototype_v10.html` | 既有 v10 HTML 原型 | 可参考早期管理端页面，但不直接复用为新系统底座 |
| `C:\XCODE\USER\input\用户运营系统-单文件.html` | 大型单文件运营系统原型 | 可参考全局菜单和字段，但不直接复用 |
| `C:\XCODE\USER\input\amazon_operator_test_entry.html` | 亚马逊提评入口原型 | 可参考需求提报、IM账号、推送策略 |
| `C:\XCODE\USER\input\客服执行.html` | 客服执行/管理原型 | 客服核心需求的重要参考 |
| `C:\XCODE\USER\input\IM 推送业务流.mm` | IM业务流脑图 | IM分层和流转最完整 |

## user-review-system 验证

### 已覆盖能力

| 模块 | 已覆盖 |
| --- | --- |
| 菜单/路由 | 工作台、评价计划、评价人管理、测评订单、回评订单、客服中心、渠道推送、风险中心、数据看板 |
| 计划 | 测评计划、回评计划、免评计划，含列表、表单、详情、关联推送/订单 |
| 测评人 | 测评人列表、详情、表单、额度、订单、风险、联系记录 |
| 订单 | 测评订单、回评订单、上传订单、上传回评、请款、返款、详情抽屉 |
| 客服 | 工单池、聊天、聊天记录、答应配合、客服绩效看板 |
| 渠道 | 推送任务、IM推送、IM卡片、IM/EDM配置 |
| 风险 | 风险事件、黑名单、退款比对 |
| 看板 | 计划、ASIN、客服绩效 |

### 暴露的缺口

| 缺口 | 影响 | 后续处理 |
| --- | --- | --- |
| 需求池与计划生成链路弱 | 无法解释需求如何变成计划 | Stage 2 需新增需求与计划调度中心 |
| 计划匹配资源视图不足 | 人群、客服、渠道、H5/卡片、风险没有统一调度 | 需新增执行匹配看板 |
| 客服管理不完整 | 排班、出勤、目标、首次回复、转化绩效不足 | 结合客服执行原型补齐 |
| KOC/KOL需求域不足 | 线索、任务、内容、带货、佣金缺失 | 阶段1必须补出完整需求 |
| 订单PRD局部过细 | 容易用订单页面替代ERP主流程 | 保留为订单模块参考 |
| 状态枚举不统一 | 测评、回评、返款、计划、客服状态口径混乱 | Stage 2需统一状态机 |
| Mock 数据含临时品类 | 部分示例与真实业务不一致 | 只取字段结构，不取业务事实 |

## 用户运营系统单文件验证

### 已覆盖

- USER评价业务闭环系统的全局菜单雏形。
- 产品、计划、订单、客服、风险、真实人、用户信息等多类字段。
- 较多运营筛选、状态、详情、操作入口。

### 缺口

- 文件过大，页面和数据逻辑混杂，不适合做正式底座。
- 未清晰区分需求完整范围和V1实现范围。
- KOC/KOL相关需求不完整。
- 客服核心执行与管理需要与 `客服执行.html` 合并分析。
- 需求到计划再到执行匹配的调度视图不足。

## amazon_operator_test_entry 验证

### 已覆盖

- 亚马逊提评入口。
- 提评单列表。
- IM推送。
- IM账号管理。
- 新建提评单。
- 推送策略。
- 卡片内容管理。
- 业务类型：测评、免评、回评。

### 可纳入需求

- 提评需求提报字段：站点、ASIN、商品、关键词、关键词链接、品牌、新品状态、要求数量、店铺、原因、备注。
- IM账号和身份管理：官方客服、品牌客服、达人、内部/外部品牌。
- 推送策略：用户标签、去除标签、优先级、间隔时间、内容形式、跳转链接。

### 缺口

- 未打通完整需求池和计划对象。
- 提评入口与USER运营调度中心的关系需重构。
- IM账号管理需与渠道配置、权限和风险联动。

## 客服执行原型验证

### 已覆盖

- 客服执行看板。
- 首页Dashboard。
- 出勤管理。
- 排班管理。
- 工单管理。
- 回复统计。
- 转化绩效。
- 目标管理。
- 角色权限：客服与主管/管理员视角。

### 可纳入需求

| 能力 | 说明 |
| --- | --- |
| 工单自动分配 | 在线优先、按工单量平均、最大工单数 |
| 客服视角 | 只看自己工单、绩效和目标 |
| 主管视角 | 查看团队数据、调整工单、排班和目标 |
| 绩效统计 | RSO/RDO登记订单、上评、完成率 |
| 出勤/排班 | 早班、午班、晚班、迟到、早退、请假、缺勤 |

### 缺口

- 与评价计划、渠道推送和订单履约的联动需要补强。
- 客服容量尚未进入需求与计划匹配。
- 客服误登记、投诉、转移失败、排班不足等异常需要补全。

## IM推送业务流验证

### 已覆盖

- 用户分层：未参与、参与过、长期测评人。
- 推送前风控校验。
- 回评卡片、测评卡片、免评产品、催评消息。
- 用户提交订单号、返款账号、评论截图/链接。
- 订单号核实和客服补全。
- 财务返款提醒。
- 自动打标体系。
- 店铺紧急催评。

### 可直接作为Stage 2输入

- IM用户分层。
- 核心标签体系。
- 每次互动复检。
- 未完成流程的标签与自动通知。
- 长期测评人转免评策略。

### 缺口

- IM流程需要与统一计划、额度台账、客服工单和风险事件对象对齐。
- 文档中提到的“当天测评计划需要刷的名额”需要接入计划匹配。

## KOC/KOL需求验证

### 已有线索

- `KOC 每日工作流.md` 提到账号、标签、风险、新增线索、用户分层、自动打标、任务去重、回复、订单、返款、Review、带货、风险。
- `商家KOL商业服务系统-USER项目知识迁移清单.md` 提供服务包、KOC/KOL分层、佣金原则、内容分级和推荐分发接口意识。
- 现有原型仅零散覆盖KOC/KOL，未形成完整中心。

### 阶段1必须补出的需求

- KOC/KOL线索池。
- KOC/KOL档案和分层。
- KOC/KOL与测评人/真实人的身份关系。
- 内容任务、样品/免评、带货任务。
- 内容审核、链接、Code、订单归因。
- 佣金计算与结算接口。
- KOC/KOL风险和异常。

### 阶段建议

- V1必做：免评补单相关的KOC/KOL入口、标签、风险和任务关联。
- V1预留：KOC/KOL档案、线索池、合作状态。
- V2实现：内容审核、带货归因、佣金结算、商家服务包完整后台。

## 进入Stage 2的输入清单

| 输入 | 说明 |
| --- | --- |
| 需求与计划调度中心 | 需要新设计，不应从现有订单页面改 |
| 今日作战台 | 需要按OKR和岗位每日工作方式设计 |
| 客服执行/管理 | 可综合 `客服相关模块.md` 和 `客服执行.html` |
| IM推送 | 可基于 `IM 推送业务流.mm` 和 user-review-system IM页面 |
| 订单页面 | 可参考 review-order PRD，但需合并测评/回评/免评口径 |
| 测评人/真实人 | 可参考 `测评信息字段管理.xlsx` 和数据对象v3 |
| KOC/KOL中心 | 现有原型不足，需要新建需求模型 |
| 风险中心 | 可参考现有风险页面，但需扩展KOC/KOL与计划匹配异常 |

## 不能直接继承的内容

- 不能直接继承 Vibe Coding 的文件结构作为正式工程结构。
- 不能把 mock 数据当业务事实。
- 不能把回评/测评订单PRD当成整个 ERP PRD。
- 不能因为 V1不实现完整KOC/KOL平台，就在阶段1删除KOC/KOL需求。
- 不能把客服降级为“工单页面”，客服是核心执行和转化资源。

## Gate 1 - Vibe Coding验证完成条件

- 已记录所有原型的可用需求点。
- 已记录原型不能支撑的业务缺口。
- 已确认正式系统需要重新做 Stage 2 高保真模型。
- 已确认KOC/KOL、客服、需求计划匹配是现有原型的主要补强方向。
