Miss U：AI 宠物数字陪伴项目介绍

一、项目概述

Miss U 是一个面向宠物主人的 AI 数字陪伴产品。用户可以上传宠物照片，或使用文字描述创建宠物形象；系统通过多模态 AI 识别宠物特征、生成数字头像和个性档案，并让用户以类似即时通讯的方式与宠物进行持续对话。

项目并不只是一个“套壳聊天机器人”，而是围绕“数字陪伴”搭建了一条完整产品链路：

1. 用户通过手机号验证码注册和登录；
2. 上传宠物照片或填写文字描述；
3. AI 判断素材是否为真实宠物，提取品种、毛色、性格等信息；
4. AI 生成风格统一的宠物数字形象，并自动处理为透明背景贴纸；
5. 用户进入宠物专属聊天页，与具备固定身份、性格和上下文的 AI 宠物对话；
6. 系统从聊天中提取有价值的信息，并将其保存为宠物的长期记忆；
7. 通过每日聊天额度、投喂和数字内容购买形成基础商业化闭环；
8. 同一套 Web 代码通过 Capacitor 打包为 iOS App。

这个项目将多模态生成式 AI、后端业务系统、移动端适配、支付与情感化产品设计结合在了一起。

二、整体技术架构

项目采用 npm Workspaces Monorepo，将前端、后端和共享类型统一管理：

app-miss-u/
├── apps/web          # Next.js Web 与 Capacitor iOS 前端
├── apps/api          # NestJS REST API
├── packages/shared   # 前后端共享的 TypeScript 类型
└── prisma            # PostgreSQL 数据模型

一次典型的 AI 调用链路如下：

照片/文字输入
    ↓
Next.js 创建流程
    ↓
NestJS API 参数校验与用户权限检查
    ↓
视觉模型识别宠物信息
    ↓
图片模型生成统一风格头像
    ↓
Sharp 色键抠图，生成透明 PNG
    ↓
Prisma 写入宠物档案与初始记忆
    ↓
进入带短期上下文和长期记忆的宠物对话

三、技术栈

1. 前端与移动端

• Next.js 15、React 19、TypeScript：使用 App Router 构建首页、创建页、登录页和聊天页。
• React Hooks：封装陪伴列表、创建流程和聊天会话等状态逻辑。
• Optimistic UI：发送聊天消息时先在本地展示用户消息，接口返回后再替换为服务端数据，降低 AI 响应等待带来的卡顿感。
• Capacitor 8：复用 Web 前端构建 iOS App，并接入 Camera、Keyboard、Haptics、Status Bar、Splash Screen 等原生能力。
• Lottie：在 AI 图片生成和离场动画中提供等待反馈，改善长耗时任务的体验。
• Lucide React 与自定义 CSS 动画：完成移动端优先的视觉界面和交互动效。

2. 后端

• NestJS 10、TypeScript：按 Auth、Pets、Chat、AI、Payments、Feeding、Store 等领域进行模块化分层。
• REST API + DTO 校验：统一请求验证、鉴权和异常返回。
• OpenAI JavaScript SDK / OpenAI 兼容接口：调用文本、视觉和图片生成模型；模型名称、Base URL 和超时时间均支持环境变量配置。
• Sharp：完成图片方向校正、格式归一化、像素级绿幕抠图、边缘去绿和 PNG 压缩。
• 阿里云号码认证服务：发送和校验手机验证码。
• Z-Pay：创建支付订单、验证异步回调签名并进行数字权益履约。

3. 数据与工程化

• PostgreSQL + Prisma ORM：持久化用户、会话、宠物、消息、长期记忆、订单和投喂记录。
• 共享类型包：@miss-u/shared 统一前后端接口模型，减少字段漂移和重复定义。
• 双存储模式：开发演示时可使用内存 Store，正式环境使用 Prisma Store；业务服务依赖抽象的 PetStore，降低存储实现与业务逻辑的耦合。
• 生产配置 fail-fast：生产启动时检查数据库、AI、短信、支付、HTTPS 地址和 CORS 来源，避免因漏配环境变量静默进入不安全的演示模式。
• Git + npm scripts：支持统一的 build、typecheck、Prisma generate、数据库迁移以及 iOS 同步命令。

四、AI 能力设计

1. 多模态宠物档案生成

系统将照片以 Data URL 上传，在服务端完成解码和格式归一化，然后交给视觉模型判断主体是否为真实宠物，并生成结构化资料：

• 宠物类别；
• 品种提示；
• 毛色与外观特征；
• 3～5 个中文性格标签；
• 符合宠物身份的第一句问候。

服务端不会直接相信模型输出，而是对 JSON 结构、物种枚举和 isPet 结果再次校验。对于人物、玩具、摆件和普通物品等非宠物素材，会返回明确的业务提示。

2. AI 数字形象生成与自动抠图

为了让头像能自然叠加在聊天页和“我的家”等不同场景中，生成结果必须具有稳定的透明背景。但不同图片模型对直接生成透明 PNG 的支持并不稳定，因此项目采用了更可控的两阶段方案：

1. Prompt 强制模型生成统一的 #00FF00 纯绿背景，并约束主体数量、全身构图、居中位置和画面占比；
2. 后端使用 Sharp 遍历 RGBA 像素，根据绿色亮度、相对色彩优势和饱和度计算色键强度；
3. 强绿色像素设为透明，边缘半透明像素进行去绿处理，减少绿色溢色；
4. 检查绿幕像素占比，若模型未按要求生成合格背景则拒绝错误结果，而不是存入脏数据；
5. 最终压缩为透明 PNG Data URL。

这一实现把生成式 AI 的概率性输出转化成了可验证、可进入产品界面的稳定资产。

3. 有角色一致性的宠物对话

对话系统通过 Prompt、宠物档案、最近消息和长期记忆共同构建上下文。核心设计包括：

• 明确 AI 的第一身份是“用户的宠物”，避免输出客服或模型口吻；
• 日常问题优先直接回答，不把每次聊天都强行变成悼念或心理安慰；
• 只有用户主动表达想念、悲伤、自责或告别时，才切换到更深的情绪陪伴；
• 将最近 8 条消息加入上下文，保证短期对话连续性；
• 检索与当前输入相关的长期记忆，使宠物能够自然承接共同经历；
• 过滤“数字形象由照片创建”等系统元信息，避免角色在聊天中暴露内部设定；
• AI 不可用时使用规则化降级回复，保证核心聊天链路仍可体验。

4. 对话记忆提取

每次用户发言后，系统会调用独立的记忆提取器，判断内容是否包含偏好、日常习惯、家庭关系、里程碑或重要共同经历。符合条件的内容会被整理为结构化记忆并写入数据库。

记忆分为 preference、routine、family、milestone、moment 等类型。AI 服务不可用时，还可根据“喜欢、以前、生日、散步、告别”等线索进行规则降级提取。这样既保留了模型的语义理解能力，也避免外部服务异常时整个记忆功能失效。

五、项目中遇到的问题与解决方案

问题 1：AI 生成的头像背景不透明，且主体大小不一致

问题表现： 图片模型可能生成渐变背景、阴影、边框或不同远近的主体，导致头像无法作为贴纸复用，页面布局也会跳动。

解决方案： 在 Prompt 中同时约束纯色绿幕、无阴影、单主体、全身、居中和约 78% 的画面占比；随后使用 Sharp 自研色键算法抠图，并通过绿色像素比例做质量门控。该方案同时解决了透明背景、绿边和不同头像视觉尺度不统一的问题。

问题 2：视觉模型输出具有不确定性，非宠物图片可能进入创建流程

问题表现： 仅靠前端文件类型无法判断照片内容，模型也可能返回 Markdown、非法 JSON 或不受支持的类别。

解决方案： 服务端先验证 Data URL 与图片格式，再将图片归一化；要求模型只返回固定 JSON，并对 isPet、species 和字段枚举二次校验。对无效图片、未配置、超时、上游不可用和非法响应分别映射成可读错误，便于前端给出准确提示。

问题 3：AI 宠物容易复读、暴露设定或过度煽情

问题表现： 初版角色对话容易重复用户原话、每次都提“想念与离别”，或者直接说出“照片生成”“性格标签”等后台资料，破坏沉浸感。

解决方案： 重构系统 Prompt，规定“先回答问题、再保持宠物口吻、按情绪强度决定陪伴深度”的优先级；加入少复读、少套话、日常话题轻量回应等具体约束；同时过滤系统生成的 onboarding 档案，只把真实故事和用户记忆用于对话。

问题 4：只有短期上下文，长时间使用后角色不记得重要经历

问题表现： 把全部历史消息发送给模型成本高、速度慢，而只发送最近几条又会丢失长期信息。

解决方案： 将记忆从聊天原文中抽取为独立结构化数据；生成回复时只组合最近 8 条消息和与当前输入相关的记忆。这样在控制 Token 成本与延迟的同时，实现了短期上下文和长期记忆的结合。

问题 5：并发发送消息可能穿透每日额度

问题表现： 用户快速点击或重复请求时，多个请求可能同时读到相同的剩余额度，从而超出每日限制；单纯依赖前端禁用按钮并不可靠。

解决方案： 前端在请求期间锁定发送状态；后端按“用户 + 宠物”建立发送队列。在 PostgreSQL 模式下，再使用事务和 SELECT ... FOR UPDATE 锁定对应宠物记录，把额度检查和用户消息写入放进同一事务，降低并发超额风险。每日边界按照中国时区计算，额度状态由服务端统一返回。

问题 6：支付成功回跳与异步通知存在时序差异，权益可能重复或遗漏

问题表现： 浏览器回跳可能早于支付平台异步通知，也可能被刷新或重复访问；如果只在前端显示“支付成功”，刷新后权益就会消失，重复调用还可能发放多次。

解决方案： 支付平台回调负责校验签名、商户号、金额和订单信息；前端回跳后先查询订单状态，再调用服务端履约接口。订单通过 status 与 consumedAt 记录状态，履约逻辑以数据库为准并设计为可重复调用，已履约时返回现有结果，从而保证最终一致性和幂等性。

问题 7：免费创建资格与付费资格在异常时可能被错误消耗

问题表现： 创建宠物涉及视觉识别、图片生成、数据库写入等多个步骤，任何一步失败都可能造成“资格扣了，但宠物没有创建成功”。

解决方案： 创建前先预留免费或付费资格；只有宠物成功保存后才完成消费。若生成或保存失败，则在 catch 中释放免费名额或付费订单预留，使长链路操作具备补偿机制。

问题 8：Web 迁移到 iOS 后出现本地地址、键盘遮挡和支付状态恢复问题

问题表现： iOS 真机无法访问开发机的 localhost；软键盘会改变可视区域并遮挡最新消息；从浏览器支付页返回 App 后还需要恢复订单与聊天状态。

解决方案： 使用 Capacitor 复用静态导出的 Next.js 页面；构建时检查原生环境下的 API 地址，发布包禁止使用 localhost，并要求线上 HTTPS API；通过 Capacitor Keyboard 的 Native Resize 和聊天布局状态调整处理键盘；支付回跳时读取 URL 参数、查询服务端订单、完成履约，再清理 URL 并刷新时间线。

问题 9：开发环境需要快速演示，生产环境又不能静默降级

问题表现： 本地开发如果强依赖数据库和全部第三方服务，启动成本高；但若生产环境误用内存存储，重启后用户和订单数据会全部丢失。

解决方案： 数据访问层通过 Store 接口支持内存与 Prisma 两种实现；开发时可以快速跑通演示链路，生产启动则集中校验 USE_DATABASE、PostgreSQL、AI、短信、支付、HTTPS 与 CORS 配置，缺少关键配置时直接启动失败。

六、项目亮点

1. AI 能力不是单点调用，而是完整业务闭环

项目把视觉理解、图片生成、角色对话和记忆提取串成连续体验，并进一步连接用户系统、数据库、支付和移动端，而不是停留在一个 Prompt Demo。

2. 对概率性 AI 输出进行了工程化治理

图片有格式归一化、绿幕比例检测与失败拦截；结构化文本有 JSON 解析、字段白名单和枚举验证；所有外部 AI 调用都有独立超时、异常分类和降级策略。这些设计提高了 AI 功能在真实产品中的稳定性。

3. 自研像素级抠图链路

通过“可控绿幕生成 + Sharp 像素处理”解决生成模型透明背景不稳定的问题，同时处理抗锯齿边缘的绿色溢色。这是一个兼具 AI Prompt 设计与传统图像处理的复合方案。

4. 面向情感场景的角色与安全边界设计

Prompt 不仅定义“说什么”，还规定普通闲聊、具体问题、悲伤、自责与告别等不同情绪场景的响应优先级；避免 AI 过度煽情、冒充心理医生或暴露模型身份，使对话更自然、克制且符合产品定位。

5. 长短期记忆结合

最近消息保证当前对话连贯，结构化长期记忆保存用户的重要经历；通过相关记忆检索控制上下文体积，在体验、延迟和调用成本之间做了平衡。

6. 具备真实业务系统所需的可靠性意识

项目处理了用户数据隔离、Session Token 哈希存储、验证码重试与尝试次数、并发额度、支付签名、幂等履约、异常补偿和生产配置校验等问题，体现了从原型走向可上线产品的工程思考。

7. 一套代码覆盖 Web 与 iOS

使用 Next.js + Capacitor 复用主要业务界面和逻辑，同时对相机、键盘、状态栏、启动页、触觉反馈与原生网络环境进行适配，降低了多端开发和维护成本。

8. 兼顾产品体验与商业化

创建等待动画、乐观消息、投喂反馈和“我的家”等设计强化了陪伴感；每日额度、付费创建、投喂和家具等机制则验证了 AI 产品的商业化路径。

七、我在项目中的工作总结（面试表述参考）

我独立完成了一个 AI 宠物数字陪伴产品的前后端与移动端实现。前端使用 Next.js、React 和 TypeScript，后端使用 NestJS、Prisma 与 PostgreSQL，并通过 Capacitor 将 Web 项目迁移为 iOS App。

AI 部分包含宠物照片识别、结构化档案生成、数字形象生成、角色对话和长期记忆提取。我针对图片模型透明背景不稳定的问题，设计了“纯绿背景生成 + Sharp 像素级色键抠图”的处理链路；针对大模型角色漂移、复读和过度煽情的问题，重构了分场景 Prompt，并将最近对话与结构化长期记忆组合进上下文。

工程方面，我实现了手机号验证码登录、Token 鉴权、用户数据隔离、聊天并发额度控制、支付回调验签、幂等履约和失败补偿，并通过共享类型包统一前后端协议。这个项目让我完整实践了如何把不确定的生成式 AI 能力包装成一个可交互、可持久化、可商业化且具备基本可靠性的产品。

八、当前可继续完善的方向

以下内容适合作为面试中“如果继续做，我会怎样优化”的回答：

• 将原图和 AI 图片从数据库 Data URL 迁移到对象存储，数据库仅保存对象键和元数据；
• 为图片增加真实格式、像素数、解码资源和恶意内容检测；
• 引入 Redis 或数据库原子计数器，实现多实例下的统一限流与任务队列；
• 为 AI 调用增加成本监控、请求追踪、重试、熔断和缓存；
• 使用向量 Embedding 优化长期记忆的语义检索与去重；
• 补充鉴权、支付、额度、上传和 AI 降级的自动化测试，并接入 CI；
• iOS 数字内容购买改用 StoreKit 2 和服务端交易验证，满足 App Store 要求；
• 增加应用内账号注销、隐私政策、数据删除与第三方 AI 数据处理说明；
• 增加结构化日志、错误追踪、指标告警和数据库 readiness 检查。

---

本文根据 app-miss-u 当前源码、Prisma 数据模型、项目文档与 Git 提交记录整理。功能判断以前端当前实际引用和用户可达页面为准：后端虽然保留 AlbumItem、MemoryCard 数据结构及相关写入代码，但当前前端聊天页面没有渲染对应组件，因此本文不将其表述为 App 已有的相册或纪念卡片功能。面试时应以自己实际负责和完成的部分为准，避免把未接入界面的代码或规划项表述为已经上线的能力。