用 AI 辅助拆解一个学校业务需求

学校业务系统里的一个需求，表面上可能只是“新增一张表单”或“增加一个审批入口”，真正落地时却会牵涉用户、角色、字段、状态、流程、接口和工作台展示。

进入高校业务系统和低代码平台二次开发阶段后，我开始更频繁地用 AI 帮助整理需求。它可以把零散描述拆成检查清单，也可以提醒我关注遗漏的角色和异常路径，但业务规则最终仍然要和实际需求、平台能力及现有系统确认。

先弄清需求要解决什么

收到需求后，我不会立刻让 AI 生成页面或接口，而是先确认业务目标：

• 谁会发起这项业务；
• 为什么需要这项功能；
• 当前通过什么方式处理；
• 完成之后要形成什么结果；
• 哪些人可以查看、修改或审批；
• 哪些情况算作异常或退回。

如果业务目标还不清楚，后面的字段和流程设计很容易反复变化。

公开文章使用抽象业务场景，不涉及真实学校、部门、角色名称和内部制度。

把一句需求拆成几个对象

例如，“提交申请后进入审批，并在工作台查看进度”可以先拆成：

申请人
    -> 填写业务表单
    -> 提交申请
    -> 进入审批流程
    -> 更新业务状态
    -> 工作台显示待办或进度

这是一个通用需求模型，不代表某个内部系统的真实流程。实际项目中是否存在多级审批、抄送、撤回或转办，需要根据需求单独确认。

AI 可以帮助我从一句话中识别参与者、数据对象和状态，但不能根据常见模式自动补出真实审批节点。

字段设计要回到业务含义

表单字段不能只根据页面效果决定。每个字段都需要说明：

• 由谁填写；
• 是否必填；
• 数据类型和长度；
• 是否来自字典或其他系统；
• 哪些状态下允许修改；
• 是否需要在列表、详情和导出中显示；
• 是否包含敏感信息。

我可以把脱敏后的字段说明交给 AI，让它帮助整理字段表或检查类型是否矛盾。但字段含义、数据来源和权限必须由业务和系统实际情况确定。

这个表格是通用模板，不对应内部表单字段。

状态和流程要分开看

审批节点和业务状态有关，但并不完全相同。流程结束不一定代表业务立即完成，流程退回也可能对应“可修改后重新提交”而不是彻底结束。

流程动作
    + 当前业务状态
    + 操作人权限
    -> 允许执行的业务操作

拆解时可以分别列出：

• 业务状态有哪些；
• 每个状态从哪里进入；
• 哪些角色可以触发变化；
• 退回、撤回和驳回分别意味着什么；
• 流程状态如何同步到业务记录；
• 工作台展示依据哪个状态。

AI 可以帮助检查状态表是否存在缺口，但具体状态名称和转换条件不能凭空生成。

平台配置和代码扩展的边界

低代码平台通常能提供表单、数据模型、流程和权限等基础能力。需求拆解时，我还要判断哪些部分可以通过平台配置完成，哪些需要接口或代码扩展。

业务规则
    -> 平台现有能力
    -> 配置可覆盖部分
    -> 需要扩展的特殊逻辑
    -> 前后端联调和验证

判断依据不是“代码更灵活”或“配置更快”，而是规则是否稳定、平台能力是否满足、后续维护是否清晰。

我参与的是平台二次开发和部分独立技术开发，不能把这类扩展写成从零独立设计整套系统。

让 AI 帮助补充异常路径

正常流程通常容易描述，边界条件更容易遗漏。可以让 AI 根据脱敏后的需求，帮助列出待确认的问题：

• 重复提交如何处理；
• 草稿是否可以删除；
• 审批过程中字段能否修改；
• 角色变化后待办如何处理；
• 接口失败时页面保留什么状态；
• 移动端和 PC 端是否使用同一流程；
• 历史记录如何查询和追踪。

这些内容只是问题清单，不能直接写进需求结论。每一项都需要与业务人员、现有功能或需求材料确认。

形成可以验证的交付清单

拆解完成后，我希望得到的不是一段看起来完整的 AI 回答，而是一份可以逐项验证的清单：

业务目标
参与角色
字段与数据来源
状态和流程
页面与工作台入口
接口与权限
异常路径
验收条件
待确认问题

其中“待确认问题”不能为了文档完整而删除。没有证据或明确答复的内容，继续保留待确认状态比自行补全更可靠。

用 AI 辅助拆解学校业务需求，真正有价值的是把模糊描述转化为可以讨论和验证的问题。AI 可以帮助整理结构、补充检查角度和维护文档，但需求理解、技术选择和最终验收仍然需要由开发者结合真实业务完成。