AI Engineer onepage/ Gadgets
Kenton Varda, Cloudflare · 約 17:24
這支影片在講：讓使用者用 AI 加功能，但別讓核心 App 失控
Cloudflare 的 Kenton Varda 主張，個人 AI codegen 不該只是把不受信任的程式碼塞進既有產品；它需要一個以「每份文件一個隔離 app」為核心、把分享與權限交給平台的執行模型。
Published: 2026-08-05Video ID: RmS5s6Wbin4
01 / 問題
功能請求卡在核心產品
現在的 SaaS 只有開發者能改功能；使用者的特殊需求往往排進 backlog，最終消失在 Jira。
02 / 反轉
外掛重寫不是出口
為了可客製化而重做 plugin architecture，常常要花數年、破壞核心產品，最後仍難真正交付。
03 / 解法
文件就是一個 Gadget
每個簡報、白板或文件都是獨立 app instance；使用者能讓 agent 擴充它，平台則接管分享與隔離。
Design signals
影片最值得抓的四個設計訊號
App unit
1 文件
一個 Gadget 對應一份文件，而不是一套多租戶、由廠商統一部署的 app。
UI boundary
null origin
前端 iframe 只能以 postMessage 與父頁溝通，縮小 vibecoded UI 的可觸及範圍。
Server runtime
workerd
Demo 本機執行；架構刻意不依賴 containers 或資料庫才能運作。
Legacy model
25 年
雲端長期以單一「正式版本」集中部署，正是個人化功能難落地的根源。
Core story
Gadgets 想修正的三個架構錯位
01
把客製需求當成主產品需求
使用者想要的可能只是文字置中、刪除線或一個 SVG 圖表框。這些能力不該逼核心團隊改 roadmap；讓 agent 在使用者自己的文件中加上它，核心產品就能保持乾淨。
02
把程式碼隔離，卻把權限留給它
單純 sandbox 不夠。Gadgets 讓平台實作分享，避免 app 自己寫 access control；即使生成的程式含有 XSS，前端也沒有可直接外洩的資料或權限。
03
把部署當成應用程式的唯一形態
傳統雲端假定一個 app 由開發者部署、所有人使用。Gadgets 反過來把每份使用者資料變成應用實例，讓可變動的邏輯貼近該份資料。
Architecture
安全不是功能限制，而是資料流設計
UI：null-origin iframe不受信任的 UI 不能直接存取父頁或同源資料；它只透過
postMessage 發出受限請求。RPC：Cap'n Web sessionUI 與 server code 之間走 RPC session，而非把任意網路與帳號能力交給前端。
Server：dynamic worker sandbox把生成的 server 邏輯放進動態 worker sandbox，降低它對平台其他資源的影響面。
Sharing：平台能力共享由平台實作，不讓每個 vibe-coded app 重複發明登入、ACL 與邀請流程。
Use this checklist
如果你要做可擴充的 AI 產品，先問這五題
客製化能否限制在單一資料物件？把 scope 綁在文件、專案或 board，可比允許 agent 改整個 workspace 更容易隔離、回溯與分享。
誰持有授權與分享邏輯？若每個生成 app 都自己實作權限，安全品質會被最弱的一個 app 決定；平台應保留這個責任。
生成 UI 被攻破後還能拿到什麼？用能力邊界檢查，而不是假設 XSS 永遠不會出現：它是否有 cookie、同源資料或可任意呼叫的 API？
最小可執行單位是否足夠輕？能在本機 workerd 跑的 demo，代表迭代不必綁定複雜的 container、database 與雲端部署流程。
核心產品與使用者擴充能否各自演進？最好的 extensibility 不是把所有變化吸收進核心，而是讓兩者在清楚的介面與安全邊界上分開演化。
Source video
原影片與時間碼
0:00–5:11｜為何現有雲端不適合個人 AI codegen功能請求、plugin system 重寫與 web 作為 escape hatch。
7:11–12:21｜Gadgets 與 blueprints demo每份文件一個 app，Claude 為做投影片而替 app 加功能。
14:04–17:24｜XSS 隔離與執行取捨null-origin iframe、RPC、dynamic worker sandbox，以及不採 container / database 的理由。