chore: initial baseline with P0-safety .gitignore
This commit is contained in:
Simon
@@ -0,0 +1,184 @@
|
||||
# IT智能服务台 — 项目开发任务调整建议
|
||||
|
||||
> **文档版本**: V1.0
|
||||
> **创建日期**: 2026-06-11
|
||||
> **作者**: 宋献 + WorkBuddy
|
||||
> **状态**: 待确认
|
||||
|
||||
---
|
||||
|
||||
## 一、项目当前状态总览
|
||||
|
||||
| 维度 | 状态 | 备注 |
|
||||
|------|------|------|
|
||||
| PRD | ✅ v1.1 完成 | 邀请功能已纳入，阶段一细化至1A/1B/1C |
|
||||
| 架构文档 | ✅ v0.11 完成 | WebSocket评估已完成 |
|
||||
| 坐席工作台 | ✅ 代码已写 | 前端 50+ 文件，含 WebSocket/快速回复/邀请等 |
|
||||
| H5用户端 | ✅ 代码已写 | 15 个组件，含聊天/AI面板/排查流程 |
|
||||
| 管理后台 | ✅ 代码已写 | 10 页面 + 16 API端点 |
|
||||
| 后端 | ✅ 代码已写 | 60+ Python文件，完整模型/服务/API |
|
||||
| 原型 | ✅ v5.3 锁定 | 7个HTML原型 + 数据文件 |
|
||||
| 外部系统集成分析 | ✅ 3份完成 | 火绒/联软/aTrust 各一份详细报告 |
|
||||
| 映射架构 | ✅ 四系统确认 | 企微设备管理已排除（付费功能，公司未购买） |
|
||||
| 部署 | 🔄 预生产已部署 | NAS生产+新服务器方案已备 |
|
||||
| **端到端验证（1C）** | ❌ 未完成 | **当前最大瓶颈** |
|
||||
| **H5登录Bug** | ❌ OPEN | 阻断性 |
|
||||
| **管理后台代码修复** | 🔄 3个问题已派发 | 待验证 |
|
||||
|
||||
---
|
||||
|
||||
## 二、核心问题识别
|
||||
|
||||
### 问题1：阶段一"最后一公里"卡住了
|
||||
|
||||
代码已写完但端到端验证未跑通，存在集成层面Gap。当前H5登录Bug + 管理后台类型问题，导致1C无法闭环。
|
||||
|
||||
### 问题2：外部系统对接全是"待对接"状态
|
||||
|
||||
4个外部系统（联软/火绒/aTrust/eHR）的分析文档已完成，但没有任何一个系统完成了实际API联调。这是阶段二及后续的关键路径依赖。
|
||||
|
||||
### 问题3：WebSocket安全债务积压
|
||||
|
||||
WS-01（认证缺失）是P0级安全问题，当前生产环境WebSocket无任何认证，阶段二实时推送上线前必须修复。
|
||||
|
||||
### 问题4：邀请功能设计完成，编码状态不明
|
||||
|
||||
PRD §21 已确认邀请功能纳入1A，技术方案和原型已完成，但代码层面是否有完整的后端API + 前端交互闭环需要验证。
|
||||
|
||||
---
|
||||
|
||||
## 三、调整建议
|
||||
|
||||
### 🔴 P0 — 立即推进（1~2周内）
|
||||
|
||||
| # | 任务 | 原排期 | 调整 | 原因 |
|
||||
|---|------|--------|------|------|
|
||||
| 1 | H5登录Bug修复 | 1C | 不变，优先级提升为最高 | 端到端验证的前置条件 |
|
||||
| 2 | 管理后台3个代码问题修复 | 1B | 不变，优先级提升 | system_alerts类型不匹配是阻断性的 |
|
||||
| 3 | 端到端验证(1C) | 1C | 不变 | 阶段一交付的唯一标准 |
|
||||
| 4 | 邀请功能端到端验证 | 1A | 确认编码完整性 | 设计+原型+技术方案都有，需确认代码是否可跑通 |
|
||||
|
||||
**建议做法**：集中1周时间，先修Bug → 跑通1C → 邀请功能验证。阶段一的目标是可演示的MVP，不追求完美。
|
||||
|
||||
### 🟡 P1 — 阶段二前置工作（2~4周内）
|
||||
|
||||
| # | 任务 | 原排期 | 调整 | 原因 |
|
||||
|---|------|--------|------|------|
|
||||
| 5 | WebSocket P0修复（WS-01认证+WS-06去重） | 2A | 提前至1C之后立即做 | 安全是不可妥协的，阶段二实时推送上线前必须完成 |
|
||||
| 6 | 联软API对接 | 无明确排期 | **新增为阶段二首个外部集成** | strusername是映射的金钥匙，联软是四系统架构的主源(P0) |
|
||||
| 7 | 外部系统抽象层设计 | 无 | **新增** | 后端需设计统一的ExternalSystemAdapter抽象层，联软/火绒/aTrust/eHR统一接口，解耦具体实现 |
|
||||
|
||||
**联软对接建议**：
|
||||
- 本周内：联系终端安全团队，申请API测试账户
|
||||
- 同时：后端先基于文档Mock数据开发抽象层
|
||||
- 获取账户后：立即联调验证
|
||||
|
||||
### 🟢 P2 — 中期推进（1~2月内）
|
||||
|
||||
| # | 任务 | 原排期 | 调整 | 原因 |
|
||||
|---|------|--------|------|------|
|
||||
| 8 | 火绒API对接 | 无明确排期 | 阶段二期间推进 | 火绒=安全源（杀毒+漏洞+隔离），与联软互补，但非映射关键路径 |
|
||||
| 9 | aTrust API对接 | 无明确排期 | 阶段二期间推进 | aTrust=VPN源，覆盖远程场景，需找信息安全团队获取API ID/密钥 |
|
||||
| 10 | eHR对接 | 无明确排期 | 阶段二后期 | eHR=辅助/静态数据，优先级最低 |
|
||||
| 11 | OAuth2登录切换 | 2D | 不变，等公司域名审批 | 1A~2C继续使用Mock登录，不影响功能开发 |
|
||||
|
||||
### 📋 备忘 — 条件触发
|
||||
|
||||
| 条件 | 触发动作 |
|
||||
|------|---------|
|
||||
| 公司购买了企微设备管理 | 接入为第五映射源（MAC→火绒交叉匹配桥） |
|
||||
| 坐席扩至3人以上 | 启用轮询/最少活跃分配模式（管理后台已预留） |
|
||||
| Dify Agent2创建完成 | 启动3A（AI Wingman验证） |
|
||||
|
||||
---
|
||||
|
||||
## 四、外部系统集成排程调整
|
||||
|
||||
原五阶段路线图未细化外部系统集成的具体排期。基于分析结果，建议如下：
|
||||
|
||||
```
|
||||
阶段一收尾（当前）
|
||||
└─ 1C端到端验证
|
||||
└─ 邀请功能闭环
|
||||
|
||||
阶段二（H5全流程+实时推送）
|
||||
├─ 2A WebSocket修复+实时推送
|
||||
│ └─ WS-01认证、WS-06去重（P0安全）
|
||||
├─ 2B 联软集成（映射主源） ← 🆕 新增
|
||||
│ └─ queryDevByParams → 员工↔终端映射
|
||||
│ └─ 抽象层 ExternalSystemAdapter
|
||||
├─ 2C 火绒集成（安全源） ← 🆕 新增
|
||||
│ └─ 终端列表+详情+漏洞+隔离
|
||||
├─ 2D 接单优化+满意度
|
||||
└─ 2E OAuth2（待域名审批）
|
||||
|
||||
阶段三（AI Wingman）
|
||||
├─ 3A AI Wingman验证
|
||||
├─ 3B 排查流程图+AI混合
|
||||
│ └─ aTrust集成（VPN源） ← 🆕 移入3B
|
||||
│ └─ VPN会话+踢出+授信状态
|
||||
├─ 3C 标注体系
|
||||
└─ eHR对接（辅助源） ← 🆕 移入3C后
|
||||
```
|
||||
|
||||
**调整逻辑**：
|
||||
- 联软提前到2B：映射是后续所有功能（终端信息面板、一键隔离、VPN状态）的基础设施，越早接入越好
|
||||
- 火绒紧跟联软2C：联软提供映射后，火绒的安全数据才有锚点（通过MAC/pc_name交叉匹配）
|
||||
- aTrust移到3B：VPN场景相对独立，不阻塞核心流程，与排查流程图结合更有价值
|
||||
- eHR放到3C后：静态数据同步，优先级最低，联软已经覆盖了映射需求
|
||||
|
||||
---
|
||||
|
||||
## 五、映射架构（已确认）
|
||||
|
||||
### 四系统联合架构
|
||||
|
||||
```
|
||||
联软 LV7000（主源 P0）
|
||||
└─ strusername → 精确员工账号→终端映射
|
||||
└─ 覆盖：总部办公员工（强制安装联软安全助手）
|
||||
|
||||
aTrust（VPN源）
|
||||
└─ name / bindUsers / vips（待实测）→ VPN终端映射
|
||||
└─ 覆盖：远程接入员工
|
||||
|
||||
eHR（辅助源）
|
||||
└─ 静态数据：部门/岗位/联系方式
|
||||
└─ 覆盖：人员基础信息补全
|
||||
|
||||
火绒（安全源，不参与映射）
|
||||
└─ 终端安全状态：杀毒/漏洞/隔离
|
||||
└─ 与联软通过MAC/pc_name交叉匹配
|
||||
```
|
||||
|
||||
### ❌ 已排除：企微设备管理
|
||||
|
||||
- 原因：企微"设备管理"为安全高级功能，需付费购买，公司未购买
|
||||
- API验证：errcode 48002（应用无调用权限）
|
||||
- 潜在价值：如未来购买，可作为交叉验证源
|
||||
- 企微仍作为通信平台（H5宿主+消息推送+用户身份认证），不参与终端映射
|
||||
|
||||
---
|
||||
|
||||
## 六、风险提示
|
||||
|
||||
| 风险 | 影响 | 缓解措施 |
|
||||
|------|------|---------|
|
||||
| 外部团队对接响应慢 | 联软/火绒/aTrust都是跨团队协作，API账户审批可能耗时2-4周 | 本周立即启动联系，同时用Mock数据开发 |
|
||||
| aTrust `vips`字段实测可能不存在 | VPN虚拟IP交叉匹配方案失效 | 联软的映射为主源，aTrust的vips仅为辅助验证 |
|
||||
| OAuth2域名审批延期 | H5必须继续用Mock登录，影响真实用户体验 | Mock登录已够用，阶段二功能不受影响 |
|
||||
| WebSocket认证修复涉及现有连接 | 修复后坐席端需同步升级 | 先在预生产环境验证，再灰度发布 |
|
||||
|
||||
---
|
||||
|
||||
## 七、建议的下一步行动
|
||||
|
||||
| 优先级 | 行动 | 负责人 | 时间 |
|
||||
|--------|------|--------|------|
|
||||
| 🔴 | 修复H5登录Bug | 开发 | 本周 |
|
||||
| 🔴 | 修复管理后台3个代码问题 | 开发 | 本周 |
|
||||
| 🔴 | 端到端验证(1C)跑通 | 开发 | 本周~下周 |
|
||||
| 🟡 | 联系终端安全团队（联软API账户） | 宋献 | 本周 |
|
||||
| 🟡 | 联系信息安全团队（火绒AccessKey + aTrust API ID） | 宋献 | 本周 |
|
||||
| 🟡 | 设计ExternalSystemAdapter抽象层 | 开发 | 下周 |
|
||||
| 🟢 | WebSocket P0安全修复 | 开发 | 1C完成后1周内 |
|
||||
Reference in New Issue
Block a user