審批
每個有分量的變更，都要等一個"同意"。
一筆超過 15% 的折扣批下來是什麼樣？流程停駐、訂單鎖定，財務在審批收件箱裡看到請求——記錄快照、誰在什麼時候做了什麼，一目瞭然；批准放行，駁回帶評論退回，超時自動升級。ObjectOS AI Builder 對已上線且已有記錄的應用所做的變更也要等：它先存為草稿，由人釋出後才生效。
- 4 種路由
- 指定使用者、角色、團隊或管理層級
- 鎖定
- 決策未定時，記錄保持原樣
- 留痕
- 每次請求、決定與升級都被審計
籤核即中繼資料
一屏就能審完的審批策略。
這就是那條折扣審批鏈：財務先審（一人響應即可），高管複核（須一致通過），全程鎖定記錄，最多兩輪退回修改。策略本身是一份任何人都讀得懂的緊湊定義。
import { defineFlow } from '@objectstack/spec';
export const DiscountApproval = defineFlow({
name: 'sales_discount_approval',
label: 'Discount Approval',
type: 'autolaunched',
nodes: [
{
id: 'start',
type: 'start',
label: 'On Large Discount',
config: {
objectName: 'sales_order',
triggerType: 'record-after-update',
condition: 'discount > 15 && discount != previous.discount',
},
},
{
id: 'finance_review',
type: 'approval',
label: 'Finance Review',
config: {
approvers: [{ type: 'role', value: 'finance' }],
behavior: 'first_response',
lockRecord: true,
maxRevisions: 2,
},
},
{
id: 'exec_review',
type: 'approval',
label: 'Executive Review',
config: {
approvers: [{ type: 'role', value: 'exec' }],
behavior: 'unanimous',
lockRecord: true,
},
},
{ id: 'approved', type: 'end', label: 'Approved' },
{ id: 'rejected', type: 'end', label: 'Rejected' },
],
edges: [
{ id: 'e1', source: 'start', target: 'finance_review' },
{ id: 'e2', source: 'finance_review', target: 'exec_review', label: 'approve' },
{ id: 'e3', source: 'finance_review', target: 'rejected', label: 'reject' },
{ id: 'e4', source: 'exec_review', target: 'approved', label: 'approve' },
{ id: 'e5', source: 'exec_review', target: 'rejected', label: 'reject' },
],
});審批模型
跟著這筆折扣走完兩級籤核
審批人的解析走與權限相同的身份模型，組織調整不會弄斷籤核鏈——下面每一步都寫在同一份定義裡。
兩級審批鏈
財務先審、高管複核，按序串聯在一個流程裡；財務是"一人響應即可"，高管是"須一致通過"——行為按步驟單獨設定。
審批人按組織解析
路由給 finance 角色、某個團隊，或沿申請人的管理層級向上——在請求發起那一刻按即時身份解析，人事變動不用改流程。
超時就升級
財務三天沒處理？請求自動升級並提醒——流程不會卡死在某一個收件箱裡。
記錄鎖定與退回
決策期間訂單保持原樣，誰也改不了；財務也可以"退回修改"——銷售改完折扣重新提交，最多兩輪（maxRevisions: 2）。
決策全程留痕
問了誰、誰答了、看到的是什麼快照、什麼時候——每次審批留下完整且不可變的軌跡，審計隨時可查。
審批收件箱
審批人真正用的那個介面
開源 ObjectStack 控制台自帶審批收件箱——不是郵件裡的一個連結，而是一個帶上下文、能直接決策的工作臺。
三個頁籤
"我的待辦"（等我批的）、"我提交的"（我發起的走到哪了）、"全部"（分頁總覽）——每行顯示流程、記錄、提交人、狀態與時間。
側欄裡帶上下文決策
點開任何一行：記錄快照、逐步操作時間線、批准/駁回按鈕和評論框——不用跳轉到別處找資訊。
撤回與退回修改
提交人可以撤回自己的請求；審批人可以退回修改而不是一駁了之——狀態色區分待辦、通過、駁回、撤回、退回。
為高頻審批人設計
j/k 上下移動、Enter 開啟、a/r 批准或駁回——處理一隊請求不需要碰滑鼠。
AI 治理閘門
應用有了資料，AI 改動就要等人
這就是在真實記錄依賴它之後，讓 AI 編寫的軟體保持可治理的機制：Agent 對已上線應用的改動不會自行生效——它要等人。在開源執行環境上，等的是你的 git diff；在 ObjectOS Cloud 上，等的是由人來發布的草稿。
已上線應用的改動存為草稿
在 ObjectOS Cloud 上，AI Builder 的首次搭建會直接釋出。應用上線並有了記錄之後，對其物件、欄位、動作或流程的改動改為存為草稿，由人釋出後才生效。
diff 就是請求本身
在開源執行環境上，編碼 Agent 的改動就是 git diff 裡的普通中繼資料，審閱者看到的正是將要發生的變化——schema、權限、自動化——而不是一段轉述，並像合併其他改動一樣合併它。
業務決定走審批節點
流程中的審批節點可以讓 AI 觸發的退款或批次更新停下來等人籤核，收件箱、鎖定和決策記錄與其他審批完全相同。
決策面
改什麼、誰來審、跑什麼
| 業務需求 | AI 編寫 | 執行環境供給 |
|---|---|---|
| 15% 以上的折扣要過財務 | 變更上的一個審批步驟 | 路由、收件箱、鎖定、決策記錄 |
| 大額退款需要兩級批准 | 一條多級審批鏈 | 按序籤核，帶升級與退回修改 |
| 不讓流程卡死在一個收件箱 | 一個超時與升級路徑 | 自動升級與提醒 |
| AI 對已上線應用的改動要有人把關 | 中繼資料改動本身 | ObjectOS Cloud 上由人釋出的草稿；開源執行環境上你的 git 審閱 |
評審清單
審批評審應確認
- 每個高影響動作都寫明瞭自己的審批路徑。
- 路由基於角色與層級，而不是寫死的人名。
- 每一步都定義了超時與升級。
- 決策未定時記錄被鎖定。
- AI 對已上線且已有記錄的應用所做的改動要等人——ObjectOS Cloud 上是待發布的草稿，開源執行環境上是 git diff。
FAQ
常見問題
審批是獨立於流程的另一套系統嗎？
不是——審批是流程裡的一個持久步驟。整個過程只有一個執行模型：流程暫停，人來決定，流程繼續。
這裡哪些是開源的，ObjectOS 又加了什麼？
多級審批、審批人解析、升級、記錄鎖定、審計軌跡，以及三頁簽收件箱連同側欄、評論、撤回、退回修改和鍵盤快捷鍵，都隨開源 ObjectStack Console 釋出，Apache-2.0。ObjectOS 加的是產品內 AI Builder（Enterprise 版為預覽版）。在 ObjectOS Cloud 上，它的首次搭建會直接釋出；對已上線且已有記錄的應用所做的變更存為草稿，由人來發布。上面那筆折扣這類業務決定，仍然走流程中的審批節點。
下一步