审批
每个有分量的变更，都要等一个"同意"。
一笔超过 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
这一页应该回答的问题
审批是独立于流程的另一套系统吗？
不是——审批是流程里的一个持久步骤。整个过程只有一个执行模型：流程暂停，人来决定，流程继续。
审批收件箱在开源版里吗？
在。三页签收件箱、侧栏时间线、评论、撤回与退回修改、键盘快捷键，连同多级审批、审批人解析、升级、记录锁定与审计轨迹，都是开源版的一部分。
下一步