 Blizzard
|
60ee9d4bbc
|
feat(be): 记录类型挪进数据库，后台可配 + 15 种新类型
## 为什么
9 种记录类型全是低频医疗和记账（疫苗一年一次、驱虫一季一次、体检更少），
用户今天打开 App 大概率没什么可记，时间轴是空的。竞品 35 种里有 26 种是
高频日常（洗澡/剪指甲/换猫砂/喝水/洗食盆），那才是每天打开的理由。
## 一个比预想好得多的发现
本来担心加类型会踩到分析逻辑。把那 9 个常量的引用全捞了一遍，结论是不会：
weight record.go:83 回写宠物体重；home/insight/report 的体重趋势与基准
food + poop insight.go:130 食便相关性
symptom insight.go:160 症状聚类；report 高风险计数
cost report.go:99 消费统计
vaccine report.go:137 疫苗完成度
deworm/medicine/photo 没有任何特殊分支
这些分支全都是「按某个具体常量过滤」，没有一处是 switch 全枚举、也没有
default 兜底。CreateRecord 更是完全没有 type 白名单校验。所以新增类型
不可能碰到任何现存逻辑——一行分析代码都不用改。
于是分工是：
record_types 表 负责「展示什么、能记什么」
那 9 个常量 负责「哪几种参与分析」
两者各管一段，常量一个都没删。
## 表设计
code / label / icon / group_key / sort / enabled / form / locked。
group_key 而不是 group：group 是 MySQL 保留字，GORM 会加反引号所以能跑，
但手写 SQL 排查时很容易踩。
form 区分 full（弹层里有专用 wx:elif 分支）和 simple（时间+备注+照片）。
15 种新类型全是 simple——下一步在弹层加一个通用分支吃掉它们，不然 28 个
分支再加 15 个会把 bottom-sheet 写到 1800 行。
locked 给那 9 种：有代码分支依赖、且被 care_template_items.sheet_type 引用。
## 两条硬拦在 service 层的规则
1. locked 的删不掉
2. 已经有记录的删不掉（删了历史记录会变孤儿）
想让它从记录页消失应该用 enabled=false，历史记录仍能正常显示。
都在 service 层拦，不是靠前端隐藏按钮。改 code 同样受 2 的约束——
code 是落库值，改了历史记录会对不上任何类型。
## bootstrap 的取舍
文章和养护模板当初按你的要求从代码里挪走了，这次 24 种类型仍然放在 seed 里，
因为它不是内容而是结构：表空着记录页一个可记事项都没有，App 直接不能用。
和管理员账号一样，只在表**完全为空**时铺一次，之后一切以数据库为准。
表非空就完全不碰，否则后台删掉的类型会每次重启自己长回来。
ListRecordTypes 在表为空时返回空数组 + 打 warn，不硬编码兜底一份——
那等于把「可配置」又变回代码常量，下次改配置的人会发现改了没用。
## 图标
新增 15 个（iconfont.wxss 40 → 55），全部取自本地那份 tabler-icons-3.46.0
真源，不是凭记忆画路径。已解码抽检确认路径非空。
## 验证（生产库实跑）
建表 + 24 条 bootstrap 一次到位，分组 daily6/health7/care6/clean5
locked 9 个、simple 表单 15 个
规则 1 删 weight → 「有统计和分析逻辑依赖它，不能删」
规则 2 新增 nose 成功 → 重复 code 报错 → 删除成功
规则 3 造 1 条 tmptest 记录 → 删类型被拦；删掉记录后再删 → 成功；残留 0
规则 4 停用「美容」→ 小程序端洗护组只剩 5 项；恢复后回到 6 项
规则 3 一开始没真验到：库里唯一的记录类型是 weight，locked 先拦住了，
「已有记录」那个分支根本没走到。补了个造真记录的测试才算验过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-07-30 09:24:24 +08:00 |
|
|
Blizzard
|
75765b3ee8
|
feat: 健康洞察——把散落的记录变成能看懂的结论
之前用户记几十条数据只换回一条折线，数据没有回到他身上，所以不记也不亏。
新增 GET /api/pets/:id/insights，只看最近 90 天（更早的对「现在怎么样」
没参考价值，还会让关联分析找出一堆巧合），产出最多 6 条按严重度排序的结论：
1. 体重趋势 —— 单次数字没意义，跨度 ≥14 天的连续同向变化才算。
跌 10% 报警建议血检，涨 15% 提醒控制，跌 5% 持续观察
2. 换粮 → 软便的时间关联 —— 找异常排便前 72 小时内的饮食记录。
这是用户最看不出来的一类：两条记录隔两三天、分属不同类型，翻时间轴翻不出来
3. 异常扎堆 —— 两周内 ≥2 次异常。偶发一次和反复出现完全不是一回事
4. 逾期提醒 —— 设了不看等于没设
5. 同龄体重对比 —— 同物种、月龄差 2 个月内其它宠物的中位数。
样本 <8 只直接不显示：拿 3 只算出来的「中位数」比不给还糟
6. 记录习惯 —— 数据不足时negative空手而归，给一句「再记几条就能看出规律」
每条都带 evidence（支撑它的具体数据）和 action（点击直接跳到对应记录入口），
结论不能只是断言。文案沿用 AI 助手同一套护栏：不做诊断，异常一律写清
什么时候必须就医。
前端落在记录页体重趋势卡上方，三档配色区分严重度。
实测（造 4 条体重下滑 + 换粮 + 软便 + 两次异常）：
🔴 体重掉了 13%，建议就医检查（39 天内 4.50→3.90kg）
🔴 两周内记了 2 次异常
🟠 这次「软便」之前 2 天有过饮食变化（7月20日换粮 → 7月22日软便）
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-07-29 15:03:36 +08:00 |
|
|
Blizzard
|
2f5dd6eefc
|
feat: 养护模板/社区运营/体重趋势/计划日历 + 雪花ID重构 + 文件表与图片上传
后端
- 主键改雪花字符串 ID（pkg/idgen + Base.BeforeCreate），全表外键/JWT/中间件随之调整
- 新增 files 表：/api/upload 按 MD5 去重，返回 {id,url,md5}，服务端只收图片
- 头像/记录附图/帖子图改 file_id 关联，读取解析为 URL
- 养护模板（物种×阶段）后台可配 + AI 生成草稿；建档按模板生成任务/计划/提醒
- 社区 AI 运营：虚拟账号池 + 每日定时/手动生成，帖子带 AI 标
- 计划路线图节点带真实日期；首页周历与计划日历同源；新增 day-plan 当日安排
- 体重趋势接口带备注；记录列表分页
小程序
- 公共图片上传 utils/upload.js（仅图片）；记录拍照/我的头像/社区发图三处接入
- 首页日历点选查当日任务；记录页体重趋势可点看备注 + 时间轴分页折叠
- 计划页日历点选查当日计划；自定义 tabBar 高度调整
后台（React）
- 新增「养护模板」「社区运营」页；用户管理加机器人筛选
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-06 08:48:15 +08:00 |
|
|
Blizzard
|
609f7d06cf
|
init: 毛孩子计划 小程序 + Go 后端 + 内嵌后台
- pets-fe: 微信原生小程序（首页/计划/记录/报告/社区/引导），
服务端驱动、无假数据；弹层改用 scroll-view，打开时隐藏自定义 tabBar
- pets-be: Gin + GORM(MySQL, sundynix_ 前缀) + MinIO，统一响应/分页，
微信 code2session 登录，provider-neutral AI(DeepSeek)，go:embed React 后台
- 修复：分段选择类型不匹配（字符串 vs 数字）导致选不中
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
2026-07-03 15:36:55 +08:00 |
|