交付出件箱

← 返回出件箱

个性化解读报告：档案解读升级接力说明

更新日期：2026-10-07
文档用途：让其他会话了解业务背景、当前实现、升级目标、实施起点和验收范围。
当前进度：已完成方案梳理、现状核查和业务图；本次升级尚未实施。
核心定位：升级现有视光档案的智脑解读，主要供门店老师使用；接入第三方眼底分析，并衔接互联网医院医生审核、处方建议及医生签字。

供本机其他会话读取的固定存放位置：

/home/dev2/reports/personalized-report-upgrade-20261007/个性化解读报告-档案解读升级接力说明-20261007.md

1. 接手后先看这部分

1.1 这次到底要做什么

在现有儿童视光档案中，把现在的“智脑分析”升级为有明确数据依据、可追溯规则和完整业务流程的“个性化解读报告”。

报告需要综合两类能力：

• 单据和档案数据解读：检查单、验光单及本次档案中已采集的相关数据。
• 眼底分析：通过第三方专业服务分析眼底资料，结果回到智脑，进入同一份个性化报告。

门店老师核对后，把报告及相关检查资料提交互联网医院。医生审核，确认处方建议并签字，结果返回门店。

1.2 一句话业务流程

门店准备资料 → 智脑生成个性化报告 → 老师核对并提交互联网医院 → 医生审核、确认处方建议并签字 → 门店查看结果。

1.3 必须理解的三个区别

1. 已有的“报告秒读”和这次升级不是同一件事。它能提供部分可复用能力，但本次主要升级现有档案解读。
2. 已有眼底图片上传，不等于已经接入第三方眼底分析。目前有存档能力，也有旧的通用模型影像分析分支；没有查到本次需要的第三方专用接口已接入。
3. 智脑报告、门店结论、医生签字结果是不同成果。门店确认或推送不能代替医生审核，系统生成的建议也不能冒充医生已签字结果。

2. 用户已经确认的方向

以下来自本次会话的明确要求，接手时应优先于早期方案中的不同表述。

2.1 早期方案需要更新的地方

2026-09-29 的方案仍有价值，但不能原样作为最新定案：

• 早期稿有面向家长的卡片表达；本次主要使用者已明确为门店老师。
• 早期稿未把医院审核作为默认新增流程；本次已经明确需要互联网医院审核和医生签字。
• 早期稿提出引用已有眼底结果；本次进一步明确要接入第三方眼底能力。
• 早期稿建议先用参数条件和文本库打通解读；这个方向可以继续复用，但具体规则、文本和阈值尚需逐项确认。
• 医院流程已经是本次目标范围；具体医院、对接契约、签字形式和交付顺序尚未确定。

3. 当前进度与证据范围

3.1 已完成和未完成

3.2 本次核查基线

核查仓库：/home/dev2/doctor-ai-brain。

2026-10-07 已刷新本机远程跟踪引用，读取的是以下固定提交中的实现：

• codeup/test：205d15512bafd139392067f8bc07143d5e584edc。
• codeup/main：cd087461d7abbdfc52dcb63acf4e8c7bce212533。

本次比较的七个关键后端文件在两个引用间没有差异：档案接口、档案解读服务、共享摘要提示、旧影像编排、家长单据识别、检查图片存档和旧报告接口。

另已只读核对生产机构配置：org_brain_config 中 53 条配置均为 four_l_upload_mode=simple。这说明机构默认配置采用双单据模式；不代表逐一访问过所有页面。前端还存在入口参数覆盖模式的逻辑。

边界：本次不是线上完整功能验收。未验证所有生产实例的实际部署提交，未运行本次升级的服务联调或病例验收。后续实现前应重新核对最新版本，不能把本节作为永久不变的现状。

4. 现有档案解读已经具备什么

4.1 档案和数据基础

现有核心对象包括：

• RefractiveRecord：孩子的一次检查记录、检查时间、录入方式、原图关联、分析状态和门店结论等。
• RefractiveRecordEye：左右眼检查数据，包括视力、验光、眼轴、曲率、眼压等。
• RefractiveRecordVisualFunction：双眼视觉、眼位、集合和调节等视功能结构。

记录中已经存在验光单、眼轴单原图关联，以及 extra_images 中的眼底、OCT 和其他图片分类。眼别表还存在人工填写的眼底/OCT状态和备注。

这些来源要分开理解：

• 人工勾选的眼底状态不是第三方图像分析结果。
• 图片存档不是已完成识别或解读。
• 有字段不等于该字段已经进入当前智脑报告。

4.2 现有页面和操作

门店手机端和平板端已经有相应的档案查看与录入页面，主要内容包括：

• 智脑分析：本次分析、历次对比。
• 门店结论：编辑草稿、保存、推送给家长。
• 检查数据查看与编辑。
• 重新生成分析。

本次升级应从这些页面和服务接续，避免另建一套独立儿童档案。

4.3 当前“本次分析”的生成链路

当前主要链路是：

RefractiveRecord + 左右眼数据
→ _exam_like_from_eyes 适配
→ compute_summary_hint 派生已知事实
→ 检索相关知识内容
→ build_summary_messages(scene="refractive")
→ 模型生成结构化分析
→ 清洗、固定表达覆盖及输出校验
→ 保存到 ai_analysis_text

ai_analysis_text 目前是文本列，保存结构化 JSON 字符串，也兼容部分旧的普通文本记录。现有分析会使用 p1_diag、p2_advice、p3_warning、plan_4l 等内容，并可能附带 ai_comparison 和 kb_trace。

当前分析状态为 pending / done / failed，另有 ai_analysis_missing 返回缺少的最低数据项。

4.4 当前最低分析数据门槛

本次核查到的档案分析最低门槛是：

• 双眼裸眼视力。
• 双眼验光球镜。
• 双眼验光柱镜。
• 双眼眼轴。

缺少任一项时不调用分析模型。手动生成接口会明确返回缺项。

记录保存完成与分析生成是不同动作。当前 complete_record 对部分缺项返回提醒，并不等同于已经生成分析，也不等同于医生审核通过。不要因为新增医院流程，就把现有检查记录状态直接改成医院状态。

4.5 当前哪些数据变化会触发重算

_ANALYSIS_TRIGGER_FIELDS 包含视力、验光、眼轴、角膜曲率、眼压和单眼瞳距等字段。

眼底、OCT、完整视功能等不在这份触发清单内。因此新增眼底结果后，需要同时考虑报告输入和重新生成条件；只增加上传入口或一段提示词不够。

也不能仅凭“列入触发清单”就断言某字段已被最终报告使用。当前实际生成链路的 _exam_like_from_eyes 主要映射眼轴、球镜柱镜、K1/K2和裸眼视力，未把眼底结果、眼压和完整视功能接入共享 SummaryHint；CCT也未提供。辅助函数或历史注释不能代替实际调用链核查。

4.6 历次对比已有基础，不能按旧印象重做

当前档案服务已经具有：

• “上次检查、半年、一年、全部历史”等时间窗的基准选择逻辑。
• 按检查时间限制历史，避免把未来检查放入当前报告。
• 由程序计算差值和相关展示值，再交模型组织语言。
• 无历史或无可比数值时不强行输出对比结论。
• 已存对比结果优先读取，缺少时存在旧逻辑回退。

当前“本次分析”还主动去除历史趋势提示，历史变化由“历次对比”负责。升级时应保留这个分工。早期方案提到的旧摘要趋势缺陷，不能直接套用成当前档案对比完全没有时间窗。

4.7 门店结论和家长展示已有基础

现有门店结论具有草稿与已推送快照，草稿修改不直接覆盖已经推送的内容。

现有家长读取接口对事实数据和门店可见分析有区分。本次主要交付对象是门店老师；是否把新个性化报告或医生签字结果进一步开放给家长，需要单独明确，不应顺手扩大展示范围。

5. 眼底能力现状：准确描述缺口

当前家长单据识别类型只有 refraction 和 axial。不能直接把“已有OCR识别”表述为已经支持眼底专业分析。

还发现旧报告映射和影像结果处理中存在缺省数值或缺省正常状态。例如缺少眼底状态时会回退到正常。新报告不能沿用这种未知值处理方式。本次仅记录问题，没有修改这些实现；升级涉及哪条链路，就需要核查并修正那条链路的缺失语义。

6. 最新业务流程

6.1 给门店老师看的四步

flowchart TB
    A[1 门店上传检查资料] --> B[2 智脑生成个性化报告]
    B -->|老师核对后提交互联网医院| C[3 医生审核并签字]
    C --> D[4 门店查看审核结果]

第三方服务的调用和结果处理放在智脑内部，门店主流程不需要显示接口调用细节。

6.2 实施时需要理解的内部关系

孩子 + 本次检查记录
├─ 检查单 / 验光单 / 已录入检查数值
│  └─ 数据核对 → 已启用规则判断 → 对应解读
└─ 本次眼底资料
   └─ 第三方眼底分析 → 接收并关联眼底结果
          ↓
智脑汇总：单据事实 + 规则解读 + 眼底结果 + 数据限制
          ↓
个性化报告草稿 → 门店老师核对
          ↓
检查资料 + 眼底原图与结果 + 个性化报告 → 互联网医院
          ↓
医生审核 → 要求补资料 / 确认处方建议并签字
          ↓
已签字结果返回 → 门店查看

资料不足、图像不清或分析失败的处理要清楚，但不必把所有分支画进门店主图。

6.3 三份成果不能混淆

医生可以接受、修改或不采纳系统的辅助内容。最终签字应对应医生确认的实际内容。

7. 数据输入与统一口径

以下是实施时要核对的数据清单，不表示全部已经纳入当前分析，也不表示全部都是首版必填。

统一要求：

• 右眼 OD、左眼 OS 保持一致；双眼共同项目不硬拆成两眼。
• 原始录入值与标准化值应可追溯。
• “没做检查、未上传、识别失败、缺失、真实0值”要分开。
• 原始资料、人工核对、第三方结果和医生意见分别保留来源。
• 参数是否进入最终分析，应核对“采集—保存—读取—适配—规则—报告”的完整链路。

8. 个性化解读的规则与文本

8.1 规则设计方向

延续早期方案的核心思路：

本次检查事实
→ 判断已经确认并启用的条件
→ 取对应解读文本并绑定眼别、数值
→ 多条命中合并、去重、排序
→ 生成门店可读的个性化报告

这是一项可复用的方案建议。首批启用哪些规则、具体文本和医学依据，还没有全部确认。

8.2 需要逐项确认的候选参数

这张表是待定需求清单，不是可直接执行的专业规则。不得把早期讨论中的数字直接变成正式阈值，也不能把关注条件替换成现有医学分级。

8.3 一条规则最少要记录什么

建议规则清单至少包含：

运行结果建议区分：命中、未命中、数据不足、不适用、输入冲突。未命中某条规则不等于整项正常。

8.4 程序和模型的分工

• 程序负责数据归属、标准化、计算、条件判断、眼别、排序、版本和缺项。
• 固定文本承载已确认的专业解释。
• 模型可以辅助把已确定事实整理为自然表达，但不能补数字、阈值、诊断或未确认的处方内容。
• 数值与眼别尽量固定绑定；表达失败应有可用回退。
• 现有档案分析已有多项固定表达和输出约束，升级不能直接用早期稿替换这些已存在的业务约束。

是否首版继续使用现有模型、在哪个环节使用及回退策略，应在实施设计中明确。当前尚未定案。

8.5 一个用于验收设计的虚拟例子

假设某条规则已经完成专业确认，条件为“验光柱镜绝对值严格大于阈值T”。这里不指定正式阈值，也不代表这条规则已经启用。

如果本次眼底尚未返回，报告显示眼底状态和缺项；能否继续提交医院按最终确认的业务门槛处理。医生最终审核和签字的内容独立关联，不能由这个条件命中直接得出。

9. 个性化报告建议包含什么

以下为报告内容建议，主要面向门店老师，待形成正式字段与页面设计。

1. 孩子与本次检查：孩子、检查日期、机构、报告版本及资料来源。
2. 本次重点：最需要老师理解和讲解的发现，不强行凑满条数。
3. 左右眼检查事实：数值、单位、眼别及缺项。
4. 规则解读：发现、对应数据、解读、允许表达的下一步、依据。
5. 眼底分析：是否完成、第三方来源、原图入口、返回结果及限制。
6. 历次对比入口：复用现有模块，标明基准和时间范围，与本次分析分开。
7. 待核对或补充资料：缺项、冲突、图像质量问题。
8. 医院处理进度：未提交、处理中、需补资料、已返回等业务状态。
9. 医生审核结果：医生确认的处方建议、签字信息、日期和对应报告版本。

智脑报告与医生审核结果可以在同一业务入口查看，但应清楚标注各自提供方和状态。

10. 第三方眼底能力如何接入

10.1 已明确的业务要求

• 能力属于智脑处理范围，不是门店报告完成后另挂一个无关联入口。
• 结果要关联到正确的孩子和本次检查。
• 结果进入个性化报告，并作为医生审核资料之一。
• 原图和结果来源要能查看。

10.2 对接前必须取得的信息

• 服务商名称、具体产品和正式接口文档。
• 服务接收原始眼底照片、设备输出报告，还是两者都接收。
• 图片格式、分辨率、拍摄视野、眼别、质量要求及支持数量。
• 支持的分析项目；是否支持早期讨论中的豹纹斑相关内容。
• 返回结构化字段、原文报告、可读文件，还是组合形式。
• 同步返回或异步任务；失败、补拍、重试和重复请求如何处理。
• 测试环境、实际结果样本、调用费用和服务时限。
• 资料发送与保存的业务要求。

服务商未确定前，不写死供应商地址、字段、准确率或能力清单。OCT不是本次已确认的第三方接入范围。

10.3 建议保留的结果信息

以下是逻辑清单，不是现有数据库结构或已定接口：

• 孩子与检查记录关联。
• 原图标识、眼别、拍摄/检查时间、资料版本。
• 服务商、请求或任务标识、处理状态、结果返回时间。
• 可追溯的供应商原始返回和本系统使用的标准化结果。
• 图像质量、失败原因及需补充资料的信息。
• 分析报告文件或可读结果。
• 对应智脑报告版本。

人工填写的正常/异常与第三方判断应分别保存；产生冲突时提示核对，不自动覆盖一方。

10.4 异常和迟到结果

建议业务处理：

眼底是否每次必做、未完成时能否生成部分报告或提交医院，仍待确认。不要擅自设成全部阻断或全部放行。

11. 互联网医院审核与医生签字

11.1 提交材料

目标业务包含以下材料，最终以医院接收契约为准：

• 正确关联的孩子与本次检查信息。
• 检查单、验光单及已核对检查数据。
• 眼底原图和第三方分析结果。
• 智脑个性化报告。
• 医院要求的补充材料。

仅上传一段智脑摘要可能不足以支持医生审核，需要先确认医院具体接受什么。

11.2 医生动作

医生应能查看本次提交材料，给出审核意见，必要时要求补资料，确认处方建议并签字。

如果希望系统先生成处方建议草稿，也必须由医生实际确认后形成最终交付。草稿的生成主体、可用内容和医院支持方式尚待确定，不直接让当前档案模型自动出具签字处方建议。

11.3 签字结果至少应能对应什么

建议保留：审核医生、所属医院或平台、审核时间、最终意见/处方建议、签字凭据或已签字文件，以及其对应的材料和报告版本。

具体采用电子签名、平台签章、已签字PDF或其他形式，由医院支持能力决定。当前没有取得医院契约，不能宣称已有签字接口。

11.4 资料变更与签字版本

建议把本次提交给医院的材料固定为一个可追溯快照：

• 智脑报告重新生成，不直接改写已经提交或签字的那一版。
• 老师修改检查数据或补换眼底图片后，标记已有报告与当前资料的关系。
• 新材料如需医生重新审核，应形成新提交和新审核结果关联。
• 已签字结果保留原样，不能只替换内容而沿用旧签字状态。
• 医院重复回传或延迟回传不能造成重复结果、串记录或状态倒退。

这是建议的实施原则，具体数据结构和重提规则待设计。

11.5 尚未确定的医院范围

• 哪家互联网医院、是否已有可复用平台关系。
• 提交接口、查询/回传方式、结果文件获取方式。
• 审核分配、时效、退回、拒绝和补资料规则。
• “处方建议”具体指什么；是否包含正式处方及其另外的业务步骤。
• 医生签字返回形式及可核验的信息。
• 结果是否只供门店查看，是否还需交付给家长。

12. 状态设计：别把不同进度混成一个状态

现有记录和分析状态可以复用，但眼底与医院需要独立表达进度。

重要对应关系：

• 检查记录完成 ≠ 智脑报告完成。
• 智脑报告完成 ≠ 医生审核通过。
• 老师核对 ≠ 医生签字。
• 医院已收件 ≠ 已出具带签字结果。
• 缺少分析结果 ≠ 眼底正常。

门店页面可以把这些状态整理成简单的当前步骤和下一步按钮，不必把全部内部状态都展示出来。

13. 页面升级与复用边界

13.1 优先升级现有门店档案

建议从现有“智脑分析”区域接入新个性化报告，复用孩子选择、本次检查、数据查看与修改等基础。

需要兼顾手机端和平板端。不能只完成一种终端。

13.2 门店新增操作保持少而清楚

建议围绕以下动作组织：

• 准备/补充资料。
• 查看个性化报告及缺项。
• 核对后提交互联网医院。
• 查看医生结果或补资料要求。

第三方服务的请求标识、技术重试细节等不进入门店主流程。老师看到清楚的进度和可执行动作即可。

13.3 不顺手扩大成其他项目

本次目标不要求重建患者系统、训练眼底模型、建立大型规则后台或新建一套综合风险评分。

现有家长结论推送、四L表达、历次对比、特殊屈光路径及其他已存在约束，涉及变更时单独说明，不把它们当作可以随意替换的旧内容。

14. 建议的实施顺序

以下是接续安排建议，不是已完成工作。第三方眼底和医院审核均属于最终目标，不能在阶段结束时遗漏。

阶段一：确认内容和数据通路

• 明确首批规则、对应文本、依据、适用范围与边界。
• 明确本版必须使用哪些检查数据，解决已采集但未传入的问题。
• 确定第三方眼底服务商并取得文档和真实样例。
• 确定医院及审核、处方建议、签字的交付契约。
• 确认眼底缺项、失败和迟到时的业务处理。

产出：规则清单、输入/输出清单、对接契约、待定项确认记录。

阶段二：完成档案个性化报告

• 在现有档案链路上生成有依据的个性化报告。
• 处理多条规则命中、缺项、冲突、排序与去重。
• 接入门店手机端和平板端。
• 核对重新生成、旧记录读取、既有对比和结论推送的兼容行为。

产出：真实检查记录可生成并查看个性化报告，能追溯数据和规则。

阶段三：接通第三方眼底能力

• 完成资料发送、结果接收和正确归档。
• 眼底结果进入个性化报告。
• 处理质量不合格、失败、重试、重复回传及旧资料结果。
• 明确未完成眼底时的报告行为。

产出：第三方真实返回结果能进入正确孩子的正确本次报告。

阶段四：接通医院审核和签字

• 门店核对后提交整套材料。
• 展示提交、审核、补资料和结果返回进度。
• 接收医生确认的处方建议及签字结果。
• 关联材料版本，处理修改后的重新提交。

产出：医生完成真实审核和签字，门店能查看对应结果。

阶段五：端到端业务验收

覆盖完整主流程和异常场景，核对报告事实、资料归属、医生结果和版本关系。部分阶段可并行准备，但最终完成声明必须覆盖实际交付范围。

15. 验收清单

下面是后续验收要求清单，本次没有执行或勾选为通过。

15.1 数据和规则

• [ ] 同一孩子、同一本次检查、正确眼别与单位。
• [ ] 已确认规则在边界下方、等于、上方行为正确。
• [ ] 缺值不补0，未命中不等同正常，未做检查不等同漏填。
• [ ] 多条命中可以合并，冲突可提示，重要提醒不被摘要截断。
• [ ] 候选未确认规则不被默认启用。
• [ ] 现有已采集数据按本版范围进入实际报告，不只存在于表单或提示中。
• [ ] 本次分析和历次对比各自使用正确数据范围；首次检查不输出虚假趋势。
• [ ] 模型不能改数值、眼别、已确定条件或增加无依据的内容；回退可用。

15.2 眼底

• [ ] 真实第三方服务返回结果进入正确记录和正确报告。
• [ ] 原图、服务来源、结果时间及相关版本可以追溯。
• [ ] 缺少照片、照片不清、部分眼别、服务超时和失败有明确状态。
• [ ] 重复请求或回传不造成重复资料或错误状态。
• [ ] 换图后旧结果不会被当作新图结果。
• [ ] 人工记录与第三方结果冲突能看见，不静默覆盖。

15.3 医院与签字

• [ ] 老师能核对并提交规定资料；医院实际收到可用材料。
• [ ] 提交失败可以明确处理，不误显示为待审核成功。
• [ ] 医生要求补资料后，老师能补齐并重新提交。
• [ ] 医生实际审核并确认处方建议。
• [ ] 门店能查看真实带签字结果及其对应版本。
• [ ] 修改新资料不会篡改旧签字成果。
• [ ] 迟到或重复返回不会串孩子、串检查或覆盖新版本。

15.4 页面与兼容

• [ ] 门店老师能说清自己下一步要做什么。
• [ ] 手机、平板及相邻尺寸可读可操作。
• [ ] 旧记录和旧分析内容仍可读取。
• [ ] 既有历次对比、门店结论草稿与推送快照没有被意外改变。
• [ ] 家长展示范围与本次明确范围一致。
• [ ] 完成真实数据存储、服务请求、浏览器主流程和供应商/医院联调验收。

规则计算测试可以证明程序行为，不能单独证明专业规则正确。正式启用还需要相应内容确认与真实业务验收。

16. 仍待确认的问题

接手者应优先整理这些问题，并在依赖它们的实施前取得明确答案；不需要因这些问题暂停独立的数据核查与方案细化。

17. 实现定位索引

以下文件均在本次固定的 codeup/test 中核对存在。路径以仓库根目录为基准。行号会随版本变化，优先按符号定位。

17.1 档案核心

现有档案路由前缀为 /api/h5/refractive-records。相关现有路径包括：

• POST /records/{record_id}/analysis：手动生成分析。
• GET /records/{record_id}/comparison：读取历次对比。
• PATCH /records/{record_id}/conclusion：保存门店结论草稿。
• POST /records/{record_id}/conclusion/push：推送门店结论快照。
• POST /records/{record_id}/complete：完成检查记录。
• POST /ai-recognize：单据识别回填。

这些是已有入口；本文件没有定义新的医院或第三方正式接口路径。

17.2 门店页面

17.3 原图、眼底和旧报告参考

17.4 可参考的现有测试

这些测试文件已核对存在，本次文档任务没有执行它们，不能标记为通过：

• tests/unit/test_refractive_analysis_correctness_fix.py
• tests/unit/test_refractive_prompt_batch_9_06.py
• tests/unit/test_phase81_refractive_4l_grounding.py
• tests/integration/test_refractive_rule10_history_and_dup_leak.py
• tests/integration/test_refractive_visibility_service_org.py
• tests/e2e/test_golden_paths_refractive_record.py
• tests/e2e/test_phase81_refractive_4l_real27b.py
• web/__tests__/mobile-refractive-record-view.test.tsx
• web/__tests__/tablet-refractive-view-first-and-ai-entry.test.tsx
• web/__tests__/tablet-refractive-frame4-conclusion.test.tsx

现有文档参考：

• docs/plans/2026-07-23-refractive-record-design.md
• docs/superpowers/plans/specs/phase63-tablet-refractive-record-spec-v0.1.md
• docs/superpowers/specs/phase81-refractive-4l-kb-grounding-spec-v0.1.md
• docs/superpowers/plans/tech/phase81-refractive-4l-kb-grounding-tech-v0.1.md

这些材料用于理解历史实现；最新业务要求以本文已确认事项及用户后续指令为准。

18. 设计材料与业务图

18.1 早期材料

原始材料目录：/srv/vouchers-inbox/个性化报告原型/。

本次工作目录已保存副本：

• /home/codex-one/Documents/Codex/2026-10-06-new-chat/个性化报告-产品与出报告流程方案-v01-20260929.md
• /home/codex-one/Documents/Codex/2026-10-06-new-chat/个性化报告-交互原型-v01-20260929.html

原型是设计材料，不是已实现功能；阅读时结合第2节的最新调整。

18.2 当前优先使用的简明业务图

• 查看门店简明业务图
• 下载门店简明业务图 PDF
• 查看简明业务说明页

这些链接在本次整理时已重新检查，可访问且与本地交付内容一致。门店沟通优先使用简明图。

更详细的流程与现状说明作为补充：

• 完整业务流程与说明

本文已写出完整文字关系，即使无法访问图片，也不影响接手理解。

18.3 本文阅读和交接

• 在线阅读完整接力文档
• Markdown 文件保存在文首的固定路径，可直接交给本机其他会话读取。

19. 接手会话的第一轮工作建议

1. 阅读本文件和目标仓库 AGENTS.md，核对当前版本与本次基线的差异。
2. 从现有档案页面和 generate_record_analysis 追踪数据流，确认本次升级的最小改动范围。
3. 整理第16节待确认事项，优先确认规则、第三方眼底、医院和签字契约。
4. 形成字段与报告结构设计，明确现有内容复用、数据补齐、结果版本和页面操作。
5. 根据用户接续任务推进实施；在项目要求的独立工作区完成相关验证。
6. 验收时分别记录档案报告、第三方眼底、医院审核签字三段实际完成情况，再核对完整主流程。

接手时不要再次把问题定位成“找一份具体检查报告”，也不要重新停留在“项目已有报告秒读”。本次业务范围已明确，主要未定的是规则细节与两个外部服务契约。

20. 可直接交给下一会话的接续说明

请读取《个性化解读报告：档案解读升级接力说明》。我们要升级现有视光档案中的智脑解读，主要给门店老师使用。不是新建患者系统，也不是只修改已有报告秒读。

新报告要汇总检查单、验光单和第三方眼底分析结果。第三方眼底能力属于智脑处理环节。老师核对后，将报告和检查材料提交互联网医院；由医生审核、确认处方建议并签字，结果返回门店。

目前已完成设计梳理和业务图，本次升级尚未实施。现有档案已具备本次分析、历次对比、门店结论及推送基础，但眼底专用第三方结果还没有进入综合解读。

请先核对最新实现，区分已确认需求、建议方案和待确认事项。重点接续规则与文本确认、实际数据通路补齐、第三方眼底对接、医院审核签字和对应版本关联。业务页面保持简单，让老师看清自己下一步要做什么。不要把未完成或建议内容写成已经上线。

本次交付的是升级接力文档和既有业务图索引。没有实施应用功能，没有新增数据库结构，也没有执行应用发布；文中测试和业务验收清单均为后续工作。