審批流程

在實踐中

審批流程遠早於工作流軟體——採購申請、變更評審委員會、授信委員會、藥物試驗放行，編碼的都是同一個模式。有三個性質把真正的審批流程與「看起來像審批的通知」區分開來。變更必須在請求待決期間真的被擋住，而不是一封郵件躺在收件箱裡沒人讀、事情照樣往前走。決定必須可歸屬到一個在做決定的那一刻確實持有該權限的人，而不是歸屬到一個共享郵箱。以及路由必須對著組織解析，而不是對著人名——綁死在具體人身上的審批鏈，會在下一次組織調整時悄悄斷掉，然後路由給一個已經離職的人。三條一條都不滿足的，是一個帶延遲的通知。

在 ObjectStack 裡，審批不是一個獨立系統，而是流程裡的一個持久節點：執行到達審批節點，開出一個請求，掛起，等一條決定被記錄下來之後，再沿它的 approve 或 reject 出邊恢復。審批人可以宣告為某個使用者、某個角色、某個團隊，或申請人的上級鏈，並在請求發起時對著即時身份解析——一個崗位會展開成當前持有它的人。每一步設定自己的行為，於是一個節點可以是「首個響應即生效」，下一個是「必須全票」；lockRecord 讓記錄在待決期間保持不動，沒人能越過審閱者去改；maxRevisions 給退回修改的迴圈設上界，一個請求不會在「請修改」裡永遠打轉；onEmptyApprovers 決定審批人名單解析為空時怎麼辦，預設交給管理員接管，而不是悄悄把記錄放行。決定會在執行繼續之前先寫進審計賬本，於是不存在任何一條「沒有記錄決定就越過審批」的路徑。這也是 AI 提出的結構性變更所進入的同一個佇列——那份 diff 本身就是請求——正是這一點，讓 Agent 寫出來的軟體變成一個人可以簽字的東西，而不是事後才發現的東西。

對任何審批引擎都值得追問的是：它的截止時間住在哪裡？在這裡，誠實的答案是範圍很窄。流程裡的 wait 節點完全沒有超時：曾經有兩個鍵聲稱有，兩個都被退役了，而不是留著當一句執行時並不兌現的承諾。升級只存在於審批節點上，而且是逐節點的 SLA，不是一個全域定時服務。設定 timeoutHours，一次掃描會找出自建立起超過該小時數仍處於待決的請求並逐個升級，每個請求一生只升級一次，執行配置的 action——notify、reassign、auto_approve 或 auto_reject——escalateTo 指向一個使用者或一個會展開成當前持有者的崗位，而升級的審計行先寫，於是崩潰或重跑的掃描不會重複觸發。由此得到的設計結論值得直說：如果某一步必須有時限，就把它建模成一個帶 SLA 的審批，或者從流程外部驅動那個截止時間。一個光禿禿的 wait 會耐心地、正確地、永遠等下去。