從自然語言到應用後設資料：AI Builder 如何生成物件和許可權

先給結論：好的 AI Builder 不是把一句話變成幾個頁面，而是把一句業務需求拆成物件、欄位、檢視、流程、許可權和 agent 工具——一份可執行、可修改、可治理的應用規格。

“一句話生成應用”聽起來很有衝擊力，但這句話本身容易誤導。

如果讀者以為它只是“輸入一句話，然後生成幾個頁面”，那它和很多程式碼生成演示沒有本質區別。真正值得關注的是：AI Builder 如何把一句業務需求拆成可執行、可修改、可治理的應用後設資料。

我們用一個具體需求來看：

幫我搭建一個供應商風險管理應用。系統要管理供應商、資質、報價、採購訂單、交付和質量問題；AI 能識別資質過期、報價異常和交付風險；關鍵物料供應商出現高風險時，要採購經理審批。

讀者真正想知道的是：這句話進入平臺以後，到底發生了什麼？

第一步不是生成頁面，而是生成業務物件圖

AI Builder 首先要識別業務裡的“名詞”。

在這個例子裡，主物件不是一個籠統的“供應商表”，而是一組相關物件：

• supplier：供應商主體；
• supplier_qualification：資質證照；
• quotation：報價記錄；
• purchase_order：採購訂單；
• delivery_record：交付記錄；
• quality_issue：質量問題；
• supplier_risk：風險記錄；
• approval_task：審批任務。

這一步很關鍵。因為物件決定了後續應用的邊界。

如果只有一張大表，使用者後面想問“這個風險來自哪次交付、哪張報價、哪份資質”，系統很難回答。物件拆清楚以後，風險就能關聯證據，審批就能關聯原因，Agent 也能解釋依據。

第二步：欄位和關係要帶業務語義

低質量生成器會把欄位當成表單項。高質量 Builder 會把欄位當成業務語義。

例如資質物件不只是“附件”：

• 資質型別；
• 證書編號；
• 生效日期；
• 到期日期；
• 稽核狀態；
• 稽核人；
• 關聯供應商；
• 是否關鍵資質。

報價物件也不只是金額：

• 物料；
• 數量；
• 單價；
• 有效期；
• 歷史均價偏差；
• 是否包含運輸和售後；
• 關聯採購申請。

關係同樣重要：供應商有多份資質、多次報價、多張訂單、多條交付記錄和多個質量問題。風險記錄要能反向指向這些證據。

這一步生成得好，後面的 AI 分析才不是“模型猜測”，而是“基於物件關係的解釋”。

第三步：生成檢視，讓不同角色看到不同工作

企業應用不是給所有人看同一張表。

AI Builder 應該根據角色生成初始檢視：

角色	檢視
採購專員	我的供應商、待補資質、報價對比
採購經理	高風險供應商、待審批採購、關鍵物料風險
質量負責人	最近質量問題、重複缺陷、整改狀態
法務/合規	資質缺口、合同條款風險、供應商黑名單
管理層	風險分佈、供應商集中度、採購決策趨勢

這一步很像低程式碼平臺裡的檢視配置，但 AI Builder 的價值在於：它能從業務需求裡先生成一套合理起點。

使用者不需要從空白畫布開始。

第四步：生成許可權和動作邊界

許可權是 AI Builder 最容易被忽略、但最能區分專業度的地方。

在這個供應商應用裡，至少要生成幾類邊界：

• 採購可以維護供應商檔案，但不能直接修改質量結論；
• 質量負責人可以關閉質量問題，但不能審批採購訂單；
• 採購經理可以審批高風險採購；
• 普通使用者不能檢視供應商敏感財務資訊；
• AI 可以生成風險建議，但不能自動把供應商拉黑；
• 關鍵物料採購的高風險動作必須審批。

這些不是頁面互動細節，而是執行時規則。

如果 Agent 後續能“幫我找出高風險供應商並暫停採購”，它必須先經過這些動作邊界。否則 AI Builder 生成得越多，風險越大。

第五步：生成流程、自動化和 SLA

業務物件靜態存在還不夠。應用要能推動事情流轉。

這個例子裡的流程可能包括：

1. 新供應商建檔；
2. 上傳資質；
3. AI 檢查資質完整性；
4. 報價進入比價；
5. 採購訂單生成；
6. 交付記錄回寫；
7. AI 識別風險；
8. 高風險進入審批；
9. 整改或替代供應商建議；
10. 風險關閉並留痕。

自動化也應該從需求中生成：

• 資質到期前 30 天提醒；
• 關鍵資質過期時阻止新採購；
• 交付準時率低於閾值時生成風險；
• 同類質量問題重複出現時建立複審任務；
• 高風險審批超時提醒採購經理。

這才是“生成應用”，而不是“生成頁面”。

第六步：生成 Agent 工具，並解釋它能做什麼

AI 原生應用的最後一層，是 Agent 工具。

平臺應該生成受控工具，而不是讓模型直接訪問資料庫。例如：

• 查詢供應商風險；
• 比較報價；
• 解釋風險來源；
• 建立複審任務；
• 發起高風險採購審批；
• 生成供應商月度風險報告。

每個工具都要有輸入、輸出、許可權和審計。

當用戶問：

這個供應商還能不能下單？

Agent 應該先查供應商、資質、交付、質量和報價，再給出結論和證據。它可以建議“降低首批採購量”或“要求補充資質”，但真正暫停採購或發起審批，要走平臺動作。

好的 Builder 會展示“生成計劃”

從讀者角度看，AI Builder 最需要建立信任。

所以它不應該靜默生成一切，而應該展示生成計劃：

• 將建立哪些物件；
• 每個物件有哪些關鍵欄位；
• 物件之間有哪些關係；
• 將生成哪些檢視；
• 哪些許可權規則會生效；
• 哪些自動化會執行；
• Agent 可以呼叫哪些工具；
• 哪些動作需要人工確認。

使用者確認後再生成應用。這樣 AI Builder 不是黑盒，而是一個可以協作的應用架構師。

ObjectStack 的生成鏈路

ObjectStack 的 AI Builder 應該把自然語言轉成應用規格，再由規格驅動執行時。

這條鏈路是：

自然語言需求 → 業務物件 → 欄位關係 → 視圖表單 → 許可權邊界 → 流程自動化 → Agent 工具 → 審計執行時

這條鏈路越清楚，讀者越容易理解平臺差異。

一句話生成應用不是魔法。真正的價值，是平臺知道這句話應該落到哪一層後設資料，以及這些後設資料如何一起驅動一個可執行的業務系統。