原诊断抓到了两个最严重问题：
但原诊断仍有四个明显不足：
应采用的总策略是：
先保障可用，再降低理解成本，再优化高频操作，最后处理低频复杂功能。
优先级不是单纯按页面数量，而应按：
业务阻断程度 × 使用频率 × 误操作损失 × 目标人群理解难度
原诊断测了页面文本、尺寸和输入复杂度，但没有回答以下问题：
因此，原诊断更接近“界面静态体检”，还不是完整的可用性评审。
依据：材料只描述了 DOM 抓取和尺寸统计，没有真实用户任务测试、误操作测试、网络异常测试或完成率数据。
应至少测试以下任务流：
| 任务 | 应观察的问题 |
|---|---|
| 办理入住 | 是否理解排房、入住人、收款、确认顺序 |
| 办理退房 | 是否知道应收、已收、余额的差异 |
| 订单接单 | 是否能区分确认接单和拒单 |
| 修改房态 | 是否知道改的是房量、房价还是开关房 |
| 餐饮接单 | 是否知道待处理、制作中、已完成的状态 |
| 扫码/输码核销 | 无法扫码、码错误、重复核销时怎么办 |
| 夜审 | 是否知道为什么要执行、执行后会发生什么 |
依据：这些任务直接对应材料中的高频入口和高风险动作，但原诊断没有提供任务完成率、耗时、错误率等数据。
西藏阿里地区的网络和设备条件不能假设与城市商户相同。需要验证：
材料没有提供真实网络和设备分布，因此不能直接断言具体性能瓶颈，但弱网和低端机必须纳入验收范围。
“中文白话化”不等于“藏语用户可用”。
至少需要验证：
材料没有说明藏语版本、翻译资源或语音能力是否存在，因此不能直接要求全量藏语化；但应先对高频、高风险任务做小范围语言验证。
原建议把“核销”改成“扫码验票”，这个判断过于武断。
问题在于：
更稳妥的命名是：
建议：不要为了白话化牺牲业务准确性。
ADR、RevPAR 对老板或酒店经营者可能有价值，直接删除会损失经营能力。
更合理的方案：
依据：材料只证明用户难以理解术语，没有证明这些指标没有业务价值。
原诊断将“有 4 笔预订”和“入住 0 次”直接判定为数据没串起来，这需要谨慎。
可能存在多种定义：
因此应先核对数据定义和订单状态，不能直接把它归为前端问题。
整改上应改为：
订单页中“确认接单 92×36、拒单 62×36 并排”，问题不只在尺寸，还包括：
建议：
图标可以降低阅读压力，但不能独立承担业务含义。
正确方式：
例如：
| 不建议 | 建议 |
|---|---|
| 单独使用房子图标 | 房间 |
| 单独使用钱袋图标 | 收款 |
| 单独使用勾图标 | 确认接单 |
| 单独使用扫码图标 | 扫码/输码 |
依据：低识字用户不一定能识别抽象图标，图标本身也存在地域和文化差异。
对低中文读写能力用户，数字、状态和动作通常比长句更容易识别。
建议：
但数字不能脱离单位，例如“3”必须显示为“3 间”“3 单”“¥580”。
可使用：
但不能只依赖颜色，因为：
应同时显示：
例如“红色格子”应改为“关闭房源”“不可售”，而不是只显示红色。
可分为三层：
例如：
适合：
对夜审、房态调整等低频任务，提供“边做边说”的步骤引导。
但需注意：
默认只展示完成任务所需的信息，复杂字段放到“更多信息”。
例如订单卡默认展示：
订单号、渠道订单号、原始备注放入展开区。
低文化水平用户容易出现“点错但不知道错在哪里”，因此应：
错误提示不要写“参数校验失败”，应写：
“网络不好，没有保存成功。请检查网络后再试。”
建议增加：
但不要把所有功能都做成长教程，否则会增加复杂度。只引导高频、高风险、低频复杂任务。
以下按“改动成本 × 目标收益”排序。工作量为相对估计，需结合现有代码和接口确认。
| 优先级 | 改动项 | 量级 | 主要收益 |
|---|---|---|---|
| P0 | 修复餐饮页面白屏、增加异常兜底 | S/M | 恢复核心业务可用 |
| P0 | 建立接口数据结构校验和统一适配层 | M | 防止同类白屏反复出现 |
| P0 | 防重复提交、网络异常、保存结果反馈 | S/M | 降低重复订单和误操作 |
| P1 | 房态日历改为分层操作模式 | M/L | 解决最高频操作痛点 |
| P1 | 接单、拒单、下架等危险操作重构 | S/M | 降低不可逆误操作 |
| P1 | 高频术语白话化和任务化命名 | S/M | 降低理解成本 |
| P1 | 首页按待办任务改造 | M | 让用户知道“现在该做什么” |
| P1 | 订单卡简化和信息分层 | S/M | 提高扫描效率 |
| P2 | 报表专业指标分层展示 | M | 保留经营能力，降低理解门槛 |
| P2 | 夜审自动化、引导化 | M/L | 降低低频任务使用难度 |
| P2 | 藏语/语音试点 | M/L | 覆盖中文读写能力有限用户 |
| P3 | 全面可用性测试和埋点体系 | M | 形成持续优化依据 |
量级：S/M
不要只做一次性 unwrap 修改，应同时做三层防护：
data: []data: { items: [] }量级：S/M
所有涉及订单、收款、入住、核销的按钮：
低端设备和弱网环境下，用户可能连续点击多次。对于入住、收款、核销而言，重复提交的损失高于一般视觉问题。
依据：材料已有核销、入住、订单等交易性动作，但没有异常提交设计信息。
量级：M/L
原建议“把格子加大”不够。42 个日期格子同时保留在手机屏幕上，本身就与最小触控尺寸冲突。
采用业内常见的多层信息结构，而不是强行把桌面日历缩小到手机上：
点击一个房态格子后，不直接在小格子内完成复杂修改，而是打开底部抽屉或全屏编辑页：
显示：
操作控件使用大按钮：
允许选择：
再执行：
批量操作必须展示影响范围，例如：
“将修改 7 月 1 日至 7 月 7 日，共 7 天，房型：标准间。”
美团、携程商家端、Agoda YCS 等商家系统通常采用的成熟方向不是“在手机上完整复制桌面房态表”，而是：
具体产品当前版本的实际交互，材料未提供，不能据此断言其每个细节完全一致；但上述模式符合移动端高密度管理界面的通用解法。
量级：S/M
保留为主按钮：
确认接单
点击后显示订单摘要：
确认后完成接单。
将“拒单”从并排主操作移到：
更多操作 → 拒绝订单
然后要求：
把“下架”改为：
暂停售卖
更符合低文化水平用户理解。确认弹窗说明：
“暂停后，客人将不能继续预订这个房型。已有订单是否继续保留？”
材料未说明下架对已有订单的具体业务影响，因此这部分需要产品和业务确认，不能直接确定文案。
量级：S/M
建议替换如下：
| 当前术语 | 建议主文案 | 备注 |
|---|---|---|
| 排房 | 分配房间 | 可保留“排房”作为帮助说明 |
| 未排房 | 还没分配房间 | 更直接 |
| 应收 | 应收金额 | |
| 已收 | 已收金额 | |
| 余额 | 还需收取 | |
| 本班次收款 | 这段时间收款 | |
| 房态 | 房间状态 | |
| 房态日历 | 房间安排 | |
| 执行夜审 | 处理逾期订单/完成当日结算 | 需根据真实业务确认 |
| 核销 | 扫码/输码完成验证 | 避免误改成验票 |
| ADR | 平均房价 | |
| RevPAR | 每间可售房收入 |
对于专业词，不建议完全消灭，应采用：
白话主标题 + 专业词帮助说明
例如：
平均房价
酒店行业叫 ADR
量级：M
现有“今日概览 + 大按钮 + 宫格”方向是对的，但还应加入待办排序。
首页优先展示：
每项显示：
例如：
待接单 2 个
[去处理]
不要让用户先理解全部模块，再自行寻找任务。
量级：S/M
默认卡片建议只保留：
订单号 B8001DEMO2 这类信息默认折叠，保留在“订单详情”中，以便客服或后台追踪。
但不能完全删除订单号，因为它可能用于售后、对账和渠道核对。
量级：M
默认视图：
日期筛选默认只提供：
“起止日期”放到“自定义时间”中。
专业指标采用：
平均房价（ADR）
每间可售房收入（RevPAR）
不要在默认页面同时展示“今日、近 7 天、近 30 天、自定义日期、多个专业指标”，否则低识字用户容易失去重点。
材料中“执行夜审”被描述为“处理逾期未到店”，但夜审具体是否还包含结算、账务、房态更新等内容，材料未涉及。
因此第一步应先确认：
不能只根据按钮名称设计。
页面不要要求用户理解“夜审”概念，而是直接展示：
今日有 2 个订单超过入住时间，还没有入住
[查看并处理]
每条显示：
例如：
具体动作取决于业务规则，材料未涉及，不能直接指定默认结果。
例如：
将处理 2 个逾期未入住订单。
处理后，订单状态和房间安排可能发生变化。
[返回检查] [确认处理]
建议分三档：
例如：
例如：
例如：
进入夜审页面时，直接显示三步：
每一步只展示当前需要做的事情，不要一次展示全部规则。
可提供：
不建议默认自动取消订单或自动释放房间，因为这可能造成客诉、退款和房态错误。
如果商户确实不适合操作夜审，可提供授权代运营，但要具备：
“代运营”可以降低学习成本，但不是替代产品设计的理由。
至少招募三类用户：
每类用户测试同一批任务，记录：
材料没有现成用户测试结果，因此目前不能判断具体问题发生比例。
可设置内部验收目标：
具体数值目标需根据现有基线确定，材料未提供当前基线，不能直接编造提升百分比。
建议记录：
这样才能判断是“用户不会用”，还是“系统本身不稳定”。
核心判断是：原诊断的方向基本正确，但不能把低文化水平问题简化为“换几个词”和“放大按钮”。真正有效的方案必须同时覆盖语言、任务结构、视觉编码、防错、语音、弱网和业务结果反馈。