周天浩
患者 AI 消息预警平台 — 技术方案
· v1.0 · 2026-06-30 把「采集库里的患者体征 → 丢给 AI 研判 → 把风险预警实时推给医护」这条链路，做成一个独立、可靠、可追溯的后台平台。支持多条产品线，一期接入**重症（ICU）和麻醉（ANES）**两条产品线。 文中关键参数（查库周期、AI 并发/超时、容量等）附默认值和测算过程。 一、为什么单独建一个项目 体征数据已经由采集系统写进了数据库。我们要做的是中间这段：定时取数 → 调 AI → 拿结果 → 推送前端，并保证全程不丢、可查、可统计。 平台不做两件事：不做体征采集入库（采集系统已有），不做 AI 模型（AI 团队提供 HTTP 接口）。 采集库由其他部门维护，
患者 AI 消息预警平台 — 技术方案
· v1.0 · 2026-06-30 把「采集库里的患者体征 → 丢给 AI 研判 → 把风险预警实时推给医护」这条链路，做成一个独立、可靠、可追溯的后台平台。支持多条产品线，一期接入**重症（ICU）和麻醉（ANES）**两条产品线。 文中关键参数（查库周期、AI 并发/超时、容量等）附默认值和测算过程。 一、为什么单独建一个项目 体征数据已经由采集系统写进了数据库。我们要做的是中间这段：定时取数 → 调 AI → 拿结果 → 推送前端，并保证全程不丢、可查、可统计。 平台不做两件事：不做体征采集入库（采集系统已有），不做 AI 模型（AI 团队提供 HTTP 接口）。 采集库由其他部门维护，
ESB平台 Compose Docker 部署与服务器迁移
Docker部署 compose方式的前后端环境教程
AI 流式消息持久化机制与 ChunkBuffer 竞态问题修复总结
AI 流式消息持久化机制与 ChunkBuffer 竞态问题修复 记录智能麻醉系统中 AI 流式响应的完整消费链路、批量缓冲持久化设计，以及一次偶发性 response_payload 数据丢失问题的根因分析与修复。 一、背景 系统后端为 Java Spring Boot 微服务，AI 能力通过调用 Dify 平台的 chat-messages 流式接口（SSE）实现。用户在前端发起请求后，Dify 以 Server-Sent Events 的形式逐块返回 AI 生成内容，后端需要： 1. 实时推送给前端 —— 用户能看到逐字输出效果 2. 完整持久化到数据库 —— ai_message 表的 content（答案正文）和 response_payload（原始