Files
PolyWeather/docs/ux-research-review.md
2026-05-11 17:56:45 +08:00

190 lines
10 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# PolyWeather UX 研究员审查报告
> 审查日期:2026-06 | 视角:UX 研究员 | 范围:用户理解修正逻辑、第一眼认知、图表误导风险、普通用户语言、天气异常体验
## 一、修正逻辑:用户是否看懂"上修/下修/维持"
### 当前状态
AI 后端提示词明确要求 AI 使用**上修 / 下修 / 维持**三个方向词(`scan_city_ai_prompt.py:47-51`)。但前端 `WeatherDecisionBand` 完全不用这三个词,而是用:
| AI 判断方向 | 前端实际展示 | 中文原文 |
|------------|------------|---------|
| 上修(偏暖) | "Watch hotter range" | "关注偏高温区间" |
| 下修(偏冷) | "Avoid chasing high" | "暂不追高温" |
| 维持(中性) | "Wait for peak-window confirmation" | "等待峰值窗口确认" |
### 问题
| # | 问题 | 严重度 |
|---|------|------|
| 1 | **AI 输出与前端展示词汇不一致** — AI 用"上修/下修/维持",用户看到的是"关注偏高温/暂不追/等待确认"。这是两套完全不同的语言体系,用户读完 AI 解读再看决策条可能对不上号 | 🔴 |
| 2 | **没有"维持/不变"标签** — 中性状态被表述为动作("等待确认"),而不是状态("维持不变")。用户想知道"现在是什么判断"而不是"现在该做什么" | 🟡 |
| 3 | **"偏高温区间" vs "暂不追高温" 不对称** — 上修方向指向一个温度区间,下修方向指向一个行为。一个说 where,一个说 what。逻辑结构不一致 | 🟡 |
| 4 | **颜色语义双重解读** — warm=红色边框=偏暖(上修),cold=绿色边框=偏冷(下修)。天气直觉是"热=红、冷=蓝/绿",但金融直觉是"红=跌、绿=涨"。两类用户可能得出相反的解读 | 🟡 |
### 建议
统一词汇体系,前端和 AI 使用同一套语言:
| 方向 | 建议前端标签 | 建议说明 |
|------|------------|---------|
| 上修 | **"预计最高温上修"** / "Revise upward" | 比 DEB/模型集群基准偏高 |
| 下修 | **"预计最高温下修"** / "Revise downward" | 比 DEB/模型集群基准偏低 |
| 维持 | **"维持模型基准"** / "Stay with model base" | 无需显著上修或下修 |
---
## 二、第一眼理解:用户打开卡片看到什么?
### 视觉层级
```
1. CityCardHeader
├─ Kicker: "城市深度分析" / "Deep analysis"
├─ 城市名(大号标题)
├─ 状态标签(实测突破 / METAR 过旧 / 模型高度一致 等)
├─ 数据新鲜度条(METAR / 模型 / 市场 / AI 各自的新鲜度)
└─ 三指标:当前温度 | 预计最高温 | 峰值时间
2. WeatherDecisionBand(修正条)
├─ Kicker: "天气优先判断 · 市场价格另列"
├─ 主体判断(大号粗体): "关注偏高温区间" / "暂不追高温" / "等待峰值窗口确认"
├─ 原因文字(高亮 pill 内)
└─ 三指标:天气区间 | 路径偏差 | 报价状态
3. 图表 + AI 证据 + 模型证据
```
### 问题
| # | 问题 | 严重度 |
|---|------|------|
| 5 | **Kicker 说了两遍"市场"** — Header 的 kicker 是"城市深度分析"Decision band 的 kicker 是"天气优先判断 · 市场价格另列"。两个 kicker 都提到了市场,但新手不知道"市场"指的是 Polymarket 温度合约。这个词对圈外人完全无意义 | 🟡 |
| 6 | **"预计最高温"没有解释来源** — 用户看到这个数字,不知道它是 AI 独立判断的、还是 DEB 融合的、还是某一个模型给的。只有一个数字,没有可信度标签 | 🟡 |
| 7 | **状态标签过多** — 一个卡片可能同时显示 3-4 个标签:实测突破 + 峰值窗口已过 + METAR 过旧 + 模型高度一致。这些标签颜色不同、含义各异,用户需要逐一解码 | 🟢 |
---
## 三、图表是否误导?
### 日内温度图表(`AiCityTemperatureChart`
三条线:
- 灰色虚线:DEB 原始路径(过去+未来都是虚线)
- 蓝色实线:METAR 修正路径
- 绿色散点:METAR 实测
### 问题
| # | 问题 | 严重度 |
|---|------|------|
| 8 | **DEB 路径永远是虚线** — 即使过去部分(已发生的几小时)也是虚线。虚线在图形语言中普遍表示"不确定/预测",但过去几小时 DEB 已经是根据已知观测计算的,不应该看起来不确定 | 🟡 |
| 9 | **没有"现在"标记** — 图表上没有任何竖线或标记指示当前时间。用户不知道图表上哪里是"现在",哪里是"未来" | 🔴 |
| 10 | **X 轴标签稀疏** — 每 4 个小时才显示一个标签,最多 6 个。用户可能以为数据只在标记的小时上有,实际上每个小时都有数据 | 🟢 |
| 11 | **HistoryChart 缺 °C/°F** — 历史图 tooltip 只显示 `°`,没有 `C``F`。在混合温度单位的环境下可能混淆 | 🟡 |
| 12 | **没有轴标题** — Y 轴只有数字 + °C,没有"温度"标签。对新手来说不够自解释(虽然常见于仪表盘类产品) | 🟢 |
### 建议
| 建议 | 实现 |
|------|------|
| 添加"现在"竖线 | `chart-utils.ts` 中在 `currentIndex` 位置画一条 annotation line |
| 过去 DEB 改为实线 | `segment: { borderDash: past=[], future=[6,4] }` 给过去和未来不同样式 |
| HistoryChart tooltip 补全单位 | 使用 `data.temp_symbol` 替代硬编码 `°` |
---
## 四、普通用户能看懂多少?
### 高频出现的专业术语
| 术语 | 出现次数 | 用户理解难度 | 是否有解释 |
|------|---------|------------|----------|
| **METAR** | ~50+ 处 | 高 — 只有飞行员/气象人员知道 | ❌ 无 |
| **DEB** | ~30+ 处 | 高 — 项目内部术语 | ❌ 无 |
| **TAF** | ~15 处 | 高 — 航空术语 | ❌ 无 |
| **峰值窗口** | ~20 处 | 中 — 可推测含义 | ❌ 无 |
| **模型集群** | ~10 处 | 中 — 可推测含义 | ❌ 无 |
| **边界层** | 3 处 | 极高 — 气象学专业术语 | ❌ 无 |
| **冷平流/暖平流** | 2 处 | 极高 — 气象学专业术语 | ❌ 无 |
| **中枢** | ~8 处 | 中 — 在这个语境下表示中心值 | ❌ 无 |
### 问题
| # | 问题 | 严重度 |
|---|------|------|
| 13 | **所有专业术语都没有 tooltip 或解释** — METAR、DEB、TAF 在全站出现数十次,没有任何地方解释它们是什么。用户的唯一学习途径是 `/docs` 页面,但需要主动离开看板去查阅 | 🔴 |
| 14 | **AI 输出的"最终判断"字段直接暴露给用户** — 如果 AI 提到了"冷平流支撑"、"边界层逆温"等术语,前端不做任何改写或解释,直接原样展示。用户要么读懂,要么跳过 | 🟡 |
| 15 | **"DEB 融合"对普通用户完全无意义** — 这是一个内部算法名称。用户需要的是"综合预报"或"多模型加权平均",而不是一个缩写 | 🟡 |
### 建议
| 建议 | 实现 |
|------|------|
| 核心术语加 tooltip | 首次出现的 METAR/DEB/TAF 加 `title` 属性或悬浮解释 |
| DEB 改用用户语言 | "DEB 融合" → "多模型综合预报" 或保留 DEB 但加括号说明 |
| AI 术语过滤 | 在后端 `scan_city_ai_fallback.py` 或前端展示层过滤掉过于专业的术语 |
---
## 五、天气异常时的体验
### 当前异常信号和用户看到的反馈
| 异常事件 | 前端展示 | 评估 |
|---------|---------|------|
| 实测温度突破模型上沿 | 红色标签"实测突破" + "Observation has broken above the model range" | ✅ 清晰 |
| METAR 数据过旧(超过一天) | 黄色标签"METAR 过旧" + "已过旧,仅作背景参考" + 数据新鲜度条标红 | ✅ 清晰 |
| 峰值窗口已过 | 灰色标签"峰值窗口已过" + 温度图表可能显示下降趋势 | ⚠️ 图表不标注窗口起止 |
| 模型数据不足(<2个模型) | "等待模型补齐" | ⚠️ 没说为什么模型少、什么时候能补上 |
| 市场价格不可用 | "市场价暂不可用" + "天气证据可参考,但暂无可交易价格" | ✅ 清晰 |
| 快速判断与完整解读不一致 | 先显示"快速判断已完成",再异步合并完整 AI 解读 | ⚠️ 两种状态切换可能让用户困惑 |
### 问题
| # | 问题 | 严重度 |
|---|------|------|
| 16 | **异常没有"下一步"指引** — 当实测突破模型上沿时,用户看到"Observation has broken above the model range",但不知道这意味着该做什么。是应该买入?卖出?等待?系统不给建议 | 🔴 |
| 17 | **"快速判断"和"完整解读"的切换可能造成 flicker** — 卡片先显示快速判断文案,然后完整 AI 返回后替换。如果两者结论一致,用户感知不到变化;如果不一致,用户会困惑"刚才不是这么说的" | 🟡 |
| 18 | **极端天气没有特别处理** — 如果城市出现 40°C+ 或 -10°C 以下的极端温度,卡片和普通温度展示方式完全一样,没有视觉强调 | 🟢 |
### 建议
| 建议 | 实现 |
|------|------|
| 异常加行动建议 | 在 `primaryReason` 后追加一句行动建议("建议等待下一报文后再做判断" / "建议关注更高温区间" |
| 极端温度视觉强化 | 温度超过历史极值时加大字号或添加红色脉冲高亮 |
| 快速→完整过渡加标记 | 文案更新时显示 "✓ 已更新" 小标记,避免用户以为信息没变 |
---
## 六、优先级总结
### P0 — 用户理解障碍
| # | 问题 | 建议 |
|---|------|------|
| 1 | AI 用"上修/下修",前端用"偏高温/暂不追" | 统一为"上修/下修/维持"三词 |
| 9 | 图表没有"现在"标记 | 在 currentIndex 位置画竖线 |
| 13 | METAR/DEB/TAF 全站无解释 | 加 title tooltip + 首次出现时加括号说明 |
| 16 | 异常没有行动建议 | 在 primaryReason 后追加引导文字 |
### P1 — 体验提升
| # | 问题 | 建议 |
|---|------|------|
| 3 | 上修/下修文案不对称 | 统一用"方向 + 幅度"格式 |
| 4 | 红/绿颜色双重解读 | 保留但加文字标签确认 |
| 8 | DEB 路径全是虚线 | 过去部分用实线,未来部分用虚线 |
| 15 | "DEB 融合"对普通用户无意义 | 改为"多模型综合预报" |
### P2 — 优化打磨
| # | 问题 | 建议 |
|---|------|------|
| 11 | HistoryChart 缺 °C/°F | 使用 temp_symbol |
| 12 | 图表无轴标题 | 可加可不加(仪表盘惯例) |
| 17 | 快速→完整 flicker | 加过渡标记 |
| 18 | 极端温度无强调 | 加视觉强化 |