摘要：操作记录回答“谁做了什么”，增强审计还要回答“为什么能做、影响了什么、是否符合预期”。
为什么这个问题值得单独写
放学系统通常都会保存操作记录，但操作记录不等于审计。记录一行“某教师点击开始放学”只能证明动作发生过，不能说明该教师是否有权限、当时任务状态是什么、触发了哪些通知和展示。
这类问题的麻烦之处在于，它通常不会在演示环境里暴露。演示只要一个班、一个按钮、一个屏幕就能跑通;真实学校会出现多批次、多角色、多校门、多终端、设备离线、家长通知失败和人工重置。技术架构如果没有提前留出边界，后续每增加一种学校规则，就会变成一次临时补丁。
设计原则
增强审计建议围绕命令全链路保存：请求来源、操作者、权限判断、状态前后值、幂等结果、副作用事件、失败原因和人工备注。这样才便于复盘现场争议和排查问题。
对校园放学系统来说，架构设计首先要尊重现场流程：老师需要快，门岗需要确定，家长需要可理解，管理者需要可复盘。系统不应为了技术模型漂亮而增加现场负担，也不能为了短期上线把责任边界写得含糊。
模型拆分
审计数据不应成为普通业务人员随意修改的备注。它可以被查询、归档和脱敏导出，但修改应受到更严格限制。
这一步最容易被忽略。很多系统不是没有表，也不是没有接口，而是核心概念没有拆清楚。只要核心概念混在一起，后面就会出现页面字段越来越多、接口参数越来越长、设备接入越来越难测的问题。
数据与接口示意
操作记录适合给学校日常查看;增强审计适合项目验收、问题排查和合规复核。两者面向不同读者，字段和展示方式也不同。
示意结构里的字段不要求照搬。真正落地时，更重要的是确认字段背后的责任：谁创建，谁修改，谁消费，谁能看到，出了错谁来复核。字段的业务解释比字段名本身更重要。
异常与失败路径
失败场景包括只记录成功操作、不记录失败授权、无法关联通知失败、手动重置没有原因。增强审计的价值往往在异常时体现。
放学系统不适合只设计成功路径。现场人员最需要系统帮忙的时候，往往就是网络不稳、设备不在线、家长没到、重复点击或人工误操作的时候。异常路径如果没有进入主流程，就会退回到微信群、口头交接和纸面登记。
分阶段落地方式
第一阶段建议先做流程澄清，不急着把所有终端和设备一次性接入。以“任务是否能生成、状态是否能被授权角色推进、异常是否能被记录”为最低闭环，先让学校确认这套模型能解释真实放学流程。这个阶段的价值，是把讨论从“买哪个设备”拉回“现场到底怎么协同”。
第二阶段再接入展示和通知。大屏、语音、家长通知、小程序消息等能力都应消费核心事件，而不是重新计算状态。这样做的好处是，当通知渠道失败或大屏离线时，核心任务仍然可用，现场人员也能知道问题发生在输出层，而不是业务本身。
第三阶段才适合考虑设备联动、跨校区汇总、增强审计或更复杂的离线补传。复杂能力越靠后，越需要前两阶段留下清晰的任务模型、权限模型和事件记录。否则后续每一次扩展都会变成补丁叠补丁。
架构评审问题
●这个设计里，操作记录与增强审计不是同一个概念对应的业务事实由哪一层负责写入?
●如果现场网络、设备或通知渠道失败，流程是否还能给出可执行结果?
●如果同一动作被重复提交，系统如何判断是重试、并发还是冲突?
●如果学校规则下个月变化，是否只改配置或适配层，而不是改核心流程?
●这个设计在试点验收时，学校、教师、门岗和技术实施方分别需要看到哪些证据?
测试与验收建议
测试应覆盖失败命令、权限拒绝、重复请求、状态冲突、通知失败、人工补录和重置原因。
验收不要只看页面是否美观，也不要只看接口是否返回成功。更好的办法是构造完整场景：任务生成、权限校验、状态迁移、设备事件、通知、大屏、语音、日志和日终复盘都跑一遍。只要其中任何一环说不清，系统就还没有真正进入可运营状态。
一个比较实用的验收方式，是把“正常路径、重复路径、失败路径、恢复路径”写成四组用例。正常路径证明功能可用，重复路径证明幂等和状态机可靠，失败路径证明异常可见，恢复路径证明系统不是一次性演示工具。对于学校项目来说，能恢复、能解释、能复盘，往往比单次成功更重要。
写在最后
校园放学系统看起来是一个垂直场景，但它背后包含领域建模、权限、状态机、消息、设备、部署、测试和可观测性。把这些问题拆开写，不是为了把系统讲复杂，而是为了让学校和集成伙伴知道：可视化放学不是堆硬件，也不是多发通知，而是一套需要持续治理的现场协同系统。
相关阅读：接口幂等、日志验收、权限模型。