【免费下载链接】yozu-webYozu web app scaffold for an AI travel decision and execution layer: landing, demo flow, source-backed trip options, approval-gated coordination, and preflight checks.项目地址https://gitcode.com/gh_mirrors/yo/yozu-web点击查看免费下载你有没有好奇过一个差旅申请是怎么从只是个想法一步步走到可以执行的Yozu 状态机就是这套流程的引擎。它用7 种审批状态驱动每一个差旅工单TripCase从草稿审阅稳稳走向最终交接。这篇文章用大白话带你看懂状态有哪些、怎么流转、又被哪些守卫拦住了脚步。 适合人群第一次接触 Yozu、想了解审批流程是怎么被代码管起来的同学。不需要会写代码也能看懂。先认识主角一张会变身的差旅工单在 Yozu 里每一次差旅需求都被打包成一个工单对象TripCase。你可以把它想象成一张会自己变身的进度卡它身上同时挂着两个状态标签工作流状态CaseState给人看的粗粒度阶段新工单、审阅中、待审批……审批状态ApprovalState真正驱动流转的细粒度引擎草稿审阅、选项就绪、已批准……所有状态的字典都定义在 app/lib/ops.ts 里这是整个 Yozu 状态机的心脏。7 种审批状态一张全景表审批状态是 Yozu 状态机的核心。下面这 7 种状态正好覆盖了一张差旅工单从草稿到交接的完整生命周期#状态值界面显示它意味着什么1draft_reviewDraft review草稿审阅工单刚建好还在内部打磨2options_preparedOptions prepared决策就绪的选项已经准备妥当3approval_requestedApproval requested已正式向审批人发起审批4approval_blockedApproval blocked审批被卡住需先解除阻塞5approval_grantedApproval granted拿到明确批准解锁后续动作6returned_to_reviewReturned to review被退回需要重新修订选项7ready_for_handoffReady for handoff审批闭环准备进入受控交接状态转移地图谁能让谁接棒Yozu 不允许工单乱跳。每一种状态能去哪些下一站被一张转移表写死逻辑在 状态转移表定义app/lib/ops.ts#L306-L314当前状态可以流转到draft_reviewoptions_preparedoptions_preparedapproval_requestedapproval_requestedapproval_granted/approval_blocked/returned_to_reviewapproval_blocked死胡同必须先解除阻塞approval_grantedready_for_handoffreturned_to_reviewoptions_preparedready_for_handoff终点看出来了吗正常路径是一条单行道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会按顺序检查四件事任何一条不过都放行不了批准了吗没拿到明确批准 → 拦跑预检了吗还没跑 → 拦预检过线了吗结果是blocked或reconfirm_required→ 拦披露确认了吗没点确认披露 → 拦四条全绿工单才能真正走进受控交接。一次完整旅程从草稿到交接把上面的状态串起来一个差旅工单的一生大概是这样的 工单诞生 →draft_review草稿审阅 操作员组装好可决策的选项 →options_prepared✋ 正式提交审批 →approval_requested这里分岔✅ 批准通过 →approval_granted⛔ 资料不全被卡住 →approval_blocked解除后重来 审批人退回 →returned_to_review→ 回到options_prepared修订 批准后跑预检pass / warn / blocked / reconfirm_required 预检过关 披露确认 → 解锁ready_for_handoff这条旅程的每一步都被上面三层守卫盯着保证没有未批准先执行的漏洞。联动彩蛋工作流状态怎么跟着变前面说过工单身上挂着两个状态标签。审批状态一变工作流状态会自动跟着换映射规则在 联动映射app/lib/ops.ts#L336-L353审批状态联动出的工作流状态draft_review/returned_to_reviewreviewing审阅中options_preparedoptions_sent选项已发出approval_requested/approval_blocked/approval_grantedawaiting_approval待审批ready_for_handoffcoordinating协同交接中这样用户看到的待审批协同中等粗粒度标签其实都是细粒度审批状态自动投影出来的。谁改了什么审计事件链每一次状态变化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 种审批状态画好了单行道三层守卫设好了检查站审计事件又给整个过程盖上了时间戳。正是这套设计让一张差旅工单从草稿走向交接时永远不会出现没批准就先执行的灰色地带。赞分享【免费下载链接】yozu-webYozu web app scaffold for an AI travel decision and execution layer: landing, demo flow, source-backed trip options, approval-gated coordination, and preflight checks.项目地址https://gitcode.com/gh_mirrors/yo/yozu-web点击查看免费下载相关推荐揭秘Super Mario 64角色状态管理马里奥的7种核心状态完全指南揭秘Super Mario 64角色状态管理马里奥的7种核心状态完全指南 Super Mario 64作为3D平台游戏的里程碑其角色状态管理机制堪称游戏开发游戏开发逆向工程CacheCloud 工单审批完全指南十大工单类型、审批状态机与后端任务流实现解析CacheCloud 工单审批完全指南十大工单类型、审批状态机与后端任务流实现解析 导读 本文围绕 CacheCloud搜狐视频 Redis 私有云管理平后端运维EmbodiedScan FAQ终极答疑数据申请、许可证、版本更新等20个常见问题EmbodiedScan FAQ终极答疑数据申请、许可证、版本更新等20个常见问题 EmbodiedScan 是一个面向具身智能Embodied AI的多创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考