gui-user-review

把 PR 里用户看得见的改动，逐条翻译成"一个不懂技术的人会看到什么、会怎么理解、能做什么"，再判断合不合理。

何时触发

• 用户运行 $gui-user-review，或要求从用户视角评审某个 PR / 分支的界面改动
• 不是代码评审（$review-strict），不是设计体检（$design-audit），不是视觉验收

约束

• 只读。不改代码、不提交；用户明确要求时才按结论改。
• 不启动浏览器、GUI、模拟器或真机。凡是需要看实际排版、动效、对比度、真机交互才能确定的，写进"未验证项"交给用户，不凭文案推断。
• 只评价用户可感知的内容：文案、控件、默认状态、副作用、失败提示、占用的资源。不评价内部实现。
• 主语言用 zh-CN 文案判断，同时检查 en-US 的含义是否一致；其余语言只检查键是否齐全、含义是否偏离。

工作流

1. 定范围

git diff --stat origin/main...HEAD -- apps/gui-go/frontend/src apps/gui-go/*.go

• 取 components/、pages/、i18n/locales/、host 命令返回给界面的字段。生成代码（api/generated/、bindings/）只用来确认字段含义，不评审。
• 没有 GUI 改动：报告"无 GUI 变更"并退出。

2. 提取用户可见变化

对每个改动回答：

• 在哪里看到：哪个页面、哪个分组、什么时候出现。
• 新增、删除还是改变：控件、文案、默认值、条件显示、提示、弹窗。
• 隐藏副作用：用户操作一个开关，是否还触发了别的事（落盘、联网、占用空间、记录隐私相关数据）。界面是否告诉了用户。
• 失败与空状态：加载中、读取失败、未配置、离线、部分成功时用户看到什么。

文案先读 zh-CN，再对 en-US。用 git diff origin/main...HEAD -- apps/gui-go/frontend/src/i18n/locales/zh-CN.json 取新增键，并找到使用它的组件。

3. 用这些镜头判断

1. 用户能据此行动吗：显示的信息是否对应一个用户可做的事。不能行动、也不影响用户决策的信息，归"可删除"。
2. 能用一句话向非技术用户解释吗：不能就是"困惑"。典型信号：库名、协议名、flush、运行 ID、字节计数、内部状态名。
3. 与相邻界面一致吗：同一分组里相似功能的开关、说明、提示语气、单位是否一致。
4. 默认值与副作用说清了吗：默认开启的、占磁盘的、涉及隐私的行为，用户是否能在界面或说明里看到。
5. 失败信息有用吗：说清发生了什么、影响什么、用户该做什么；不要只报内部原因。部分失败不能被说成成功，也不要吓到用户。
6. 信息密度：同一屏的说明行是否过多；能合并或折叠的是否合并。
7. 多语言与无障碍：键是否齐全；占位符和复数形式是否正确；控件是否有可读标签。
8. 与产品原则一致吗：对照 VISION.md 的用户体验与隐私原则，只在确有冲突时引用。

4. 可选的独立复核

改动较大时，派一个只读子代理，只给它 diff、新增文案和相邻界面路径，不给你的结论，让它独立列出"会让用户困惑的点"。你逐条核对后再采纳，只保留能在代码或文案里找到证据的。

5. 出报告

按下面的格式输出，使用简体中文。每条都要有证据（file:line 或文案键加原文）。每个"优化"和"困惑"条目都给出具体改法：改成什么文案、删掉哪一行，或需要产品决定什么。

## 范围
<对比基线、涉及页面、是否有 GUI 变更>

## 合理
- <条目>：<为什么合理>（证据）

## 需要优化
- [高/中/低] <条目>（证据）
  用户看到：<原文>
  问题：<为什么不好>
  建议：<具体改法>

## 会让用户困惑
- <条目>（证据）
  用户看到：<原文>
  可能的误解：<...>
  建议：<...>

## 用户不需要关心，可以删除
- <条目>（证据）：<为什么删除不影响用户>

## 需要产品决定
- <问题>：<可选方案与影响>

## 未验证项
- <需要实际看界面或真机才能确认的点>

完成标准

• 每个条目有证据，没有凭空评价；事实与判断分开写。
• "合理"也要写，不只挑毛病。
• 没有把需要看实际界面才能确定的事写成结论。
• 没有启动 GUI，也没有改动文件。