| # Human-Clone 系统需求调研记录 | |
| ## 调研日期 | |
| 2025-01-04 | |
| ## 项目概述 | |
| Human-Clone 系统需求分析 | |
| ## 第一轮调研 | |
| ### 用户回答记录 | |
| **问题**: 这个human-clone系统的主要用途是什么？ | |
| **回答**: human 和 clone 之间相互协作，且可以和其他 clone、human 之间相互通讯的系统。现阶段首先解决的是通讯问题。 | |
| ### 初步需求分析 | |
| - **核心功能**: 多主体间通讯协作系统 | |
| - **主体类型**: human, clone | |
| - **通讯模式**: | |
| - human ↔ clone | |
| - clone ↔ clone | |
| - human ↔ human (通过系统) | |
| - **当前优先级**: 通讯功能 | |
| ### 下一步调研方向 | |
| 需要深入了解通讯的具体需求和技术细节。 | |
| ### 第二轮调研记录 | |
| **问题**: 这些主体之间的通讯主要是通过什么形式？文字、语音、还是视频？ | |
| **回答**: 第一步先解决主体之间文字形式的通讯 | |
| ### 需求更新 | |
| - **通讯方式**: 首先实现文字通讯 | |
| - **开发阶段**: 第一阶段专注文字通讯功能 | |
| - **通讯模式**: 实时异步通讯 | |
| ### 第三轮调研记录 | |
| **问题**: 系统需要支持实时通讯（如聊天室形式）还是异步通讯（如邮件/留言形式）？ | |
| **回答**: 基本属于实施通讯，但是是异步的，计划采用 redis 订阅的方式来实现信息传递，每一个主体都会有一个 redis-adapter，负责发送和接收消息 | |
| ### 技术架构初步确定 | |
| - **消息传递**: Redis 订阅/发布模式 | |
| - **组件设计**: 每个主体配备 redis-adapter | |
| - **消息处理**: 发送/接收消息统一处理 | |
| ### 第四轮调研记录 | |
| **问题**: 每个主体（human/clone）需要有自己的身份标识吗？比如用户名、ID之类的？ | |
| **回答**: 需要有 id —— uuid 格式、实体名称（name)、redis-adapter 里和 redis 相关订阅 channel 相关的配置信息 | |
| ### 主体身份设计 | |
| - **唯一标识**: UUID格式ID | |
| - **显示名称**: 实体名称(name) | |
| - **配置信息**: redis-adapter配置（订阅channel等） | |
| ### 第五轮调研记录 | |
| **问题**: 消息需要有哪些基本字段？比如发送者、接收者、时间戳、消息内容？ | |
| **回答**: 需要，其中发送者、接收者都使用 id | |
| ### 消息结构设计 | |
| - **发送者**: UUID格式ID | |
| - **接收者**: UUID格式ID | |
| - **时间戳**: 消息发送时间 | |
| - **消息内容**: 文字内容 | |
| - **消息类型**: 点对点通讯 | |
| ### 第六轮调研记录 | |
| **问题**: 是否需要支持群发消息（一个发送者同时发给多个接收者）？ | |
| **回答**: 此阶段不需要 | |
| ### 功能范围明确 | |
| - **当前阶段**: 仅支持点对点消息 | |
| - **群发功能**: 后续版本考虑 | |
| ### 第七轮调研记录 | |
| **问题**: 系统需要存储历史消息记录吗？ | |
| **回答**: 需要 | |
| ### 数据持久化需求 | |
| - **消息存储**: 需要保存历史消息记录 | |
| - **存储方案**: 待确定（数据库选择） | |
| ### 第八轮调研记录 | |
| **问题**: 历史消息需要保存多长时间？ | |
| **回答**: 先不讨论历史记录的问题，先解决通信问题 | |
| ### 开发优先级调整 | |
| - **当前重点**: 通讯功能实现 | |
| - **历史记录**: 后续阶段处理 | |
| ### 第九轮调研记录 | |
| **问题**: redis-adapter 需要哪些具体的配置信息？比如 Redis 服务器地址、端口、认证信息等？ | |
| **回答**: redis 服务器地址、端口、db、channel | |
| ### redis-adapter 配置设计 | |
| - **服务器地址**: Redis host | |
| - **端口**: Redis port | |
| - **数据库**: Redis DB number | |
| - **频道**: 订阅/发布的 channel | |
| ### 第十轮调研记录 | |
| **问题**: 每个主体是使用相同的 channel 还是各自有独立的 channel？如果是独立的，channel 的命名规则是什么？ | |
| **回答**: 每个主体都是独立的 channel，channel 的命名就是主体的 id | |
| ### Channel 设计方案 | |
| - **Channel 分配**: 每个主体独立 channel | |
| - **命名规则**: 使用主体的 UUID 作为 channel 名称 | |
| - **通讯机制**: 目标主体监听自己的 channel 接收消息 | |
| ### 第十一轮调研记录 | |
| **问题**: 当一个主体要发送消息给另一个主体时，是如何知道接收者的 channel 名称的？是否需要一个主体注册发现机制？ | |
| **回答**: 主体注册发现机制可以放到下一个迭代，此次只假设可以通过目标主体的 id 就可以获得目标主体的订阅 redis 参数，包括服务器、端口、db、channel | |
| ### 主体发现机制设计 | |
| - **当前版本**: 假设可通过 ID 获取目标的 Redis 连接参数 | |
| - **后续迭代**: 实现主体注册发现机制 | |
| - **参数获取**: 服务器地址、端口、DB、channel 通过 ID 直接获得 | |
| ### 第十二轮调研记录 | |
| **问题**: redis-adapter 是否需要处理连接断开重连、消息发送失败重试等异常情况？ | |
| **回答**: 目前不需要 | |
| ### 异常处理设计 | |
| - **当前版本**: 不处理连接重连和重试机制 | |
| - **设计原则**: 专注核心通讯功能，异常处理后续考虑 | |
| ### 第十三轮调研记录 | |
| **问题**: 消息的发送和接收是否需要确认机制？比如接收者收到消息后需要回复确认？ | |
| **回答**: 不需要 | |
| ### 消息确认机制 | |
| - **确认机制**: 不需要消息确认 | |
| - **通讯模式**: 单向发送，无回复确认 | |
| - **简化设计**: 降低复杂度，专注基础通讯 | |
| ### 第十四轮调研记录 | |
| **问题**: 系统是否需要区分不同类型的消息？比如普通消息、系统消息、命令消息等？ | |
| **回答**: 不需要 | |
| ### 消息类型设计 | |
| - **消息分类**: 不区分消息类型 | |
| - **统一处理**: 所有消息均为普通文字消息 | |
| - **简化架构**: 无需消息类型判断和处理逻辑 | |
| ### 第十五轮调研记录 | |
| **问题**: 每个主体的 redis-adapter 是需要同时监听多个 channel（包括自己的和其他主体的）还是只监听自己的 channel？ | |
| **回答**: 只监听自己的 | |
| ### 监听机制设计 | |
| - **监听范围**: 每个主体只监听自己的 channel | |
| - **消息接收**: 通过订阅自己的 ID channel 接收消息 | |
| - **消息发送**: 向目标主体的 ID channel 发布消息 | |
| ### 需求调研总结 | |
| 基于15轮调研，Human-Clone 系统第一版本的核心需求已明确： | |
| #### 系统架构 | |
| - **主体类型**: human、clone | |
| - **通讯模式**: 点对点文字通讯 | |
| - **技术方案**: Redis 订阅/发布模式 | |
| - **身份标识**: UUID + name | |
| #### 核心组件 | |
| - **redis-adapter**: 每个主体一个，负责发送/接收消息 | |
| - **配置参数**: 服务器地址、端口、DB、channel(=主体ID) | |
| - **监听机制**: 只监听自己的 channel | |
| #### 消息格式 | |
| - **发送者ID**: UUID格式 | |
| - **接收者ID**: UUID格式 | |
| - **时间戳**: 发送时间 | |
| - **内容**: 文字消息 | |
| #### 功能边界 | |
| - ✅ 点对点文字通讯 | |
| - ❌ 群发消息 | |
| - ❌ 历史消息存储 | |
| - ❌ 连接重连机制 | |
| - ❌ 消息确认机制 | |
| - ❌ 消息类型区分 | |
| - ❌ 主体注册发现 | |
| ### 第十六轮调研记录 | |
| **问题**: 发送消息时是否需要引入发送缓存队列来解耦主体发送和Redis发送操作？ | |
| **回答**: 在发送主体不直接调用发送消息到 redis，而是在 redis-adapter 里设置一个发送缓存 queue，通过线程循环逐个 pop 后发送到 redis，这样主体发送和 redis 发送分开，且有缓存，解耦 | |
| ### 第十七轮调研记录 | |
| **问题**: 消息接收部分是否也需要类似的队列解耦设计？ | |
| **回答**: 消息接收部分，目标主体 B 的redis-adapter 收到 channel 里的消息后，推送到接收队列 receiver-queue，在线程里循环读取 queue，并调用 callback，给到 B 的函数里进行处理 | |
| ### 完整架构设计优化 | |
| - **发送缓存**: redis-adapter内部设置发送队列 | |
| - **接收缓存**: redis-adapter内部设置接收队列 | |
| - **双向异步**: 发送和接收均采用队列+线程机制 | |
| - **回调机制**: 接收线程通过callback将消息传递给主体 | |
| - **完全解耦**: Redis操作与主体处理完全分离 | |
| #### 下一步行动 | |
| 基于明确的需求和完整的双向异步架构设计，可以开始进行技术设计和开发实现。 |