构建AI应用的建模分析

软件开发中较为重要的一点是对软件面向的问题进行建模，建模的方式有很多种，在复杂的业务交互中较为常见的是DDD（Domain Drive Design）领域模型驱动驱动设计。

考虑到AI应用总是需要结合到具体的场景中进行拆解，重组。因此我比较推荐使用领域模型对AI应用建模。

领域划分

从上一章节我们可以分析到，不同场景类型的AI应用，总是需要不同的模型，并且需要有机的组合才能去初步的解决问题，本章我们决定对应用粗浅的分类三类

• 纯文字交互类
• 音视频操作类
• 图像生成类

本书总是以 纯文字交互类的AI应用开发为主线，望各位读者知悉

纯文字交互类的AI应用建模

纯文字类的AI应用是LLM模型出来时候第一个我们接触到的交互形式，具体我们可以回看谷歌Gemini和OpenAI的ChatGPT时候的发布会。

其交互形式为：

1. 用户输入一段提示词，可能是问题，可能是指令加内容，模型返回答案或者操作结果；
2. 软件预制了一段提示词，用户以语音形式输入，通过专用模型转换为文字后，实际以文字与模型交互，然后模型吐出字符后，通过文字转语音（TTS）完成交互；

根据以上分析，我们可以参考的最佳领域模型就是聊天软件的领域模型，而且必须是精简后的，非常高层级的领域模型。

聊天软件的领域模型建模

作为AI软件开发的软件工程师，绝对不能采取是自己独自冥思苦想，必须学会利用LLM做为自己最大的助力。

所以，此处实例采用DeepSeek-R1-0524推理模型构建，其prompt提示词为：

我需要构建一个类似聊天问答的输入交互软件，可能包含群聊，单聊，带功能的机器人。聊天的内容包含，文字，语音，图片，视频，文件。请以文字方式帮我整理输出其领域模型，并且需要说明，每个模型划分的原因，面向的场景，并以Markdown格式返回。

聊天软件领域模型

1. 用户模型

• 属性：
  • 用户ID: 唯一标识
  • 用户名: 显示名称
  • 头像: 图片链接
  • 是否机器人: 布尔值
  • 在线状态: 在线/离线/忙碌
• 划分原因：
  区分真实用户与自动化服务，统一管理基础信息
• 使用场景：
  用户登录、联系人列表展示、状态监控

2. 会话模型

• 属性：
  • 会话ID: 唯一标识
  • 会话类型: 私聊/群组/频道
  • 成员列表: 用户ID集合
  • 会话标题: 群组名称
  • 创建时间: 时间戳
• 划分原因：
  抽象沟通场景的共同特征
• 使用场景：
  新会话创建、消息分发、未读消息统计

3. 消息模型

• 属性：
  • 消息ID: 唯一标识
  • 发送者: 用户ID
  • 所属会话: 会话ID
  • 内容类型: 文本/语音/图片/视频/文件
  • 内容主体: 文字内容或文件链接
  • 发送时间: 时间戳
  • 阅读状态: 已发送/已送达/已读
• 划分原因：
  统一消息处理管道，支持多媒体交互
• 使用场景：
  消息收发、状态同步、历史记录查询

4. 媒体资源模型

• 属性：
  • 资源ID: 唯一标识
  • 文件类型: 音频/图片/视频/文档
  • 存储路径: 文件地址
  • 文件大小: 字节数
  • 持续时间: 音视频时长(秒)
  • 缩略图: 预览图链接
• 划分原因：
  独立管理大文件资源，优化传输效率
• 使用场景：
  文件上传下载、多媒体预览、存储管理

5. 智能助手模型

• 属性：
  • 助手ID: 关联用户ID
  • 指令列表: 支持的功能命令
  • 应答规则: 关键词响应配置
  • 服务接口: 外部API地址
• 划分原因：
  扩展标准用户能力，实现自动化服务
• 使用场景：
  指令响应(如/天气)、智能问答、服务对接

6. 功能指模型

• 属性：
  • 指令ID: 唯一标识
  • 触发词: 如/帮助
  • 功能说明: 描述文本
  • 处理器: 本地函数或远程接口
• 划分原因：
  标准化机器人交互方式
• 使用场景：
  快捷操作触发、功能发现、权限控制

模型关系说明

设计要点说明

1. 多格式消息处理
   通过 内容类型字段自动适配不同消息的展示形式，文本直接呈现，多媒体调用对应渲染组件
2. 智能助手扩展

• 基础版：配置 应答规则实现自动回复
• 高级版：通过 指令列表+服务接口对接外部系统
• 示例场景：发送”/翻译 你好”触发翻译服务
  3. 资源优化方案
• 大文件独立存储，消息体仅保存元数据

• 自动生成 缩略图提升图片加载效率

• 持续时间字段支持音视频进度控制

  4. 会话统一管理
     私聊视为两人群组的特例，减少系统复杂度，群组专属字段在私聊时自动隐藏
  5. 状态追踪机制
• 阅读状态实现消息已读回执

• 在线状态实时显示用户可用性

AI聊天类应用软件的初步建模

考虑到，我们构建的应用软件还不需要那么复杂的富文本交互，我们可以采取精简场景策略。利用LLM帮助我们裁剪模型。以下是本次希望精简模型的prompt：

考虑到，我的软件是面向本地问答类型的，可能暂时不需要多用户参与，但是多机器人交互可能需要，同时需要对不同机器人交互顺序进行编排，不需要人类在线交互，请帮助我修改模型。

本地问答交互软件领域模型设计（单用户多机器人版）

1. 核心用户模型

• 属性：
  • 用户ID: 唯一标识（固定为本地用户）
  • 用户名: “本地用户”
• 划分原因：
  简化多用户系统，聚焦单用户场景
• 使用场景：
  作为所有交互的发起者和接收者

2. 机器人代理模型

• 属性：
  • 机器人ID: 唯一标识
  • 机器人名称: 显示名称
  • 能力类型: 问答/工具/分析等
  • 执行优先级: 数值（用于编排）
  • 输入格式: 支持的数据类型
  • 输出格式: 返回的数据类型
  • 服务端点: 本地函数或API地址
• 划分原因：
  作为核心交互对象，强化编排能力
• 使用场景：
  机器人注册、执行链编排、多机器人协作

3. 交互会话模型

• 属性：
  • 会话ID: 唯一标识
  • 参与机器人: 机器人ID列表
  • 当前状态: 进行中/已完成
  • 创建时间: 时间戳
• 划分原因：
  管理单次问答的生命周期
• 使用场景：
  会话创建、机器人执行顺序管理、结果汇总

4. 交互消息模型

• 属性：
  • 消息ID: 唯一标识
  • 所属会话: 会话ID
  • 发送方: 用户/机器人ID
  • 接收方: 机器人ID（可多个）
  • 内容类型: 文本/数据/文件
  • 内容主体: 问题或结果数据
  • 时序标记: 执行顺序编号
• 划分原因：
  支持多机器人顺序/并行处理
• 使用场景：
  问题分发、中间结果传递、最终答复组装

5. 执行编排模型

• 属性：
  • 流程ID: 唯一标识
  • 触发条件: 关键词/意图
  • 机器人序列: 有序机器人ID列表
  • 数据传递规则: 输入输出映射
  • 超时设置: 毫秒数
• 划分原因：
  核心控制多机器人协作逻辑
• 使用场景：
  复杂问题拆解、多步骤任务处理、机器人流水线

6. 媒体处理模型

• 属性：
  • 资源ID: 唯一标识
  • 来源消息: 消息ID
  • 媒体类型: 图片/音频/视频/文件
  • 处理状态: 待处理/分析中/已完成
  • 分析结果: 文本/标签/元数据
• 划分原因：
  专门处理多媒体问答需求
• 使用场景：
  图像识别、语音转文字、文件内容提取

模型关系说明

设计要点说明

1. 单用户多机器人架构

• 移除多用户相关属性，聚焦本地用户场景
• 机器人代理模型增强服务端点定义，支持本地函数调用
  2. 机器人编排核心机制
• 执行优先级：控制机器人调用顺序

• 时序标记：跟踪多步骤执行过程
• 数据传递规则：定义机器人间输入输出映射

• 示例流程：

  “`
  用户问题 → 路由机器人(优先级1) → 分析机器人(优先级2) → 执行机器人(优先级3) → 最终答复
  “`

  3. 多媒体处理流程
• 媒体处理模型独立存储分析状态

• 支持异步处理：用户上传图片 → 图片分析机器人 → 文本结果返回

  4. 会话生命周期管理
• 交互会话绑定多个机器人

• 通过 当前状态跟踪问答进度

  5. 异常处理设计
• 超时设置自动终止长时间未响应流程

• 媒体 处理状态跟踪分析进度

  6. 扩展性考虑
• 机器人 能力类型支持动态扩展

• 数据传递规则允许自定义输入输出转换
• 新增机器人只需注册到系统即可参与编排

总结

本文介绍了如何利用领域驱动设计（DDD）对AI应用进行建模，重点聚焦纯文字交互类应用。通过借鉴聊天软件的领域模型，将其精简为适用于单用户多机器人交互的场景，包含核心用户、机器人代理、交互会话、交互消息、执行编排和媒体处理六大模型。这些模型支持多机器人协作、任务编排和多媒体处理，为构建本地问答型AI应用提供了清晰的架构设计思路。