技术社区口径：本文只谈工程实现，不涉及任何商业推荐。
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、私有化、混合部署：三种技术路线的数据层，架构上差在哪》，从工程实现角度把选型讲透。关注后可追更。
（本文为工程实践分享，不涉及任何商业推荐。）
