- name
- cross-platform-mvp-ui-alignment
- license
- Apache-2.0
- description
- 对齐 Android、Apple 等多平台 MVP 规格、功能状态、设计语言与 Phone/Tablet 成套 UI 资产。适用于已有规格或图稿发生平台分叉、页面覆盖不一致、需要建立共享页面矩阵和可审查视觉基线的产品设计工作;不用于直接实现原生客户端代码。
# Cross-platform MVP UI Alignment
把多平台 MVP 先收敛成同一套可观察行为和页面矩阵,再生成逐页对应、可复现、可审查的 Phone/Tablet UI 资产。平台一致性指功能和状态等价,不要求抹平 Android 与 Apple 的原生交互差异。
## 快速开始
- “对比 Kotlin 和 Swift 的 MVP 规格,列出功能、状态和页面差异,再统一四端矩阵。”
- “沿用已确认的视觉母版,为 Android/Apple 的 Phone/Tablet 生成同源成套图稿。”
- “审计 P01-P19 是否四端齐套,区分候选图、已审核母版和原生验收截图。”
开始时读取用户指定的规格、README、manifest、现有资产和已确认母版。若仓库有自己的规格体系,沿用其事实源,不另建冲突规格。信息不足时先输出带假设和缺口标记的审计结果;只有会改变页面范围、主流程或视觉方向的缺口才询问用户。
## 适用对象与能力边界
### 擅长
- 产品/设计负责人:比较多个平台的 MVP 范围并裁决分叉。
- 移动端团队:建立 Android/Apple × Phone/Tablet 的共享页面与状态矩阵。
- 设计工程师:基于同源场景、令牌和渲染规则生成成套候选资产。
- 评审者:核验覆盖率、跨端语义等价、文件归档和资产成熟度。
### 需要素材
- 至少一份规格、功能清单或现有产品流程,才能判断 MVP 边界。
- 至少一张已确认母版或明确风格约束,才能做视觉对齐。
- 目标平台、画布尺寸和交付目录,才能生成可落盘资产。
- 需要替换旧资产时,必须提供审核状态或明确授权。
### 超出范围
- 不凭图稿宣称原生实现、可访问性、暗色模式或运行时行为已通过。
- 不在未获授权时删除旧 README、图稿、manifest 或历史版本。
- 不把 Android 与 Apple 的控件逐像素复制;改用共享语义加平台原生映射。
- 不处理包含真实 token、账号、隐私会话或生产数据的截图;先脱敏或改用合成数据。
## 工作流
完整步骤见 [references/workflow.md](references/workflow.md)。
1. **建立事实基线**:定位规格事实源、资产树、manifest、已确认母版与历史稿;区分源事实、用户裁决、推断和待验证项。
2. **比较产品语义**:按功能、入口、状态、事件、权限、错误恢复、后台恢复逐项比较,不先比较像素。
3. **裁决统一合同**:形成一个共享 MVP 合同;平台差异进入原生映射表,不能形成第二套产品逻辑。
4. **建立页面矩阵**:每个页面/关键状态使用稳定 ID;记录触发条件、可见结果、下一步及四端覆盖。
5. **锁定设计语言**:从已确认母版提取令牌、层级、色彩面积、材质、排版、图标和反馈;保留已确认的深度与色彩品质。
6. **生成同源资产**:四端共享场景数据、文案、插图包、状态和渲染输入。Phone 与 Tablet 分别构图;Android 与 Apple 分别原生化。
7. **验证并分级**:检查矩阵、尺寸、命名、manifest、视觉一致性和来源。区分候选资产、审核母版和原生截图。
8. **审核后提升**:用户确认新基准后才能提升候选树;删除或归档旧资产需单独授权并保留映射。
## 核心决策规则
- **功能先于视觉**:页面数相同不代表功能对齐;必须检查状态、事件和恢复路径。
- **共享合同,平台实现**:共享功能、状态、文案意图和页面 ID;平台采用原生导航、控件和反馈。
- **Tablet 不是放大 Phone**:应利用双栏、主从区或常驻上下文,但保持同一任务闭环。
- **同源不等于复制**:业务场景、测试数据和插图来源相同;布局可按设备与平台重排。
- **资产证据分层**:规格一致、渲染成功、文件存在、视觉审核、原生运行是不同门禁。
- **保留已确认决策**:纠偏时保留已确认布局、交互和视觉优点,只修正被指出的问题。
## 输出合同
默认交付事实源清单、跨平台差异与裁决表、共享 MVP 合同、页面覆盖矩阵、设计语言卡、Phone/Tablet 资产清单和验证报告。字段模板见 [references/artifact-contract.md](references/artifact-contract.md)。每个结论说明依据;无法确认的内容标为假设,禁止补写不存在的功能、审核结论或运行证据。
## 质量与安全门禁
- 使用合成或脱敏的名称、会话、位置、token 和账号;不得复制观察记录中的敏感内容。
- 外部图片、字体和图标记录来源与许可;来源不可靠时使用自有资产或明确占位符。
- 破坏性操作前解析精确目标、列出文件并取得用户确认。
- 工具失败时报告“缺少的工具/素材 + 补充方法”;可降级交付矩阵、提示词或渲染规范,不伪造图稿。
- 输出目录已有未提交内容时停止覆盖,改用候选目录或请求裁决。
## 常见问题
**Q1:两份规格谁优先?** 看项目指定的事实源和用户最新裁决;无法判断时保留冲突并请求选择。
**Q2:必须四端像素一致吗?** 不必。功能、状态、文案意图和视觉品牌一致,控件遵循平台习惯。
**Q3:没有母版怎么办?** 先给中性设计语言候选并标明未获批,不批量生成全矩阵。
**Q4:先做 Phone 还是 Tablet?** 通常先锁定一个 Phone 和一个 Tablet 主场景母版;已有母版则沿用。
**Q5:什么时候能删旧图?** 新规格、矩阵和图稿通过审查且用户明确授权后。
**Q6:渲染成功算完成吗?** 不算。还需文件/manifest 与视觉检查;原生实现另需设备验证。
更多边缘情况见 [references/faq-deep.md](references/faq-deep.md),失败方式见 [references/anti-patterns.md](references/anti-patterns.md)。
在 GitHub 查看