精选machi-dual-platform-sync-playbook
Machi 双端同步方法论
当 iOS App 与 Web 客户端必须共享账号、Feed、互动、私信、通知和会员状态时。
原则
- 后端是真相源
- DTO 要兼容新旧客户端
- 平台差异留在交互层
步骤
- 列出共享状态
- 定义 REST 与 SSE 契约
- 补齐序列化兼容字段
- 分别跑 Web 与 iOS 验收
Machi 的 Web 和 iOS 不追求界面完全一致，但用户、帖子、互动和支付状态必须来自同一套后端事实。
正在准备页面
每一条方法论都对应一个真实场景：如何取舍功能、推进开发、协作 AI、同步 Machi 双端、设计离线优先 iOS，以及复盘项目。
当 iOS App 与 Web 客户端必须共享账号、Feed、互动、私信、通知和会员状态时。
原则
步骤
Machi 的 Web 和 iOS 不追求界面完全一致，但用户、帖子、互动和支付状态必须来自同一套后端事实。
从需求到上线，需要稳定推进而不是临场发挥时。
原则
步骤
当一个功能看起来很有吸引力，但资源有限时。
原则
步骤
一个项目完成后，需要把经验变成下一次的速度时。
原则
步骤
页面看起来还行，但缺少高级感和记忆点时。
原则
步骤
需要快速探索复杂方案，但仍要保持判断权时。
原则
步骤
当原生 App 需要在弱网或离线场景下继续可用时。
原则
步骤
我会优先让系统真实可运行，再逐步提升视觉和交互。
如果一个功能只能让页面显得更丰富，却不能提高用户完成目标的概率，我会推迟它。
复盘不是证明自己做对了，而是让未来的自己更少重复犯错。
如果背景很美却影响阅读，这不是设计进步，而是噪音增加。
AI 生成的内容不能直接成为结论，必须经过项目上下文和运行结果校验。
Machi iOS 可以离线浏览和起草内容，联网登录后再由 RemoteSyncService 与后端状态对齐。