技术社区口径本文只谈工程实现不涉及任何商业推荐。2026 年 11 月 1 日《旅游景区智慧化运营管理要求》GB/T 30225-2026实施全部代替 2013 版《旅游景区数字化应用规范》。作为做过票务系统的人我把这版标准里跟系统设计直接相关的那部分——数据管理独立成章——反推成了一套可落地的设计清单记录一下。一、先说结论验收口径变了2013 版的验收方式是「建设导向」接近数零件有没有票务系统、有没有监控、有没有导览。新版换成「运营导向」六大板块中数据管理独立成章围绕数据归集、数据安全、数据使用三条展开。对开发者的含义是你交付的不再是一套功能而是一条能被验证的数据链路。二、数据归集先解决主数据再谈中台很多团队一上来就做数据中台结果做了个 ETL 管道把三套口径不同的数据物理聚到了一起。这在验收时是站不住的。归集的前提是主数据统一。以景区票务为例至少三类主数据需要先定全局标识主数据 典型来源 常见冲突游客 购票实名信息、人脸特征、会员 同一人多个 ID手机号/身份证/人脸各自为政订单 自营小程序、OTA、窗口、自助机 同一笔交易在 OTA 与本系统各有一条记录设备 闸机、自助机、手持机、摄像头 设备编码规则不统一无法定位到点位一个真实的口径冲突场景票务系统的「入园人数」按核销时间统计客流系统按闸机过闸时间统计停车系统按车牌识别统计。三个数在大屏上互相差 5%。这不是数据缺失是口径不一致。工程上的做法是先定义事实表的时间语义核销时间、过闸时间、入园时间分别是什么业务含义哪些能作为「入园」的权威口径。这一步不做后面所有指标都会漂。三、数据安全人脸数据的特殊性标准的数据安全部分引用了《信息安全技术 个人信息安全规范》GB/T 35273-2020。景区票务系统处理的是实名信息其中人脸数据需要单独设计**不可重置性**密码泄露可改人脸泄露不可改。因此人脸特征应独立存储、独立加密不与其他业务数据混库。**留存期限**需要明确「采集—使用—留存—删除」全生命周期的策略而不是默认一直保留。**删除可行性**游客要求删除时系统必须真的能删——包括主库、缓存、备份、日志。这一点在架构设计阶段就要考虑事后补往往补不上。一个常见的架构缺陷是人脸特征只存在主库但比对结果、抓拍图散落在多个业务库和日志里导致「删除」在技术上无法穷尽。四、数据使用通数据之后才有模型公开报道中贵州兴义万峰林景区整合多源数据后AI 模型综合节假日、天气、线上搜索热度提前 7 天预测门票预订趋势观光车旺季周转率提升 40%游客候车时间从 35 分钟降到 12 分钟。从工程角度看这类能力的前提是特征可用节假日日历、历史客流、天气、搜索热度必须能被对齐到同一时间粒度通常是天或小时并且有稳定的事实表支撑。数据不通模型只能消费单一数据源——不是算法不够好而是地基没打。五、把「责任主体」翻译成技术需求数据管理独立成章后责任主体是景区。这意味着以下能力需要在系统层面具备1.全量导出能导出结构化全量数据CSV / JSON / 数据库备份不依赖厂商人工配合。2.接口开放票务、闸机、停车、监控、财务之间的接口协议与调用方式需成文。3.数据责任人系统上线后有明确的数据维护与异常处理归属避免「人一走数据就断」。4.历史数据迁移老系统的数据是迁移、归档还是丢弃需要有明确方案。六、验收五问技术版1. 现场跑一条端到端链路闸机过闸 → 票务订单 → 经营报表观察延迟与一致性2. 索要接口文档而非功能截图3. 提一个跨系统复合查询「今天上午入园游客中同时产生园内消费的比例」4. 确认数据责任人及异常响应机制5. 明确历史数据迁移路径。小结验收的落脚点从来不是「有没有」而是「通不通」。从设计角度这版标准给的其实是一张数据契约清单归集要有主数据标准安全要有加密与留存策略使用要有可对齐的特征表。把它提前写进技术方案比上线后补数据链路便宜得多。这版标准对票务系统开发者最实际的提示是把「数据」当成一等公民来设计而不是功能的副产品。具体到落地顺序我倾向于三梯队先做统一口径与安全底线不做会出事再做接口标准化与数据责任人不做长不大最后做预测类模型与体验类改造做了更值钱。距离实施还有 30 天如果手上正好有在做的票务项目值得拿上面的清单过一遍。---这是《景区数字化这盘棋》系列第 1 篇。下一篇拆《SaaS、私有化、混合部署三种技术路线的数据层架构上差在哪》从工程实现角度把选型讲透。关注后可追更。本文为工程实践分享不涉及任何商业推荐。