一個圖譜，多個原生界面：推測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這樣的框架，因為共享代碼是合適的約束。另一些可能選擇原生界面，因為代理能承擔更多實現負擔。在那個世界裏，有價值的資產不僅僅是應用代碼，而是告訴每個界面什麼應該保持真實的圖譜。

未來可能不是一個應用到處運行，而是一個應用地圖幫助每個界面感覺它屬於那裏。