企业官网建设流程全解析

你有没有好奇过，一个差旅申请是怎么从"只是个想法"一步步走到"可以执行"的？Yozu 状态机就是这套流程的引擎。它用7 种审批状态，驱动每一个差旅工单（TripCase）从草稿审阅稳稳走向最终交接。这篇文章用大白话带你看懂：状态有哪些、怎么流转、又被哪些"守卫"拦住了脚步。

💡 适合人群：第一次接触 Yozu、想了解审批流程是怎么被代码"管起来"的同学。不需要会写代码也能看懂。

先认识主角：一张会"变身"的差旅工单

在 Yozu 里，每一次差旅需求都被打包成一个工单对象TripCase。你可以把它想象成一张会自己变身的"进度卡"，它身上同时挂着两个状态标签：

• 工作流状态CaseState：给人看的粗粒度阶段（新工单、审阅中、待审批……）
• 审批状态ApprovalState：真正驱动流转的细粒度引擎（草稿审阅、选项就绪、已批准……）

所有状态的"字典"都定义在 app/lib/ops.ts 里，这是整个 Yozu 状态机的心脏。

7 种审批状态：一张全景表

审批状态是 Yozu 状态机的核心。下面这 7 种状态，正好覆盖了一张差旅工单从"草稿"到"交接"的完整生命周期：

状态转移地图：谁能让谁"接棒"

Yozu 不允许工单"乱跳"。每一种状态能去哪些下一站，被一张转移表写死，逻辑在 状态转移表定义（app/lib/ops.ts#L306-L314）：

看出来了吗？正常路径是一条单行道：

draft_review → options_prepared → approval_requested → approval_granted → ready_for_handoff

而approval_blocked和returned_to_review是两条"岔路"，专门用来处理审批不顺的情况。

三层守卫：为什么你不能"抄近道"

光有转移表还不够。Yozu 用三层守卫（Guard），在任何一步都可能把动作拦下来并记录原因。

守卫一：审批转移守卫

函数getApprovalTransitionGuardReason（审批守卫逻辑（app/lib/ops.ts#L320-L334））负责盯住每一次状态跳转：

• 想跳到ready_for_handoff，但你不在approval_granted？→ 拦下："必须先有明确批准才能交接。"
• 转移本身不被允许？→ 拦下："从 X 到 Y 不合法。"
• 想原地不动？→ 提示"工单已经在这个状态了"。

守卫二：预检守卫 Preflight

"预检"（preflight）是交接前的最后体检，但它有个硬性前提——必须先拿到批准。getPreflightGuardReason（预检守卫（app/lib/ops.ts#L432-L438））规定：只有工单处于approval_granted或ready_for_handoff时，才允许跑预检，否则直接提示"预检只能在明确批准后运行"。

守卫三：交接守卫 Handoff

这是最严格的一道闸。getHandoffGuardReason（交接守卫（app/lib/ops.ts#L440-L466））会按顺序检查四件事，任何一条不过都放行不了：

1. 批准了吗？没拿到明确批准 → 拦
2. 跑预检了吗？还没跑 → 拦
3. 预检过线了吗？结果是blocked或reconfirm_required→ 拦
4. 披露确认了吗？没点"确认披露" → 拦

四条全绿，工单才能真正走进受控交接。

一次完整旅程：从草稿到交接

把上面的状态串起来，一个差旅工单的一生大概是这样的：

1. 📝 工单诞生 →draft_review（草稿审阅）
2. 🧩 操作员组装好可决策的选项 →options_prepared
3. ✋ 正式提交审批 →approval_requested
4. 这里分岔：
   • ✅ 批准通过 →approval_granted
   • ⛔ 资料不全被卡住 →approval_blocked（解除后重来）
   • 🔙 审批人退回 →returned_to_review→ 回到options_prepared修订
5. 🔍 批准后跑预检（pass / warn / blocked / reconfirm_required）
6. 🔓 预检过关 + 披露确认 → 解锁ready_for_handoff

这条旅程的每一步，都被上面三层守卫盯着，保证没有"未批准先执行"的漏洞。

联动彩蛋：工作流状态怎么跟着变

前面说过工单身上挂着两个状态标签。审批状态一变，工作流状态会自动跟着换，映射规则在 联动映射（app/lib/ops.ts#L336-L353）：

这样用户看到的"待审批""协同中"等粗粒度标签，其实都是细粒度审批状态自动投影出来的。

谁改了什么：审计事件链

每一次状态变化，Yozu 都会写下一条审计事件（AuditEvent）：谁、在哪个请求下、把状态从 A 改成 B、为什么。这套"事件链"持久化在 app/lib/case-store.ts，在工单详情页能直接回放（app/ops/cases/[id]/case-detail-client.tsx），后端守卫逻辑则集中在 app/api/cases/[id]/route.ts。

被拦截的动作也不会"悄悄失败"——系统会记下类似approval_transition_denied、handoff_guard_denied这类事件，让每一次拦截都有据可查。

一句话总结

Yozu 状态机的精髓，不是"状态多"，而是每一步都被规则锁死：7 种审批状态画好了单行道，三层守卫设好了检查站，审计事件又给整个过程盖上了时间戳。正是这套设计，让一张差旅工单从草稿走向交接时，永远不会出现"没批准就先执行"的灰色地带。