用 AI Agent 搭建小型 OA，聊聊 B 端审批工作流、角色权限如何设计

本文是我用 AI-Agent 做一个轻量化 OA 项目后的思考总结，少贴代码，多聊 B 端业务设计。

一、引言

中小企业的办公协同其实有很多"不大但很烦"的事：请假要发微信等领导回、审批进度全靠催、公告发群里很快被刷走、谁批了什么也没有记录。它们用不上动辄几十万的大型 OA，但又确实需要一个能把审批和公告线上化、留痕化的轻量工具。

我最近基于扣子（Coze）AI-Agent 做了一个简易 OA，核心就是解决这几件事：员工管理、角色权限、以请假为核心的审批流转、公告发布。这篇文章不打算讲怎么调 API、怎么写页面，而是想聊清楚两个 B 端最核心、也是 AI 最容易帮倒忙的问题：审批工作流怎么设计、角色权限怎么画边界。

需要先说清楚：AI 在这个项目里是效率工具，帮我快速产出基础的增删改查和页面逻辑，但权限设计、状态流转这些业务规则的确定和校验，都是我自己盯的。它不是一键生成一个完整项目，真正让系统"能用且不出错"的部分，恰恰是在 AI 生成之后我反复调试出来的。

二、OA 核心业务拆解

2.1 请假申请的完整流转逻辑

我先以"请假"这一条主线把流程捋顺，因为它最能代表 B 端审批的共性：

1. 员工发起：填写请假类型、起止时间、天数、事由，提交后单据进入"待审批"状态；
2. 主管审批：本部门主管在待办里看到这张单子，可以同意或驳回；
3. 驳回要给理由：驳回不是点一下就完，必须填写驳回原因，员工要知道为什么没通过；
4. 结果通知员工：审批完成后，员工收到通知，能在"我的申请"里查到最终状态和意见；
5. 状态锁定：一旦同意或驳回，这张单子就进入终态，不能再被反复修改、重复审批。

这里我专门抽象了一个状态机：草稿 → 待审批 → 已同意 / 已驳回。关键不是有哪些状态，而是哪些状态之间允许流转。比如"已同意"绝不能再变回"待审批"，“已驳回"也不能被偷偷改成"已同意”。这个约束如果没在后端写死，系统就是不可信的。

2.2 两种（三类）角色的权限边界

系统里有三个角色：普通员工、部门主管、超级管理员。权限设计的核心原则是最小权限——每个人只能看到他该看的、做他该做的。

能力	普通员工	部门主管	超级管理员
发起请假/查看自己的单据	✅	✅	✅
审批本部门单据	❌	✅	✅
查看本部门员工数据	❌	✅	✅
发布部门公告	❌	✅	✅
管理员工账号	❌	仅本部门普通员工	全部
系统全局配置/审计/备份	❌	❌	✅

我在画边界时特别注意了几个点：

• 主管不是缩小版管理员：主管只能管本部门、且只能管普通员工，不能创建主管账号、不能改全局配置；
• 管理员也不能凌驾流程之上为所欲为：比如审批人不能审批自己提的单子，这条对所有角色都生效；
• 数据有权属：员工只能查自己的请假单和考勤，主管只能查本部门的，这就是所谓的数据权限，和"功能权限"同等重要。

2.3 哪些数据员工可读，哪些操作仅限管理员

我把"看"和"做"分开梳理：

• 员工可读：本人的申请记录、本人考勤、全员公告、本部门公告、知识库制度、自己收发的站内消息；
• 主管可读（本部门范围）：本部门全部申请记录、本部门考勤报表、下属工作日志；
• 仅管理员可操作：部门增删改、用户角色与账号管理、审批流程配置、全局公告发布、审计日志查看、数据库备份恢复、全局统计报表。

把这张"谁能对什么数据做什么操作"的矩阵画清楚，是整个系统的地基。后面 AI 写出来的每一个接口，我都是拿这张表去对的。

三、用 AI Agent 开发 B 端业务的高频踩坑点

这一部分是干货。AI Agent 生成 B 端代码时，有几个非常高频的毛病，几乎是"本能"会犯的。

3.1 只在前端藏按钮，不在后端拦接口

这是最常见、也最危险的问题。AI 实现"权限"时，第一反应往往是：如果是管理员，就显示"删除"按钮；如果是普通员工，就把按钮隐藏掉。

但隐藏按钮不等于没有这个能力。我用普通员工登录后，直接构造一个请求去调管理员接口，发现请求竟然成功执行了——因为后端压根没校验角色。这在安全上是完全不及格的。

我最后的做法是：所有敏感接口在服务端入口统一做角色校验，前端是否显示按钮只是体验层面的优化。权限判断必须以后端为准。

3.2 忽略水平越权（张三能看李四的数据）

除了"员工能不能干管理员的事"（垂直越权），还有一类更隐蔽：员工 A 通过改请求里的单据 ID，能不能查到员工 B 的请假单？AI 第一版是能的，因为它只判断了"你登录了"，没判断"这条数据归不归你"。

修法是：凡是带数据 ID 的查询/操作接口，都要校验这条数据的归属——要么是本人的，要么是你本部门的，要么你是管理员，三者满足其一才放行。

3.3 状态机缺失，终态可被反复改写

前面提到过，AI 写审批接口时很"实在"：你传"同意"我就改成同意，你传"驳回"我就改成驳回，完全不管这张单子当前是什么状态。结果就是已通过的单子还能被驳回、已驳回的能被改回通过。

我加的约束是：只有"待审批"的单子才允许执行审批动作，进入终态后接口直接拒绝。每次状态变更都要先查当前状态、再判断是否合法、最后才更新，并且记录是谁在什么时候做了什么操作。

3.4 只完成"点"，没串成"线"

AI 很擅长把单个功能写出来，但不擅长主动补业务闭环。比如它写了审批接口，但审批完不通知申请人；它做了驳回按钮，但驳回不强制填理由；首页有个"待办红点"，但统计口径和待办列表对不上。

这些问题单独看都不报错，但流程是断的。我最后是靠自己扮演不同角色、端到端走完整条业务线才把这些"缝"一个个补上。

小结：AI 能很快给你一个"看起来能用"的系统，但 B 端真正的难点——权限拦截、状态机、业务闭环——它都倾向于忽略。这也是为什么我一直强调：AI 负责产出，人必须负责校验。如果你自己不懂这些业务规则，你根本验收不出它的问题。

四、业务流程文字说明

以"请假审批"为例，完整的业务流程如下：

1. 员工登录系统，进入"发起审批 → 请假申请"；
2. 填写请假类型（事假/病假/年假等）、开始时间、结束时间、天数、请假事由，可暂存为草稿或直接提交；
3. 提交后，单据状态变为"待审批"，系统自动将其送入该员工所属部门主管的待办列表；
4. 部门主管登录后在"审批工作台"看到待办，点开单据详情查看内容；
5. 主管选择"同意"或"驳回"：选择驳回时必须填写驳回理由；
6. 系统校验该单据当前确为"待审批"状态、且审批人与申请人不是同一人后，更新状态为"已同意"或"已驳回"，并写入审批记录（操作人、时间、意见）；
7. 系统自动向申请人发送站内消息，告知审批结果；
8. 员工在"我的申请"中查看单据状态：通过则显示"已同意"及审批意见，驳回则显示"已驳回"和具体驳回理由，可据此修改后重新提交；
9. 已进入终态的单据不允许再被审批或修改，作为历史记录永久留痕。

五、项目收获与感悟

做完这个项目，我最大的感悟是：B 端系统里，业务逻辑的严谨性，优先级永远高于"快速实现"。

C 端产品追求体验和转化，偶尔一个小瑕疵影响有限；但 B 端系统处理的是审批、权限、钱、数据留痕，一个状态流转错误、一个权限漏洞，后果可能是审批被绕过、数据被越权查看、责任无法追溯。这种地方"快"没有意义，"对"才是第一位的。

关于 AI-Agent，我的看法也更理性了：

• 它是非常强的效率工具，能把我从大量重复的 CRUD 和页面搭建里解放出来；
• 但它对业务规则没有"责任感"，会默认走最省事儿的实现路径，恰恰绕开 B 端最该严谨的地方；
• 业务校验工作必须由人完成——权限矩阵要自己画、状态机要自己定、端到端流程要自己走、越权和异常路径要自己测。

换句话说，AI 放大的是"会做业务的人"的效率，而不是替代业务判断。你越懂业务，它越好用；你不懂业务，它给你的就是一个埋着雷的花架子。

六、后续迭代优化方向

当前版本是一个 MVP（最小可用版本），已经能跑通核心闭环，但离真实生产环境还有距离。我规划的优化方向有：

1. 多级审批：目前是员工 → 直属主管一级审批，后续要支持按金额/天数分级，比如请假超过 3 天需要主管审批后再流向上级；
2. 消息通知强化：现在是站内消息，后续接入邮件/企业微信/钉钉提醒，避免漏看；
3. 数据统计看板：增加请假趋势、部门出勤率、审批时效等可视化报表，给管理决策提供数据支撑；
4. 更细的权限配置：把角色权限从代码里的硬编码，做成后台可配置；
5. 附件与流程留痕增强：报销附件、审批流转历史的完整追溯。

---

这个项目我会作为实习求职作品持续迭代。它的技术栈并不花哨，但我希望它能体现一种 B 端思维：先想清楚规则，再写代码；AI 帮我写，但对不对由我负责。 如果你也在用 AI 做 B 端项目，欢迎一起交流踩坑经验。