跨端开发规则复用
3 节点1 篇3 来源
【背景】在 AI 辅助编程大幅降低原生开发成本的当下，跨端开发的“复用”定义正在发生根本性转移：从共享底层代码逻辑转向共享上层设计规则与规范。
少数派作者 Tw93 在开发 Windows 版清理工具 Mole 时发现，其 Mac 版十几万行 Swift 代码中，能脱离 macOS 框架直接复用的不足 20%。他最终选择用 C# 和 WinUI 3 从零重写，但通过同步设计 Token、多语言文案及架构规则文件（SYNC.md），实现了两端功能与视觉的高度一致。这一实践印证了行业趋势：随着 W3C 设计令牌标准成熟及 LLM 介入，GitHub、Shopify 等大厂正将“代码”而非 Figma 作为唯一真相源，而“平台无关的功能规范”取代“共享代码层”，成为新的复用单元。
争议在于：传统跨端框架（如 Flutter、React Native）仍试图通过抽象层抹平差异，而新范式主张各端原生实现，仅对齐规则。对于追求极致性能或深度系统集成的应用，后者正成为更优解。
事情怎么走到这一步
Tw93 发布文章《你不知道的客户端开发》，披露 Mole Windows 版开发细节：因 Swift 代码复用率低于 20%，改用 C#/WinUI 3 重写，并通过脚本同步设计 Token 和文案实现一致性。
sspai.com ↗W3C 设计令牌规范达到 v1.0 版本，加速了“代码即真相源”的设计系统转型，使得 GitHub、Shopify 等团队能够更严格地以代码库为准同步多端表现。
github.com ↗Brad Frost 提出 AI 在设计系统中的六大用例，包括组件代码生成和跨框架翻译，指出 AI 虽能提升效率，但输出仍需人工审查，且设计令牌是控制 AI 生成质量的关键锚点。
github.com ↗
还没定论的部分
- 在缺乏统一行业标准的情况下，如何确保不同团队间“规则文件”（如 SYNC.md 或 JSON Token）的兼容性与可迁移性？
- 当 AI 生成的代码出现“幻觉”导致逻辑错误时，现有的自动化测试体系能否有效拦截这些“垃圾手榴弹”（Slop Grenades）而不依赖大量人工复核？
- 对于中小型团队，完全放弃跨端框架而采用“规范驱动+各端原生”的模式，其长期维护成本是否真的大于使用 Electron 或 Flutter 等传统方案？