宠物相亲平台档案模块设计：健康数据与品种建模
导语
档案模块是宠物相亲平台所有能力的输入端：匹配引擎吃的是档案字段，活动报名校验吃的是健康记录，借配风控吃的是检疫证明。档案设计得好坏，直接决定后面每一个环节的上限。本篇从数据建模视角展开档案模块设计：基础字段体系如何分层、疫苗与检疫证明如何做结构化承接、档案数据如何建模成匹配引擎可用的输入，并给出可直接参考的 JSON 结构与建表语句。适合负责数据库设计与后端开发的工程师，也适合在需求评审阶段评估档案表单合理性的产品技术负责人。
一、字段体系：把档案拆成四个可独立演进的子域
品类公开的功能清单里，宠物档案的字段覆盖品种、年龄、性别、性格、绝育状态、疾病史、过敏史、照片视频。直接把这些字段平铺在一张表里是最常见的错误——字段来源不同、更新频率不同、敏感级别不同，混在一起会导致后期无法独立演进。建议按四个子域建模：
- 身份子域：品种、年龄、性别、绝育状态、体重。低频更新，强结构化，枚举值为主，是规则过滤层的主要输入。
- 行为子域：性格标签、精力水平、社交经验、训练程度。以多选标签加自由文本描述组合，是内容理解层（NLP 解析性格描述）的输入。
- 健康子域：疫苗接种记录、疾病史、过敏史、体检记录。高频更新（每次免疫后追加），敏感级别最高，需要单独的访问控制。
- 媒体子域：照片、视频、封面图。容量大、更新随意，独立存储与压缩处理，同时是 CV 内容理解的输入。
子域拆分带来的直接收益是权限与合规的解耦：健康子域只在配对流程、借配风控、活动报名校验三个场景按需披露，身份子域可以完整公开，行为子域与媒体子域按用户隐私设置控制。品类的安全合规分析也指出，宠物生物信息应单独加密存储并符合个人信息保护法的数据可携权要求，子域化正是这些要求落地的前提。
图中四个子域各自对接不同的下游消费方，这正是拆分的意义：身份子域喂给规则过滤层做硬性判断，行为与媒体两个子域喂给内容理解层做算法分析，健康子域则主要服务于风控与校验场景而非公开展示。任何子域的字段变更都不会波及其他子域的表结构。
二、疫苗与检疫证明的结构化设计：三个证明、一份模型
健康子域里最容易被做扁的是疫苗与检疫数据——很多实现只留一个「已接种疫苗」的布尔字段加一张图片上传。但《动物防疫法》语境下的犬猫检疫要求是明确的三件套：狂犬病免疫证明、免疫抗体检测合格报告、动物检疫合格证明（逐只出具），线上借配与活体流转场景的核验依赖这三份材料。品类公开报道也显示，业内早有注册资质设槛、上传疫苗证明扫描件的实践建议。
把它们结构化的关键，是把「证明」建模为带有效期、带颁发信息、带核验状态的对象，而不是图片附件：
{
"pet_id": "pet_20260906_0001",
"vaccination_records": [
{
"vaccine_type": "rabies",
"vaccine_name": "狂犬灭活疫苗",
"immunization_date": "2026-05-20",
"expire_date": "2027-05-19",
"hospital_id": "vet_h_0321",
"cert_image_id": "img_vac_881",
"status": "valid"
}
],
"antibody_test": {
"test_date": "2026-06-10",
"result": "qualified",
"report_image_id": "img_ab_102",
"lab_name": "第三方检测机构",
"valid_until": "2027-06-10"
},
"quarantine_cert": {
"cert_no": "AQ-2026-XXXXXX",
"issued_date": "2026-08-01",
"issuing_authority": "动物卫生监督机构",
"valid_until": "2026-08-31",
"cert_image_id": "img_qc_205",
"verify_status": "manual_verified"
}
}
这份结构有三个设计要点。第一，有效期字段（expire_date/valid_until）必须显式建模，因为品类匹配方案里的规则引擎要求「疫苗失效暂停推荐」，没有有效期就无法自动执行这条规则。第二，status/verify_status 字段区分「已提交」与「已核验」两个状态——用户上传不等于平台采信，平台可以走人工复核或对接宠物医院的接口核验。第三，检疫证明编号（cert_no）保留原始编号而非只存图片，为将来对接官方申报渠道（如品类内可用的「宠运通」类小程序申报通道）预留字段。
三、匹配输入建模：档案字段如何变成特征
档案模块的下游是匹配引擎，数据建模阶段就要想清楚字段如何被算法消费。品类内的四层匹配引擎对档案字段的消费方式各不相同：
- 规则过滤层消费枚举型字段：性别与绝育状态组合出配对合法性规则，疫苗有效性来自健康子域的有效期判断，攻击性等级标签用于互相隔离。这一层要求字段必须是受控枚举，不能是自由文本——规则引擎无法理解「性格挺温顺的」这样的描述。
- 打分层消费数值化特征：品种体型等级、年龄（通常按月数化）、性格标签的向量表示。海外开源项目 Playdate Matcher 的做法有参考价值：行为兼容 40 分、体型匹配 25 分、年龄相似度 20 分、健康状况 15 分，特征向量化后按夹角相似度计算。健康分直接来自健康子域的完备度与有效性。
- 内容理解层消费非结构化数据：NLP 微调模型解析性格描述文本，CV 模型解析图片视频。这一层的输出（性格维度向量、图像特征）回写到档案的衍生字段区，与人工填写的结构化字段并行存在。
数据建模上，建议在档案表之外单独建一张「特征衍生表」，存放算法计算的衍生特征（标签权重、图像特征向量、文本嵌入），与用户填写的原始档案隔离。这样做的理由是：原始档案是事实记录，衍生特征随算法版本迭代而重算，两者混存会导致模型升级时的数据回填灾难。
建表参考
-- 宠物档案主表（身份子域）
CREATE TABLE pet_profile (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
owner_id BIGINT NOT NULL COMMENT '主人用户ID',
breed_code VARCHAR(32) NOT NULL COMMENT '品种编码，受控枚举',
gender TINYINT NOT NULL COMMENT '1公 2母',
birth_date DATE NOT NULL COMMENT '出生日期，运行期折算年龄',
sterilized TINYINT NOT NULL DEFAULT 0 COMMENT '绝育状态',
weight_kg DECIMAL(5,2),
breed_size TINYINT COMMENT '体型等级1-5，由品种码映射',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
KEY idx_owner (owner_id),
KEY idx_breed_size (breed_size, sterilized)
) ENGINE=InnoDB COMMENT='宠物档案-身份子域';
-- 健康子域表：疫苗接种记录
CREATE TABLE pet_health_vaccination (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
pet_id BIGINT NOT NULL,
vaccine_type VARCHAR(16) NOT NULL COMMENT 'rabies/distemper等',
immunization_date DATE NOT NULL,
expire_date DATE NOT NULL COMMENT '失效日期，规则引擎判断依据',
hospital_id BIGINT,
cert_image_id BIGINT,
status VARCHAR(16) NOT NULL DEFAULT 'submitted',
KEY idx_pet_type (pet_id, vaccine_type, expire_date)
) ENGINE=InnoDB COMMENT='宠物档案-健康子域';
-- 特征衍生表：算法输出与原始档案隔离
CREATE TABLE pet_feature_derived (
pet_id BIGINT PRIMARY KEY,
trait_vector JSON COMMENT '性格/行为衍生特征向量',
cv_embedding JSON COMMENT '媒体子域图像特征',
health_score DECIMAL(4,1) COMMENT '健康完备度与有效性得分',
model_version VARCHAR(32) NOT NULL,
computed_at DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB COMMENT='匹配特征衍生表';
三张表对应三个设计原则：身份子域用受控枚举加复合索引支撑规则过滤的高频查询；健康子域的失效日期参与索引，让「疫苗是否有效」成为索引可覆盖的判断而非全表扫描；特征衍生表带 model_version 字段，算法升级时按版本重算，不动原始档案。
四、字段完整率与档案质量运营
档案模块上线后最大的工程挑战不是建表，而是字段完整率的运营。品类公开的用户痛点分析指出，主人普遍关注品种匹配度、线上沟通不畅的根源之一就是档案信息不足导致匹配不可信。技术侧可以做的支撑包括：
- 必填与选填的分级策略：P0 阶段把品种、年龄、性别、性格、绝育状态设为必填（与品类 MVP 功能分析一致），健康子域在借配场景触发时强制补全——按场景渐进收集比一次性表单的完成率高得多。
- 完整度评分展示：按子域加权计算档案完整度分并在前端展示，这是行业通行做法，直接驱动用户补全。
- 证明材料的时效提醒：基于疫苗记录的
expire_date做订阅消息提醒，既提升数据质量，又天然提高用户回访。 - 异常字段治理：自由文本字段（性格描述等）定期跑内容审核与归一化清洗，把高频表述收敛进标签体系，反哺内容理解层的语料质量。
实操要点
技术总结
本篇要点回顾：其一，档案模块按身份、行为、健康、媒体四个子域建模，权限与算法消费各自解耦；其二，疫苗与检疫证明要结构化为带有效期与核验状态的对象，狂犬疫苗、抗体检测报告、动物检疫合格证明三件套缺一不可；其三，匹配输入建模区分规则过滤、打分、内容理解三层消费方式，衍生特征与原始档案隔离并带模型版本；其四，字段完整率是档案模块上线后的核心运营指标，场景触发式补全优于一次性表单。
延伸思考：档案模块的本质是「把真实的宠物翻译成算法可计算的结构」。翻译质量的上限决定了匹配引擎的上限——下一篇匹配算法拆解篇将展示，同样的档案数据在规则打分与协同过滤两套方案下的具体计算差异。
浙公网安备 33010602011771号