严格审视 HarmonyOS 设计

本 Skill 只做审视，不从零设计，不批量改代码，也不审查与界面设计无关的工程问题。

默认立场：通过需要证据，问题也需要证据。

1. 审视范围

• 用户任务和导航；
• 手机、平板、折叠屏、PC、穿戴、智慧屏、车机适配；
• 触摸、鼠标、键盘、遥控器等输入；
• 控件正常、禁用、按下、焦点、激活、悬停状态；
• 视觉 Token、vp/fp、大字体；
• 动效目的、曲线、时长、跟手、速度和可打断；
• 异步状态真实性；
• 无障碍；
• 动画性能；
• 稳定原则与版本化平台层；
• 可交互原型与真实实现证据。

2. 不在范围内

遇到以下请求，说明不适用并指向通用工程审查：

• HAP/APP 签名；
• 编译器错误；
• 网络、权限、数据库；
• 非 UI 业务逻辑；
• 其他移动平台的设计规范；
• 直接实现新功能。

3. 先建立上下文

复用用户已提供的信息：

目标设备:
窗口形态:
主要输入:
API_Level:
主题与字号:
任务路径:
证据:
假设:

缺失信息不会影响当前发现时，不重复提问。证据不足的结论标低置信度。

4. 十三项不可妥协标准

1. 导航清晰。 用户知道位置、去向、返回和退出。
2. 跨设备不是等比缩放。 必须有具体适配策略。
3. 系统优先。 自定义不削弱系统状态和无障碍。
4. 输入状态完整。 目标输入下按下、焦点、悬停、激活等可区分。
5. 反馈立即。 按下阶段有本地反馈。
6. 手势连续。 跟手、离手速度继承、目标变化可打断。
7. 运动表达真实关系。 曲线、方向、共享元素和层级一致。
8. 异步状态不撒谎。 Pending 不冒充 Confirmed；成功反馈不早于真实确认。
9. 基础与版本分层。 当前视觉语言不得推翻方向感、可读性、无障碍和状态真实性；旧原则也不能阻止新平台能力。
10. 产品语境优先。 不把所有产品改成同一种玻璃、圆角、弹跳或“高级感”。
11. 可执行原型。 高风险手势、转场和跨端方案不能只凭静态稿通过。
12. 可访问。 非文本语义、状态、焦点、大字体和自绘内容可用。
13. 性能有证据。 避免手写逐帧、连续布局动画和冗余刷新，并进行真机验证。

详细审视标准见 [references/STANDARDS.md](references/STANDARDS.md)。

5. 看到即升级的问题

通常标为 BLOCKER 或 MAJOR：

• 关键页面无返回或退出；
• 平板/大字体下核心操作被裁剪；
• 核心按钮没有按下反馈；
• 手势松手后速度归零产生明显停顿；
• 动画期间锁住输入；
• 共享转场和默认 Navigation 转场叠加；
• 远端请求尚未确认就显示或播报成功；
• 图标按钮无可访问名称；
• 焦点陷阱；
• 高频手势每帧修改 width/height；
• 把 House Style 声称为官方规则；
• 用当前视觉趋势为理由移除必要对比度、焦点或方向感；
• 高风险手势只有静态稿，没有可运行原型或目标设备证据。

6. 修复优先级

1. 修复任务、导航和状态真实性；
2. 恢复系统默认能力；
3. 修复跨设备和输入；
4. 修复无障碍；
5. 删除无目的动效；
6. 修复跟手、速度和打断；
7. 统一语义 Token；
8. 优化性能；
9. 最后处理品牌微动效。

7. 必需输出格式

上下文卡

列出已知条件和假设。

Findings 表

一行一个问题。没有证据的问题不进入 Findings。

影响归纳

按以下顺序，只输出非空类别：

1. 任务与导航；
2. 异步真实性；
3. 跨设备与输入；
4. 手势与动效；
5. 无障碍；
6. 性能；
7. 稳定原则与平台版本；
8. 视觉一致性；
9. 原型与证据；
10. 待验证。

最小修复计划

给出依赖顺序、修改范围和验证方法，不直接重写整个项目。

结论

只能是：

• 不通过：存在 Blocker；
• 有条件通过：无 Blocker，但存在未关闭 Major；
• 通过：无 Blocker/Major，关键设备、输入、字号、无障碍和性能已有证据。

8. 来源措辞

• H1：华为官方；
• H2：OpenHarmony 官方；
• H3：官方观察；
• H4：项目建议。

不要把 0.97、统一弹簧、错峰入场、玻璃材质等写成 HarmonyOS 官方要求。

9. 反同质化检查

每次审视补充：

应保留的产品特征：
不应套用的通用风格：
允许的 House Style：

审视的目标是适合，而不是时髦。