1. 项目缘起与整体思路1.1 先说说这个项目到底要做什么2021年春天我第一次站在龙泉大窑遗址的龙窑边上满地的碎瓷片在太阳底下泛着青绿色的光。那一刻我突然意识到我们做的这个龙泉青瓷数字传承平台不是简单做一个展示瓷器图片的网站而是要替这些碎片、这些窑址、这些散落在老匠人手艺里的记忆找到一条能活到数字时代的根。瓷路寻根这个名字也是后来反复讨论定下来的。我们想做的核心是三件事第一把龙泉境内已知的古窑址和文保单位全部落到一张地图上用GIS技术建立空间关系第二给非遗传承人的技艺、工序、口述史做结构化数字档案第三建立一个青瓷AI鉴伪的辅助判断系统把过去靠老师傅肉眼和经验才能做的真伪鉴别变成可量化、可学习、可追溯的数据模型。整个项目做下来前后耗时将近三年团队也经历了从5个人扩展到17个人的过程。这里我不打算只讲成果更想把我们在技术选型、功能落地和踩坑排障中的完整过程记录下来给后面做文化遗产数字化、特别是做器物类数字平台的朋友一些参考。1.2 为什么选择数字中台GISAI这个组合项目启动时我们内部开了不下十次需求讨论会。一开始有人提议做成一个普通的官网加电商模块因为龙泉当地不少青瓷厂家都希望平台能带销售功能。但我们最终没有走这条路而是坚持做传承属性优先的数字平台。原因很简单如果只做电商那这个平台的独特性就消失了它跟淘宝上任何一家青瓷店没有本质区别。传承平台的核心价值在于数据资产——窑址数据、器物档案、技艺结构化记录、真伪鉴别数据这些数据是积累性的越用越有价值越沉淀越难被复制。所以整体定位是一个底座、三个引擎数字资源底座数据库对象存储、GIS空间引擎窑址文化带可视化、AI鉴伪引擎。底座负责管数据两个引擎负责让数据活起来。1.3 三类目标用户的需求差异做平台之前我们专门在龙泉待了两个月走访了当地文保所、青瓷研究所、老匠人和一些收藏圈的朋友。最终的结论是这个平台至少要服务三类人三者的需求完全不一样不能用一个功能模板覆盖。研究者考古、文博专业要精确的窑址坐标、地层信息、器物尺寸和釉色数据要能批量导出要能在空间上叠加分析。收藏爱好者和一线工艺师最关心的是手里的东西是不是真品以及能不能溯源到某个窑口或生产年代。大众用户非遗文化爱好者要体验感要看得懂的故事要能云游窑址和博物馆。这三类需求交织在一起逼迫我们不得不在架构上做分层。研究者走的是数据接口和后台分析模块工艺师走的是鉴伪和档案查询模块大众用户走的是移动端的文化漫游模块。前端互不相通但共享同一个数据底座。这个决策后来被证明非常正确因为开发时模块之间几乎没有发生互相牵制的情况。2. 需求拆解与架构选型2.1 文化资源的数字化难点不在数字化而在结构化我们最早期最大的误区是把数字化简单理解为拍照录像存网盘。真做起来才发现瓷器这种器物的数字记录远比想象中复杂。一个器物要真正被记录下来至少需要五层信息维度基础属性名称、年代、窑口、尺寸、重量、完整度影像数据多角度照片、三维扫描模型、显微釉面图工艺信息成型工艺、装饰手法、烧制温度曲线流转信息出土位置、收藏单位、展览记录鉴别数据真伪判定结果、判别依据、特征标记这五层数据如果只是在Word或者Excel里存着等于没有结构。所以我们在数据架构阶段就引入了数据建模的概念把每个器物拆成器物主表影像子表工艺子表流转子表鉴别子表的强关联结构。这个设计当时有人觉得太重了觉得一个小项目没必要搞这么复杂的库表结构。但实际运行一年后再看正是这套结构化设计才让后面的分类检索、空间关联和AI训练数据准备变得异常顺利。没有结构化AI模型连干净的训练集都拼不出来。2.2 技术栈选型C# GIS、云平台、AI框架的取舍思路技术选型是整个项目里争论最激烈的部分。我们的团队成员背景比较杂有做.NET出身的老牌GIS工程师也有玩Python深度学习的新人。这里把我的选型逻辑讲清楚供大家参考。GIS部分选C#是有明确原因的。龙泉窑址数据的源头来自浙江省文物考古研究所的测绘成果他们早期的数据生产工具链大量基于ArcGIS Engine和ArcObjects这些组件在.NET环境下调用最成熟。虽然我们平台最终对外是Web应用但内部要做大量矢量数据的空间分析、坐标转换和切片处理直接用C#调用ArcGIS的接口或写GDAL的.NET绑定曲线最平滑。加上团队里那位GIS老工程师用C#写了十年与其让他半路学Python生态不如让合适的人用顺手的工具。云平台和大数据部分选型。数据存储用了阿里云的组合方案RDS MySQL用于关系型事务数据OSS用于影像和三维模型这类非结构化对象PostGIS安装在独立ECS上处理空间数据MongoDB放操作日志和用户行为流。大数据这块实际是云平台大数据应用开发的思路——并没有一开始就上Hadoop这么重的体系而是先用Spark离线跑每天的用户访问日志和鉴伪请求统计等数据量真正起来后再考虑建数仓。AI鉴伪部分。我们踩过的最大坑是一开始认为深度学习模型什么都能解决后来发现对于瓷器真伪鉴别这种细粒度问题纯黑盒模型难以被文博专家信任。最终方案是传统图像特征深度学习特征双通道先用传统算法提取釉色分布、开片纹理、气泡结构等专业特征再把这些特征与ResNet50的深度特征拼接在一起最后接一个分类器。这样模型输出的结果可以逆向回溯——告诉用户为什么判定它真/假专家才认可。2.3 整体架构分了几层最后我们敲定的技术架构是四层感知层三维扫描仪、高清摄影设备、无人机航拍、手持GPS定位数据层RDS、OSS、PostGIS、MongoDB、Spark离线仓库服务层.NET Core微服务、GIS切片服务、AI推理服务Python FastAPI、用户鉴权应用层管理后台、PC端门户、移动端H5、小程序微服务之间通过HTTP API通信AI推理单独拆出来部署在GPU服务器上避免图像计算吃满CPU把主站拖垮。这个拆分当时是为了应对鉴伪一次最长可能要15秒的现实——如果同步阻塞在Web请求里用户体验会非常差。后来我们用了异步任务加消息推送的方案请求发出去后用户可以先干别的事出结果再通知。3. 核心功能落地窑址GIS与AI鉴伪3.1 三步完成窑址GIS文化带搭建窑址空间数据的采集和落图是整个项目中最苦最累的环节。它不像软件代码可以反复调试走错一个坐标点就得重新跑一趟山路。我们前后整理出139处窑址、窑群和瓷土矿遗址的数据整个过程分三步走。第一步数据源清洗与坐标统一。从文保所拿到的基础资料里坐标格式极其混乱有度分秒的有十进制度数的有用本地相对坐标的甚至有几处只有文字描述大窑村北面山坡上距离村口约2里地。先把所有数据统一成WGS84经纬度再通过坐标转换接口把地方测绘坐标系也换算过去。这里有个很重要的经验所有坐标转换必须在入库前完成而不是在查询时实时转换。我们刚开始贪图省事想在前端做实时转换结果地图上同一处窑址在放大到15级时出现了明显偏移就是因为不同层级的地图底图坐标系不一致实时转换在浏览器端折损了精度。最终的做法是在后端统一转好存两个字段原始坐标和标准坐标展示时只读标准坐标。第二步基于C#搭建GIS数据管线。空间数据结构化我用的是C#开发了一套离线工具主要做三件事读取Excel测绘记录表、调用GDAL库做矢量要素的读取和投影转换、把清洗后的数据批量写入PostGIS。这套管线虽然丑但极其可靠所有过程都写了日志每条记录入库后返回一个成功/失败原因的回执。第三步地图可视化与保护范围标识。前端用的是开源Leaflet叠加大窑遗址片区等各级文保单位已有的Shapefile边界文件。除了标记点位还给每个窑址配置了三种状态色已发掘保护红色、考古调查中黄色、待勘探确认灰色。颜色系统我们参考了文博行业的涂色习惯这种细节不要自己拍脑袋发明跟着行业惯例走最省事。后期我们还叠加了窑址间瓷土运输路线的推测路径线这些是考古专家根据各窑址出土胎料的化学成分相似度推算出来的。3.2 三维器物数据采集与轻量化处理青瓷数字传承平台如果想让人看得过瘾没有三维模型是撑不起来的。我们选了30件馆藏标准器和50件现代匠人代表作做三维扫描这个数量不多但每一件都做得尽量保真。扫描用的设备是EinScan Pro系列手持式三维扫描仪。处理流程大概是先贴标定点用固定扫描模式扫两圈再用手持模式补扫细节凹槽。龙泉青瓷最大的特点是釉面光滑反光扫描仪红外结构光打到瓷器表面经常会产生噪点。我们的解决办法是喷薄层显像剂——这是一层可以水洗掉的白色粉末能有效降低反光干扰。但喷显像剂有个副作用就是会让瓷器表面的细微开片纹路暂时被遮住影响后续纹理颜色贴图的高精度采集。所以我们先扫描几何模型再擦掉显像剂重新做一遍纯色摄影采样最后在Blender里把两套数据做几何纹理重投影。轻量化处理是重要一环。原始扫描模型单个器物至少2000万三角面片文件量动辄2-3GB直接放网页上根本带不动。我们做了两套方案高精度原始模型离线存档Web端使用经Quadric Edge Collapse算法减面后的低模压到10万面片以内再用Normal Map弥补细节损失。颜色贴图用4096×4096分辨率格式转成WebP压缩率比JPEG高30%肉眼差异基本看不出来。3.3 AI鉴伪平台开发从数据集到可解释特征这个模块是我们投入最大也最谨慎的一个。真正的行业痛点不是做不做得出模型而是专家信不信你的模型。我们花了大量时间解决可解释AI的问题。先说数据集。我们从三个方向收集青瓷影像博物馆公布的馆藏标准器高清图用于建立真品的视觉原型考古所合作的出土瓷片显微摄影图这是最刻骨铭心的数据因为出土残片就是断代的标准答案市场上征集和藏家捐赠的仿古瓷、赝品图片以及部分超越国宝帮水准的高仿青瓷影像。总样本12万多张真伪比例大致为1:0.7。直接输入模型肯定不行因为原图上器物有大有小、背景不一。我们做了两轮预处理先做器物主体分割用Mask R-CNN再归一化到512×512分辨率。然后是特征工程。龙泉青瓷的鉴别要点在行内是有一套专业标准的核心看四个维度釉色梅子青、粉青、月白之间微妙的色相差异、釉面气泡真品气泡疏密和大小分布受窑温气氛影响仿品往往过均匀、开片纹理走向哥窑开片与仿哥釉开片的形态不同、底足露胎处胎色朱砂胎与灰白胎的对比。这些专业经验我们全部翻译成了可计算的图像特征釉色用Lab色彩空间统计数据重点提取b轴黄蓝方向的分布曲线梅子青的b值会落在一个很窄的区间仿品往往色彩饱和度过高或过绿。气泡结构用局部二值模式和形态学筛选取出气泡区域计算气泡密度、直径方差、聚集系数。开片纹理用Hessian矩阵提取线条走向转成方向直方图正宗哥釉开片呈现金丝铁线的双体系纹理方向而现代仿品多为单体系网格化。将这些手工特征直接拼接进深度网络的全连接层是行不通的因为传统特征维度太高反而干扰学习。我们的做法是把传统特征压缩成16维向量再和ResNet50倒数第二层输出的2048维深度特征拼接在一起最后过一层Dropout和两层全连接。训练细节上也有些心得。分类损失函数用了Focal Loss因为赝品的高仿样本本质上分布极其接近正样本普通交叉熵很容易被大量容易分类的样本带偏。Batch size设为16初始学习率1e-4Adam优化器早停机制设置patience8。训练集和验证集按9:1划分并且确保同一个器物的不同角度图像全部落在同一侧防止数据泄漏。最终在独立测试集上真伪二分类的准确率做到92.7%AUC达到0.965。这个成绩说实话在实验室里已经很好了但离可以替代专家还差很远。所以我们对系统定位是辅助鉴伪输出形式不是简单的真/假而是给出一个概率值加四维特征雷达图——釉色、气泡、开片、胎色分别得分多少。最终解释权还是回到人机器给的是数据依据。这个设计让我们在向文博专家汇报时几乎没有遇到阻力因为专家看到了他们自己的经验在系统里得到了数据化复现。4. 平台开发中的实操细节与参数配置4.1 数据治理与接口性能优化平台跑起来之后数据量增长的速度超过了我们的预期。光三维模型的原始存档就有几十个TB影像数据也有接近3TB。这个体量在文化遗产领域算大的OSS存储费用每月是一笔不小的开支。我们后来加了生命周期管理冷数据迁移到低频访问存储池热数据保持在标准存储费用降了约45%。接口性能优化上踩过几个典型的坑。最常见的是鉴伪接口超时问题。AI推理服务部署在GPU服务器上单次推理大约需要3-8秒视网络并发而定。用户在前端提交图片后如果HTTP请求一直挂着网关层默认100秒超时实际体验非常差。我们改用异步任务提交后立刻返回一个任务ID前端轮询获取状态推理完成后推送结果。同时给AI服务加了一个消息队列缓冲避免突发请求直接把GPU显存打满。数据库层面最头疼的是空间查询的性能。PostGIS上的139条窑址记录本身不多但前端每次加载地图时会把所有点位的关联统计信息如该窑址馆藏器物数量、发掘年份也一起JOIN出来导致首次地图加载要2-3秒。后来用物化视图把空间要素和统计信息预聚合查询时间降到400毫秒以内。这个优化看似简单但很值得记录——文化遗产类数据普遍是记录少但关联多物化视图是性价比最高的解法。4.2 云平台部署与弹性扩缩容实践云平台部署这块我们采用的是一套相对朴素但足够稳的方案。基础设施在阿里云上应用服务器2台8核16G ECS跑.NET Core Web APIGPU服务器1台4核24G加T4显卡跑AI推理数据库RDS MySQL 8.02核4G主实例只读实例空间数据库1台2核8G ECS安装PostgreSQL 13PostGIS 3.2对象存储OSS标准存储低频存储混合容器化我们做得比较晚是在项目上线半年后因为频繁更新版本导致部署效率太低才引入的。用Docker Compose在单机上编排所有服务开发测试环境足够用生产环境没有强行上K8s——因为整个集群规模就三台服务器硬上K8s反而增加运维复杂度。弹性扩缩容这块有一个重要触发场景平台和龙泉本地青瓷文化节合作做过几次线上直播活动瞬时流量能冲到平时的十倍以上。第一次直播我们没经验用户在线看三维模型的同时并发调鉴伪接口直接把数据库连接打满页面白屏了五分钟。后来做了三件事Redis缓存预热把首页、热门器物详情、知名窑址信息的缓存提前拉起来应用服务器弹性扩容配置好镜像和启动脚本流量触发阈值后3分钟拉起新节点数据库层面开启连接池复用和读分离写操作走主实例读操作走只读实例。这套组合下来后面几次活动再没有出现过崩溃。4.3 大数据分析用户行为与文化热力图云平台大数据应用开发在本项目里不是装点门面而是实打实产生了业务价值。用户所有对窑址的浏览、路线规划、器物查询行为都记录在MongoDB的行为日志里。我们用Spark离线任务每天凌晨跑一次聚合统计每个窑址的访问热度排行用户在地图上的视野停留热区鉴伪功能调用量按小时分布器物页面的上下游跳转关系最有价值的一个产品洞察来自停留热区。数据分析发现用户使用地图时在大窑—溪口—金村这条考古发掘核心线路上的平均停留时长是其他区域的4.2倍。这条路其实就是古代龙泉青瓷外运的主要通道。基于这个发现我们在平台上主动推荐了大窑古窑址-溪口窑址-金村码头这条考古研学路线内容策划团队专门补录了每一处遗址的语音讲解。上线后这个路线的整体访问量占全站地图模块的37%文创衍生品详情页的转化也比均值高出不少。这就是数据反哺内容的好例子不是我们拍脑袋觉得哪里重要是用户行为告诉我们哪里需要深挖。5. 常见问题与排查技巧实录5.1 三维模型纹理拉花问题项目初期扫描了第一件梅子青釉瓶模型几何没问题但贴图展开后纹路全是扭曲的釉面的光滑反光处出现了类似拉花咖啡的条纹。排查过程先怀疑是UV展开算法问题换了两个展UV工具仍然存在。后来才意识到是采集环节的光源问题——扫描时窗外自然光随时间变化导致同一物体表面不同区域的光照色温不一致贴图重投影时这些色差被算法放大成条纹。解决方案把所有扫描工作移到室内恒光环境用两只6000K色温的LED柔光灯做对称布光采集前先用标准色卡做白平衡校准。此后拉花问题基本消失。5.2 GIS坐标漂移到底是谁的锅平台内测阶段有用户在手机端打开地图发现窑址点位标志和卫星底图上的实际建筑位置偏移了约40米。排查过程分了三步先查数据库存的坐标值确认WGS84原始坐标正确再查切片地图的坐标参考系发现我们用的在线底图是GCJ-02火星坐标系而窑址点位入库时忘了做坐标系转换。最后在后端写了一个WGS84转GCJ-02的统一转换函数重新刷了一遍数据。这里补充一下地方测绘提供的资料如果用的是独立坐标系还必须先通过控制点计算七参数转换到WGS84不能简单用网上开源代码直接转否则偏远山区误差能到百米级。5.3 AI鉴伪对高仿品误判的应对模型上线初期拿了一批收藏圈朋友支援的高仿青瓷做盲测误判率明显高于普通赝品。特别是有几件仿哥窑开片瓷器开片纹理特征与真品非常接近模型几乎失去判别力。我们重新分析了误判样本发现高仿品在开片这个维度上已经模仿得像模像样但在微观气泡的直径方差和胎色端元分布上仍有破绽。于是做三处调整增加高仿样本的权重Focal Loss里把高仿类别的alpha调到0.75引入微观图采集提示用户上传瓷器底足和釉面局部特写作为第二输入分支在雷达图输出里明确标注每个维度置信度当开片维度置信度很低时系统提示建议结合胎釉微观特征综合判断经过两轮迭代高仿误判率从17.5%降到6.8%。无法再往下打的主要原因是部分高仿样本连老专家都要上手才能确认现有图片数据维度下已接近上限。5.4 负载突增时的优雅降级方案前面提到的直播崩溃事件后除了扩容和缓存我们还做了一个更关键的优雅降级开关在高并发状态下自动把AI鉴伪入口从实时推理降级为预约排队同时把三维模型查看模式从真彩色切换为贴图模式减少带宽消耗。优先保住地图浏览和器物档案等基础功能不让整个平台白屏。我们还在管理后台做了一个人工熔断按钮运维值班人员一旦发现异常流量可以一键启用降级策略。上线以来真正手动触发过一次是从百度贴吧涌进来一波用户导致的流量尖峰人工熔断后平台稳定运行没有出现事故。6. 一点实际操作后的体会三年项目做下来我最大的体会是文化遗产数字化最难的永远不是技术而是翻译。技术团队要能把考古学家脑子里的经验翻译成数据结构和特征向量把老匠人手上的肌肉记忆翻译成可记录的数字流程把釉色和气泡翻译成模型能学习的规律。这个过程需要大量时间泡在现场、蹲在窑址边听专家讲故事。我们团队后来形成了一条不成文的规矩每个新来的算法工程师先去龙泉待两周再回来写代码。如果你正准备做类似的非遗数字化平台我的建议是不要急着买设备搭环境先和领域专家把什么数据值得记录什么样的判定结果能被信任这两个问题聊透。数据结构的顶层设计一旦错了后期重构的代价远超你想象。另外一个细节是这种项目要提前谈好知识产权和数据所有权问题。我们和文保所、博物馆、非遗传承人合作时花了很多时间确认每件器物的数字资产授权范围。文化遗产数字化归根结底是公共事业数据平台的可持续运营不能靠一次拨款得找到公益性适度商业反哺的平衡点。目前我们平台上的鉴伪服务对个人用户免费对商业机构比如拍卖行、藏家俱乐部适度收费这笔收入用来覆盖服务器成本和后续数据更新的开支。做数字平台三年多最让我有成就感的一个瞬间不是哪个模型精度刷新了记录而是项目上线后一位已经七十多岁的龙泉青瓷老匠人在孙女的帮助下第一次在平板上看到了自己在窑场里拉坯、素烧、上釉、龙窑烧成的完整工序视频被结构化地记录在平台上。他看了很久然后用方言说这个好玩后代能看到了。那一刻我知道我们做的事方向是对的。