# Review Harmonyos Design

> 严格审视 HarmonyOS、OpenHarmony 与 ArkUI 产品或代码，只报告有证据的设计、导航、跨设备适配、输入状态、动效、异步状态真实性、无障碍和动画性能问题，并给出规则 ID、ArkUI 落点与通过结论。用于用户明确要求 review、audit、审查、验收或评估鸿蒙 UI；不要用于从零设计、直接实现功能、修复构建签名或审查非界面代码。

- Skill: `dososo/review-harmonyos-design` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dososo/review-harmonyos-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dososo/review-harmonyos-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: dososo (https://skillmd.com/u/dososo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dososo/review-harmonyos-design

---


# 严格审视 HarmonyOS 设计

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

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

## 1. 审视范围

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

## 2. 不在范围内

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

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

## 3. 先建立上下文

复用用户已提供的信息：

```yaml
目标设备:
窗口形态:
主要输入:
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 表

| 优先级 | 规则 ID | 证据 | 问题 | 用户影响 | 建议 | ArkUI 落点 | 来源等级 | 置信度 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |

一行一个问题。没有证据的问题不进入 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. 反同质化检查

每次审视补充：

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

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