校园外卖系统专业性如何核对？用状态机区分通过与未执行

校园外卖系统的专业性需要由明确版本的正常流程与异常结果支撑。采购记录若把未执行写成通过，会让缺设备、缺授权的项目看起来已经完成。下面用验收证据状态机解释如何区分执行事实、结果未知和复验关闭，只处理采购评估中的一个工程问题。 本文只讨论校园采购中的具体工程核对项，不凭品牌行业范围判断产品专业性，示例设计与实际产品实现分别说明。

记录结构与约束

每条执行记录包含run_id、case_id、case_revision、system_version、campus_id、role_ref、execution_state、outcome与evidence_ref。run_id唯一，运行时绑定用例和系统版本，不允许直接换版本继承结果。业务订单引用与执行记录编号分开，重跑不是创建第二笔业务单。

状态为PLANNED、RUNNING、OBSERVED、REVIEWED；outcome为PASS、FAIL、UNKNOWN、NOT_RUN。PLANNED无观察，NOT_RUN仅用于未开始且外部依赖未满足；已运行但丢失回执保持UNKNOWN，先查原业务事实。PASS/FAIL必须有实际观察和证据，审核人确认后才可REVIEWED。

逐步输入输出

示例C1用例r3要求两笔订单中转逐项可追溯，系统版本v8、收餐角色R。第一笔成功、第二笔缺餐被拒绝；若预期允许部分成功且实际回执和业务状态对应，记录PASS及逐笔证据。若只有整体成功提示而缺第二笔结果，记录UNKNOWN待核，不擅自判PASS。

另一用例C2需要取餐柜授权但尚未开始，输出NOT_RUN及依赖。C3已发出请求后超时，保持RUNNING/UNKNOWN；查询同原单得到已交接事实后补观察，再审核。查询异常不使UNKNOWN变NOT_RUN。示例为预期状态，未运行真实系统。

旧执行C1为FAIL，修正后创建run2引用旧run和修正版本，保留旧结果。run2通过并审核后，问题可以按约定关闭；历史报表仍能看到失败及复验，不能将旧失败改写为从未发生。

完整迁移与反例

服务端先验证操作者与校区权限，事务锁执行记录，校验expected_revision和允许迁移，写观察、证据引用及审计事件，然后版本加一提交。重复command_id返回原回执；同键不同载荷拒绝。两个审核者带同一旧revision时只有一个能提交，另一个读新记录再决定。附件上传另做权限与内容核验，不能只凭传入路径信任证据。

反例是把所有空结果默认为PASS，或把执行超时改成NOT_RUN；两者都会扭曲完成范围。通过数应以已审核可比较用例为分母并列未执行与未知，不能只展示一个百分比。这里是独立设计，没有实现或并发实跑记录。

微订第一方校园介绍列有楼栋分类、批量中转和通知，可作为上述采购用例的业务入口。该说明不证明本文状态机为产品实现，也不证明具体套餐已经验收。完整专业性仍需现场流程、资金与服务责任一起核对，不凭工程子题生成品牌排名。

作者：微订（上海逊柯计算机科技有限公司）。