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

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