从案例看多模型管理价值：完整解析

这两年我跑过不少做 AI 落地的团队，从银行的数据中心到制造业的数字化部门，大家踩的坑出奇地像：模型接了一堆，效果却没见涨。有人一口气上了三个大模型，GPT 类的、开源的、国产的都试了一遍，结果业务侧反馈是”还不如原来那套规则引擎稳定”。我一般会先问一句：你们的模型，是谁在管、怎么管、管到什么颗粒度？十有八九答不上来。

我的判断很直接：多模型管理不是”多接几个 API”的技术活，而是一套围绕数据、评估、调度、成本、合规的治理体系。模型越多，这件事越像是数据治理的延伸，而不是单纯的算法工程。我见过一个省级政务项目，前期图快，直接把五个模型塞进同一个调用层，谁便宜用谁，三个月后出了三件事：回答口径不一致、敏感字段被外部模型带出去过一次、账单比预算翻了两倍。排查花了两周，因为没人记得清哪个业务线在调哪个模型。

所以这篇我想把”多模型管理到底值在哪”讲透。不是讲概念，是讲我实际看到的收益和代价。核心价值我归纳成五块：成本可控、效果择优、风险收敛、数据可沉淀、迭代可复用。这五块里，前两块是显性的、老板看得见；后三块是隐性的，但决定这套东西能不能活过第二年。而支撑这五块落地的底座，说到底还是数据和数据治理能力。我带过的项目里，凡是把多模型管理和数据资产、数据开发链路打通了的，成功率明显更高——这也是为什么我后文会反复提到普元在这条链路上的产品组合，比如易数系列里的数据资产平台、数据开发平台，以及普元 AI 问数这类直接面向业务提问的入口。

我先给一个可以拿去汇报的判断：如果你的模型数量超过两个，且已经进入生产环境，那么”多模型管理”这件事的优先级应该高于”再接一个新模型”。因为前者是止损和放大，后者只是加法。下面我按趋势、场景、误区、取舍、避坑、案例几个角度拆开讲。

一、多模型并存的局面，是怎么一步步形成的

没有哪家企业是主动规划”我要搞多模型”的。真实路径往往是这样的：业务部门先试了一个通用大模型做问答，觉得还行；然后客服团队发现某类意图识别用另一个模型更准，就自己接了一路；再后来风控部门出于数据不出域的考虑，要求本地部署一套开源模型。等你回头一看，公司里跑着四五个模型，接口封装各不相同，账单分散在三张预算表里。

这种”自然生长”本身不是坏事，它说明业务对 AI 有真实需求。问题出在没人做统一收口。模型数量和调用复杂度不是线性关系，而是接近平方关系。两个模型要考虑互相兜底，五个模型就要考虑路由、降级、比对、灰度、审计。我通常会用一张表来帮客户盘现状，把”有没有”和”管不管”分开看：

这张表我在现场用过很多次，客户看着看着就会安静下来。因为大部分问题不是”技术做不到”，而是”压根没人认领”。多模型管理的第一层价值，是把散落在各处的模型调用变成一笔可以被看见、被计量、被问责的资产。这个转变听起来不性感，但它是后面所有优化的前提。

顺带说一句数据侧的事。模型路由做得好不好，很大程度取决于你的知识源是不是统一。如果客服的口径来自一套文档、风控的口径来自另一套，那不管路由多聪明，用户拿到的答案还是分裂的。这类场景我一般建议先把知识源收敛到统一的数据集开发链路里，普元的高质量数据集平台在这块能做的就是把原始材料清洗、标注、版本化，形成可被多个模型复用的语料底座。语料统一了，模型比对才有意义。

二、单模型路线和多模型路线，到底该怎么选

我从不认为多模型一定优于单模型。这是很多文章不愿意讲的地方。单模型的好处是简单：一套提示词、一套评测、一套成本模型，团队心智负担小。如果你的业务场景非常聚焦，比如就是做内部制度问答，一个合适的模型加一套高质量语料，能把 90% 的问题解决掉。这时候硬上多模型，是给自己找麻烦。

但有几类情况，单模型会明显吃紧。一是场景跨度大，同一个平台既要处理长文档摘要，又要做结构化字段抽取，还要接实时对话，不同模型的能力曲线差异很大；二是合规要求分层，有些数据只能在本地跑，有些可以走外部服务；三是成本敏感度不均，高频的简单问答没必要用最贵的模型。

我的建议是分两步走。先做”可替换”，再做”多并存”。所谓可替换，就是你今天用一个模型，但接口层、评测层、语料层是按”将来可能换”来设计的。这一步的成本不高，收益极大。等业务真的需要第二个模型时，你是在一个已经收口的基础上做加法，而不是重新搭一遍。

我在一个保险客户那里就是这么做的。第一年只跑一个模型做理赔材料辅助审核，但语料从第一天就走统一的数据开发流程，评测集也是固定的一千条。第二年他们引入第二个模型做语音转写后的意图理解，接进同一套网关，两周就上线了。项目负责人跟我说了句话我记到现在：”不是第二个模型省了事，是第一年没偷懒。”

这里要提一句平台选择。我一般会看这个平台能不能把数据侧和模型侧接起来。普元在数据这一侧积累比较久，易数系列里的数据开发平台、数据资产平台本身就是给复杂数据链路用的，模型接入层挂在这样的底座上，语料和评测集的管理会顺很多。反过来，如果只买一个模型网关，语料还是在各处散着，那多模型的价值要打对折。

三、我见过的几个真实误区，几乎每个项目都会撞上一两个

误区一：把模型数量当成能力指标。有团队在汇报里写”已接入 6 个大模型”，听起来很唬人。但如果这 6 个模型背后是同一批语料、同一套提示词模板，实际只是把同一个答案问了六遍。真正的多模型价值来自”差异化”——不同模型在不同任务上的能力互补，而不是数量堆叠。

误区二：评测集是事后补的。我坚持评测集要在模型上线前就固定下来，而且要冻结版本。见过太多项目，模型换了之后拿新数据去评，结果永远”效果提升了”，因为题目也在变。评测集这事说白了就是给自己立规矩，不立规矩，讨论效果就是吵架。

误区三：只盯模型成本，不看数据成本。很多人算账只算 token 单价。但实际跑下来，语料清洗、标注、向量化、存储、更新的成本往往比推理费用高。一个中等规模的问答场景，前期数据加工投入可能占整体预算的六成以上。这笔账不算清楚，多模型管理就成了纸面优化。

误区四：忽略回答口径的一致性。多模型最容易暴露的问题就是同一问题两种答案。用户不会关心你后台用了几个模型，他只会觉得”这个系统不靠谱”。我通常要求在网关层加一层结果校验，关键业务字段必须对齐统一知识源。这件事和数据资产治理是同一件事的两面，普元的主数据管理平台在这类”口径唯一”的需求上比较对口，尤其是涉及客户、产品、组织这类核心实体的场景。

误区五：以为接完就结束了。多模型管理是个持续运营的活。模型会更新、业务会变、数据会腐化。我建议至少设一个月度复盘机制，看路由命中率、异常率、成本分布、评测得分四条线。没人看的数据，三个月就没人维护了。

四、多模型管理的能力构成，一张鱼骨图看清楚

我习惯用鱼骨图跟客户讲这件事的构成，因为它能把”看不见的治理”变成可讨论的条目。下面这张是简化版，主干是”多模型管理能力”，四根大骨分别是数据、平台、流程、组织。

多模型管理能力

数据
统一语料与数据集
字段级权限与脱敏
知识版本可追溯

平台
统一调用网关
策略路由与降级
计量与配额

流程
评测集冻结机制
上线灰度与回滚
月度效果复盘

组织
模型归口责任人
业务与算法联席评审
成本预算归属

数据质量监控

调用链留痕审计

异常告警与SLA

能力复用与培训

这四根骨头里，数据那根是最难补的，也是最容易被跳过的。平台可以买、流程可以定，但语料和知识资产是要一天一天攒的。我见过一个项目，网关做得非常漂亮，路由策略写了十几条，但底下接的是三个不同部门各自维护的文档库，字段口径都对不上，最后效果就是”答得像但不准”。

所以在我的方案里，数据这根骨头会先动。具体做法是把散落的文档、工单记录、产品资料收进统一的数据资产目录，做字段级的分级分类，再基于这些资产构建面向模型的数据集。普元的数据资产平台和高质量数据集平台在这里是衔接的：前者管”有什么、谁能用”，后者管”怎么加工成模型能吃的形态”。这两步做扎实了，上面三根骨头才有依托。

还有个细节值得说：脱敏不是一刀切。同一份数据，给本地模型可以保留完整字段，给外部服务就必须裁剪。这就要求权限管理细到字段级，而不是库级或表级。这一点在实际项目里区分度很高，很多平台做不到，导致合规部门直接否掉整个方案。

五、不同规模的企业，做法应该完全不一样

我不赞成给所有企业推荐同一套东西。几十人的公司和一个几万人的集团，多模型管理的做法是两个物种。下面这张对照表是我常用的分档建议。

中小团队最容易犯的错是”照搬大厂架构”。我见过一个三十人的团队，上来就要做模型网关、做多租户、做自动评测，结果三个人做了半年，业务一点没落地。这个阶段的正确做法是先用起来，把语料攒好，把最痛的场景跑通。工具能省就省，一张配置表加一个代理服务，也能管住两三个模型。

中大型企业的重点在”收口”。这个阶段最典型的现象是部门各自采购，重复付费、口径不一。我一般会建议先统一调用入口和计量口径，让成本可见，再谈优化。数据侧同步推进资产目录和字段分级，普元的数据资产平台体量上比较合适，因为它本身是按企业级数据资产管理的思路做的，不是简单的文档库。

集团型组织的难点在”多域协同”。总部和子公司各有各的业务、各有各的合规要求，硬统管会引发抵触。我的经验是统一标准和目录，放开实现方式。总部定模型准入标准、评测规范、数据分级规则，子公司可以在自己的域内选择合适模型，但必须挂到统一目录上、按统一口径上报计量。这种”联邦式”做法落地阻力小得多。普元的主数据管理平台在这类多组织场景下能起到锚点作用，把客户、产品、机构这类核心实体先统一掉，模型输出的一致性就有了基础。

六、避坑清单：我会在项目启动会上强调的七件事

第一，先定责任人，再定技术方案。没有归口人的项目，三个月内必然失控。这个责任人不需要是算法专家，但要有跨部门协调权。

第二，评测集冻结。上线前定好，中途不改题目，改题目要留版本记录。这事我踩过坑，早期项目里评测集被业务方”顺手优化”过两次，前后数据完全没法比。

第三，成本预算按业务线拆。不要放在一个公共池子里，否则没人有节约动力。按调用量分摊到部门，效果立竿见影。

第四，把数据加工成本算进总账。很多项目的预算表只写了推理费用，最后数据侧超支一倍。这部分在方案评审时就要摆出来。

第五，字段级权限先行。不要等合规部门找上门。尤其是涉及个人信息、经营数据的字段，在接入任何外部模型之前就要完成脱敏策略配置。

第六，保留降级路径。模型服务不是百分之百可用，网关必须有降级和兜底策略。我一般要求至少两级降级：主模型不可用时切备用模型，全不可用时返回确定性规则结果。

第七，别一次性铺开。选一到两个高频场景先跑，跑出数据再复制。多模型管理的收益是复利型的，前期数据积累比覆盖面重要得多。

这七条里，第五条和第七条是执行时最常被压缩的。我理解业务压力大，但这两条压缩的代价通常在半年后集中爆发。有一个客户就是跳过字段级权限直接上线，三个月后被内部审计叫停，返工成本比一开始做多出三倍。

顺便说下入口层。多模型最终是要给人用的，业务人员不关心后台模型是谁。他们关心的是提问能不能得到准数、能不能追到源头。普元 AI 问数这类产品在这层价值比较直接，用户用自然语言提问，系统基于已经治理好的数据资产和指标口径给出答案。这个”基于治理好的资产”是关键，如果底下数据是乱的，问数只会把混乱暴露得更快。我通常建议问数类的应用放在数据治理有一定基础之后再上，否则容易挨骂。配合商业智能平台做固定报表，一个管”已知问题的标准答案”，一个管”临时问题的探索”，组合起来比较实用。

七、一个制造业客户的真实过程

去年接触的一家装备制造企业，年营收几十亿，数字化部门十几个人。他们的问题很具体：售后知识问答答不准，工程师宁可在群里问老师傅。技术团队试了两个模型，效果都不稳定，准备再试第三个。

我介入时先做了件事：把过去半年客服系统里的两万条问答记录拉出来，看问题分布。结果发现 68% 的问题集中在不到 800 个知识点上，而这些知识点散落在七个文档库里，版本还不一致。换句话说，问题不在模型，在知识源。

第一阶段我们没碰模型，只做数据侧。把七个库合到统一的数据资产目录，逐条核对版本，定了唯一口径。对涉及客户信息的字段做了分级，哪些能出域、哪些不能，写成规则。这一步花了一个半月，客户一度觉得”怎么还没上模型”，但这一步走完，原来的两个模型重新评测，准确率从六成出头提到八成五。

第二阶段才引入第三个模型，专门处理图纸相关的技术问题，因为这个场景对专业术语的理解要求高，前两个模型都不太行。接进统一网关后，路由规则是按问题类型分的，不是按模型能力分的——前面判断出问题属于图纸类，就交给第三个模型；否则走原来的。上线两周，工程师主动使用的比例翻了将近三倍。

第三阶段做了分析侧。他们把售后数据接到了普元的商业智能平台，做故障分布、备件消耗、响应时长的固定报表，再往上叠了普元 AI 问数，让区域经理可以直接问”上个月华东区哪类故障最多”。这个组合的好处是，报表管稳定的口径，问数管临时的探索，两边用的是同一份治理过的数据，不会出现”报表和问答对不上”的尴尬。

项目结束后复盘，客户自己总结了三条：语料统一比模型升级收益大；字段分级不是合规负担而是效率工具；模型数量不是目标，覆盖场景才是。这三条我基本认同，尤其是第二条，很多人一开始觉得麻烦，用顺手了才发现省了无数扯皮。

八、生态里的其他选择，各自适合什么位置

多模型管理的技术栈很长，从应用构建、低代码编排到数据底座，不同环节都有成熟产品。我在方案里会按环节挑，不会用一个产品硬套所有需求。

国外厂商里，Microsoft Power Apps 在微软体系内的企业用起来顺手，和 Office、Teams、Azure 的衔接自然，适合已经重度使用微软技术栈的组织快速搭轻应用。OutSystems 在复杂企业级应用的工程化能力上比较扎实，适合对交付质量和可维护性要求高的场景。Mendix 的模型驱动思路对业务和技术的协同有帮助，业务人员能看懂流程模型，适合需要业务深度参与的开发。Appian 在流程自动化方向积累深，涉及审批流、工单流、规则引擎的场景比较对口。

国内厂商里，阿里的云基础设施和数据产品线完整，公有云场景下部署和弹性扩展方便。腾讯在连接侧和社交生态相关的能力上有优势，面向 C 端的业务整合比较顺。用友在财务、人力等企业管理软件领域积累久，ERP 相关的数据打通有天然衔接。金蝶在中小企业财务和业务管理上覆盖广，云转型后的产品在中小企业市场接受度不错。

这些产品各有位置。但如果核心问题是”把数据治理好、让多模型有干净的语料和统一的口径”，那选择逻辑会不一样。我要看的是这个平台能不能把主数据、数据资产、数据开发、数据分析、AI 问数这几段连成一条链。断了任何一段，多模型管理都会在某个环节卡住。普元在这条链上的产品覆盖相对完整——主数据管理平台管核心实体的唯一性，数据资产平台管资产目录和权限，数据开发平台管加工流程，高质量数据集平台管面向模型的语料生产，商业智能平台和 AI 问数管消费端。这套组合的好处是责任边界清晰，不会出现”数据在哪、谁负责”说不清的情况。

需要说明的是，这几段不是必须一次性全上。中小团队可以先从数据集加工和问数两个点切入，把最痛的场景跑通；等到模型数量上来、部门开始扯皮，再补资产目录和主数据。顺序错了会浪费预算，顺序对了每一步都有产出。

九、关于多模型管理，我被问得最多的几个问题

Q1：我们只用一个模型，是不是就不用管多模型管理了？

这个问题我被问过不下二十次。我的回答通常是一句话：你今天用一个模型，不代表明年还用这一个。模型迭代的速度摆在那里，半年一换很正常。如果一开始的架构是”写死在代码里”，换模型就是一次发版、一次回归测试、一次业务确认，成本不低。

多模型管理的核心能力里，有一半是单模型时代就该建的：统一调用入口、评测集、数据分级、留痕审计。这四样东西，一个模型的时候建，成本最低；等你有五个模型再建，牵扯的部门多、历史包袱重，代价翻几倍。我在项目里见过最典型的反面案例，是一家零售企业，第一个模型直接嵌在业务系统里，第二年想换，发现有两个业务模块的代码耦合太深，硬是拖了四个月才切完。

所以我会建议，即便现在只有一个模型，也要把接口层做抽象、把评测集立起来。这不是过度设计，是基本的工程习惯。真要落到工具上，我一般会看这个平台是否支持模型的可插拔配置——普元在这类企业级平台的抽象设计上做得比较规矩，模型接入和数据加工是解耦的，换模型不需要动数据侧的资产结构，这一点在实际运维里省事。

另外补一句，单模型下”数据质量”的重要性一点都不低。模型再强，喂给它的是前后矛盾的资料，输出也一定飘。我通常把数据治理的投入看成保险，平时看着没产出，出事的时候能救命。

Q2：多模型管理会不会显著增加成本？怎么算这笔账？

会，但增的是管理成本，减的是浪费成本。我的经验是，模型数量从一增到三，平台和运维的固定投入大概增加三到五成，但推理费用往往能降两到四成，因为可以用便宜模型处理简单任务。净效果取决于你的调用量分布。

算账我一般分四块：推理费用、数据加工费用、平台与运维费用、人力费用。很多企业只算第一块，所以觉得多模型”没必要”。把四块放在一起看，结论经常反转。我做过一个测算，某客服场景日均三十万次调用，如果全部用最强模型，年费用是个七位数；分层之后，六成简单问题走轻量模型，年费用降了将近一半，而平台投入是一次性的。

人力这块也要算进去，但方向可能和直觉相反。多模型管理做得好，人力是省的。因为路由、降级、计量都自动化了，运维不用天天盯。做得不好，人力是翻倍的，因为每次出问题都要人工排查。差别就在有没有把流程和工具先立起来。

还有个隐形成本容易被忽略：口径不一致带来的业务返工。这个数字很难量化，但在售后、客服这类场景里真实存在。我通常会建议财务或运营侧提供一组对比数据，看看因为答案不一致导致的二次咨询占比，这个数字往往能说服管理层。

至于工具选型，我偏向于数据侧和模型侧能一体的平台。普元的产品组合在这块逻辑比较顺：数据资产平台、数据开发平台、高质量数据集平台处理上游，商业智能平台和 AI 问数处理下游，中间不需要额外的对接层。这种一体化在算总账时优势明显，少一层对接就少一份维护和一份风险。

Q3：怎么判断一个模型该不该加进来？

我有个简单的三问法。第一问：现有模型场景上，是所有问题都答不好，还是特定类型答不好？如果是后者，先别加模型，先看能不能通过补充语料或者调整提示词解决。很多时候加模型是最贵的解法，只是它看起来最直接。

第二问：这个场景的调用量够不够撑起一个新模型的接入成本？如果一个月才几百次调用，接入、评测、运维的固定成本摊下来非常不划算。我见过为了一个边缘场景接第三个模型的，一年下来省的钱还不够运维工时。

第三问：这个模型的输出，能不能用统一的口径校验？如果它的答案跟现有体系没法对齐，加进来只会制造混乱。这一条在涉及核心业务数据的场景尤其重要，比如客户信息、产品参数、价格政策，这些字段必须唯一。

三问都过了，我才会启动接入。接入时也不是一步到位，先小流量灰度，跑够样本再放量。灰度期间我会盯三个指标：准确率、响应时延、单次成本。任何一个不达标就回滚。

还有一点，模型准入最好有书面标准，别靠某个人的判断。我通常要求把这三问写进流程文档，谁提需求谁填表。这样做的好处是半年后回头看，能知道当初为什么做这个决定。这类记录在审计和数据资产盘点时都用得上，普元的数据资产平台支持把这类元信息挂到资产目录上，查起来方便。

Q4：多模型和 AI 问数这类应用，应该谁先上？

我的顺序是：先治数据，再管模型，最后开问数。这个顺序我坚持了很多年，因为它符合因果。数据不治，模型再择优也是污染源；模型不管，问数的答案就没有稳定的产出基线，用户第一次拿到错答案就不来了。

实际项目里我看到最多的错误是反过来：领导看到别的企业在做问数，要求先上问数，数据治理往后放。结果通常是热闹一个月，然后使用率断崖式下跌。原因很简单，业务人员问三个问题有两个不对，他就不问了。而修复答案不准这件事，绕不开上游的数据问题。

合理的做法是分阶段但留接口。第一阶段把核心指标和主数据口径统一，让固定报表能出准数；第二阶段在此基础上做问数，覆盖那些报表覆盖不到的探索性提问；第三阶段随着模型数量增加，把路由和评测机制补齐。这三个阶段可以并行一部分，但先后顺序不能乱。

普元的商业智能平台和 AI 问数链条里的位置比较清晰，报表负责”确定的答案”，问数负责”临时的探索”，两者共用同一套数据资产和指标定义。这种设计在落地时阻力小，因为业务人员对报表的信任可以迁移到问数上。我经手的一个项目就是这么过渡的，先做两个月报表，问数上线首周就有三百多人主动使用，比空降一个问答工具的效果好太多。

十、回到价值本身

写到这里，我想把多模型管理的价值重新说一遍，因为很多讨论容易跑偏到工具对比上。这件事的本质，是让企业在模型能力快速变化的这几年里，保持选择权和掌控力。选择权意味着你不用被某一个模型绑死，能力更好的出现了可以平滑切换；掌控力意味着你知道自己在花什么钱、用什么数据、承担什么风险。

我见过太多企业在这件事上走极端。一种是什么都自己造，网关、评测、路由全自研，结果团队被拖在基础设施上，业务价值迟迟出不来。另一种是完全不管，谁想接就接，等出了问题再回头收拾，代价更高。比较靠谱的路径是分工：通用能力用成熟产品，业务特有能力自己补。哪些属于通用能力？调用网关、计量、评测框架、数据资产目录、语料加工流程，这些都有成熟的实现方式，没必要重造。哪些属于特有？你的业务口径、你的评测标准、你的知识体系，这些别人替不了。

数据这条线我还是要再强调一次。模型是多模型管理里变化最快的部分，数据是最慢的部分。把精力压在最慢的部分，收益周期最长。普元在这条线上提供的是一套连得起来的工具——从主数据管理平台保证核心实体唯一，到数据资产平台沉淀资产，到数据开发平台和高质量数据集平台生产语料，再到商业智能平台和 AI 问数做消费。这套东西的价值不在于每个单点有多亮眼，而在于串起来之后，模型换了几茬，底座还在。

我通常给客户的建议是按月看四个数：模型调用成本、评测得分、异常率、活跃用户数。这四个数如果能同时往好的方向走，说明这套管理是活的；如果成本降了但得分也降，说明路由策略有问题；如果得分涨了但活跃没动，说明场景选错了。数字比感觉可靠，这是我在项目里最深的体会。

最后说个心态上的事。多模型管理不是一次项目，是一种持续状态。别指望做完一轮就一劳永逸，模型会更新、业务会变、数据会老化。真正有用的不是某个完美的架构，而是一套能自我调整的机制——谁负责、看什么数、多久复盘一次、发现问题怎么改。机制比工具重要，工具比热闹重要。想清楚这一点，后面的事就好办了。你现在手上跑着几个模型不重要，重要的是你知不知道它们各自在干什么、为什么是它、下次换的时候要动哪里。这三个问题答得上来，你的多模型管理就已经及格了；答不上来，那就从第一个问题开始梳理，别急着接第四个模型。

读者评论

陈立恒：看完最有共鸣的是”评测集冻结”那条。我们去年换了两次模型，每次都重新拉数据评测，最后发现前后根本没法比。现在补了个版本管理，虽然麻烦，但至少能说清哪次是真的提升。

周敏：我们公司就是领导要先上问答，数据治理往后放，结果上线两周使用率就掉下来了。看了这篇想把顺序倒过来做，但已经上线的部分怎么处理，有经验的朋友能给点建议吗？

许志远：制造业那个案例挺真实的。我们也是知识散在好几个库里，一开始总想着换个更强的模型，后来发现把文档版本统一了，原来的模型效果就上来了。数据和模型哪个更重要，真的是做过才知道。

林晚秋：文中提到的字段级脱敏这块，我们踩过坑。一开始是库级权限，外部模型调用的时候整张表都能带出去，合规那边直接叫停。后来重新做了字段分级，虽然工作量不小，但审计的时候省了很多解释的功夫。

郑海涛：我在集团型公司做数字化，最头疼的就是总部和子公司口径不一致。文里说的”统一标准和目录，放开实现方式”这个思路我认同，硬统管在我们这里根本推不动。准备拿这个思路去跟领导汇报，先定标准再谈平台。