23 · AI 实现前后的质量关卡

适用：任何新增、修改或审查产品 UI 的任务。这一篇作为短检查入口，具体决策按链接深入，避免每次把整本手册塞入上下文。

GATE-01 · 开始前提交最小可执行规格

任务和用户：谁在什么情况下完成什么事。
页面范围：实际路由、弹层与适用状态，不能只写“优化 UI”。
依据：设计稿 / 已确认母版 / 明确提出的新方案。
产品文案：可见文字及语义键；内部说明放到研发资料。
复用：现有组件、领域规则、状态逻辑；新增抽象的职责。
变量：视觉 token、业务限制、行为配置及来源和单位。
个例：为什么不同、覆盖范围、必须保留的公共行为。
交互：事件、合法转移、并发策略、取消、恢复与副作用清理。
内容：长短文案、emoji、翻译、大数、缺图和大字号策略。
证据：进入方式、检查方法、影响页面与未确定事项。

有现成依据的常规细节可直接沿用；缺失的关键业务或设计决定要标明假设或给出具体方案，不要伪装成已经确认。

GATE-02 · 实现中执行五项约束

这些约束适用于失败分支、移动端、辅助技术文本与后续新增页面，不只适用于第一次展示的主页面。

GATE-03 · 完成前做可观察的检查

1. 导出可见文案，逐项确认受众、事实和下一步；检查错误与无障碍名称。
2. 修改一个代表性的共享变量或规则，检查适用调用方共同变化、受保护个例不被误伤。
3. 用临界内容、超长内容和不同脚本检查，不通过删内容或缩小字号掩盖问题。
4. 执行乱序、重复、取消、离开、权限变化等事件序列，验证最终事实。
5. 按受影响路由与状态检查主题、布局、操作和出口，记录截图与实现摘要。

测试优先验证真实风险与系统边界。无需为每个标签值、样式字面量和简单映射写一套照抄实现的测试；不能因为测试困难就删除状态或修改预期。

GATE-04 · 交付明确陈述证据与边界

交付包括实现范围、公共代码变化、变量与文案来源、保留的个例、运行命令和结果、设计对照、未验证项。写“哪些检查通过”，不写无范围的“所有场景完美适配”。

没有真实运行条件时记录阻塞；没有设计确认时记录待确认；没有真机或读屏测试时明确未验证。文档、功能、视觉与人工确认分别陈述。

GATE-05 · 可复制到项目的规则示例

下载 project-ui-rules.example.md，按项目填入设计、变量、文案、路由清单和检查命令路径。它是待适配模板，不会自动修改当前仓库的工作规则。

把这些约束放在 AI 能发现的项目文档中，并在任务卡中引用。规则再详细，如果 AI 只读到“做一个好看的页面”，也很难持续保持一致。