一个图谱，多个原生界面：推测AI与跨平台应用

跨平台框架一直追求一个艰难的承诺：一次构建，覆盖多个平台。.NET MAUI、Flutter、React Native等框架试图通过共享代码、组件或运行时层来降低发布Web、iOS、Android和桌面应用的成本。这确实有价值。

但AI可能改变需要共享的内容。如果代理能够生成更多实现，最有价值的共享资产可能不再是一个UI框架，而是一个产品图谱。

共享代码解决了实际问题：减少重复，避免业务逻辑被重写多次。但它也带来了压力：应用可能感觉不够原生，平台行为变得别扭。团队可能花同样多的时间来绕过抽象层，而不是使用它。这并不意味着跨平台框架是错误的，而是共享代码并非共享产品意图。

更深层的问题可能是：实际应该共享什么？有用的共享层可能上移至UI框架之上。团队不再要求一个框架让每个平台都感觉合适，而是用一个图谱来描述产品的含义：哪些能力存在、哪些实体和工作流重要、用户需要哪些界面、每个界面应有哪些组件和状态、哪些规则约束行为、哪些可访问性和本地化承诺适用、哪些证据证明体验有效。

然后，代理或生成器可以产出不同的原生输出。Web应用使用Web原生模式，iOS应用使用iOS原生导航和控件，Android应用使用Android原生约定，桌面应用使用桌面隐喻。共享层不再是低共同分母的UI，而是应用地图。

一个在iOS应用上工作的代理在原生iOS环境中可能比在通用跨平台抽象中更有效。编译器、模拟器、平台API、可访问性工具和设计约定都为代理提供了更强的反馈。Android、桌面和Web也是如此。代理不必猜测自定义抽象是否干净地映射到平台，它可以直接与平台合作。

但这只有当代理有共享的意图来源时才有效。否则，每个原生界面都会成为产品自己的解释：iOS应用漂移，Web应用漂移，Android应用漂移，桌面成为无人信任的奇怪界面。只有团队保持产品一致性，原生输出才强大。

可能的形态是：一个图谱，多个原生界面。图谱描述产品，每个界面以正确的平台语言实现产品。这意味着：一项能力出现在Web、iOS、Android和桌面；每个平台获得原生布局、导航和交互模式；共享规则定义行为而非像素；界面记录描述每个平台对用户的承诺；代理从同一意图生成或维护平台特定代码；审查者将每个输出与图谱和证据进行比较。

这不是“一次编写，到处运行”，而是更接近“一次规范，到处实现”。实现可以不同，产品契约不应不同。

像.NET MAUI这样的框架仍然可能重要。它们解决实际问题。有些团队想要统一代码库，有些应用在不同平台上足够相似，有些组织宁愿接受平台妥协也不愿配备多个原生团队。AI不会抹去这一点，但它可能开辟另一条路径：如果代理能从同一个应用地图帮助维护多个原生目标，团队可能不再需要针对每个目标的跨平台UI层。这改变了权衡。

问题可能不再是“哪个框架让我们共享最多代码？”，而是“哪个共享图谱让我们在保持每个平台原生时维持最多产品一致性？”。

Topogram适用于那些希望共享意图而不强制每个界面通过相同UI抽象的团队。应用地图可以描述能力、实体、界面、组件、工作流、规则、决策、需求、任务和验证。Web界面和移动界面可以指向同一个产品能力，同时命名不同的布局、交互和证据。这为代理提供了更好的起点：这个平台在实现什么功能？它属于哪项能力？哪些状态和规则必须保持一致？哪些部分是平台特定的？这个界面应该通过哪些证据？

然后代理可以在原生环境中工作而不丢失共享的产品地图。好处是：原生工作与共享意图。

如果AI持续降低实现成本，跨平台开发可能变得更少依赖一个运行时，而更多依赖一个协调的真相来源。一些团队仍会使用像.NET MAUI这样的框架，因为共享代码是合适的约束。另一些可能选择原生界面，因为代理能承担更多实现负担。在那个世界里，有价值的资产不仅仅是应用代码，而是告诉每个界面什么应该保持真实的图谱。

未来可能不是一个应用到处运行，而是一个应用地图帮助每个界面感觉它属于那里。