Goal

站在 UI 人机交互角度, 深度分析 ~/opencode-blog-showcase/blog-app/ 的 /watchdog 页面 (templates/watchdog.html) 怎么改最合适.

背景

今天 omo 派 build agent 实现了 watchdog 功能, omo 已经分析出 6 个 UX 问题 (在 /home/yi/.omo/analyze-watchdog-ui-v4-2026-08-16.md). 现在让你从 UI 人机交互角度再深挖一层, 看看前端要怎么改合适.

你 (omo Sisyphus) 的工作

你是 UI/UX 设计师, 实际去看 watchdog 页面 + 报告内容 + 现有 blog-app 的 UI 风格 (templates/base.html + templates/index.html + templates/project_detail.html + templates/analyze.html + templates/watchdog.html + static/css/style.css), 站在用户视角想:

评估维度 (你自主决定, 我不预设)

认知负荷 — 用户进 /watchdog 第一眼看到啥? 要点几次才能找到关心的信息? 信息密度是不是太高/太低?
交互完整性 — 按钮 / 表单 / 链接是不是真能用? 有没有死按钮 / 不可点的链接 / 误导用户的 UI 元素?
视觉层级 — 标题 / 重要信息 / 次要信息的视觉权重是不是合理? ★ 项目 vs 普通项目怎么区分? breaking change vs 普通更新怎么区分?
一致性 — watchdog 页面跟 blog-app 其他页面 (首页 / 项目详情 / 分析页) 的 UI 风格是否一致? 颜色 / 字体 / 卡片 / badge 等?
反馈与可恢复性 — 用户的每个操作有没有反馈 (loading / success / error)? 出错了能不能重试? 数据有没有备份?
可达性 (a11y) — 鼠标 / 键盘 / 屏幕阅读器都能用吗? aria-label, focus, contrast 都行吗?
响应式 — 移动端 / 平板 / 大屏都能正常显示吗? 表格 / 长内容在窄屏怎么处理?
状态表达 — 数据空 / 加载中 / 错误 / 成功这 4 种状态分别在 UI 上怎么表达?
可发现性 — 用户怎么知道 watchdog 存在? 怎么知道数据更新? 怎么知道能看历史?
信任与透明度 — 数据从哪来? 抓取时间? 失败原因? 用户能不能信这报告?

输入文件 (你必读, 用 Read 工具)

/home/yi/opencode-blog-showcase/blog-app/templates/watchdog.html (主要改这个)
/home/yi/opencode-blog-showcase/blog-app/templates/base.html (布局 + 导航)
/home/yi/opencode-blog-showcase/blog-app/templates/index.html (首页风格)
/home/yi/opencode-blog-showcase/blog-app/templates/project_detail.html (项目详情 — 看 markdown 渲染方式)
/home/yi/opencode-blog-showcase/blog-app/templates/analyze.html (分析页 — 看 SSE 流式 UI)
/home/yi/opencode-blog-showcase/blog-app/static/css/style.css (全局样式)
/home/yi/opencode-blog-showcase/blog-app/app.py (看 /watchdog + /watchdog/run 路由逻辑)
/home/yi/opencode-blog-showcase/logs/daily-agent-watchdog-2026-08-16.md (实际报告长啥样)
/home/yi/.omo/analyze-watchdog-ui-v4-2026-08-16.md (你自己之前的报告, 看怎么深化)
/home/yi/opencode-blog-showcase/data/watchdog.db (db schema, 用 sqlite3 只读查)

输出 (你必须给)

报告路径: /home/yi/.omo/ui-hci-analysis-watchdog-V1-2026-08-16.md (新文件, 别覆盖 V4)
报告内容:
- "整体评价" 段: watchdog 前端在 UI/HCI 维度的整体判断 (1-2 段, 真判断)
- "维度评估" 段: 上面 10 个维度每个的评估 (每个维度说现状 + 问题 + 建议)
- "重构方案" 段: 给出完整的前端重构方案 (不是分散 6 个修, 是整体改 UI 的蓝图)
  - 整体视觉层级 (卡片 / 列表 / 折叠 / tab 怎么组合)
  - 颜色 / 字体 / 间距系统 (用现有 CSS 变量, 不要新引)
  - 关键交互细节 (按钮 / 加载状态 / 错误处理 / 反馈消息)
  - mockup / ASCII art (描述每个核心视图长啥样)
  - 涉及文件 + 改法 + 行号 + 改前后代码
- "实施顺序" 段: 这次重构分几个 PR / 几个 task, 顺序怎样
- "跟 V4 报告的关系" 段: V4 报告 6 个问题在这次重构里怎么解决 (避免重复, 整合到新方案)

Process (硬约束, 跟 SKILL.md §3 一致)

你 (omo Sisyphus) 内部用 Atlas Kimi K2.6 calibration 工作流:
- plan (1 read + 1 dep map)
- 派 sub-agent (Oracle 看代码, Librarian 查 UI 设计模式, Explore 找现有 CSS 类, Multimodal Looker 看截图)
- 自己写报告 (Sisyphus 写)
不动代码 (这次是 analysis 任务, 跟 V4 一样)
max-runtime 15 分钟

拍权前置边界 (跟 V4 一致)

禁改 litellm / restart litellm-proxy / llama-server / K3s / opencode serve
禁改 projects.db schema / fetch_data.py / 已有 watchdog.db 数据
禁改 ~/.omo/omo.jsonc / ~/.local/lib/node_modules/oh-my-openagent/
不动任何代码 (这次纯分析)

False completion guards

❌ 不要写代码 (patch / edit / write 工具不该用, 只用 read / grep / search; 唯一例外是写分析报告文件本身)
❌ 不要按 brief 里"维度评估"的顺序抄 — 你自己判断哪些维度最重要
❌ 不要只复制 V4 报告 — 这是新角度 (UI/HCI), 要深化
❌ 不要 deploy.sh 重启 blog-app
❌ 不要创建新文件 (除了分析报告)

Acceptance (worker 会逐条自验, 5 项)

报告存在: /home/yi/.omo/ui-hci-analysis-watchdog-V1-2026-08-16.md
不动代码真凭据: 5 个交付物 (daily_watchdog.py / install_watchdog_cron.sh / app.py / watchdog.html / base.html) 改动时间没变
10 个维度全覆盖: 不是只挑 2-3 个, 是全评估 (即使某维度"没问题"也要写一句"评估过, 没问题")
重构方案完整: 给出整体蓝图 (不是分散 6 修, 是整体改 UI 的方案), 含 mockup / 改法 / 行号
跟 V4 报告整合: 说明 V4 6 问题在这次重构里怎么解决, 不重复劳动

临时文件如需落盘, 放 workspace 内 ./.analysis-tmp/ (不要写 /tmp).

5.7 KiB Raw Permalink Blame History