轨道交通 AFC 系统升级，平凯 Loop 把跨部门协同变成可追溯闭环早高峰时段，驾驶舱突然出现一条异常曲线：闸机通过率

早高峰时段，驾驶舱突然出现一条异常曲线：闸机通过率降至 96.40%，低于场景基线 1.80 个百分点。

当 AFC（自动售检票）系统正处于“新老交替”的重构期，这样一个指标波动，可能引发一连串跨领域的疑问：是闸机固件导致处理时延上升，还是交易链路出现波动？扣费是否成功？进出站交易是否配对？票价和优惠规则有没有变化？如果需要调整参数，谁来评估影响、批准变更并确认回退条件？

除了架构、接口和数据迁移，真正决定系统重构项目稳定推进的，还有另一条看不见的链路：需求、责任、数据、规则、审批和结果，能不能持续地连接起来。

本文内容与数据均来自匿名化行业场景，不代表真实线路运营数据或客户生产成效。

一、AFC 重构，为什么容易“越做越复杂”？

随着二维码、NFC、银行卡等多元支付方式进入公共交通，乘客希望获得更快捷的通行体验，运营方也需要更灵活地调整票制、优惠与服务。但老旧架构、复杂接口和长期积累的业务耦合，让 AFC 重构很难只由一个团队独立完成。

在上述早高峰场景中，需求由线网运营、AFC 清分和车站设备维保等团队共同提出，技术部门牵头立项，票务稽核、信息安全与项目负责人共同参与。但各方关注点并不相同：

如果这些信息散落在会议、群聊、表格和个人电脑里，项目就容易陷入三种状态：进展看不清、事实对不上、关键变更控不住。

项目空间集中承载范围、进展与风险

Loop 在这里主要作为项目的协同与治理层。

项目负责人先把范围、里程碑、依赖和风险放进项目空间。每天打开项目，不必先逐个询问进度，而是先看：哪个迁移批次受阻，哪项规则等待确认，哪条任务会影响下一次演练。

当早高峰的异常发生时，清晰的协同机制开始运转。各角色在同一个频道里围绕同一问题协作：运营描述现场影响，维保检查设备与固件，数据团队核对事件和时间窗，票务与清分团队确认扣费及规则是否异常。

在此过程中，Agent 可以辅助整理已知事实、标注缺失信息和下一步动作，但专业的判断依然交由责任团队完成。更重要的是，讨论不会停留在“大家都知道了”——设备验证、数据核对、规则复核和差异整改要继续转成具体任务，明确负责人、优先级和下一步。

这样一来，推进项目不再从头汇报所有事项，而是直接从风险和阻塞项开始——问题卡在哪里，需要谁拍板，下一步由谁负责。

跨部门协同最怕“大家说的都对，但说的不是同一件事”。同一个“扣费成功率”，如果分母不同，结论就可能完全不同。

在 AFC 早高峰场景中，数据空间集中管理交易、闸机、设备、票价、清分、对账和迁移校验等信息，并通过只读 Data API 提供给驾驶舱。

以扣费成功率为例，口径明确为：

11,977 笔扣费成功 ÷ 11,984 笔已配对交易 = 99.94%。

而进出站配对率则是：

11,984 笔已配对交易 ÷ 12,000 笔交易 = 99.87%。

两个指标数字接近，但业务含义和分母不同。把来源、时间窗、公式与责任部门同时记录下来，才能避免“同名指标、不同口径”。

数据告诉团队“发生了什么”，规则则解释“为什么、按什么处理”。票价与优惠、清分口径、接口规范、数据标准、切换与回退条件，都可以沉淀到知识库和协同文档中。

各部门在同一份方案里评论、回复和解决分歧，意见始终锚定原文，确认也保留上下文。对于尚未执行的方案，则必须明确状态。

AFC 重构中的票价、清分、切换与回退，不适合交给自动化系统自行决定。

Loop 工作流可以先高效检查材料是否齐全、汇总风险和推动流程，但技术复核、业务复核、风险与合规确认、负责人批准等关键节点，仍然保留人工审批。

“控得住”不是增加更多流程，而是让高风险决策有明确边界，让每一次操作都能回到责任人与证据。

在场景验证中，一次运行停在人工审批，等待责任人处理；另一次运行则保留了完整的通过记录。自此，“谁批准了什么、基于哪些材料、流程走到哪一步”都有依据可循。

在一次数据异常背后，团队可以基于平凯 Loop 打造一条完整的项目协同与管理链路，让跨部门协作可观察、可验证、可追溯：

需要强调的是，Loop 不替代 AFC 在线交易、票价计算、闸机控制和清分结算核心系统，也不进入这些系统的实时关键路径。它的价值边界在于，承载重构过程中的需求、责任、数据、规则、审批和结果。

对于复杂的 AFC 重构项目，有价值的数智化，不是把更多页面搬到线上，而是真正地解决从验收、上线到长期运营过程中的协同与治理问题。

场景说明：本文展示的是匿名化行业场景，用于说明协同方法，不代表真实线路、站点、客户生产数据、运营成效或统一建设标准。票价、清分、风险、切换与回退均应由获得正式授权的人员决定。