審批
每個有分量的變更，都要等一個"同意"。
一筆超過 15% 的折扣批下來是什麼樣？流程停駐、訂單鎖定，財務在審批收件箱裡看到請求——記錄快照、誰在什麼時候做了什麼，一目瞭然；批准放行，駁回帶評論退回，超時自動升級。AI 剛提議的 schema 變更，走的也是這同一個佇列。
- 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）。
決策全程留痕
問了誰、誰答了、看到的是什麼快照、什麼時候——每次審批留下完整且不可變的軌跡，審計隨時可查。
審批收件箱
審批人真正用的那個介面
開源控制台自帶審批收件箱——不是郵件裡的一個連結，而是一個帶上下文、能直接決策的工作臺。
三個頁籤
"我的待辦"（等我批的）、"我提交的"（我發起的走到哪了）、"全部"（分頁總覽）——每行顯示流程、記錄、提交人、狀態與時間。
側欄裡帶上下文決策
點開任何一行：記錄快照、逐步操作時間線、批准/駁回按鈕和評論框——不用跳轉到別處找資訊。
撤回與退回修改
提交人可以撤回自己的請求；審批人可以退回修改而不是一駁了之——狀態色區分待辦、通過、駁回、撤回、退回。
為高頻審批人設計
j/k 上下移動、Enter 開啟、a/r 批准或駁回——處理一隊請求不需要碰滑鼠。
AI 治理閘門
審人的佇列，同樣審 AI
這就是讓 AI 編寫的軟體可治理的機制：Agent 提出的結構性變更不會直接上線——它們排隊。
結構性變更排隊
Agent 提議新物件、欄位、流程或許可權變更時，變更以緊湊 diff 的形式落入同一個審批收件箱。
diff 就是請求本身
審閱者看到的正是將要發生的變化——schema、許可權、自動化——而不是一段轉述。
敏感動作也設閘
執行時動作同樣可以要求籤核，AI 觸發的退款或批次更新會停下來等人。
決策面
改什麼、誰來審、跑什麼
| 業務需求 | AI 編寫 | 執行時供給 |
|---|---|---|
| 15% 以上的折扣要過財務 | 變更上的一個審批步驟 | 路由、收件箱、鎖定、決策記錄 |
| 大額退款需要兩級批准 | 一條多級審批鏈 | 按序籤核，帶升級與退回修改 |
| 不讓流程卡死在一個收件箱 | 一個超時與升級路徑 | 自動升級與提醒 |
| AI 的 schema 變更必須有人審 | 提議的 diff 本身 | 部署之前的那道審批佇列 |
評審清單
審批評審應確認
- 每個高影響動作都寫明瞭自己的審批路徑。
- 路由基於角色與層級，而不是寫死的人名。
- 每一步都定義了超時與升級。
- 決策未定時記錄被鎖定。
- AI 提議的結構性變更無法繞過佇列。
FAQ
這一頁應該回答的問題
審批是獨立於流程的另一套系統嗎？
不是——審批是流程裡的一個持久步驟。整個過程只有一個執行模型：流程暫停，人來決定，流程繼續。
審批收件箱在開源版裡嗎？
在。三頁簽收件箱、側欄時間線、評論、撤回與退回修改、鍵盤快捷鍵，連同多級審批、審批人解析、升級、記錄鎖定與審計軌跡，都是開源版的一部分。
下一步