交付出件箱

← 返回出件箱

品牌方合作 · 正式方案 v1（Phase 48）

日期：2026-09-15 ｜ 状态：阶段 1 需求稿，待长官确认后进阶段 2（出图）
来源：2026-09-09 思路稿 + 2026-09-11 梳理稿 + 2026-09-15 长官逐条拍板
技术现状均已物理 grep 核实，附 file:line

一、这件事要干什么（一句话）

品牌方出码把家长拉进来 → 家长看见 4L 硬件展示区是灰的 → 想点亮就得问门店 → 倒逼门店买设备、倒逼品牌方接数据。

品牌方生成一个固定二维码，印成卡片塞进镜片盒（不预购名额、不设上限）
   ↓
家长拆盒扫码 → 微信认人 → 免注册直接进家长端（计入该码开通数）
   ↓
到店复查 → 门店扫家长码 / 家长扫门店码 → 档案归到这家店（计入机构自己的开通数，不重复计入品牌码开通数）
   ↓
家长端首页 4 个灰框 → 有设备才点亮 → 家长追问门店 → 门店采购

计费口径（9-15 拍板）：不设名额上限、不做充值，按累计开通人数与机构结算，见规则 20。

4L 指四个防控手段：Laser 弥散红光 / Light 室内补光 / Long 远像屏读写台 / Lens 离焦镜
出处：app/services/prompt_templates.py:39（"回答必须围绕 4L 防控体系展开(Laser 弥散红光 / Light 室内补光 / Long 远像屏读写台 / Lens 离焦镜 DOT)"）
4L 展示区的 4 个框即对应这四项；品牌方通常就是这四类产品的厂家。

二、Phase 编号与拆分

Phase 48 为历史空号（grep -rni "phase.\?48" docs/superpowers/ 返 0，对照组 Phase 47 返 23 行，查法有效）。本次占用，拆三个子 Phase：

长官 9-15 拍板实施顺序：48A + 48C 一起动，48B 紧跟。48C 能与 48A 并行的原因（规则 17 确认后）：4L 展示区依赖的是「家长自己绑定设备」这条新链路，不依赖机构绑定（48B），两条线互不阻塞。

三、已拍板的规则（长官定，不再讨论）

四、技术现状（已物理核实）

4.1 好消息：微信认人这套已经在生产跑了，不是新造

推论（规则 6 能落地的根据）：家长子席位登录本来就强制绑微信，所以老家长身上一定已经存着 unionid。他扫品牌码进来，拿到的 unionid 与 seat_bound_unionid 一比对就认出是同一个人 → 合并天然成立，不需要让家长手工输手机号找回。

4.2 真缺口：家长自己开不了席位

开子席位的端点只有两个，都不在家长侧：

品牌码扫进来的是陌生家长，门店和平台都没人给他开 → 48A 的核心工作量就是加一条「扫码自动开席位」的口子。

4.3 档案归属与可见性现状

patients 表归属字段只有 4 个（app/models/flywheel.py:16-79）：

过滤逻辑集中在 app/services/refractive_record_service.py：
- 门店视角：owner_type IN (NULL,'seat') ∪「被本机构家长席位绑定的档案」子查询（:98-106）
- 通用可见性：Patient.org_id == org_id OR is_sample（:142）
- 家长视角：owner_seat_id == 自己（:143-151、:524-555）

✅ 规则 7（已定案）：org_id（谁带进来的）必须一直保留、门店认领动作不得改写它——否则解绑后就无法把可见性回落给品牌方，规则 7 的兜底会失效。机构认领只写 service_org_id（谁在服务他）。品牌方可见性判据 = service_org_id 为空时可见、有值时不可见，回落兜底由此天然成立，不需要额外逻辑。

4.4 记录来源标记已存在

source 不是数据库列，是运行时按 owner_type / creator_seat_type 算出来的值，两档：personal（家长自传）/ org（机构录入）——
app/api/parent_patients.py:316（档案级）、:603、:771（记录级）。⚠️ 别写成"字段已在用"，避免后续开发以为能直接 SQL 按 source 查询。规则 11 = 维持不动。

4.5 家长 ↔ 机构 互看档案的现状（已 grep 核实）

结论：互扫绑定（48B）本质是把机构手里那个"手动点绑定"换成"扫一下"，不是从零造机制；但品牌码进来的家长，其席位属于品牌方（linked_org_id 指向品牌方），上表第一行的"自动可见"对他们不生效，因此扫码绑定对这类家长是必需的。

五、要新建 / 要改的东西

5.1 数据层

⚠️ 换店只顶替 service_org_id，不动 org_id，所以「换回老店」天然成立（规则 10）。

5.2 可见性规则改写（refractive_record_service.py）

⚠️ 改动范围提示：现有可见性过滤硬编码 Patient.org_id == org_id 的地方至少 6 处（refractive_record_service.py 的 get_org_patient:545、bind_patient_seat:470、unbind_patient_seat:511、_patients_filtered_stmt:142、:370、:599），引入 service_org_id 后这些点全部要改写，原方案低估了改动范围。

✅ 写权限已定案（规则 18）：能看=能改。品牌方（org_id=自己）在孩子尚未被机构绑定期间能看也能改；一旦被某机构绑定，编辑权转移给当前绑定机构（曾经绑过、现在没绑的机构不能看也不能改）；解绑且无人接手时，编辑权随归属回落给品牌方。上表「看得到什么」直接等同「改得了什么」，不再是两套规则。

5.3 前端

五之二、机构品牌码管理页（长官 9-15 提出，9-16 补充开启流程与整页排版）

流程：机构默认不开启品牌码。平台管理员在机构管理列表里点「开启品牌码」，弹二次确认（说明：生成专属码长期有效不换码 / 家长扫码微信授权免注册进家长端并计入该机构开通数 / 按实际开通人数结算不预设上限），确认后生成码并进入该机构的「品牌码与开通」整页。列表可按「品牌码状态：全部/已开启/未开启」筛选。

说明：到期日 = 开通时间 + 365 天。

技术可行性已核实：微信头像昵称能拿到（app/models/user.py:41-42 有 wechat_nickname / wechat_avatar，app/services/wechat_oauth_service.py 走 snsapi_userinfo）。

六、还悬着的

（原「名额到底设不设期限」已由规则 8 拍板为 365 天，本轮从表中移除；原「4L 具体是哪四种」已查明并写入第一节，本轮从表中移除；原「品牌方能不能编辑档案」「写权限」已由规则 18 拍板——能看=能改，本轮从表中移除；原「4L 靠什么点亮」已由规则 17 拍板——家长自己绑定设备，本轮从表中移除；原「48A 和 48C 能否并行」随之解决——4L 展示区依赖"家长绑定设备"这条新链路，不依赖机构绑定，可与 48A 并行开发，本轮从表中移除；原「机构二维码管理页放手机端还是电脑端」已由规则 19 拍板为电脑端，本轮从表中移除）

七、配套（跟着主线做，不单独排期）

• 家长端放一条演示案例，让家长一眼看懂效果；4L 展示区同样配样例
• 品牌方卡片物料：把「扫码进入 + 门店绑定」流程做成卡片，交品牌方打印塞包装箱

最新效果图：brand-partner-mockup-v2-20260915.html（六节：扫码进门 / 4L 三方案 / 互扫绑定 / 条件表 / 一步绑定 / 机构管理列表含未开启态 → 开启确认弹窗 → 品牌码与开通整页·电脑端；原手机端机构码管理页节 9-15 已删除，管理页统一定为电脑端，见规则 19）

本方案为阶段 1 需求稿。长官确认后进阶段 2：出效果图 → 确认 → 阶段 3 技术方案 → 阶段 4 实施计划。