應用介面
沒人手寫的介面，人人信得過的檢視。
拿一個客服工作臺來說：客服在網格里處理待辦工單，主管拖著按狀態分組的看板，所有人都會看截止日曆。在 ObjectOS 裡這是一份檢視定義——按使用者渲染、隨記錄即時變化，還能在檢視設計器裡調整，不碰一個檔案。
- 0
- 列表、表單、詳情頁——沒有手寫前端
- 按使用者
- 行、欄位與動作按許可權過濾
- 即時
- 記錄一變，開啟的介面跟著變
介面即後設資料
檢視是可審閱定義的一部分。
這就是那個工作臺：帶列的網格、按狀態分組的看板、截止日曆，還有一個存好的"待辦工單"列表——一份定義。Agent 加一個欄位時，受影響的介面就在同一份小 diff 裡，而不是另開一張前端工單。
import { defineView } from '@objectstack/spec';
const data = { provider: 'object' as const, object: 'support_case' };
export const CaseViews = defineView({
list: {
label: 'All Cases',
type: 'grid',
data,
columns: [
{ field: 'subject' },
{ field: 'customer' },
{ field: 'priority' },
{ field: 'status' },
{ field: 'due_date' },
],
appearance: {
allowedVisualizations: ['grid', 'kanban', 'calendar'],
},
kanban: { groupByField: 'status', columns: ['subject', 'customer', 'priority'] },
calendar: { startDateField: 'due_date', titleField: 'subject', colorField: 'status' },
},
listViews: {
open: {
label: 'Open Cases',
type: 'grid',
data,
columns: [{ field: 'subject' }, { field: 'customer' }, { field: 'priority' }],
filter: [{ field: 'status', operator: 'equals', value: 'open' }],
},
},
});從後設資料渲染
把工作臺一個面一個面看過去
型別化欄位自帶控制元件與格式，生成的介面外觀行為天然一致——不需要先做一個設計系統專案。
檢視與列表
同一批工單渲染成網格、看板或日曆——帶排序、"待辦工單"這樣的儲存篩選和批次操作——宣告出來的，不是搭出來的。
表單與詳情頁
工單表單跟著欄位型別和校驗走：優先順序渲染成帶顏色的選擇列表，必填就是必填。介面永遠不會和規則脫節。
儀表盤
工單量和 SLA 計數器就擺在它們所彙總的佇列旁邊，共享同一份定義與許可權。
導航與應用
客服團隊得到一個聚焦的工作區——它的物件、檢視、儀表盤組成一個應用——而不是一個巨大的後臺。
多語言介面
標籤、格式與翻譯按 locale 解析，一份定義服務所有地區。
檢視設計器
看著介面調介面
檢視在開源控制台的即時預覽設計器中開啟——預覽用的就是真實渲染器載入草稿，所見即所釋出。
邊改邊看的即時預覽
改一列，網格立刻變——設計器用真實資料渲染列表、看板、日曆和表單檢視，改動過程全程可見。
列與篩選檢查器
在檢查器裡增刪、隱藏、重排列；視覺化地搭巢狀與/或篩選——"待辦、緊急、未指派"不用寫一行查詢。
積木式詳情頁
詳情頁由塊組成——分節、欄位、按鈕——每塊帶可見性規則，在畫布上拖到位。
響應式是預設項
頁面設計器預覽手機、平板、桌面三檔斷點，帶元件樹和撤銷/重做——佈局決策始終看得見。
許可權感知是構造出來的
一份介面定義，每個使用者各見其面
介面不是手工做的千人千面——它由許可權模型塑形。這正是生成式 UI 值得信任的原因。
能看到的行
客服的網格只有本團隊的工單，審計員的網格是全部——同一份介面定義，行級規則在查詢內部生效。
能讀到的欄位
被脫敏、被隱藏的欄位在表格、表單、匯出和詳情頁裡保持脫敏——由執行時執行，不靠前端自覺。
能執行的動作
"升級"按鈕只在使用者許可權與記錄狀態都允許時出現——服務端把關，不只是藏起來。
即時協作
記錄變更、評論和動態流式推送到開啟的介面，團隊面對的是同一幅即時圖景。
決策面
改什麼、誰來審、跑什麼
| 業務需求 | AI 編寫 | 執行時供給 |
|---|---|---|
| 給客服團隊一個工作臺 | 檢視、表單和一份應用定義 | 渲染的介面、導航、儲存篩選 |
| 主管要看板，客服要網格 | 一份檢視、兩種視覺化 | 同一份定義，兩種都渲染 |
| 經理看得比客服多 | 物件上的行級與欄位級規則 | 同一個介面，按使用者成形 |
| 運營調列不用發版 | 什麼都不用寫——設計器編輯的就是同一份後設資料 | 即時預覽、檢查器、草稿 |
評審清單
介面評審應確認
- 介面宣告在後設資料裡，而不是被 fork 成定製程式碼。
- 每個列表和儀表盤都遵守行級規則。
- 脫敏欄位在匯出和詳情頁裡保持脫敏。
- 動作有許可權把關，而不只是被隱藏。
- 新欄位通過同一份被審閱的 diff 到達介面。
FAQ
這一頁應該回答的問題
還能自己寫定製介面嗎？
能。生成的介面覆蓋重複度最高的 CRUD 主體，同一套 API 與許可權模型支撐你新增的任何定製前端——定製介面繞不過治理。
檢視設計器在開源版裡嗎？
在。帶即時預覽的檢視設計器、列與篩選檢查器、積木式頁面畫布和響應式頁面設計器都隨開源控制台釋出——連同後設資料渲染的檢視、表單、儀表盤、導航、多語言與即時更新。
下一步