127 lines
8.8 KiB
Markdown
127 lines
8.8 KiB
Markdown
|
||
|
||
|
||
非常感谢你的指正！确实，将**统一的数据库连接配置项**以及**核心表的真实插入格式参考**放入 Prompt 中，能够极大程度上防止大模型在生成代码时“自由发挥”，从而保证各个模块连接达梦数据库时的绝对一致性。
|
||
|
||
我已将这两块关键信息补充进了 `prompt.md` 的核心架构规范中。以下是为你更新后的、更加完美的 `prompt.md` 文件：
|
||
|
||
---
|
||
--- START OF FILE prompt.md ---
|
||
|
||
# 🤖 体系推演平台模块重构指令 (Meta-Prompt)
|
||
|
||
## 📌 背景说明
|
||
你现在是一名资深的全栈开发工程师与数据库架构师。当前系统是一个基于 Flask + 原生 JS + 达梦数据库 (Dameng) 的军事体系推演与分析平台。
|
||
系统正处于架构升级阶段，核心目标是：**实现基于 JWT Token 的多租户数据隔离、全面接入达梦数据库、以及在数据库异常或数据缺失时具备本地模拟兜底机制。**
|
||
|
||
你需要根据本文件的规范，将我提供的【原始前后端代码】重构为符合新架构的代码。
|
||
|
||
---
|
||
|
||
## 🏗️ 核心架构与通用方法规范（重构必读）
|
||
|
||
### 1. 鉴权与租户隔离规范 (JWT + 战略任务ID)
|
||
* **前端规范**：必须拦截原生的 `fetch` 请求，从 URL 中获取 `207.SSO_TOKEN`，并在所有以 `/api/` 开头的请求 Header 中注入 `Authorization: Bearer <Token>`。
|
||
* **后端解析规范**：使用 `pyjwt` 解析 Header 中的 Token 获取 `user_id`（解析失败则兜底使用 `'ADMIN'` 或 `'default_user'`）。同时从请求参数中获取 `strat_task_id`（战略任务ID，如 `'TASK_FULL_KB'`）。
|
||
* **数据库隔离规范**：所有涉及达梦数据库的连接，在获取 `cursor` 后，**必须第一时间调用存储过程设置上下文**：
|
||
```python
|
||
cur.execute("CALL PKG_SYSTEM_CTX.SET_USER_ID(?)", (user_id,))
|
||
```
|
||
设置完成后，所有对视图（`V_MY_*`）的查询将自动实现行级隔离。
|
||
|
||
### 2. 数据库连接、读取与写入规范 (DB Connector 模式)
|
||
* **数据库连接配置标准**：请统一使用环境变量与兜底配置初始化达梦数据库连接句柄（`DMInterface` 或对应的 Connector）：
|
||
```python
|
||
dm_handler = DMInterface(
|
||
host=os.getenv("DM_HOST", "127.0.0.1"),
|
||
port=os.getenv("DM_PORT", 9080),
|
||
user=os.getenv("DM_USER", "SYSDBA"),
|
||
password=os.getenv("DM_PASS", "Dm508508")
|
||
)
|
||
```
|
||
* **数据插入格式参考 (核心表结构)**：在写入 `SYSTEM_VERSION_MASTER` 时，请严格遵守以下 SQL 格式和强约束字段（注意时间转换与类型）：
|
||
```sql
|
||
INSERT INTO SYSTEM_VERSION_MASTER (version_id, user_id, strat_task_id, sys_date, sys_type, system_task, country_region, sys_attr_id)
|
||
VALUES ('V_FULL_KB_001', 'ADMIN', 'TASK_FULL_KB', DATE '2026-04-15', '当前体系', '综合防御任务', '台', 'ATTR_FULL_KB');
|
||
```
|
||
* **业务逻辑解耦**：严禁在核心业务逻辑中写散装 SQL，必须封装在 `db_connector.py` 或模块专属的 DB 类中。
|
||
* **数据挂载关系**：体系数据的存取**必须以版本（version_id）为核心**。体系包含三个层级：
|
||
1. `SYSTEM_VERSION_MASTER` (版本总表)
|
||
2. `SYSTEM_ENTITY` (实体表：挂载在 version_id 下)
|
||
3. `SYSTEM_RELATION` (三元组关系表：挂载在 version_id 下)
|
||
* **分析结果写入**：分析结果的存取必须写入对应的 `RES_*` 表，并将结果序列化为 JSON 存入 `CLOB` 字段。
|
||
|
||
### 3. 双轨运行与模拟兜底机制 (Fallback 机制)
|
||
与预测模块一样，本模块必须具备极强的鲁棒性：
|
||
* **读取时**：如果数据库连接失败，或数据库中查不到所需数据，必须能够回退到读取本地 `pkl/json/xlsx` 文件。
|
||
* **如果连本地文件都没有**：必须基于内置的军事规则（如实体角色、作战编制规范）**动态生成模拟数据**供算法消费，绝不能直接抛出异常崩溃。
|
||
* **写入时**：所有新生成的数据（体系数据、分析结果）必须**先保存在本地工作区目录**，然后再执行数据库的 `INSERT/UPDATE` 操作。如果数据库上传失败，仅打印警告，不影响前端展示。
|
||
|
||
---
|
||
|
||
## 🎯 各业务模块专属重构逻辑指引
|
||
|
||
请根据我当前要求你重构的模块，匹配以下业务逻辑进行代码修改：
|
||
|
||
### 模块 1.1：目标识别模块
|
||
* **数据流向**：前端传入实体名集合 -> 触发上层知识库接口（模拟） -> 知识库将图片、新闻、属性存入数据库 `ENTITY_ATTR_DETAIL` 表。
|
||
* **计算逻辑**：模块从数据库读取这些属性进行数据融合与目标识别。
|
||
* **入库操作**：识别出实体的国家、角色、任务后，执行 `UPDATE SYSTEM_ENTITY`（如果实体已存在）或覆盖写入。结果明细写入 `RES_TARGET_RECOGNITION`。
|
||
|
||
### 模块 1.6-1.7：节点价值分析模块
|
||
* **数据流向**：通过 `user_id` 和 `strat_task_id` 从数据库中提取所有实体及对应的 `ENTITY_ATTR_DETAIL`。
|
||
* **计算逻辑**：执行价值计算算法。
|
||
* **入库操作**：将计算出的最终价值分数 `UPDATE ENTITY_ATTR_DETAIL SET entity_value = ?`。分析报告 JSON 存入 `RES_NODE_VALUE`。
|
||
|
||
### 模块 2.1：关系推理模块
|
||
* **数据流向**：读取实体库、实体可能的关系 (`possible_relations`) 以及实体属性。
|
||
* **入库操作**：将推理出的全新三元组数据，作为全新的体系快照入库。
|
||
* 在 `SYSTEM_VERSION_MASTER` 中插入新记录，且 **`sys_type` 必须标记为 `'关系推理后的体系'`**。
|
||
* 将推理详情日志存入 `RES_REL_REASONING`。
|
||
|
||
### 模块 1.3：形式化模块
|
||
* **数据流向**：默认从数据库中读取 `sys_type = '关系推理后的体系'` 的数据。
|
||
* **入库操作**：形式化计算完成后，将结果作为全新的体系入库，**`sys_type` 标记为 `'形式化后的体系'`**。详细规则存入 `RES_FORMAL_ANALYSIS`。
|
||
|
||
### 模块 1.4：体系构建模块 (核心中枢)
|
||
* **读取逻辑**：默认拉取 `sys_type = '形式化后的体系'` 用于可视化。前端需新增接口，拉取该任务下 **所有版本** 的体系列表供用户切换查看。
|
||
* **定时保存功能**：后端需支持定时任务，触发时将当前画板体系存入数据库，**`sys_type` 默认为 `'历史体系'`**。
|
||
* **手动保存功能**：前端提供下拉框，允许用户自由选择 8 种体系类型之一进行保存。
|
||
* **设为当前体系**：前端左下角新增【确认构建为当前体系】按钮，点击后将当前数据覆盖或新建为 **`sys_type = '当前体系'`**。
|
||
|
||
### 模块 1.5：体系分析模块
|
||
* **数据流向**：强制读取 `sys_type = '当前体系'` 的数据及实体属性。
|
||
* **入库操作**：
|
||
* 将包含 OODA 角色的体系存为 **`sys_type = '指控体系'`**（更新 `SYSTEM_ENTITY` 中的 `c2_type` 字段为 Observe/Orient/Decide/Act）。
|
||
* 分析报告存入 `RES_SYS_ANALYSIS`。
|
||
|
||
### 模块 3.1, 3.2, 3.3：失效机制与体系效能模块
|
||
* **数据流向**：全部强制读取 `sys_type = '当前体系'` 的数据。
|
||
* **入库操作**：
|
||
* 模块 3.2（体系重构）执行完毕后，将结果生成新版本，**`sys_type` 标记为 `'重构体系'`**。
|
||
* 模块 3.1 / 3.3 算出的效能指标，更新到 `SYSTEM_ATTR_DETAIL` 表中，详细报告存入 `RES_SYS_EFFECTIVENESS`。
|
||
|
||
### 模块 3.4, 3.5：重心分析模块
|
||
* **数据流向**：强制读取 `sys_type = '当前体系'`。
|
||
* **入库操作**：链路重心结果存入 `RES_LINK_COG`，节点重心结果存入 `RES_NODE_COG`。
|
||
|
||
---
|
||
|
||
## ⚠️ 数据库表结构校验指令 (非常重要)
|
||
|
||
在重构代码前，请你仔细审阅我提供的 `CreatTable.sql` 文件。
|
||
如果你发现在上述业务逻辑中，**有部分属性、字段或关联关系在 `CreatTable.sql` 中不存在**（例如：某个模块需要保存一种特殊格式的 JSON，但对应表没有 CLOB 字段；或者缺少了知识库中间表），请你**务必在输出代码前明确指出**，并为我提供用于达梦数据库的补充 SQL 语句（`CREATE TABLE` 或 `ALTER TABLE`）。
|
||
|
||
---
|
||
|
||
## 💻 你的任务
|
||
|
||
现在，我已经将本模块的 **前端 JS、HTML、后端 Python 逻辑** 上传给了你。
|
||
请你严格遵守以上《体系推演平台模块重构指令》，一步步思考，并输出：
|
||
1. **数据库结构审查报告**（是否需要补充 SQL 表？若需要，请给出 SQL）。
|
||
2. **后端的重构代码**（包含 Python API 路由接收参数、Token 解析、DB 调用与 Fallback 生成逻辑）。
|
||
3. **前端的重构代码**（包含 Token 注入、接口参数适配、以及模块特定（如1.4模块）的 UI 按钮与下拉框新增）。
|
||
|
||
请确保输出的代码完整、注释清晰，并且变量名符合原代码的上下文风格。
|
||
|
||
--- END OF FILE prompt.md --- |