在個人應用中巧妙融合AI與UI

本文探討了如何在個人應用中安全地將AI生成的動態內容融入用户界面，而不讓AI模型直接操作標記、樣式或DOM。作者介紹了其應用millfolio中的一項名為Millwright的功能，該功能採用三層數據契約架構，將模型輸出轉化為可安全渲染的UI組件。

第一層是構件層。構件的內容由小型沙盒程序生成，這些程序同樣用於處理一次性查詢。程序從不返回HTML或Markdown，而是返回版本化的JSON信封，其中包含類型化的數據塊，例如文本、表格、關鍵績效指標（KPI）、時間/類別序列、份額餅圖以及離線比例符號地圖。每個值都有明確的類型，例如貨幣值以{raw, text}形式傳遞，客户端根據數字和格式化字符串分別使用，無需從顯示字符串中解析。這種“可信外殼”不變量確保程序只產生數據，而外殼管理所有交互。當表格列標記為商家或標籤時，外殼會自動將單元格轉換為指向Vault記錄的深層鏈接，程序無法注入腳本或鏈接。因為契約中根本沒有位置放置這些元素。

第二層是看板層。看板本身是一個語義化的版本化規範文檔，包含有序的構件列表，每個構件有ID、標題、大小提示和指向計算程序的指針。編輯操作（調整大小、編輯程序、刪除構件）會生成新的內容尋址版本（基於字節的16位十六進制FNV-1a哈希），並追加到版本日誌中。當前看板只是該日誌中的一個指針，因此撤銷只需移動指針，編輯出錯不會破壞早期版本。在接受任何候選規範之前，無論來自內聯編輯器還是模型，都會經過驗證器檢查：構件ID必須路徑安全且唯一、引用的程序必須存在、遠程URL被直接拒絕、結構限制被強制執行。模型提出，驗證器決定。

第三層是頁面層。一組構件可以提升為頁面，獲得自己的頂級導航按鈕，與Ask和Vault並列，解散頁面則將其構件返回看板。頁面使用相同的規範文檔（pages[]部分）、相同的版本控制和驗證器，但有一條額外規則：導航變更是僅添加的。生成的編輯可以添加頁面，但絕不能重命名或移除內置標籤。用户依靠檢查模型行為的UI部分（如Ask、Vault）本身不能被模型編輯。

為什麼採用分層而不是讓模型直接編寫UI？顯而易見的替代方案是讓模型生成HTML/JSX並沙箱化，但其缺點包括無法進行差異比較、無法結構驗證、無法通過移動指針還原，而且每次渲染都涉及安全決策。三層數據層提供了相反的權衡：每個模型貢獻都是可檢查、可版本化、可驗證和可拒絕的文檔，而像素始終由隨應用發佈的代碼繪製。這種分層也使得公共演示安全可靠：演示看板使用相同機制處理合成數據，編輯保存在瀏覽器的localStorage中——相同的哈希算法、驗證器和外殼。

總結：Millwright通過嚴格的數據契約和分層架構，實現了安全、可審計且用户可控的AI集成，避免了AI直接操作UI帶來的安全風險和不可預測性。用户可以在demo.millfolio.app體驗編輯並撤銷功能。