案例面向养宠人群的 AI 平台：覆盖健康诊断 / 训练指导 / 社区互动 / 走失找回，整合微信小程序、Web 站、后台与运营。
面向养宠人群的 AI 平台：覆盖健康诊断 / 训练指导 / 社区互动 / 走失找回，整合微信小程序、Web 站、后台与运营。5 人核心团队 12 周完成首版上线，小程序端承载 80+ 页面，覆盖宠主、训犬师、兽医、救助站、平台运营等 8 大角色视角。
这个项目的小程序端页面数量远超一般电商或工具类小程序——健康诊断流程涉及拍摄引导→照片确认→分析中→报告展示→历史记录等 7 个连续页面，训练模块又有日志填写→AI 评估→方案展示→打卡记录等 5 个页面，加上社区、个人中心、走失找回等，首版就有 80+ 页面。
微信小程序对包体积有硬限制（主包 ≤ 2MB、总包 ≤ 20MB），80+ 页面全部打包进主包根本不可能。我们的解决方案：按功能域拆分为 4 个分包——健康分包、训练分包、社区分包、找回分包——主包只保留首页和登录。配合分包预加载策略（在首页加载时预加载健康分包），用户进入最常用路径的感知延迟控制在 400ms 以内。
另一个容易忽略的点：小程序页面栈限制 10 层。健康诊断的 7 步流程如果全用 navigateTo 推页面，走到第 7 步时页面栈已满，后续操作会静默失败。我们将诊断流程改为单页面 + 步骤组件切换的方案，用 redirectTo 替代 navigateTo 来刷新页面栈——方案不太优雅，但在小程序生态里是唯一可行的做法。
健康诊断模块的延迟敏感度很高：宠主拍完照片后等超过 5 秒就会开始焦虑。单张照片的多模态推理耗时约 1.8–2.5 秒，如果同时传 3 张（皮肤 + 眼睛 + 牙齿），串行推理总延迟 6–8 秒不可接受。
我们做了两件事：第一，后端用 asyncio.gather 并行发送 3 个推理请求，总延迟压到约 2.5 秒；第二，推理过程中通过 WebSocket 推送进度提示（"正在分析皮肤…""正在检查牙齿…"），让用户感知到系统在工作。最终用户体验：约 2 秒后看到第一条结果，约 4 秒看到完整报告。
成本侧：单次诊断调用的推理 Token 消耗约 ¥0.12–0.18（基于 2025 年国内多模态模型 API 定价）。按日活 3000 用户、月均每用户诊断 2.5 次计算，月度推理成本约 ¥1,350–2,025——在可接受范围。但如果日活涨到 3 万，单月成本将突破 ¥2 万，届时需要考虑本地部署轻量模型做初筛、仅将疑似异常图片送大模型。
第一个坑：初版社区上线时我们做了 AI 自动审核（基于文本 + 图片敏感内容识别），人工审核作为兜底——这是标准做法。但我们低估了宠物社区的"灰色内容"比例：卖狗广告伪装成"分享我家柯基的日常"、配种信息穿插在正常帖子里、宠物药品的私下交易——AI 审核对这些半灰内容的准确率不到 60%。上线前两周，人工审核团队每天要处理 200+ 条漏网内容，远超预期的 30–50 条。
第二次翻车是修这个问题时的过度反应：我们调高了 AI 审核的敏感度，结果把大量正常内容也拦了——"我家狗狗今天有点拉稀，大家有推荐的益生菌吗？"这种正常的健康咨询也被标记为"药品交易"。用户投诉量一周内翻了 3 倍。
最终方案：AI 审核不做"拦截"而是做"分级"——明确违规（血腥、色情）直接拦截；疑似商业内容（卖狗、配种、药）标记为"待审核"但不阻断发布，人工在 2 小时内复核。同时上线了"用户举报→自动隐藏→人工复核"的社区自治机制。这套方案上线后，误伤率从约 15% 降到约 3%，漏审率保持在 5% 以内。
教训：UGC 社区的审核不能走两个极端——要么全自动要么全人工。关键是搞清楚你的社区里"灰色内容"的比例和类型，再决定审核策略的松紧度。宠物社区和母婴社区、二手交易社区的灰色内容类型完全不同，不能照搬通用方案。
前端：Next.js（website + admin） · React · TypeScript · Tailwind CSS · Lucide
后端：FastAPI · SQLAlchemy · asyncpg · Alembic · PostgreSQL · Redis（缓存 + 会话 + 消息队列）
移动端：微信小程序（80+ 页面，4 个分包）
AI 能力：多模态大模型（健康诊断图像分析）· LLM（训练方案生成 + 内容审核初筛）
部署：Docker + Nginx 反向代理 · 腾讯云服务器 · 对象存储 COS（图片/视频）
]]>