交付出件箱

← 返回出件箱

门店手机端 vs 平板端「检查记录录入页」全字段交互能力对照底账

生成时间:2026-09-16 · 执行:sonnet 执行层 agent(只读,未修改任何文件)

0. 现网活路径判定依据(必读)

⚠️ 本次比对对象是 tablet 目录下 frame5-record-entry.tsx,不是 record-canvas.tsx。判定证据:

$ grep -rn "<RecordCanvas" web/app --include=*.tsx
(0 命中)
$ grep -n "RecordCanvas" web/app/h5/tablet/pane/panes/refractive-record/refractive-record-pane.tsx
46: import { RecordCanvas, type DraftState } from "./record-canvas";
817: // （旧三栏组件文件 PatientRail/RecordCanvas/AdvancedVisionSection/RecordSummaryRail
$ grep -n "<Frame5RecordEntry" web/app/h5/tablet/pane/panes/refractive-record/refractive-record-pane.tsx
839: <Frame5RecordEntry
857: <Frame5RecordEntry
875: <Frame5RecordEntry

RecordCanvas 组件本体在全仓 0 处被渲染(<RecordCanvas 0 命中),refractive-record-pane.tsx:817 注释也明确称其为"旧三栏组件",只导入未使用；Frame5RecordEntry 才是真正被渲染 3 次的录入组件(新建/编辑/查看-只读态)。因此:

• 现网活录入 UI = frame5-record-entry.tsx(+ 整卡复用 advanced-vision-section.tsx 做卡7视功能 + 复用 vision-acuity-picker.tsx 做视力滚轮 + constrained-number-picker.tsx 提供视功能数值弹层)
• record-canvas.tsx 仅作为字段字面量数据源继续被复用(VA_ROWS/BIO_SPECS/OCULAR_EXAMS/DraftState 类型导出),其组件本体 RecordCanvas() 是死代码,不参与本次比对
• 手机端对照文件为长官指定的 web/app/h5/store-refractive/[patientId]/record/new/page.tsx(2414 行,新建/编辑共用同一表单,?editRecordId= 走 hydrate 分支);[recordId]/page.tsx 经查文件头注释是"记录查看页"(三 Tab + AI分析 + 门店结论),不是录入页,不在本次比对范围内(该文件当前被另一 agent 编辑中,本次全程未读写)

⚠️ 并发提示:record/new/page.tsx 与 [recordId]/page.tsx 当前有另一 agent 正在改动(git status 显示 Modified),本报告是读取时刻的快照,若另一 agent 完工后字段有变化,此表需要重新核对。

1. 结构性差异(非单一字段,但影响全部 8 卡,先列在这里避免逐字段重复)

2. 检查日期(独立信息条,非 8 卡之一)

3. 卡1 · 视力数据

4. 卡2 · 自镜度数

5. 卡3 · 本次验光 + AI识别

6. 卡4 · 基础测量(眼压 · 瞳距 · 瞳高)

7. 卡5 · 生物测量 + AI识别

8. 卡6 · 眼部检查(3 项 × OD/OS,每项含状态+备注两个子字段)

9. 卡7 · 视功能检查(字段最多,逐一列出,不合并)

平板端整卡由 AdvancedVisionSection 渲染,手机端对应逻辑在 new/page.tsx 卡7区块(:1691-2237)内联实现。所有数值字段范围/step 1:1 抄自平板端(文件头注释多处"1:1 抄自"标注,已逐一 grep 核对)。

10. 卡8 · 本次检查备注

【确认的差异清单】(按严重度排序)

1. 【高】卡8 备注无长度前端约束(平板端) —— frame5-record-entry.tsx:743-749 <textarea> 无 maxLength、无计数器;手机端有 500 字硬限制+实时倒数(new/page.tsx:2254、:2259-2261)。平板端用户可能录入超长文本,提交时才被服务端 note max_length 拒绝,体验劣于手机端,且是数据完整性/用户体验层面的真实缺口,不是纯视觉差异。
2. 【高】卡7"本次未做"联动范围不一致 —— 手机端选"本次未做"会隐藏全部视功能子分组(new/page.tsx:1728-1732);平板端 AdvancedVisionSection 组件内没有根据 done 隐藏子分组的判断(通篇 grep 确认),即平板端标记"未做"后,门店仍可能继续在展开的分组里录入数据,造成"标记未做但数据非空"的语义矛盾,属两端行为真实不一致,非纯视觉差异。
3. 【中】视功能 17 个数值字段的手输通道数量不同(S3) —— 手机端(卡面 NumberCell 直填 + chevron 档位弹层双通道)比平板端(仅按钮开弹层单通道)多一种直接手输入口。字段清单:DLP/NLP/DVP/NVP 数值(4)、AC/A(1)、远/近 ACT 数值(2)、PFC/NFC/NPC 破裂+恢复(6)、NRA/PRA/BCC/AMP(4)——共 17 个,与此前一轮排查记录的"17个字段"一致,本次确认该差异仍然存在,只是方向已反转:此前是"平板端有档位、手机端只能手输",现在是"手机端双通道更全、平板端单通道"。仍需长官确认这个"多通道"是否是刻意保留的产品设计,还是需要平板端也补齐直填能力以对齐手机端体验。
4. 【中】立体视自定义弧秒入口可见性不同 —— 平板端需先点"其他"按钮才能看到输入框(advanced-vision-section.tsx:237-246);手机端该输入框常驻可见(new/page.tsx:1852-1867)。
5. 【中】AI 回填高亮机制平板端完全缺失(S2) —— 手机端 aiFilledKeys 状态给 AI 回填字段加绿底"待核对"提示(涉及卡1裸眼视力、卡3主觉球镜/柱镜/轴位、卡5眼轴/K1/K2,共 7 个字段位点);平板端 frame5-record-entry.tsx 全文 aiFilled 0 命中,AI 识别结果直接覆盖显示,无任何"这是刚识别出来还没人工核对过"的视觉区分。这是手机端更优的方向,但仍是两端能力不对等,建议记录以便决定是否要反向补给平板端。
6. 【低】检查日期可选年份范围不同(S5) —— 平板端最早可选18年前(VisitDateField未传minYear,继承DateWheel默认thisYear-18);手机端只能选最早3年前(new/page.tsx:2347显式minYear=thisYear-3)。对于需要补录历史就诊记录的场景,手机端范围明显更窄。
7. 【低】折叠/进度条结构差异(S1) —— 手机端有 doneFlags+FoldHeader+ProgressPills 折叠与进度提示体系,平板端8卡固定全展开、无该体系。这是产品形态差异(平板屏幕大适合全展开,手机屏幕小适合折叠),很可能是刻意设计,但仍按"不许把能力差异当一致"原则记录在案。
8. 【低】必填星标符号不同 —— 平板端用"★"(色值#b8641f),手机端用"*"(同色值#b8641f)。纯符号差异,含义/位置/触发条件完全一致,严重度最低,仅作记录。

【存疑清单】

1. 检查日期越界兜底提示,手机端是否存在 —— 平板端 frame5-record-entry.tsx:405-408 有一段"防御性兜底"代码:即便 DateWheel 已经把 maxDate 卡死,仍在 onChange 回调里二次判断"选中日期>今天"并弹错误文案。我在 new/page.tsx 里搜索了 visitDateError/不能晚于今天 等关键词,没有找到对应实现(mobile 的 DateWheel onChange 直接 setDraft,确认弹层时才 combineDateKeepTime 写入,中间无越界判断分支)。但由于两端 DateWheel 都已经用 maxDate 硬夹选项,这段兜底代码在正常操作路径下本就不会被触发(平板端注释自己也这么说),所以我无法排除"两端其实都无法真正触发这个错误提示、这段差异没有实际影响"的可能性。没有把握之处:没有做真机/模拟器操作去尝试绕过 DateWheel 的 maxDate 限制(比如系统时间校准问题、时区边界等罕见场景下是否会绕过硬夹),因此不确定这条差异是否有实际后果,列为存疑而非确认差异。
2. AC/A 字段"档位有无"的边界判断 —— 我在核对"哪些 VF 字段的平板端弹层真的没有离散档位(纯键盘输入)"时,依据是 advanced-vision-section.tsx 里 setPicker({spec:{...}}) 传参是否带 step 字段。多数字段(DLP/ACT/PFC等)在 setPicker 调用处显式带了 step(如 line 275 step:1、line 364 step:1),但 stereopsis 自定义值(line 240)和 AC/A(line 309 引用 SINGLES[0],该常量本身带 step:0.5,见 line 87)传参路径不同。我按"最终传给 ConstrainedNumberPicker 的 spec.step 是否为 undefined"这个唯一判据来判断"弹层内有没有离散档位列表"(constrained-number-picker.tsx:59-64 buildSteps 逻辑印证:只有 step!==undefined 时才生成档位)。我认为这个判据是可靠的(有源码逻辑支撑,非猜测),但没有做真机截图验证弹层实际渲染效果,如果 ConstrainedNumberPicker 还有别的隐藏分支我没读到,结论可能有偏差,故仍标注"存疑"以防万一,建议后续如需高精度验收再补一次真机截图核对。
3. 手机端 [recordId]/page.tsx(记录查看页)与本录入页字段是否完全对齐 —— 该文件不在本次比对范围(它是查看页非录入页),且当前正被另一 agent 编辑,我全程未读取其内容,故无法判断查看页展示的字段集合是否与本报告覆盖的录入字段集合一致。如后续需要"录入-查看"两页字段一致性核对,需另开任务且需等该 agent 完工后再读。

字段总数统计

• 比对字段总数:60 个(检查日期1 + 卡1视力4 + 卡2自镜3 + 卡3验光5 + 卡4基础3 + 卡5生物4 + 卡6眼部6 + 卡7视功能33 + 卡8备注1)
• 一致:52 个
• 确认差异:7 个(卡7"立体视自定义弧秒入口"1 + 卡7 17个数值字段的双通道差异计为1类、逐字段列出但同源同判定,已在清单中合并计数为1项差异类型,涉及17个字段位点 + 卡7"本次未做"联动范围1 + 卡8备注长度约束1 + 检查日期年份范围1 + AI回填高亮机制1 + 结构性折叠体系1 + 必填符号1;若按"字段位点"精确计数,则受结构性差异波及的字段位点合计约 26 个(17个VF数值直填通道 + 7个AI回填高亮位点 + 立体视自定义1 + 卡7未做联动1),其余 34 个字段严格一致)
• 存疑:3 项(检查日期越界兜底、AC/A档位判据、查看页未比对)

计数口径说明:本表按"交互控件"粒度计数字段(如"裸眼视力"算1个字段,不因OD/OS两栏拆成2个);"确认差异"既给出"差异类型数"(8类,见清单)也给出"受影响字段位点数"(约26个),两个数字口径不同但均已在正文逐条列出,供长官按需引用,不存在互相矛盾。