交付出件箱

两个现有功能能否复用 · 物理 grep 评估

dev2 · 2026-08-21 · 长官指:「平板视力与屈光检查记录」「用户注册」这两个功能已具备,
让我查业务逻辑评估能否在其上二次开发。以下全部是 grep origin/test 的物理结论。

结论先行

能复用,而且比我原方案设想的多得多。 孩子档案 + 检查记录不需要从零建模 ——
Phase 63 已经把整套「儿童档案 + 屈光检查记录」做完了,数据模型比参照品还专业。
一期真正要做的是「归属与鉴权」改造,不是重写业务。

一、平板视力与屈光检查记录(`enable_refractive_record`)

现成的数据模型(4 张表)

表	内容
`patients`	儿童档案:姓名 · 出生日期 · 性别 · 家长手机号 · 近视家族史 · 戴镜史 · 用户类型 · 既往防控手段(多选) · 监护人同意确认时间/版本
`refractive_records`	一次检查:检查时间 · 状态 · 视力记法 · 柱镜记法 · 验光方式 · 是否戴镜 · 版本 · 创建人/完成人 · 备注
`refractive_record_eyes`	分左右眼(OD/OS):裸眼/戴镜/矫正视力(原始+统一小数双存)· 自镜球柱轴 · 眼轴 · 曲率 K1/K2 · 眼压 · 主觉球柱轴 · PD/PH · 眼前节/眼底/OCT 结论+备注
`refractive_record_visual_functions`	视功能选填:Worth 四孔灯 · 立体视 · 眼位等

现成的接口(全在 `/api/h5/refractive-records`)

GET   /patients                  本机构儿童搜索 / 最近儿童
POST  /patients                  建档
PATCH /patients/{id}             改档
GET   /patients/{id}/records     🔴 儿童档案时间线 ← 成长曲线的数据源,现成
POST  /records                   新建检查记录
GET   /records/{id}  PATCH /records/{id}

与参照品(长官给的 7 张图)逐项比

参照品要的	现有系统	结论
姓名/出生年月日/性别	✅ `patients` 有	直接用
家长身份(关系)	❌ 无	加一列
身份证号(选填)	❌ 无	加一列
裸眼视力 / 眼轴 / 曲率K1K2	✅ 全有,且双存原始+统一值	直接用
前房深度 / 晶体厚度	❌ 无	加两列(或本期砍掉)
验光单球柱轴/矫正视力/PD/PH	✅ 全有(主觉+自镜两套)	直接用
验光方式(小瞳/散瞳/散开雾视)	✅ `refraction_method`	直接用
防控措施四组多选(每次记录)	⚠️ 只有档案级`prevention_history`(既往防控手段)	要加记录级字段
眼轴变化曲线	✅ 时间线接口现成	直接用
眼轴预测/百分位	❌ 无	已定二期

反过来,现有系统还多出参照品没有的:眼压、眼前节/眼底/OCT 结论、视功能、
家族史/戴镜史、监护人同意留痕。做减法而不是加法。

🔴 一期真正要改的:归属与鉴权

现状是给门店席位用的,不是给家长用的:

全端点 require_org_seat(席位专属)· 服务层按 seat["org_id"] 圈定
search_patients(db, seat["org_id"], ...)     ← 「本机构儿童搜索」
patients.org_id NOT NULL · patients.doctor_id NOT NULL

⇒ 家长自建的档案若照旧挂 org,同机构任何席位都能搜到 ——
与已定口径「一期门店不可看家长档案」正面冲突(与自检窟窿 1 同源)。

建议改造(一期):
1. patients 加归属标记(如 owner_type = seat/parent + owner_id),
家长建的标 parent;search_patients 加过滤,默认排除家长私域档案
2. 新增家长身份的鉴权依赖(复用子席位登录态),端点走同一套 service,只换 scope
3. 二期若要「合并展示门店档案」,正是把这道过滤按家长授权放开 —— 一期先关着

二、用户注册(`enable_user_registration`)

物理事实

机构级开关,开=H5 首页短信注册拦截生效,关=直通
🔴 与 enable_password_login 二选一,并且签约门店标准套餐里写死:

_STORE_STANDARD_PACKAGE = {
    "enable_password_login": True,        # 按席位售卖 → 固定选密码登录
    "enable_user_registration": False,    # 与 password_login 二选一
    "enable_refractive_record": True,     # 🔴 签约门店默认就开着
    ...
}

对我们的影响(两条好消息)

我们选的路是对的:方案定的「账号密码交付 + 家长自绑手机号微信」走的正是
enable_password_login 这条,与现行签约套餐一致,不需要动这个二选一
不能改用短信注册:若走「家长自助短信注册」,就得开 enable_user_registration,
而它与密码登录互斥 ⇒ 会顶掉门店现有的席位密码登录。
⇒ 反过来印证长官定的「开完给账号密码」是唯一不打架的方案

顺带一个重要事实

enable_refractive_record 在签约门店标准套餐里是 True ——
也就是说现在签约的门店本来就有这套检查记录能力,不是要新买的功能。

三、评估结论:工作量重新分档

模块	原估	查完后
孩子档案 + 检查记录	从零建模+页面	复用 Phase 63 全套,加 3~4 个字段 + 记录级防控措施
成长曲线	新做	时间线接口现成,只做前端图
家长/门店数据隔离	未识别	🔴 新增归属标记 + 搜索过滤(必须做,否则门店能搜到)
登录方式	待定	确认走密码登录,与现行套餐零冲突
秒读配额	以为改字段	仍是新建(与本次无关,结论不变)
子席位开通/对账页	新建	仍是新建

净变化:档案与记录从"新建大模块"降为"改造已有模块",但多出一件必须做的隔离改造。

四、要长官定的两件

前房深度 / 晶体厚度 现有模型没有 —— 加两列,还是本期砍掉?(参照品有,咱现在的纸单口径没有)
记录级防控措施(参照品每次检查都勾四组)—— 现有只有档案级"既往防控手段"。
是加记录级字段,还是沿用档案级(即"这孩子在用哪些手段"而不是"这次检查开了什么")?

云机环境 · 非验收证据。