1. 从技术选型到工程结构
前面我们已经确定了 AI 伴侣项目的技术方案：基础设施使用 CloudFlare Workers，服务端使用 Hono.js，前端使用 Next.js。接下来要考虑的，是如何把这些技术组织成一个便于维护、协作和持续迭代的工程项目。
我们会先划分产品需要的子系统，再说明它们之间的关系。明确这些内容之后，我们才能继续判断代码应该放在一个 Monorepo 中，还是拆成多个独立仓库，以及使用什么工具管理整个项目。
一个完整的 AI Agent 全栈产品，至少需要 Hono 服务端、Next.js 客户端和 Next.js 后台管理系统三个子系统。它们面对的使用者不同，承担的任务也不同。
2 Hono 服务端
服务端负责组织所有与 AI 对话相关的处理过程。它本身不执行模型推理，但记忆、情绪、人设和上下文如何进入 Prompt，都会影响最终回复的质量。
对话管线是服务端最重要的部分。一条用户消息进入系统后，会依次经过接收消息、安全检查、身份验证、记忆检索、情绪状态读取和 Prompt 组装，然后以流式方式调用 LLM。拿到模型响应后，服务端还要解析情绪变化和记忆触发点，写回记忆、更新情绪状态，最后把内容流式返回给客户端。
记忆检索会从 D1 和 Vectorize 中读取相关记忆，情绪状态则来自 KV。Prompt 组装时，需要把这些数据与人设、对话历史一起整理成完整上下文。前面的文章分别讨论过其中的每一个环节，服务端负责把它们连接成一条完整的调用链路。
用户认证与鉴权包括 JWT 的签发和验证、用户注册登录以及会话管理。服务端需要区分普通用户和管理员两类调用者：普通用户通过客户端访问，管理员通过后台管理系统访问，两者对应不同的 API 权限。
记忆系统 CRUD 围绕 D1、Vectorize 和 KV 展开。D1 负责关系型数据，Vectorize 负责向量检索，KV 负责需要快速读写的状态。相关接口要支持情景记忆的存储与检索、语义记忆的归纳与更新，以及用户偏好的读写。
情绪状态管理负责维护 AI 伴侣的情绪状态机，并提供情绪查询和状态转移 API。
除此之外，服务端还要为后台管理系统提供数据查询和系统配置接口。这些后台管理 API 会接触更敏感的数据，因此需要更严格的权限验证。
3 NextJS 客户端
客户端是用户日常使用的产品界面，设计重点是对话体验和交互响应。
聊天界面需要支持流式消息展示，也就是逐字输出效果，同时还要处理消息气泡、时间戳和情绪标签。它是整个产品中使用频率最高的交互区域，对响应速度和动画流畅度都有较高要求。
用户注册与登录负责账号体系的前端流程，包括邮箱注册和第三方登录。用户登录后，客户端还要管理 JWT token 的存储和自动刷新。
在个人设置中，用户可以配置 AI 伴侣的性格特征，例如温柔、理性或幽默，也可以调整记忆偏好，包括哪些话题更重要、是否允许系统记住某些信息，并管理自己的对话历史。
产品介绍页、功能说明页和定价页等入口页面需要对搜索引擎友好，因此适合使用 Next.js 的 SSG 能力生成静态页面。对话功能本身主要发生在客户端，但这些 SSR/SSG 落地页仍然承担产品介绍和搜索收录的职责。
客户端可能需要提供记忆回顾功能，让用户查看 AI 伴侣保存了哪些与自己有关的信息，并允许用户手动删除或修正记忆。这项能力能够让记忆系统保持透明，也是建立用户信任的重要部分。
4 NextJS 后台管理系统
后台管理系统面向运营人员和开发者，用于观察产品运行状态、管理内容并调整 AI 行为。
用户数据总览会展示活跃用户数、日均对话轮次、记忆使用量和用户留存率等指标，帮助运营人员判断产品当前的使用情况。
对话审计与内容安全用于查看脱敏后的用户对话，识别不当内容并检查 AI 回复质量。这既是合规要求，也是持续改进回复效果的重要手段。
Prompt 模板管理允许运营人员在线编辑系统 Prompt、人设描述和情绪响应模板。模板需要支持版本管理，可以回滚到以前的版