資料建模
描述業務物件，資料庫和 API 隨之而來。
以一個訂閱計費系統為例：客戶、套餐、席位、MRR、續約日、狀態。在 ObjectOS 裡，這就是一份緊湊的物件定義——表、遷移、查詢引擎和 REST 端點由執行時供給；你的 Agent 能寫它，你的團隊能在物件設計器裡逐欄位微調它。
- 20+
- 欄位型別——文本、貨幣、百分比、lookup、公式、檔案
- 0
- 手寫端點——REST API 直接來自後設資料
- 原地
- 現有資料庫無需遷移即可聯邦接入
模型即原始碼
一份物件定義，schema、規則和 API 全在裡面。
這就是那個訂閱物件：欄位、關係、校驗和歷史追蹤都在一份可審閱的定義裡。執行時把它變成表和遷移，在每條寫路徑上執行規則，並對外提供 API——同一份定義，Agent 能讀懂擴充套件，設計器能開啟微調。
import { ObjectSchema, Field } from '@objectstack/spec/data';
export const Subscription = ObjectSchema.create({
name: 'billing_subscription',
label: 'Subscription',
searchableFields: ['plan', 'status'],
fields: {
customer: Field.lookup('crm_account', { label: 'Customer', required: true }),
plan: Field.select({
label: 'Plan',
options: [
{ label: 'Starter', value: 'starter', default: true },
{ label: 'Team', value: 'team' },
{ label: 'Business', value: 'business' },
],
}),
seats: Field.number({ label: 'Seats', min: 1 }),
mrr: Field.currency({ label: 'MRR', scale: 2, min: 0 }),
renews_at: Field.date({ label: 'Renews at' }),
status: Field.select({
label: 'Status',
trackHistory: true,
options: [
{ label: 'Active', value: 'active', default: true, color: '#10B981' },
{ label: 'Past due', value: 'past_due', color: '#F59E0B' },
{ label: 'Churned', value: 'churned', color: '#EF4444' },
],
}),
},
});為業務建模
把訂閱系統一步步建出來
定義貼著業務的說法走：客戶、套餐、續約。沒有 ORM 類，沒有散落各處的 schema 檔案——下面每一步都停留在同一份定義裡。
物件與關係
訂閱 lookup 到客戶，發票主從掛在訂閱下，多對多標籤隨取隨用——引用完整性由執行時維護，刪錯父記錄這種事故不再發生。
校驗與規則
"席位數不能低於已分配使用者""MRR 不能為負"——約束以表示式宣告在欄位旁邊，在 UI、API、匯入和 AI 工具的每條寫路徑上生效。
公式與預設值
"年化收入 = MRR × 12""續約日預設下單日 + 365"——計算欄位和動態預設值用全平臺同一種表示式語言，任何入口算出來都一致。
型別化的業務欄位
貨幣自帶精度與符號，百分比自帶上限，選擇列表自帶顏色與歷史追蹤——欄位型別攜帶語義，UI、API 和 Agent 都能直接理解。
物件設計器
欄位級微調，圖上看關係，一鍵接存量庫
Agent 寫的定義，管理員在開源控制台裡開啟就是視覺化介面——改一個欄位不需要讀一行程式碼。
欄位編輯器
點"+ 新增欄位"從 20+ 型別中挑選，拖拽行排序，欄位分組成節；右側檢查器改標籤、必填、選項和顏色，改動即成草稿。
釋出前看 diff
設計器的審閱模式把草稿與已釋出版本逐項對比——新增、修改一目瞭然，和審 Agent 的 diff 是同一種體驗。
ER 圖設計器
實體框、帶基數標註的關係連線、自動佈局和小地圖——整個資料模型一張圖看懂，拖一條線就是一個新關係。
資料來源同步
連線表單按驅動自動生成，點"測試連線"驗證，再從遠端表清單裡勾選——introspect 現有 ERP/CRM 資料庫，外部表直接生成受治理物件。
從模型到執行的系統
那些你再也不用寫的部分
下面這一切都由定義生成並保持同步——這正是 AI 編寫的變更能始終保持為一份小而可審的 diff 的原因。
表與遷移
給訂閱加一個"折扣"欄位，Postgres、MySQL、SQLite、Turso 或 MongoDB 上的遷移自動生成——沒有 SQL 指令碼要寫、要排序。
查詢引擎
"本月續約且 MRR 大於 1 萬的訂閱"——一種查詢語言搞定過濾、關係與聚合，每個請求都被許可權模型約束。
REST API
物件存在的那一刻，CRUD、批次與發現端點就存在了——移動團隊第二天就能開工，帶版本、帶文件、帶許可權校驗。
檔案儲存
合同 PDF、發票附件存放在本地磁碟或 S3 相容儲存上，訪問控制跟隨其所屬的記錄。
決策面
改什麼、誰來審、跑什麼
| 業務需求 | AI 編寫 | 執行時供給 |
|---|---|---|
| 管理訂閱與客戶 | 物件、欄位、關係 | 表、遷移、引用完整性 |
| 席位數不能超賣 | 一條表示式校驗規則 | 在 UI、API、匯入和 AI 寫入上強制執行 |
| 給移動團隊一個 API | 不用多寫——物件本身就夠了 | 帶許可權與發現的 REST 端點 |
| 繼續用手裡的 ERP 資料庫 | 一份聯邦定義 | introspect 外部表，掛載為受治理物件 |
評審清單
資料評審應確認
- 每個物件都對應一個有歸屬人的業務概念。
- 校驗寫在定義裡，而不是寫在介面裡。
- 派生值是公式，而不是複製貼上的邏輯。
- 外部系統走聯邦或整合，而不是被複刻一份。
- API 訪問與 UI 走同一套許可權模型。
FAQ
這一頁應該回答的問題
支援哪些資料庫？
目前支援 Postgres、MySQL、SQLite、Turso 和 MongoDB，資料層基於驅動架構。聯邦還能在不搬移資料的情況下掛載外部資料庫的表。
物件設計器和 ER 圖在開源版裡嗎？
在。物件設計器、ER 資料模型設計器、資料來源同步，連同物件、關係、校驗、公式、遷移、查詢引擎、REST API 與檔案儲存，都是開源版的一部分。
下一步