後設資料，不是程式碼生成：AI 應用為什麼可治理
程式碼生成能讓原型變快，但企業應用真正需要的是物件、欄位、關係、檢視、許可權、流程、動作和 agent 工具共同受控的後設資料執行時。
先給結論：AI 原生應用的核心不是把需求變成一堆程式碼，而是生成物件、許可權、流程、agent 工具共同受控的後設資料——程式碼能跑，後設資料才改得動、治得住。
過去幾年，低程式碼平臺解決了一個很具體的問題：不要每個內部系統都從零寫頁面、寫表單、寫流程。
現在 AI 又把這個問題往前推了一步：既然低程式碼可以拖拽搭應用，那能不能直接用一句話生成應用？
答案是可以，但這裡有一個很容易踩的坑：如果把“AI 生成應用”理解成“AI 生成一堆程式碼”，很快會遇到企業應用的老問題。第一版看起來很快，第二版開始變慢；頁面能跑，許可權不好管；表單能提交，流程難追蹤；AI 能回答，Agent 不知道哪些動作能做、哪些動作不能做。
真正的 AI 原生應用平臺，核心不是程式碼生成，而是後設資料生成。
讀者真正關心的不是程式碼，而是系統能不能改
站在業務負責人和 IT 負責人的角度，看一個應用平臺，最重要的問題通常不是“第一版能不能生成出來”，而是：
- 業務變化時能不能改；
- 改了欄位以後，表單、列表、許可權、流程是否同步；
- 新增審批規則時，舊資料和舊流程是否還能解釋；
- AI Agent 是否繼承使用者許可權；
- 誰看過什麼、改過什麼、批准過什麼，能不能審計；
- 這個系統半年後是不是還可維護。
程式碼生成解決的是“從無到有”的速度。後設資料解決的是“持續演進”的結構。
這就是低程式碼平臺過去十幾年得到的經驗：企業應用不是一組頁面，而是一套可配置、可治理、可升級的業務模型。AI Builder 如果只回到程式碼生成，就會繞開低程式碼最有價值的部分。
程式碼生成為什麼容易在企業應用裡失控
程式碼生成適合做原型、小工具和一次性頁面。它能快速生成 React 元件、API、資料庫 schema 和一些校驗邏輯。
但企業應用的複雜度通常不在這些地方，而在跨層一致性。
舉個例子。使用者說：
給客戶增加一個“續約風險”欄位，高風險客戶每週提醒客戶成功經理跟進。
如果這是程式碼生成任務，AI 可能會改資料庫、改表單、改列表，再寫一個定時任務。看起來完成了。
但在真實企業系統裡，這個欄位還會影響：
- 客戶詳情頁是否展示；
- 誰能編輯風險等級；
- 主管能否看到團隊風險；
- 匯出報表是否包含該欄位；
- Agent 總結客戶時能否引用；
- 高風險規則是否進入審計；
- 修改風險等級是否觸發通知；
- 未來欄位名稱變化時如何遷移。
這些內容如果散落在程式碼裡，每次修改都像小型重構。系統越用越重，最後又回到傳統定製開發的泥潭。
後設資料不是配置表，而是應用執行時的業務語言
很多人聽到“後設資料”，會以為只是配置項。這裡說的後設資料要更完整：它是應用執行時理解業務的語言。
| 後設資料層 | 它回答的問題 |
|---|---|
| 物件 | 業務裡有哪些核心實體，比如客戶、合同、工單、任務 |
| 欄位 | 每個物件有哪些屬性，型別、必填、公式、敏感性是什麼 |
| 關係 | 物件之間如何關聯，一對多、多對多、引用和反向引用是什麼 |
| 檢視 | 不同角色如何檢視資料，列表、看板、表單、詳情、儀表盤如何組織 |
| 許可權 | 誰能看、誰能改、能看哪些記錄、能操作哪些欄位 |
| 流程 | 狀態如何流轉，哪些條件觸發審批、通知和自動化 |
| 動作 | 建立任務、發起審批、生成報告、傳送提醒等業務動作 |
| Agent 工具 | AI 能查詢什麼、建議什麼、執行什麼、什麼時候必須停下來等人確認 |
| 審計 | AI 建議了什麼，人確認了什麼，系統最終執行了什麼 |
這些後設資料共同驅動 UI、API、許可權、自動化和 Agent。
頁面只是後設資料的一種表現。API 也是。Agent 工具也是。這樣系統才不會因為入口不同而行為不一致。
AI Builder 應該生成“應用規格”，不是直接甩出程式碼
一個成熟的 AI Builder 收到需求後，不應該第一反應就是寫程式碼。它更像一個懂低程式碼平臺的業務架構師，先生成應用規格。
例如使用者說：
幫我搭建一個售後工單應用，客戶可以提交問題，AI 自動分類並推薦回覆，企業客戶超時自動升級。
Builder 應該先產出：
- 主物件：客戶、工單、訊息、知識庫、SLA、升級記錄；
- 欄位：問題型別、優先順序、情緒、影響範圍、截止時間；
- 檢視：客服佇列、主管看板、快超時工單、高風險客戶；
- 許可權：客戶、客服、主管、管理員分別能看什麼；
- 流程：提交、分類、處理、升級、關閉、覆盤；
- Agent 工具：摘要、分類、知識匹配、回覆草稿、升級建議；
- 審計：AI 初判、人工修改、傳送確認、升級原因。
這份規格確認後，平臺再生成頁面、資料結構、自動化和工具呼叫。
這比直接生成程式碼慢不了多少，但後續會穩很多。
和傳統低程式碼相比，AI 改變了什麼
傳統低程式碼平臺通常要求使用者理解配置介面：物件設計器、欄位面板、流程畫布、許可權矩陣、表示式編輯器。
AI Builder 不應該推翻這些能力，而應該降低表達成本。
使用者不需要知道應該開啟哪個配置面板。他可以說：
把高風險合同單獨放到一個法務看板裡，金額超過 50 萬的再加財務複核。
平臺把這句話拆成物件篩選、檢視、流程條件、審批節點和許可權變更，並展示變更計劃讓使用者確認。
這才是 AI 對低程式碼的真正增強：不是讓平臺變成黑盒，而是讓業務語言直接進入平臺結構。
判斷一個 AI Builder 是否靠譜，可以看 6 件事
如果你在評估 AI 應用平臺，不要只看它能不能生成一個漂亮頁面。更應該問：
- 它生成的是程式碼，還是可解釋的物件、欄位、檢視、許可權和流程？
- 業務人員後續能否用自然語言修改應用結構？
- 許可權是否是執行時統一能力，而不是頁面裡的臨時判斷？
- AI Agent 是否只能通過受控工具訪問和修改資料？
- 每次 AI 建議、人工確認和系統執行是否有審計？
- 當業務規則變化時，是改後設資料，還是重新生成程式碼？
這幾個問題的答案，決定了它是演示工具，還是企業應用平臺。
ObjectStack 的差異
ObjectStack 的方向，是讓自然語言生成後設資料，再由後設資料驅動執行時。
使用者說一句需求，平臺生成物件、欄位、關係、檢視、許可權、流程、動作和 Agent 工具。應用執行後，業務人員繼續用自然語言修改它。AI Agent 也在同一套物件、許可權和動作邊界內工作。
程式碼仍然存在，但它不再是業務變化的唯一承載物。業務結構進入後設資料層，才能被生成、理解、修改、治理和審計。
程式碼生成讓第一版更快。後設資料生成讓第十版仍然可控。