反馈 — 界面 2 项小问题¶
原文 / 原始内容¶
解决界面问题
截图 v0.10.33 主面板： 1. KPI 第 5 卡 "1/1 任务进行中/..." 后面 "..." 是 ellipsis 截断 2. 任务卡 "耗时 3时04分54秒 · 剩余 495时18分10秒" — 剩余 20 天 17 时但要心算
用户选择修：③ KPI 文字截断 + ④ 剩余时间人性化 （① 顶部"由于谷"截断 = 设计为两列 label/value，跳过；② 底部"创建任务"冗余按钮 = 跳过）
上下文¶
- 版本：v0.10.33
- 在 v0.10.35 处理
事后澄清（2026-05-26）¶
用户："①和② 不是问题"
我把 ① 顶部"由于谷"截断、② 底部"创建任务"按钮重复，都当成了 bug 在清单里列出。 实际上两个都是设计：
| # | 我的误判 | 真实情况 |
|---|---|---|
| ① "由于谷"截断 | "文字溢出 bug" | label/value 两列布局，"由于谷x" 是 label 字头，后面 VIP+到期日是 value，本就分两列 |
| ② 底部"创建任务"按钮重复 | "冗余" | 任务列表长时滚动到底部仍能快速创建（顶部按钮已滚出视口），是刻意的双入口 |
教训（写给未来的 AI 和我自己）¶
做 UI 诊断时，不要把"看起来奇怪"等同于"是 bug"：
- 截断/溢出：可能是设计成 label/value 两列、可能是数据值本身就长（长 URL / 长邮箱），不一定是 CSS bug
- 重复按钮：可能是同一动作放在不同视口位置方便用户够到（顶部 + 底部双 CTA 是经典模式）
- 拥挤布局：可能是用户主动选了高密度（compact 模式）
- 看似无意义的元素：可能服务于特殊场景（如错误兜底、空状态引导）
正确流程：
- 列出所有"觉得有问题"的点 ← 我做对了
- 明确标注哪些是"我的判断"vs"用户已确认" ← 我没做
- 让用户挑要修的（避免按我的清单逐个修）← 我做了
- 修完后再问一次"剩下的真的不修吗" ← 我可以再确认一遍
下次：在列问题清单时，每条前面加（怀疑 / 可能是设计）标记，避免用户被我的"高严重度"框架推着走。