Salin Ui Quality Audit

---
name: salin-ui-quality-audit
description: 审查、批评、验收、打磨或加固 Web/App/小程序/后台/Dashboard 等用户界面，覆盖产品流程、视觉层级、一致性、反模板化、响应式、无障碍、交互状态、极端内容与性能。适用于“检查 UI、哪里不好、像 AI 模板、做质量报告、按规范审查、polish、harden、上线前验收”等请求。默认只报告已确认问题，不修改代码；只有用户明确要求修改真实文件或直接实施修复时才写入。
---

# Salin UI Quality Audit

审查必须基于真实证据，而不是审美猜测。代码静态检查、自动化规则和浏览器观察是互补证据；任何一个单独“通过”都不能证明界面质量优秀。

## 模式路由

| 模式 | 用户意图 | 必读参考 |
|---|---|---|
| Audit | 检查问题、合规、上线前验收 | [references/audit-framework.md](references/audit-framework.md) + [references/report-template.md](references/report-template.md) |
| Critique | 判断体验和视觉为什么不成立 | [references/design-critique.md](references/design-critique.md) + [references/anti-patterns.md](references/anti-patterns.md) |
| Polish | 功能已完成，要求精修或提升高级感 | [references/polish-and-hardening.md](references/polish-and-hardening.md) |
| Harden | 长文本、错误、慢网、多语言、权限等真实条件加固 | [references/polish-and-hardening.md](references/polish-and-hardening.md) |
| Current guideline review | 明确要求按最新 Web 指南/规范检查 | 必须联网获取最新官方一手规范，再结合 audit 框架；技术规范只引用权威来源 |

默认是只读 Audit/Critique。用户只说“审查、看看问题、怎么优化、给优化/打磨建议、能否 polish”时不得修改文件。只有明确要求“修改真实文件、直接改代码、在项目中实施修复”等写入动作时，才可在确认问题后实施，并保持任务边界。

审查按对象分流：整体任务流程、视觉层级、反模板化、跨页面一致性、通用无障碍、韧性与上线质量由当前 skill 主责；图表选型、数据口径、坐标轴和筛选联动交给 `salin-dashboard-builder`；shadcn CLI、component base、组件源码、tokens、主题和底层 Dialog/Popover 行为交给 `salin-shadcn-ui`。跨领域审查只设一个主负责人，其他 skill 仅提供限定证据。

## 核心流程

1. **确定对象与标准**：明确目标文件/页面、支持设备、关键用户流程、质量级别和是否允许修改。
2. **检查项目现状**：读 README、AGENTS/CLAUDE、Git 状态、依赖、设计系统、路由、组件和测试命令；不把未提交改动误判为缺陷。
3. **收集双重证据**：阅读相关代码；可运行时在浏览器检查实际渲染、交互、响应式、控制台和关键状态。截图只能证明一个时刻和尺寸。
4. **走关键路径**：按真实任务从进入到完成，覆盖加载、空、错误、权限、长内容、慢网、移动端和键盘。
5. **复核候选问题**：确认能定位、复现或用明确规则证明，再写入报告；删除猜测、重复和纯偏好。
6. **分级与排序**：按 P0–P3 排序，优先给 3–5 个最影响任务的问题；每项说明位置、证据、影响和最小修复建议。
7. **按授权行动**：只读任务到此停止。修复任务先解决根因，运行相关检查，再复查真实页面。

## 审查原则

- 产品有效性优先于视觉装饰：先看能否理解、完成和恢复，再看像素级细节。
- 设计系统偏差分为缺 token、重复的一次性实现、概念/流程不一致，修复方式不同。
- 只报告可复核的问题；不能从代码证明的视觉问题必须标明需要浏览器验证。
- 不把个人审美当通用规范，不因“不够炫”给出缺陷。
- 不把自动化检测零错误解释为“设计优秀”。
- 不为了凑数量列几十条低价值问题；同一根因可合并并说明影响范围。
- 性能必须先测量；没有指标时只报告明确的实现风险，不虚构 Web Vitals。
- 用户要求“最新、当前、合规”时必须联网；记录规范名、版本、发布状态、发布/更新日期、条款 ID、URL 和访问日期，并区分正式标准、编辑草案、解释材料、项目证据与推断。无法联网时只能标记“未验证最新性”，不得声称最新或合规。

## 严重度

严重度由核心任务影响、受影响用户范围、可恢复性和证据确定性共同决定，问题类别只作示例。仅有静态风险且未复现时不得直接升为 P0/P1。

- **P0 阻断**：有充分证据表明核心任务对大范围或关键用户无法完成，或存在严重数据/权限/安全误导且难以恢复。
- **P1 严重**：主要流程显著受损、关键用户群无法使用或错误难以恢复，例如已复现的移动端阻断、焦点陷阱、关键操作不可读。
- **P2 一般**：造成持续摩擦但仍可完成任务，例如局部层级、密度、一致性、状态、对比度或响应式问题。
- **P3 轻微**：不阻碍任务的视觉细节、局部对齐和微小润色。

## 输出要求

先给结论和高优先级问题。代码审查使用精确 `文件:行号`；运行时问题给页面、视口、操作步骤和实际结果。使用 [references/report-template.md](references/report-template.md) 的紧凑结构。

若未发现已确认问题，明确说“本次检查未发现可确认问题”，同时列出检查范围和未覆盖风险；不要为了显得有产出编造问题。

修复任务完成后额外汇报修改文件、运行检查、浏览器复测、未验证内容和残余风险。

## 完成前检查

- 每个问题是否有位置、证据、影响、复现或规则依据。
- 是否区分代码事实、浏览器事实、用户偏好和待验证假设。
- 是否覆盖核心流程、键盘、移动端、完整状态和极端内容。
- 是否删除重复、无关和未经复核的问题。
- 是否遵守“审查默认不修改”的授权边界。