對話式應用迭代：加欄位、改流程、生成檢視和自動化
AI Builder 的真正價值不是“聊一句就改”，而是把欄位、流程、檢視、許可權和自動化都落到可審查、可回滾的後設資料層。
先給結論：對話式改系統真正的價值，不是“聊一句就改”，而是每次加欄位、改流程、調許可權都落到可審查、可回滾的後設資料層——改得快，還改得安全。
業務系統上線以後，真正的工作才開始。
客服主管想加欄位，銷售總監想改階段，財務想加審批，法務想調風險規則，運營想多一個看板，IT 想收緊許可權。傳統軟體開發裡，這些都是需求單，要排期、評估、開發、測試、上線。
AI Builder 最值得期待的地方，是讓其中一大部分變化從“提需求”變成“對話修改”。
但這裡必須說清楚：對話式修改不是讓 AI 隨便改系統，而是讓自然語言生成一份可解釋、可確認、可回滾的後設資料變更計劃。
讀者會擔心什麼
站在低程式碼平臺使用者的角度，“用對話改應用”聽起來很方便，也很危險。
他們會自然擔心：
- AI 會不會改錯物件；
- 加欄位會不會影響已有表單；
- 改流程會不會影響正在審批的單據；
- 許可權變化會不會造成資料洩露；
- 自動化會不會發錯通知；
- Agent 會不會執行越權動作；
- 改完以後能不能回滾。
所以一篇講 AI Builder 的文章，不能只說“用一句話修改應用”。真正要講的是：平臺如何把一句話變成受控變更。
第一類修改：加欄位
使用者說：
給客戶增加一個“續約風險”欄位，選項是低、中、高；高風險客戶要顯示在客戶成功經理的看板裡。
專業的 AI Builder 不應該直接執行，而應該生成變更計劃：
| 變更項 | 計劃 |
|---|---|
| 物件 | 修改 customer |
| 欄位 | 新增列舉欄位 renewal_risk |
| 表單 | 在客戶詳情和編輯頁展示 |
| 檢視 | 新增“高風險續約客戶”看板 |
| 許可權 | 客戶成功經理可編輯，銷售只讀 |
| 自動化 | 高風險變化時提醒負責人 |
| Agent | 客戶摘要允許引用該欄位 |
使用者確認後，平臺再修改後設資料。
這和普通“加一列”的差別在於：欄位進入了整個應用執行時，而不是隻進入資料庫。
第二類修改：改流程
使用者說：
報銷金額超過 3000 元時，先直屬主管審批，再財務經理審批；如果關聯專案預算不足，還要預算負責人確認。
這句話涉及條件、審批節點、狀態、通知、異常和審計。
Builder 應該生成：
- 金額條件；
- 主管審批節點；
- 財務經理審批節點；
- 預算不足判斷；
- 預算負責人節點；
- 駁回和補充材料路徑；
- 審批意見和時間戳審計。
同時，它應該提示影響範圍：這個流程隻影響新提交的報銷，還是也影響已在審批中的報銷？如果影響存量流程，是否需要遷移？
這是低程式碼平臺裡非常關鍵的專業細節。流程不是畫出來就結束，它還和執行中的例項有關。
第三類修改：生成檢視
檢視是最適合對話式生成的能力之一，因為使用者往往知道自己想看什麼，卻不知道如何配置篩選和排序。
使用者說：
給專案經理生成一個“本週高風險專案”檢視，按預計延期天數排序，只顯示我負責的專案。
平臺應該生成：
- 物件：專案；
- 篩選：風險等級為高，且預計影響本週里程碑；
- 許可權：只看當前使用者負責或參與的專案；
- 排序：預計延期天數降序；
- 欄位：專案名、負責人、里程碑、風險原因、下一步動作；
- 展示：列表或看板。
好的 Builder 還應該允許使用者繼續追問：
再加一列“最近一次會議結論”。
這時它不是重建頁面，而是修改檢視後設資料。
第四類修改：調整許可權
許可權是對話式修改裡最需要謹慎的部分。
使用者說：
銷售只能看自己負責的客戶，區域經理可以看本區域客戶，老闆可以看全部客戶。
這句話看起來清楚，但平臺必須生成並展示許可權矩陣：
| 角色 | 記錄範圍 | 欄位範圍 | 可執行動作 |
|---|---|---|---|
| 銷售 | 自己負責的客戶 | 隱藏成本、合同敏感條款 | 建立跟進、更新活動 |
| 區域經理 | 本區域客戶 | 可看彙總金額 | 分配負責人、檢視風險 |
| 管理層 | 全部客戶 | 可看彙總，不一定能改 | 檢視報表、匯出需審批 |
同時，Agent 查詢也必須繼承這套許可權。銷售問“所有高風險客戶有哪些”，系統只能返回他有權看的客戶。
AI 可以幫助配置許可權，但不能讓許可權配置變得輕率。
第五類修改：建立自動化和 Agent 動作
使用者說：
每週一上午，把高風險客戶彙總給客戶成功經理，並給負責人建立跟進任務。
平臺應該拆成：
- 定時觸發；
- 查詢高風險客戶；
- 按負責人分組；
- 生成內部摘要；
- 建立跟進任務；
- 記錄自動化執行日誌；
- 失敗時提醒管理員。
還要判斷動作風險：
- 內部摘要：低風險；
- 建立任務：中低風險；
- 修改客戶風險等級：中風險，需要確認；
- 給客戶發郵件：高風險，需要審批或人工傳送。
對話式自動化的關鍵不是“自動做更多事”，而是“把可自動化和必須確認的動作分清楚”。
好的對話式修改應該有 4 個產品細節
第一，展示變更計劃。使用者應該知道平臺準備改哪些物件、欄位、檢視、流程、許可權和自動化。
第二，展示影響範圍。尤其是許可權、流程和自動化，要說明影響哪些角色、哪些資料、哪些執行中例項。
第三，支援預覽和回滾。修改前能預覽，修改後能回滾到上一個版本。
第四，留下審計。誰提出修改，AI 如何解釋，人是否確認，系統最終改了什麼，都應該有記錄。
沒有這四點，“對話改應用”會變成一個危險的黑盒。
ObjectStack 的價值
ObjectStack 適合做對話式應用迭代，是因為它把應用結構放在後設資料層。
欄位、檢視、流程、許可權、自動化和 Agent 工具不是散落在程式碼裡，而是可以被生成、解釋、修改、版本化和審計的業務結構。
業務人員用自然語言說出變化，平臺生成變更計劃；管理員或業務 owner 確認後，執行時按新後設資料工作；Agent 也繼承同樣的物件、許可權和動作邊界。
這就是用對話改業務系統的關鍵：不是讓 AI 幫你臨時改一個功能，而是讓業務系統具備持續被業務語言塑造的能力，同時仍然保持低程式碼平臺應有的治理能力。