dxe

dxe

按以下优先级顺序审查界面工作：

1. 意图优先于装饰。
2. 正确的语义和无障碍性优先于视觉便利。
3. 交互体验优先于实现技术；使用最贴合原生体验且能保留预期交互感受的实现方式。
4. 生产环境的可信度优先于原型技巧。

开始前请阅读 references/dxe-core.md。这是所有模式通用的评估准则。默认不要加载所有同级技能。

模式

根据请求推断模式；若未指定，则使用 review。

dxe 后的路径会将任意模式限定在该路径内。将“应用所有技能”视为 dxe exhaustive。

模式	范围	修改
dxe quick	在一个有代表性的界面上应用通用评估准则；除非必不可少，否则不加载同级技能	否
dxe / dxe review	完整证据矩阵和有代表性的仓库抽样；逐步加载已触发的同级技能	否
dxe fix	先审查，再实施并验证范围明确且把握度高的修复	是，仅限请求范围
dxe exhaustive	检查所有可用界面并阅读完整的同级技能套件	否，除非用户同时要求修复

审查模式严格禁止修改。不要编辑文件、安装依赖、启动外部变更或更改生产系统。允许只读检查和本地验证。在修复模式下，应保留无关的现有工作和设计系统材料。

范围和抽样

确定仓库或路径、主要用户任务、技术栈、设计令牌、基础组件以及交互／运行时库。优先使用现有材料，而非自行创造替代方案。

审查仓库时，应选择有代表性的界面，而不要暗示所有屏幕都经过了同等程度的检查：

• 主要落地页或任务页面；
• 内容／详情页和列表／索引页（如有）；
• 一个表单或变更流程；
• 一个覆盖层、对话框或菜单；
• 一个可用的加载、空状态或错误状态；
• 主要和对比性的目标设备形态、相关输入方式，以及减少动态效果的变体。

在报告中说明未检查的内容。在 exhaustive 模式下，检查前列出所有可发现的界面和状态。

证据规范

先写下简短的假设和非目标，然后根据模式收集最低限度的证据。对于常规审查／修复，记录：

证据	最低要求
材料	技术栈、令牌、基础组件、动效／运行时库
源码	有代表性的路由和共享组件
验证	在安全且可行时，执行现有类型检查／测试和生产构建
窗体规格	渲染主要布局和对比布局，检查裁切／溢出和任务层级
交互	首个有意义的输入序列；相关时检查覆盖层／菜单／面板状态、返回，以及触摸／指针／键盘的一致性
无障碍	平台名称、角色／特征／语义、状态、焦点／返回，以及减少动态效果
生产环境	加载／错误／空状态行为、平台元数据，以及平台特定的运行时日志
置信度	confirmed-rendered、confirmed-source、likely、unverified 或 environment-only

不能仅凭源码检查就断言存在渲染缺陷。如果无法渲染或执行检查，应标明限制，而不是猜测。

将观察结果分为：

1. 已确认的产品缺陷；
2. 源码层面的风险；
3. 环境或工具故障；
4. 尚未验证的疑虑。

在将工具噪声列为产品问题之前，先复现面向用户的故障。区分浏览器错误、服务端错误、预期的本地服务故障，以及框架／工具警告。

对于会触发状态变化的检查，应等待可观察到的稳定状态后再记录。优先采用目标平台的无障碍／语义值、焦点目标、过渡完成或动画稳定状态，而不是任意延时。如果渲染或动画仍在进行，不要将操作后立即采集的状态作为最终证据。

选择与交付平台相符的验证路径：

平台	必需的运行时证据
Web	浏览器 console.error、未捕获的 pageerror、服务端日志、响应式溢出、键盘操作序列
Apple 原生	在可行时执行 Xcode 构建／测试、模拟器／设备诊断、无障碍检查、动态字体大小、目标窗体规格
Android 原生	在可行时执行 Gradle 构建／测试、Logcat 错误／致命错误、语义／TalkBack 检查、字体缩放、目标窗口大小

紧凑的跨阶段检查

考虑每个阶段，但不要为了每个阶段都硬凑一个问题。

意图

• 说明界面能帮助用户完成什么。
• 标出应移除的重复操作、含义不明的界面元素和生成残留。
• 保留用途明确且有价值的元素。

平台

• 优先使用原生元素和状态约定，而不是用 div 加 ARIA 重构。
• 检查导航／焦点顺序、名称、角色、状态、禁用行为和表单参与情况。
• 如果原生 CSS／HTML 能表达相应行为且不削弱体验，就优先使用。

体验

• 检查键盘、触摸和精细指针输入下的操作可发现性。
• 动效应响应迅速，在需要时可中断，并提供减少动态效果的路径。
• 精彩设计应提升预期感、可靠性或贴心程度，而不是毫无目的地增添新奇元素。

衔接

• 检查设计结构是否有意映射到代码、令牌、基础组件、渲染和无障碍支持。
• 标记与现有系统冲突的一次性值或抽象。

发布

• 测试相关的加载、空状态、错误、身份验证、验证、焦点、元数据和重复使用路径。
• 区分原型捷径与已确认的发布风险。
• 关注关键约定是否有测试，而不是要求无差别地覆盖所有内容。

渐进式同级路由

仅当材料映射、初步证据或所需深度触发时，才加载同级 SKILL.md。集合中的同级技能会安装在此技能旁边，因此应先解析 ../<skill-name>/SKILL.md，再将某个评估视角视为不可用。如果同级技能存在且可读取，即使本次会话的发现注册表未列出它，也应使用其内容。只有在需要将其作为可单独调用的技能公开时，才需要刷新注册表；继续当前评估流程不需要刷新。如果发现机制和相邻路径都无法提供可读取的技能，则使用共享评估准则继续，说明缺少该评估视角，并避免臆造其详细指导。

触发条件	阅读
产品意图不明确，或决策需要说明理由	write-first-design
UI 装饰过多、冗余或认知负担过重	subtractive-design
需要采用丹麦功能主义设计视角	humane-functionalism
Web 表单、菜单、对话框、自定义控件或语义问题	semantic-html-first
Web 响应式布局或 CSS/HTML 实现问题	modern-css-html
SwiftUI、UIKit、AppKit、Xcode 或 Apple 平台 UI	apple-native-ui
Kotlin、Android Gradle、Jetpack Compose、Android Views 或 Compose Multiplatform	android-native-ui
手势、弹簧效果、中断或共享元素动效	fluid-design
可发现性较弱、操作仅在悬停时显示，或输入方式不匹配	interface-affordances
有明确机会提升产品体验	product-delight
设计/代码结构或令牌转换出现问题	design-engineering
重要交互行为未明确规定或前后不一致	interaction-contracts
共享组件或令牌模型需要兼容性或迁移决策	design-system-evolution
重复的设置、等待或中断导致重复工作成本高	design-for-repetition
占位或统一的内容掩盖了层级或布局决策	real-content-design
需要判断模板化或 AI 生成的残留内容	ai-output-judgement
认证、验证、状态、韧性或发布问题	prototype-to-production

dxe exhaustive 是唯一要求阅读路由表中所有同级技能的模式。

严重程度与置信度

• 严重： 阻碍主要任务、存在数据/安全丢失风险、导致已确认的严重无障碍问题，或破坏生产环境渲染。
• 应修复： 确认对理解、导航、语义、韧性或信任造成损害，且有明确的修正方案。
• 锦上添花： 润色、一致性、潜在的基础组件风险，或不影响主要功能的清理工作。

每项发现都必须包含一个置信度标签。绝不能将 unverified 或 environment-only 观察结果归类为严重。引用的源代码片段应尽可能精简，并将发现关联到具体路径或渲染界面。

报告

# dxe pass — [scope]

## Hypothesis
## Evidence collected
## Verified strengths
- [skill or core] path/surface — what should be preserved

## Findings
### Critical
- [confidence] [skill or core] path/surface — issue — bounded fix
### Should fix
### Nice to have

## Cuts
## Proposed changes
## Verification status
## Limits and unresolved observations

经验证的优势是证据，不是安慰：记录表现良好且应在后续变更中保留的系统。严重程度部分可以为空。绝不能为了凑数而强行列出问题。

验证流程

在工具和仓库脚本允许的情况下：

1. 运行现有的类型检查、测试和生产构建。
2. 渲染主要目标，以及一个对比视口、窗口、设备或外形规格。
3. 根据平台要求，检查裁切／溢出、安全区域／内边距和主要任务层级。
4. 记录首次有意义的键盘、触控、指针、遥控或辅助技术操作序列。
5. 执行一次菜单、对话框、底部面板或导航过渡；等待状态稳定后，再验证状态以及焦点／返回行为。
6. 在减少动态效果的情况下，重复一项包含动态效果的任务；等待状态稳定后，再记录动画状态或次数。
7. 捕获平台的运行时错误：浏览器的 console.error／pageerror、Apple 模拟器／设备诊断信息，或 Android Logcat 错误／致命错误。将它们与工具噪声分开归类。
8. 在修复模式下，重复受影响的检查并报告确切结果。

审查过程中，绝不修改生产系统或外部系统。

完成标准

• 明确说明范围、假设、非目标、抽样方式和限制。
• 考虑所有阶段；仅加载已触发的关联技能。
• 所有结论均与证据、严重程度、置信度和路径或界面相关联。
• 将确认的产品缺陷与工具噪声及疑点分开。
• 在适当情况下，记录现有优势和精简删减项。
• 经授权后实施的修复，其范围应受到限制，并按风险程度进行验证。