Simon
facc04aa65
本提交为 .git 对象库损坏后的重建提交，内容等价于原先三个本地提交 （5e2fd4c2 / 57a53c98 / 5d7e1873）的累积结果，未做任何额外改动。 一、docs 结构整改（整改 #14） 根因：重构时新结构为 untracked 文件，执行 git stash（未带 -u）未纳入， 随后 git reset 拉回 HEAD 旧 tracked 树，导致旧树复活、新旧两棵目录 树并存于 docs/，共 791 文件、双分类体系冲突。 修复动作： - b2 同名异主题文件改名迁移保全 9 个 - C 类 39 个孤立文件按主题正确归类 - A/B1 类 222 个重复文件删除（新结构已有内容副本） - 9 个旧独有空目录删除 - 270 处内部引用按 verified 映射改写 - 整改记录 #14 登记于 04-运维文档/部署运维 结果：docs 791 → 569 文件，顶层仅规范 8 类 + 治理文件，单树恢复。 残留：约 20 处指向从未存在文件的陈旧死链，归入独立文档卫生任务。 二、compose 双目录对齐（消除踩坑 A） - docker-compose.yml：nginx 前端挂载全部由根目录 frontend-*/dist 改为 src/frontend-*/dist（h5 / agent / admin / terminal） - docker-compose.dev.yml：dev 服务 build context 与卷同步改 src/ - 效果：本地 docker compose up 不再把根目录 stale dist 挂回， 与线上一致，分叉隐患消除（已 docker compose config 校验通过） 防复发铁律： - 重构须提交；仓库修复须 git stash -u 或先 commit - 新结构须 git add 并提交，避免再次 untracked 复活 - H5 改动只动 src/frontend-h5/，禁改根目录遗留 frontend-*/
339 lines
19 KiB
Markdown
339 lines
19 KiB
Markdown
# 复杂场景重构第一阶段 — 增量 PRD
|
||
|
||
> **版本**: v1.0
|
||
> **日期**: 2026-07-20
|
||
> **作者**: 许清楚（产品经理）
|
||
> **状态**: 待评审
|
||
> **关联文档**: `重构方案-复杂场景技术方案.md` v1.1 / `IT智能服务台-系统架构设计文档v2.md` §15.5
|
||
|
||
---
|
||
|
||
## 1. 项目信息
|
||
|
||
| 字段 | 值 |
|
||
|------|-----|
|
||
| **项目名称** | complex_scenario_phase1 |
|
||
| **技术栈** | H5端: Vue3 + Vant4 / 坐席端: Vue3 + Element Plus / 后端: FastAPI + SQLAlchemy + PostgreSQL + Redis / AI: Dify |
|
||
| **语言** | 中文 |
|
||
| **阶段范围** | P0 任务中断恢复 + P1 信息更正（不依赖 Neo4j，使用现有 PostgreSQL + Redis） |
|
||
|
||
### 原始需求复述
|
||
|
||
IT智能服务台已有完整的自动化引擎骨架（阶段5），AutoSession 模型定义了 `paused` 状态但无暂停/恢复逻辑，IntentRouter 仅识别4种场景类型意图、不支持全局对话控制意图。本阶段在此骨架上实现两个复杂对话场景：
|
||
|
||
1. **任务中断与恢复（P0）**：员工在自动化处置流程中因离开/超时/主动暂停而中断，后续可以恢复继续之前的流程。
|
||
2. **信息更正（P1）**：员工在对话中更正或补充之前提供的信息，系统理解更正意图并更新上下文。
|
||
|
||
---
|
||
|
||
## 2. 产品目标
|
||
|
||
| # | 目标 | 衡量标准 |
|
||
|---|------|---------|
|
||
| G1 | **任务可中断、可恢复** — 员工因临时事务离开时，自动化处置流程不丢失，回来后一句话即可继续 | 暂停会话恢复成功率 ≥ 95%；恢复后无需重新输入已提供信息 |
|
||
| G2 | **信息可更正、可补充** — 员工说错或想补充信息时，系统能正确理解并更新，不重复询问已修正的信息 | 更正意图识别准确率 ≥ 90%；更正后信息项值正确更新率 ≥ 95% |
|
||
| G3 | **坐席可感知** — 坐席工作台能实时看到会话的暂停/恢复/更正事件，掌握员工处置进度 | 坐席端可查看暂停会话列表及恢复点信息；更正事件在会话时间线可见 |
|
||
|
||
---
|
||
|
||
## 3. 用户故事
|
||
|
||
| # | 角色 | 用户故事 |
|
||
|---|------|---------|
|
||
| US-1 | 员工 | **As a** 员工, **I want** 在自动化处置过程中说"我先去开会"就能暂停任务, **so that** 我不用急急忙忙处理完，也不用担心中途离开导致流程丢失 |
|
||
| US-2 | 员工 | **As a** 员工, **I want** 回来后说"继续刚才的"就能从断点恢复, **so that** 我不需要重新描述问题、重新提供已填的信息 |
|
||
| US-3 | 员工 | **As a** 员工, **I want** 当我说错信息后（如用户名说成 zhangsan 实际是 lisi），系统自动更正, **so that** 不会因为口误导致处置结果错误 |
|
||
| US-4 | 员工 | **As a** 员工, **I want** 能随时补充额外信息（如"顺便说一下，是财务部的电脑"）, **so that** 系统掌握更完整的信息来精准处置 |
|
||
| US-5 | 员工 | **As a** 员工, **I want** 暂停后如果有多个未完成的任务，系统能提示我选择恢复哪个, **so that** 我不会搞混多个处置流程 |
|
||
| US-6 | 坐席 | **As a** 坐席, **I want** 在工作台看到员工会话的暂停/恢复状态和更正记录, **so that** 我能了解处置进度的完整上下文，在需要介入时不会信息缺失 |
|
||
| US-7 | 坐席 | **As a** 坐席, **I want** 能手动恢复或终止员工暂停过久的会话, **so that** 避免暂停任务长期堆积占用资源 |
|
||
|
||
---
|
||
|
||
## 4. 需求池（P0 / P1 / P2）
|
||
|
||
### P0 — 必须完成（任务中断恢复核心）
|
||
|
||
#### P0-1 全局意图识别扩展：PAUSE / RESUME_TASK
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| **需求** | 在现有 IntentRouter 中新增全局对话控制意图识别，支持 `PAUSE`（暂停）和 `RESUME_TASK`（恢复）两种意图 |
|
||
| **识别策略** | Dify Prompt 扩展优先（在现有意图识别 Prompt 中增加全局意图判断）；Dify 未配置时走关键词兜底 |
|
||
| **PAUSE 关键词** | "先去开会""等会继续""先处理别的""暂停""我去忙一下""晚点再说" |
|
||
| **RESUME_TASK 关键词** | "继续""继续刚才""好了继续吧""接着来""恢复""回来了" |
|
||
| **优先级** | 全局意图识别优先于场景意图识别 — 用户在任何流程节点发出 PAUSE/RESUME_TASK，都应被捕获 |
|
||
| **输出格式** | 在现有 `{scenario_key, confidence}` 基础上新增 `global_intent` 字段，值为 `pause` / `resume_task` / `null` |
|
||
| **兼容性** | 现有4种场景意图识别逻辑不变，仅增加一层全局意图前置判断 |
|
||
|
||
#### P0-2 会话暂停逻辑
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| **需求** | 当识别到 PAUSE 意图时，将 AutoSession 状态从 `running` 切换到 `paused` |
|
||
| **状态持久化** | 保存当前执行进度：当前动作 ID（`current_action_id`）、已收集的信息项快照、暂停时间戳 |
|
||
| **Redis 快照** | 在 Redis 中存储会话恢复点（resume_point），包含：会话标题、场景类型、当前步骤描述、待决信息项列表、暂停时间 |
|
||
| **回复消息** | 暂停时向员工发送友好提示："好的，您先忙～需要继续时跟我说一声「继续」就好。当前进度：{步骤描述}" |
|
||
| **超时处理** | 暂停超过 24 小时未恢复，自动将会话状态标记为 `closed`（closed_by = "system(timeout)"），并发送通知告知员工任务已超时关闭 |
|
||
| **边界处理** | 已处于终态（resolved/closed/handoff/error）的会话不可暂停；审批等待中（await_approval）的会话暂停时需同时挂起审批计时 |
|
||
|
||
#### P0-3 会话恢复逻辑
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| **需求** | 当识别到 RESUME_TASK 意图时，从 Redis 加载恢复点，将 AutoSession 状态从 `paused` 切换回 `running` |
|
||
| **恢复点提示** | 恢复后向员工发送上下文回顾消息："欢迎回来！您之前在处理「{会话标题}」，当前进度：{步骤描述}，我们继续吧～" |
|
||
| **多任务选择** | 若同一员工有多个 `paused` 会话，列出可恢复的任务列表（标题 + 暂停时间 + 场景类型），让员工选择恢复哪一个 |
|
||
| **信息项校验** | 恢复后检查必需信息项是否完整；若有缺失，优先补全缺失项再继续执行 |
|
||
| **动作续行** | 从 `current_action_id` 对应的下一步继续执行，已完成的动作不重复执行 |
|
||
| **边界处理** | 超时关闭的会话不可恢复，提示员工"该任务已超时关闭，请重新发起" |
|
||
|
||
#### P0-4 新增 WS 事件
|
||
|
||
| 事件名 | 触发时机 | 负载 |
|
||
|--------|---------|------|
|
||
| `automation.paused` | 会话暂停时 | `{session_id, title, paused_at, resume_hint}` |
|
||
| `automation.resumed` | 会话恢复时 | `{session_id, title, resumed_at, current_step}` |
|
||
| `automation.timeout_closed` | 暂停超时关闭时 | `{session_id, closed_at, reason}` |
|
||
|
||
#### P0-5 H5端暂停/恢复交互
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| **暂停入口** | 自然语言触发（说"先去开会"等），无需额外按钮 |
|
||
| **恢复入口** | ① 自然语言触发（说"继续"）；② 会话列表中 paused 状态的会话点击进入时自动提示恢复 |
|
||
| **恢复点卡片** | 恢复时展示一张轻量卡片，显示会话标题、场景类型、暂停时间、当前进度，带"继续处理"按钮 |
|
||
| **多任务选择** | 有多个暂停任务时，展示任务列表卡片（Vant Cell 列表），每项含标题 + 暂停时间 + 场景图标，点击选择恢复 |
|
||
| **暂停状态展示** | 会话列表中 paused 会话显示"已暂停"标签 + 暂停时长 |
|
||
|
||
### P1 — 应该完成（信息更正核心）
|
||
|
||
#### P1-1 全局意图识别扩展：CORRECT / SUPPLEMENT
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| **需求** | 在 IntentRouter 中新增 `CORRECT`（更正）和 `SUPPLEMENT`（补充）两种全局意图识别 |
|
||
| **CORRECT 关键词** | "刚才说错了""不是xx是xx""应该是""更正""说错了" |
|
||
| **SUPPLEMENT 关键词** | "再补充一下""顺便说一下""还有""对了补充""另外" |
|
||
| **输出格式** | `global_intent` 字段扩展为 `correct` / `supplement` / `pause` / `resume_task` / `null` |
|
||
| **更正信息提取** | CORRECT 意图需额外提取：`corrected_field`（更正的字段名）、`old_value`（旧值，可选）、`new_value`（新值） |
|
||
| **补充信息提取** | SUPPLEMENT 意图需额外提取：`supplement_field`（补充的字段名，可推断）、`supplement_value`（补充的值） |
|
||
|
||
#### P1-2 信息项模型与版本管理
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| **需求** | 新建 InformationItem 数据结构（PostgreSQL 表 `auto_information_items`），管理对话中收集的信息项及其变更历史 |
|
||
| **核心字段** | `session_id`、`name`（信息项名称）、`value`（当前值）、`modifiers`（修饰符列表，JSON）、`is_filled`（是否已填写）、`version`（版本号）、`update_history`（变更历史，JSON）、`updated_at` |
|
||
| **修饰符** | 复用设计文档定义的6种：`固定`/`增量`/`明确`/`隐含`/`复述`/`必需` |
|
||
| **更正策略** | CORRECT 意图 → 旧值存入 `update_history`，`value` 更新为新值，`version` +1 |
|
||
| **补充策略** | SUPPLEMENT 意图 → 若修饰符含 `增量`，追加到 `value`（分号分隔）；否则同更正处理 |
|
||
| **复述确认** | 若修饰符含 `复述`，更正后需向员工发送确认消息："已将{字段名}更正为{新值}，确认无误吗？" |
|
||
|
||
#### P1-3 更正确认与上下文同步
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| **更正确认** | 更正关键字段（用户名、终端ID等）后，向员工发送更正确认消息："已更正：{字段名} 从「{旧值}」改为「{新值}」" |
|
||
| **下游影响** | 更正后若影响已生成的动作计划（如终端ID变更导致映射失效），需重新校验并提示员工"信息已更新，正在重新评估处置方案" |
|
||
| **坐席可见** | 更正事件通过 WS 推送到坐席端，坐席可在会话时间线中看到信息变更记录 |
|
||
|
||
#### P1-4 新增 WS 事件
|
||
|
||
| 事件名 | 触发时机 | 负载 |
|
||
|--------|---------|------|
|
||
| `automation.info_corrected` | 信息更正成功时 | `{session_id, field, old_value, new_value, version}` |
|
||
| `automation.info_supplemented` | 信息补充成功时 | `{session_id, field, supplement_value, new_value}` |
|
||
|
||
#### P1-5 H5端更正/补充交互
|
||
|
||
| 项目 | 说明 |
|
||
|------|------|
|
||
| **自然触发** | 员工在对话中自然语言更正/补充，系统自动识别处理 |
|
||
| **更正确认消息** | 更正后在对话流中展示一条系统消息（带「已更正」标签），显示字段名、旧值→新值 |
|
||
| **补充确认消息** | 补充后在对话流中展示一条系统消息（带「已补充」标签），显示补充的字段和内容 |
|
||
| **信息面板** | 会话详情页新增"已收集信息"折叠面板，展示当前所有信息项的名称、值、状态（已确认/待确认） |
|
||
|
||
### P2 — 增强体验（本阶段可不做）
|
||
|
||
| 编号 | 需求 | 说明 |
|
||
|------|------|------|
|
||
| P2-1 | 暂停任务主动提醒 | 暂停 1 小时后通过企微消息主动提醒员工"您有一个待恢复的任务" |
|
||
| P2-2 | 信息更正历史可视化 | 坐席端以时间轴形式展示信息项的完整变更链 |
|
||
| P2-3 | 批量信息更正 | 一次性更正多个字段（如"用户名是 lisi，部门是财务部"） |
|
||
| P2-4 | 暂停任务过期预警 | 暂停接近 24 小时时预警员工"任务即将超时" |
|
||
| P2-5 | 信息项智能推断 | 利用 `隐含` 修饰符从上下文自动推断信息（如从终端ID推断操作系统版本） |
|
||
|
||
---
|
||
|
||
## 5. 交互流程
|
||
|
||
### 5.1 任务中断与恢复流程（P0）
|
||
|
||
```
|
||
【正常处置中】
|
||
员工：帮我查一下电脑位置
|
||
AI：好的，正在为您定位终端...
|
||
AI：已定位到您的终端：PC-FINANCE-012，IP: 10.20.3.45
|
||
|
||
【员工主动暂停】
|
||
员工：我先去开个会，等会继续
|
||
→ 系统识别 PAUSE 意图
|
||
→ AutoSession 状态: running → paused
|
||
→ Redis 保存恢复点（会话标题、当前步骤、信息项快照）
|
||
AI：好的，您先忙～需要继续时跟我说一声「继续」就好。
|
||
当前进度：终端定位已完成，等待下一步操作。
|
||
|
||
--- 2小时后 ---
|
||
|
||
【员工恢复】
|
||
员工：继续
|
||
→ 系统识别 RESUME_TASK 意图
|
||
→ 检查到1个 paused 会话
|
||
→ Redis 加载恢复点
|
||
→ AutoSession 状态: paused → running
|
||
AI：欢迎回来！您之前在处理「终端定位」，当前进度：终端定位已完成。
|
||
您的终端 PC-FINANCE-012 已定位，还需要其他帮助吗？
|
||
|
||
【多个暂停任务场景】
|
||
员工：继续
|
||
→ 系统检查到2个 paused 会话
|
||
AI：您有2个未完成的任务，请选择要继续的：
|
||
① 终端定位（暂停于 14:30）
|
||
② 密码重置（暂停于 15:00）
|
||
员工：第一个
|
||
→ 恢复终端定位任务
|
||
```
|
||
|
||
### 5.2 超时自动关闭流程
|
||
|
||
```
|
||
--- 暂停 24 小时后 ---
|
||
|
||
→ 定时任务扫描 paused 会话
|
||
→ 超过 24 小时未恢复
|
||
→ AutoSession 状态: paused → closed (closed_by = "system(timeout)")
|
||
→ 发送企微通知：您的任务「终端定位」因长时间未恢复已自动关闭，
|
||
如需帮助请重新发起。
|
||
|
||
员工（次日）：继续
|
||
AI：该任务已超时关闭，请重新描述您的问题，我来帮您处理。
|
||
```
|
||
|
||
### 5.3 信息更正流程（P1）
|
||
|
||
```
|
||
【信息收集阶段】
|
||
员工：帮我重置密码，用户名是 zhangsan
|
||
AI：好的，正在为 zhangsan 准备密码重置链接...
|
||
|
||
【员工更正】
|
||
员工：不好意思，用户名是 lisi，不是 zhangsan
|
||
→ 系统识别 CORRECT 意图
|
||
→ 提取: corrected_field = "用户名", old_value = "zhangsan", new_value = "lisi"
|
||
→ InformationItem 更新: value = "lisi", version 1→2, update_history 记录旧值
|
||
→ WS 推送 info_corrected 事件
|
||
AI：已更正：用户名 从「zhangsan」改为「lisi」。正在为 lisi 准备密码重置链接...
|
||
```
|
||
|
||
### 5.4 信息补充流程（P1）
|
||
|
||
```
|
||
【病毒处置中】
|
||
员工：我的电脑中毒了
|
||
AI：好的，已开始病毒扫描...
|
||
|
||
【员工补充】
|
||
员工：再补充一下，是财务部的电脑，上面有重要的财务数据
|
||
→ 系统识别 SUPPLEMENT 意图
|
||
→ 提取: supplement_field = "部门/备注", supplement_value = "财务部，有重要财务数据"
|
||
→ InformationItem 更新（增量修饰符，追加值）
|
||
→ WS 推送 info_supplemented 事件
|
||
AI：已补充记录：财务部电脑，含重要财务数据。查杀时将优先保护数据文件。
|
||
```
|
||
|
||
### 5.5 更正影响下游处置的场景
|
||
|
||
```
|
||
【终端定位完成，进入病毒查杀】
|
||
员工：刚才说错了，电脑名不是 PC-FINANCE-012，是 PC-FINANCE-013
|
||
→ CORRECT 意图识别
|
||
→ 更正终端名信息项
|
||
→ 检测到下游动作（病毒查杀）依赖该信息项
|
||
→ 重新校验映射，生成新的动作计划
|
||
AI：已更正终端名。信息已更新，正在重新评估处置方案...
|
||
AI：已重新定位到 PC-FINANCE-013，正在对该终端发起病毒扫描。
|
||
```
|
||
|
||
---
|
||
|
||
## 6. 坐席端影响
|
||
|
||
### 6.1 会话列表增强
|
||
|
||
| 改动 | 说明 |
|
||
|------|------|
|
||
| 新增 `paused` 状态筛选 | 会话列表状态筛选器增加"已暂停"选项，坐席可快速查看所有暂停中的会话 |
|
||
| 暂停时长展示 | 列表中 paused 会话显示暂停时长（如"已暂停 2h 15min"） |
|
||
| 超时预警标记 | 接近 24 小时的暂停会话显示橙色预警标记 |
|
||
|
||
### 6.2 会话详情增强
|
||
|
||
| 改动 | 说明 |
|
||
|------|------|
|
||
| 恢复点信息展示 | 会话详情页展示恢复点信息（暂停时间、当前步骤、已收集信息项） |
|
||
| 信息变更时间线 | 会话时间线中展示更正/补充事件，格式：`[信息更正] 用户名: zhangsan → lisi (v2)` |
|
||
| 信息项面板 | 会话详情页新增"信息项"折叠面板，展示所有已收集信息项的名称、当前值、版本号、修饰符 |
|
||
|
||
### 6.3 坐席操作能力
|
||
|
||
| 操作 | 说明 |
|
||
|------|------|
|
||
| 手动恢复 | 坐席可在会话详情页点击"恢复任务"按钮，代替员工恢复暂停的会话 |
|
||
| 手动关闭 | 坐席可终止暂停过久的会话，状态 → closed，closed_by 记录坐席ID |
|
||
| 查看更正历史 | 点击信息项可展开完整变更历史（版本号、旧值、新值、变更时间） |
|
||
|
||
---
|
||
|
||
## 7. 待确认问题
|
||
|
||
| # | 问题 | 影响范围 | 建议方案 |
|
||
|---|------|---------|---------|
|
||
| Q1 | 暂停超时阈值是否固定 24 小时？是否需要按场景区分（如密码重置 2 小时、终端定位 24 小时）？ | P0-2 超时处理 | 建议本阶段统一 24 小时，后续按场景配置化 |
|
||
| Q2 | 信息更正是否需要区分"可更正"和"不可更正"字段？例如已执行完成的动作结果不可更正？ | P1-2 更正策略 | 建议引入修饰符控制：`固定`修饰符标记的字段在动作执行后不可更正，执行前可更正 |
|
||
| Q3 | 多个暂停任务恢复时，员工用自然语言选择（如"第一个"）还是需要点击卡片？ | P0-5 多任务选择 | 建议两者都支持：卡片点击 + 自然语言序号选择 |
|
||
| Q4 | 信息更正后如果下游动作已部分执行（如病毒扫描已开始），如何处理？是终止重试还是继续？ | P1-3 下游影响 | 建议本阶段仅提示员工"部分操作已执行，无法撤回"，不自动回滚；回滚能力留给后续阶段 |
|
||
| Q5 | 全局意图识别是复用现有 Dify Prompt 扩展，还是新建独立的 Dify 应用？ | P0-1 / P1-1 | 建议复用现有 Prompt 扩展，减少调用次数；但需确保全局意图判断不影响现有场景识别准确率 |
|
||
| Q6 | 暂停期间坐席是否可以代员工操作（如代为恢复并继续执行）？是否需要员工授权？ | 6.3 坐席操作 | 建议坐席可直接恢复无需授权，但恢复后坐席端显示"坐席代恢复"标记 |
|
||
| Q7 | InformationItem 是否需要在 AutoSession 表中新增字段关联，还是独立建表？ | P1-2 数据模型 | 建议独立建表 `auto_information_items`，通过 `session_id` 关联，便于版本管理和查询 |
|
||
|
||
---
|
||
|
||
## 8. 验收标准
|
||
|
||
### 8.1 P0 验收标准
|
||
|
||
- [ ] 员工在任意处置步骤说"先去开会"，系统暂停会话并回复确认消息
|
||
- [ ] 暂停后 Redis 中存在恢复点数据，AutoSession 状态为 `paused`
|
||
- [ ] 员工说"继续"后，系统恢复会话并展示上下文回顾消息
|
||
- [ ] 恢复后从断点继续执行，已完成的动作不重复
|
||
- [ ] 多暂停任务时，系统列出任务列表供员工选择
|
||
- [ ] 暂停超过 24 小时自动关闭并发送通知
|
||
- [ ] 坐席端会话列表可筛选 paused 状态，显示暂停时长
|
||
- [ ] 坐席可手动恢复/关闭暂停会话
|
||
|
||
### 8.2 P1 验收标准
|
||
|
||
- [ ] 员工说"刚才说错了，用户名是 lisi"，系统识别 CORRECT 意图并更新信息项
|
||
- [ ] 更正后对话流中显示更正确认消息（字段名、旧值→新值）
|
||
- [ ] 员工说"再补充一下，是财务部的电脑"，系统识别 SUPPLEMENT 意图并追加信息
|
||
- [ ] InformationItem 表记录完整的变更历史（版本号、旧值、新值、时间）
|
||
- [ ] 更正影响下游动作时，系统提示并重新评估处置方案
|
||
- [ ] 坐席端会话详情可查看信息项面板和变更时间线
|
||
- [ ] WS 事件 `automation.info_corrected` / `automation.info_supplemented` 正常推送
|
||
|
||
---
|
||
|
||
*本 PRD 仅描述第一阶段（P0+P1）新增/变更部分，不重复已有自动化引擎功能描述。*
|
||
*技术实现方案详见架构师产出文档。*
|