一、技术选型

技术	选型	理由
后端框架	Spring Boot 3.2	项目已有基础框架
HTTP 客户端	Spring RestTemplate	项目已有 Bean，非流式场景够用
大模型 API	DeepSeek Chat API	OpenAI 兼容格式，国内访问稳定，性价比高
配置管理	@ConfigurationProperties	Spring Boot 原生，类型安全
接口文档	SpringDoc OpenAPI 3	自动生成 Swagger UI

二、整体架构

整个调用链路为：前端 → Controller → Service → DeepSeek API → 解析响应 → 返回前端。

三、详细实现

3.1 配置层：DeepSeek API 接入

首先在 application.yml 中新增 DeepSeek 的连接配置：

  api-key: sk-xxxxxxxxxxxxxxxxxxxxx    # DeepSeek API 密钥

  base-url: https://api.deepseek.com    # API 基础地址

  model: deepseek-chat                  # 使用的模型名称

然后通过 @ConfigurationProperties 将配置映射为 Java 对象，实现类型安全的配置读取：

设计思考：将 API 密钥和模型名称外部化到 yml，方便后续切换模型（如从 deepseek-chat 切换到 deepseek-reasoner）而不修改代码。同时在这里注册 RestTemplate Bean 供全局使用。

3.2 DTO 层：请求参数定义

定义请求体 DTO，使用 JSR-303 注解做参数校验，配合 Swagger 注解生成接口文档：

设计思考：currentMedications 使用 List<String> 而非单个字符串，因为老年人通常同时服用多种药物，列表形式更贴合实际业务场景，也方便前端从用药计划表中直接传入。

3.3 Service 层：核心业务逻辑

这是整个 Agent 的核心——Prompt 工程 + API 调用。

3.3.1 System Prompt 设计

System Prompt 是 Agent 的「人设」，决定了大模型的行为边界和输出格式：

Prompt 设计要点：

1. 明确角色：「临床药师」限定了专业领域
2. 明确受众：「老年人」让模型关注老年特殊生理（肝肾功能减退、多重用药等）
3. 结构化输出：通过指定 【审核结果】【风险等级】【详细分析】【建议措施】 四个板块，确保输出格式一致，便于前端解析展示

3.3.2 User Prompt 组装

将前端传入的药物列表转化为自然语言描述：

例如，当传入 currentMedications: ["硝苯地平", "华法林"]，newMedication: "阿司匹林" 时，组装后的 User Prompt 为：

患者（老年人）目前正在服用以下药物：【硝苯地平、华法林】，现准备加服【阿司匹林】。请运用医学与药学专业知识，判断是否存在药物配伍禁忌、药食冲突或其他用药安全风险，并给出详细分析和建议。

3.3.3 调用 DeepSeek API

DeepSeek API 兼容 OpenAI 格式，调用 /v1/chat/completions 端点：

关键参数说明：

• temperature: 0.3：设置较低的随机性，确保医学建议的严谨性和一致性。如果设为 0.9，每次对相同用药组合可能给出不同分析，在医疗场景下不可接受。
• max_tokens: 2000：足够覆盖一份详细的药物分析报告（通常 800-1500 tokens）。
• messages 数组包含 system（人设）和 user（具体问题）两条消息，这是 OpenAI 格式的标准对话结构。

3.4 Controller 层：接口暴露

Controller 保持简洁，职责仅为接收请求、参数校验、调用 Service、封装响应：

使用 @Valid 注解触发 DTO 中的 JSR-303 校验。如果前端未传 currentMedications，会自动返回 400 错误，无需手动 if-else 判断。

四、API 接口文档

请求

```

POST /elderlycare/api/medication-safety/check

Content-Type: application/json

```

```json

{

  "currentMedications": ["硝苯地平", "华法林"],

  "newMedication": "阿司匹林"

}

```

成功响应

```json

{

  "code": 200,

  "msg": "success",

  "data": "【审核结果】：存在风险\n\n【风险等级】：高危\n\n【详细分析】：\n1. 华法林 + 阿司匹林：两者均为抗凝/抗血小板药物，联合使用会显著增加出血风险（消化道出血、脑出血等），属于高危配伍禁忌。\n2. 硝苯地平 + 阿司匹林：两者无明显直接冲突，但硝苯地平可轻度影响血小板功能...\n\n【建议措施】：\n1. 强烈建议在医生指导下评估是否需要同时使用华法林和阿司匹林\n2. 如确需联用，应定期监测INR值和凝血功能\n3. 注意观察有无出血倾向（牙龈出血、皮肤瘀斑、黑便等）"

}

```

五、文件结构总结

新增文件: 

src/main/java/com/xxx/elderlycare/

├── common/config/

│   └── DeepSeekConfig.java              # dsAPI 配置

├── controller/

│   └── MedicationSafetyController.java  # REST 接口

├── dto/

│   └── MedicationCheckRequest.java      # 请求 DTO

├── service/

│   ├── MedicationSafetyService.java     # 服务接口

│   └── impl/

│       └── MedicationSafetyServiceImpl.java  # 核心实现

修改文件: 

src/main/resources/

└── application.yml                      # 新增ds配置段

六、总结与思考

本模块的核心工作在于 Prompt Engineering——如何通过精心设计的 System Prompt 让大模型扮演好「临床药师」这一角色，并输出格式统一、内容可靠的审核报告。

几个关键的设计决策：

1. 低 temperature (0.3)：医疗场景需要确定性和一致性，不适合高随机性的创意输出。
2. 结构化输出格式：在 Prompt 中约定 【审核结果】【风险等级】【详细分析】【建议措施】 四段式格式，方便前端按段落解析和分色展示。

七、 AI 功能测试报告

在完成“用药安全审核”模块开发后，我们对整个项目的 AI 组件（包含情感陪伴与用药安全相关逻辑）进行了全面验证。

7.1 测试环境与配置校验

• 核心依赖: 验证了 Spring Boot 3.2.12、MyBatis-Plus 3.5.7 及 SpringDoc OpenAPI 2.6.0 的兼容性。
• 配置验证: application.yml 中 DeepSeek API 密钥、BaseURL 及模型名称（deepseek-chat）已正确配置。

7.2 组件验证状态

组件名称	验证项	状态	备注
控制器 (Controller)	接口映射与参数校验	✅ 通过	包含标准 JSON 响应与 SSE 流式响应端点
服务层 (Service)	业务逻辑与 Prompt 注入	✅ 通过	成功集成 DeepSeek API，支持异步线程池处理
提示词 (Prompts)	角色设定与回复质量	✅ 通过	涵盖“暖心陪伴”与“专业药师/诊断”双模式
架构配置	依赖管理与数据库连接	✅ 通过	PostgreSQL 驱动及验证启动器配置正确

7.3 核心 AI 功能表现

1. 情感陪伴/医疗咨询:
   • 流式响应 (SSE): POST /api/companion/chat/stream 能够实时返回文本流，提升用户体验。
   • 多模式切换: 能够根据 User Prompt 在“温柔耐心”的陪伴模式与“专业严谨”的审核模式间切换。
2. 安全性与边界:
   • 非医疗诊断声明: AI 在处理症状描述时，能正确引导用户就医，不违规提供处方建议。
   • 参数校验: 使用 JSR-303 验证，当药物列表为空时能触发正确的 400 错误提示。

7.4 测试覆盖情况

• 自动化测试: 已创建 AiFunctionalityTest.java，涵盖控制器初始化、服务模拟行为及端点结构验证。
• 集成测试:
  • Swagger UI: 通过 http://localhost:8080/elderlycare/swagger-ui.html 完成交互式冒烟测试。
  • Curl 验证: 模拟前端请求，验证了 API 在 30 秒超时时间内的响应稳定性。

7.5 运行先决条件

在生产或完整开发环境下运行前，请确保：

1. 数据库就绪: 执行 sql/elder_guard_7tables_pgsql.sql 初始化 PostgreSQL 数据库。
2. API 额度: 确保 DeepSeek API 密钥具有充足积分且未过期。
3. 连接性: 后端服务器需具备访问 api.deepseek.com 的外网权限。

7.6 总体评估

结论：合格 该项目的 AI 架构设计合理，实现了从配置管理、Prompt 工程到流式输出的全链路闭环。针对老年人设计的“药师助手”与“情感陪伴”功能在逻辑上具有高度的一致性与专业性，具备上线运行的基础条件。