在個人應用中巧妙融合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體驗編輯並撤銷功能。