企业数据助手v2升级方案

修订版  ·  架构重构 · 安全加固 · 双模式查询

第一章  v1现状诊断

致命问题清单

• SA账号公网直连 + 弱口令——数据库直接暴露在公网，攻击者可直接登录
• 无鉴权任何人可查——接口层缺失，前端直连数据库，没有身份验证
• DeepSeek密钥硬编码——API密钥写在代码里，泄露即失控
• 无备份机制——数据一旦丢失或被勒索，无法恢复
• 单点部署——无冗余，服务宕机即全停
• 会话记忆容器内重启丢失——对话上下文存在容器内存，重启即清空
• AI直接生成SQL打库——LLM生成的SQL直接执行，注入风险极高

第二轮论证补充发现

• 原v2方案过度设计约六成，大量功能短期内用不上
• 方案缺失分析能力，只有查询没有对比解读，回答不了"为什么"
• 因此本次修订以MVP为核心，砍掉非必要功能，新增双模式设计中的分析模式

第二章  v2目标架构

完整七层架构

MVP精简版（四层核心）

第三章  核心设计修订

3.1  双模式设计

上下文继承机制

会话记忆保存上次查询参数，实现多轮对话的自然延续。例如：

• 上一轮查了"4月应收汇总"
• 下一轮问"明细呢"——自动带上"4月"参数，查询4月应收明细
• 再问"为什么差这么多"——进入分析模式，对比4月应收 vs 4月收款

3.2  AI参数提取边界规则表

AI从自然语言中提取查询参数时，必须严格遵循以下映射规则，低置信度时必须反问澄清。

自然语言表达	解析规则	示例	置信度
上个月	上月自然月	2026-05	高
最近三个月	近90天（含今天）	2026-05-10 ~ 2026-08-10	高
同比	与去年同期对比	2026年4月 vs 2025年4月	高
累计	年初至今（YTD）	2026-01-01 ~ 今天	高
季度	自然季度	Q2 = 4~6月	高
本月	当月1号至今天	2026-08-01 ~ 2026-08-10	高
含糊不清 / 多歧义	低置信度 → 反问澄清	"前阵子" → 请问是最近一周还是一个月？	低

3.3  技术选型修订

后端框架

• FastAPI 保留——异步性能好，自动生成文档，适合数据接口
• SQL Server驱动坑规避：pyodbc在容器环境下配置复杂，推荐二选一：
  • 方案A：改用 pymssql（纯Python，依赖少）
  • 方案B：用 ODBC Driver 18 容器方案（Dockerfile内置安装）

JWT密钥管理

• 密钥必须通过环境变量注入，绝对不进入代码库
• Token存储：优先 HttpOnly Cookie 防XSS，次选内存存储
• 过期策略：AccessToken 2小时，RefreshToken 7天

SSE推送优化

• nginx配置必须加：proxy_buffering off + proxy_read_timeout 120s
• 否则SSE流会被nginx缓冲，前端收不到实时推送

3.4  接口清单修订（MVP优先10个）

序号	接口名	用途	数据来源	优先级
1	应收汇总	按期间汇总应收金额	FM_ReceivableFee	P0 核心
2	应收明细	逐条应收记录详情	FM_ReceivableFee + 关联	P0 核心
3	收款汇总	按期间汇总收款金额	FM_ReceiptBill	P0 核心
4	欠款TOP	欠款最多的客户排行	应收 - 已收	P0 核心
5	经营趋势	按月/季的收入趋势图	应收/收款按月聚合	P0 核心
6	账龄分析	按账龄段统计欠款分布	FM_ReceivableFee	P0 核心
7	客户列表	客户基础信息查询	客户主表	P1 基础
8	合同列表	合同信息查询	合同主表	P1 基础
9	库存	库存数量/金额查询	库存表	P1 基础
10	商品	商品基础信息查询	商品表	P1 基础

后续迭代4个：客户详情 / 合同详情 / 收款明细 / 账龄明细

3.5  权限简化

• MVP阶段：简单两级权限（管理员 / 普通用户），或单账号密码登录
• 后续版本：五级权限体系（超级管理员 / 财务管理员 / 部门主管 / 普通员工 / 只读访客）
• 建议：MVP先用单账号起步，快速验证业务价值，再逐步细化权限

3.6  安全修订要点（12项）

3.7  实施路线修订

• MVP版：2周 / 10人天——核心功能上线，验证业务价值
• 完整版：45~55人天（后续迭代）——体验增强 → 多人使用 → 企业级安全

第四章  数据库业务逻辑挖掘成果（简述）

数据规模概览

核心发现

合同状态字典

状态值	含义	占比
-1	待提交	少量
0	审批中	少量
1	待签约	少量
2	待执行	少量
3	执行中	23.5%
4	已作废	少量
5	已终止	69.9%

应收核算逻辑

• 已收 / 未收判断：按 ReceiveAmount 与 ReceivedAmount 对比
• 主流状态：State = 0 占比约 96%

两套核算体系并存

• 现金流核算：FM_ReceivableFee / FM_ReceiptBill —— 按实际发生
• 权责发生制：FM_SysReceivableFee —— 按月拆分确认收入
• 接口口径必须明确选一套，否则数据对不上

收款 - 应收关联路径

业务逻辑分布

六张核心表无触发器，业务逻辑全部封装在存储过程中。共1061个存储过程，是v2接口开发的重要参考依据。

第五章  实施路线

MVP版（2周 / 10人天）

完整版（后续迭代 / 45~55人天）

第六章  风险与注意事项

平滑过渡策略

1. 第一步：加服务层——新接口独立开发，不影响现有系统
2. 第二步：前端切到服务层——前端逐步调用新接口，n8n退居二线
3. 第三步：n8n退场——确认新系统稳定后，关闭老webhook接口

业务口径风险

• 两套核算体系（现金流 vs 权责发生制）并存，数据口径必须在接口层定死
• 如果口径选错，所有数字都对不上，会严重影响信任
• 建议MVP阶段先明确一套口径，后续再增加口径切换功能

数据安全红线

• 只读账号，绝不放开写权限——应用层只能查不能改
• AI永远不直接接触数据库，只和业务服务层交互
• 敏感字段（手机号、身份证等）必须脱敏展示

备份先行

• 任何改造前先做全量备份
• 备份要异地存储 + 加密，防勒索软件
• 定期演练恢复流程，确保备份可用

第七章  需决策的关键事项（5个）