Archived
107 lines
11 KiB
Markdown
107 lines
11 KiB
Markdown
# 运营中心 · 活动模块重构 —— 需求记录
|
||
|
||
> 记录时间：2026-08-25
|
||
> 背景：活动模块（原「任务」模块）内容已全部清空（页签、布局、取数均已撤除，区入口与区标题保留），
|
||
> 本次重构从零定义这个模块「是什么、给谁看、管什么」。
|
||
> 本文档随用户口述逐条记录，定稿后整理为功能表。
|
||
|
||
## 一、原始需求记录
|
||
|
||
### 2026-08-25 · 核心概念：活动的定义 与 活动的实例（用户口述）
|
||
|
||
一个活动分成两个概念：
|
||
|
||
1. **活动的定义**
|
||
- 来源：把一个业务拆分成多个部分，其中的**一部分内容**成为一个活动；
|
||
- 活动要做的事：把**输入的数据**经过**一系列的动作**，变成**输出的数据**；
|
||
- 「数据」的形态不限：可能是一个 JSON 串、一个文件、一个统计结果，也可能是一个字符串；
|
||
- 一个活动**只会有一个定义**。
|
||
2. **活动的实例**
|
||
- 真正输入了一段数据给这个活动，活动经过一系列动作，产生了一个输出的数据；
|
||
- 一个活动可以有**多个实例**。
|
||
|
||
类比（用户原话的类比）：好比 Java 中的对象 —— 要使用一个对象，先**声明**这个类、声明里面有几个参数（对应**活动的定义**）；要真正用它，就 **new 一个对象并赋值**（对应**活动的实例**）。
|
||
|
||
补充确认（2026-08-25 用户定）：**活动创建的时候，输入与输出就已经定好了** —— 数据形态虽不限（JSON/文件/统计结果/字符串），但一个具体活动的定义，其输入输出的结构是声明清楚的（像 Java 参数带类型），不是跑到实例时才看。
|
||
|
||
### 2026-08-25 · L2 规划确认与补充（用户口述）
|
||
|
||
- **实例状态共 5 个**：进行中 / 待执行 / 已完成 / 驳回 / 失败；
|
||
- **创建实例**：先把入口留出来，功能待做；
|
||
- **运营概览小统计**：需要；
|
||
- **验收动作在工作台**，活动模块不管验收 —— L2 只展示状态；
|
||
- **激活/禁用都需要二次确认**；禁用会访问接口，**有实例时接口会提示无法禁用**（本期只做前端，暂不接接口，前端先把这个规则的样子做出来）；
|
||
- **L2 需要一个沙箱**：用来加载服务器返回的 HTML 页面（活动视图），先做一个版本看效果再改。
|
||
|
||
### 2026-08-25 · 版本号与版本迭代入口（用户口述）
|
||
|
||
- 活动卡片要展示**版本号**：表示当前已发布的活动属于哪个版本（有版本才显示）；
|
||
- 背景逻辑：因为活动**没有编辑和删除功能**，所以演进只能靠发新版本 —— 子页面（L2）应该有**版本迭代的入口**；
|
||
- 版本迭代功能怎么设计**回头再讨论**，本期只先把版本号加到卡片里。
|
||
|
||
### 2026-08-25 · L1 页面：两个页签（用户口述）
|
||
|
||
L1（模块首页 · 活动清单）需要一个**标签页**切换，因为活动分成两类：
|
||
|
||
1. **已发布上线**的
|
||
2. **审核中**的
|
||
|
||
### 2026-08-25 · 活动板块的六个功能（用户口述）
|
||
|
||
1. **活动的创建**（即创建定义）
|
||
2. **活动的展示**
|
||
3. **活动实例的创建**
|
||
4. **活动实例的展示**
|
||
5. **活动实例的编辑**
|
||
6. **活动实例的删除**
|
||
|
||
配套的规则（用户定）：
|
||
|
||
- **活动（定义）只允许创建，不允许编辑、不允许删除**；
|
||
- **活动创建需要审核，审核通过后才能展示**（进展示列表）；
|
||
- 活动实例**可能也不允许删除** —— 存疑，但先把删除规划出来，后续根据需求再调整。
|
||
|
||
### 2026-08-25 · 平台定位纠正（用户口述，推翻我此前的理解）
|
||
|
||
- 要做的**不是**只针对一个业务的生产环境系统，而是一个**平台**：以**活动为最小基点**，能串联整个业务的工作流；后续会有**多个类型不同的业务**接入平台。
|
||
- 目的：**减少人的工作量**，让 AI agent 在整个业务里做执行者。
|
||
- **每个活动有一个单独的 agent**，负责把这个活动的流程跑通。
|
||
- 人机分工：
|
||
- 业务的**规划**部分 → agent 来做；
|
||
- 规划出来但 **agent 无法完成的执行**部分 → AI 把执行层任务分配给某个人，这个人 = **活动负责人**；
|
||
- 负责人干两件事：① 做 AI 安排的执行任务；② 对 AI 做的规划任务、统计任务进行**验收**（责任承担 —— AI 不能承担责任，人担）。
|
||
- 系统架构已经完成；现在对**活动模块**重新规划：活动模块要能**根据业务需求创建各种各样的活动**，做的是「**活动的设计和运营**」。
|
||
|
||
## 二、澄清与决策
|
||
|
||
- 2026-08-25 · 纠正：产品形态是**可接多类业务的平台**，不是单一业务系统（界面顶栏「单组织 · ≤50 人 · 生产环境」是旧定位的遗留文案，理解时不要被它带偏）。
|
||
- 2026-08-25 · 活动模块的重新定位：**活动的设计和运营** —— 不再只是「任务的在途监控」（旧版任务模块的心智）。
|
||
- 2026-08-25 · **双台面合并方向（架构级决策）**：现有「设计中心 / 运营中心」的划分不合理，未来**只保留运营中心，设计是运营的一部分**。本次活动模块重构就按这个思路做 —— 模块内同时包含「设计」与「运营」；活动模块先做样板，**其他模块后续也按这个方式逐一重做**。
|
||
- 2026-08-25 · **需求工作方式（用户定的规矩）**：不拆讨论稿、不预设结构 —— 旧版活动模块的内容全部抛弃、暂不考虑；由用户口述「活动板块应该是什么样的」，我负责记录、之后再规划。旧内容只在用户明确说「这一步可以参考以前的东西」时才去翻。
|
||
- 2026-08-25 · **层级划分（用户确认）**：活动模块 = **三级页面**，层级关系即概念关系（定义 → 实例，类 → 对象）：
|
||
- **L1 模块首页 · 活动清单（定义层）**：两个页签 —— **已发布上线 / 审核中**（2026-08-25 用户定）；所有活动定义（名称 / 输入输出契约摘要 / 审核状态 / 实例数）→ 落功能 2；功能 1（创建定义）入口在此；
|
||
- **L2 活动详情 · 一个定义 + 它的实例清单**：定义完整信息（输入/输出结构、动作说明、审核信息）+ 该定义的全部实例（输入摘要 / 状态 / 产出摘要 / 时间）→ 落功能 4（清单）；功能 3（实例创建）入口在此（new 实例必须挂在某个定义下）；
|
||
- **L3 实例详情 · 一次运行的完整视图**：完整输入 / 动作过程记录 / 最终输出 / 当前状态 → 落功能 4（详情）、功能 5（编辑）、功能 6（删除），编辑删除收在最深层，不污染清单。
|
||
- 待定点：审核入口放 L1 还是单列；文件类输入的实例创建入口形态。
|
||
- 2026-08-25 · **L1 模版已落地（静态占位版）**：页签「已发布 / 审核中」、活动卡片（名称 / 标识·业务 / 状态丸 / 实例·负责人·时间·版本四格底板）、业务色相视觉增强（卡顶色签 / 图标块 / 悬停色影）。数据为静态假数据，接口设计定稿后整体替换。卡片点击（进 L2）未接。
|
||
- 2026-08-25 · **优先级调整（用户定）**：**先做运营部分，设计功能（创建活动）暂缓** —— L1 的「创建活动」幽灵卡已从页面注释掉（JSX 注释保留在代码里，样式未删，恢复即解开）。
|
||
- 2026-08-25 · **页签改为运营态（用户定）**：L1 页签「已发布 / 审核中」→「**激活中 / 已禁用**」——每个活动有激活/禁用状态，**在 L2 里修改**；发布与审核属于设计部分的功能，暂缓，等运营功能做好再回头改。禁用卡片走灰底弱化（复用 `.g-fcard.off`）。
|
||
- 2026-08-25 · **文案口径（用户定）**：创建实例 → **启动活动**；实例清单 → **历史活动**；停止 → **终止活动**。
|
||
- 2026-08-26 · **L2 历史活动改列表（用户定）**：卡片式清单撤掉，改表格列（实例 / 负责人 / 输入 / 输出 / 启动时间 / 状态 / 操作，操作栏带标题），隔行浅斑马 + 悬停亮行，行内操作（终止活动 / 查看详情）常驻；分页单页 8 条不变。
|
||
- 2026-08-26 · **L2 历史活动加检索（用户定）**：列表上方检索条 —— 条件下拉四选（实例 / 负责人 / 状态 / 启动时间），控件随条件换：实例=按实例号模糊输入、负责人=人员下拉（候选取自现有实例，接接口后换人员接口）、状态=五态下拉、启动时间=日期段（含两端整日）；筛中显示「筛出 X / 共 Y」并可一键清空；分页按筛出的集合走。
|
||
- 2026-08-26 · **L3 实例详情已落地（静态占位版，用户确认规划后实施）**：路由 `acti`（id = `活动id:实例号`），L2 行内「查看详情」接入。布局 = 主从 2:1（DESIGN-SPEC §9）：左侧「动作过程记录」竖时间线是主角（五步节点流：输入接收 → 要素结构化 → 定价测算 → **负责人验收** → 输出归档 —— 验收永远留给人，对应人机分工），当前步呼吸高亮、未到达空心灰显、连接线成不间断竖轨；右栏输入（键值）/ 输出（文件行，下载随接口开放）。头部 = 状态丸 + 负责人/启动/结束·耗时/专属 LLM；驳回/失败出原因说明块；终止后的过程面与「自己跑挂」区分：当前步记「已终止」而非失败原因。数据仍是静态假数据。
|
||
- 2026-08-26 · **实例不可删除、不可编辑（用户定，推翻 L3 原规划）**：L3 的编辑/删除入口撤掉，唯一动作是进行中的「终止活动」（二次确认）；六功能里实例的「编辑/删除」两项就此划掉，待确认问题里的两条（编辑指什么 / 删除是否放开）同时关闭。
|
||
|
||
## 三、功能表（整理稿）
|
||
|
||
（待需求说完后输出：功能项 / 说明 / 数据来源（接口） / 交互 / 优先级）
|
||
|
||
## 四、待确认问题
|
||
|
||
- ~~活动模块里的「设计」与设计中心「活动库」是什么关系？~~ **已答（2026-08-25）**：不再有「设计中心 vs 运营中心」的分工 —— 设计并入运营，活动模块自带设计能力；设计中心各区后续按同思路并入运营中心重做。
|
||
- ~~「设计」在活动模块里做到什么程度？~~ **已答（2026-08-25）**：六功能已界定 —— 活动（定义）的创建与展示 + 实例的创建/展示/编辑/删除；定义只许创建不许编删，创建要过审核。
|
||
- 活动创建的**审核**：谁来审、在模块内审还是别处、审什么（输入输出契约的合理性？）？（待用户展开）
|
||
- 实例的**编辑**~~具体指编辑什么~~：**已答（2026-08-26）：实例不可编辑**，入口不做。
|
||
- 实例删除~~是否真放开~~：**已答（2026-08-26）：实例不可删除**，入口不做；六功能只剩实例的创建/展示。
|
||
- 「运营」侧还要不要监控/验收类功能（此前提过负责人验收规划与统计产出）—— 六功能里未直接出现，是否归在「实例的展示/编辑」里，还是另有入口？（待用户展开）
|