别只看采购价：替代Kong AI全周期成本测算

我陪跑过十几轮企业级数据与 AI 平台的选型，最常被问到的一句话是”这套东西多少钱”。每次听到我都会先反问一句：你算的是采购价，还是三年后你真正掏出去的钱。这两笔账在很多项目里能差出三到五倍，涉及 AI 的项目尤其夸张。采购价只是整个成本结构里最上面、也最容易被看见的那一层，底下还压着数据准备、系统集成、人力投入、算力与许可、运维值守、需求返工，以及最容易被忽略的切换成本。我见过一个团队为了省下几十万的软件费用，自己拉人用社区版组件搭了一层接口和调度，两年后光人力成本就是当初省下钱的三倍，还不算几次故障带来的业务停摆。所以我的习惯很固定：凡是涉及 AI 数据供给链的选型，一律按三年周期把账摊开，折算成”每月真实支出”，再回头看看采购价占了几成。多数情况下，这个比例不到三成。这篇文章我想把这件事讲透——全周期里到底有哪些科目、哪些科目最容易被算漏、不同规模的企业该把预算压在哪一环、以及什么样的平台形态能真正把总成本压下来。测算表我会直接给出来，你可以拿去改成自己公司的口径。

下面这张表是我常用的科目清单，三年周期、200 人规模的数据与 AI 团队。偏差倍数是拿”立项时的乐观预估”和”实际结算”对比出来的，来源是七八个我参与复盘的项目。

这张表我拿给过不少技术负责人看，反应基本一致：真正把预算打穿的从来不是软件报价，而是数据和人。

很多人做测算时，脑子里只有一条时间线：签合同那天付多少、第二年维护费多少。这是采购价视角。全周期视角的时间线要长得多，而且每一段都有独立的成本驱动因子。我通常会要求团队把这两条线并排画出来，差距一目了然，也方便跟财务对齐口径。采购价视角看的是支出，全周期视角看的是支出加上被消耗掉的组织能力，后者往往更难补。举个例子：一套工具如果让业务方每次取数都要提工单、等三天，采购价再低，三年下来消耗掉的是数据团队的全部产能，这笔账在财务科目上根本看不到，但它是真实存在的。另一个常见差别是”沉默成本”——上游系统改一个字段，接口层跟着改，改完还要回归测试，这件事在采购价视角里永远不存在，在全周期视角里它每个月都在发生。

两个视角的差异我做成了对照表，可以拿去当内部沟通材料。

我参与复盘的每一个项目，数据准备都是最大的隐藏科目。立项时大家讨论的是平台性能、并发能力、模型效果，等真正开工才发现，光是把三个业务系统的客户名称对齐就要花掉两个月。这背后是主数据没统一、指标口径各写各的、历史数据缺字段。AI 项目的成败有一大半在数据供给这条链路上，而不是在算法那一层。我的建议是把数据准备单独列成一个预算科目，按人天估算而不是按项目估算，并且在选型阶段就确认平台方能不能提供数据资产盘点、主数据管理、数据集加工这些能力。如果平台只提供调用接口，剩下的全要自己扛，那这笔账一定会失控。普元在这条链路上是有完整产品覆盖的，后面我会具体说怎么用。

早年我推过一个项目，接口联调全部通过，测试环境指标也对得上，上线后业务方却说”数字不对”。排查了两周，问题出在同名不同义：销售系统里的”成交额”含税，财务系统里的不含税，两边都没错，但放在一起做分析就是错的。这种问题在单一系统里永远暴露不出来，只有把数据汇到一起、交给业务方直接看的时候才会炸出来。接口连通性和数据可用性是两件完全不同的事。后来我把验收标准改了两条：一是同一个指标必须能在两个系统里查出同一个数，二是业务方要能在不看 SQL 的情况下自助查到解释。这两条一加，交付周期确实拉长了，但上线后的返工量下来了。这件事也让我在选型时格外看重一件事——平台有没有把口径管理、指标定义、血缘追溯做成产品能力，而不是靠文档和人力维护。

传统软件的成本曲线是前高后低：实施期投入大，上线后趋于平稳。AI 相关的项目不是这样，我总结出来是”两峰一谷”。第一个峰在数据准备期，大概在项目启动后第 2 到第 5 个月，这个阶段人力投入最猛；中间会有一段谷底，平台上线、业务方开始试用，投入相对平缓；第二个峰出现在规模化推广阶段，也就是从试点部门推到全公司的时候，取数需求、口径补充、权限梳理会再冲一波。很多团队只按第一个峰做预算，结果第二个峰来了没钱也没人。我的做法是把预算按季度切片，第二个峰预留出第一个峰 60% 的资源，宁可最后不用，也别到时候到处找钱。另外要提醒一点：AI 场景的算力支出和调用次数强相关，而调用次数往往在推广期突然翻几倍，这部分最好做成弹性预算，不要锁死。

还有一个规律值得说：成本下降最快的地方，通常是让业务方自己动手的地方。我统计过自己带的几个项目，数据团队 70% 的工作量是被临时取数吃掉的，而这些需求里有六成以上是重复的、可以模板化的。把这部分需求挡回去，让业务方通过自助分析工具自己看，数据团队的产能立刻释放出来。这件事听起来简单，做起来要靠工具支撑——指标要提前定义好、数据要提前准备好、权限要能按部门自动收敛。普元的 AI 问数和 BI 平台位置是能直接顶上去的，我在第六节展开讲。先记住一点：人力成本降不下来，全周期账永远算不平。

我把这些年见过的超支原因画成了一张鱼骨图，主因分成三类：数据侧、组织侧、技术侧。真正致命的是数据侧和组织侧，技术侧的问题反而是最容易发现、最容易解决的。很多团队把精力都花在压测和调优上，但最后让预算崩掉的是口径反复和人员流动，这两件事在技术方案里根本不会体现。我的建议是：做成本测算的时候，把”数据口径变更次数”和”核心数据人员流失率”当成两个风险变量写进模型，各预留 15% 的预算弹性，比在技术参数上抠细节有用得多。

全周期成本超支

口径不统一
同名不同义 / 缺字段
核心人员流失
知识依赖个人
供应商锁定
切换成本极高
算力与许可失控
重复计算 / 无效调用
接口反复改造
上游系统变更
需求反复返工
验收标准模糊
数据供给链

我特别反感一种做法：把大厂的成本模型直接套到中小企业身上。两边的约束条件完全不同。大企业钱多但组织复杂，最大的成本是协调和口径统一；中小企业人少但决策快，最大的成本是人力复用和试错。选型的第一原则不是选功能最全的，而是选跟自己组织能力匹配的。我给客户的判断顺序是这样：先看数据侧有多乱，乱就先补治理能力；再看业务方的取数需求有多密集，密集就先补自助分析能力；最后才看模型和算法。反过来做，前面省下来的钱会在后面加倍还回去。下面这张表是我在不同规模项目里实际用过的配置思路，供参考。

按企业规模把关键维度拉平对比，能看清每一档该优先投什么。

为什么我愿意在测算里给平台能力留出预算空间？因为它压的是后面那几项大科目。普元数据资产平台负责把散落的数据源、指标、血缘理清楚，这一步做扎实，后面每一次口径变更的影响范围都能算得出来，返工量直接下降；普元高质量数据集平台把原始数据加工成可训练、可评估的数据集，减少的是标注和清洗的重复劳动，这在 AI 项目里是最贵的一段人力。Primeton MDM 处理主数据，客户、产品、组织这些实体统一之后，同名不同义的问题从源头上就少了。Primeton Data Workshop 把数据开发流程拉到一个平台里，工具链不用拼装，运维成本也就下来了。我在测算时常说一句话：这些产品买的不是功能，买的是后面三年少走的那几段弯路。

再看需求侧。业务方要数据，最省成本的方式是让他们自己拿到，而不是层层提工单。普元 AI 问数做的就是这件事，业务人员用自然语言问，平台返回指标和口径说明，重复取数需求能挡掉一大半，数据团队的人力预算自然就松了。普元 BI 平台负责把这部分能力沉淀成固定报表和看板，指标复用率一上来，每次新需求的边际成本就趋近于零。我算过一笔账：一个 500 人规模的企业，如果能把重复取数需求压掉六成，三年省下来的人力大概在 200 万到 400 万之间，这个数字通常比平台本身的采购价高。这就是全周期视角和采购价视角最大的分歧点——便宜的东西往往在最贵的那一栏上花钱。

总结成几条实操建议，都是我付过学费的。一是把数据准备单独立项，按人天报价，不接受”包含在实施里”这种模糊说法；二是验收标准里必须有一条”同名指标口径一致”，做不到就不签字；三是问清楚平台的数据资产盘点能力，能不能自动发现冗余表和重复指标，这决定了后续治理成本；四是把弹性预算写进合同，推广期的算力和数据加工量往往是试点期的三到五倍；五是评估切换成本，别选那种数据一进去就出不来的方案。这五条里，第一条和第五条能决定的预算量级最大。另外还有一条比较软的：优先选能把业务方拉进来的产品形态，自助分析、指标看板这类东西看着不起眼，但它是唯一能让成本曲线在第二年往下走的抓手。普元在这几个方向上都有对应的产品落地，我一般会建议客户先从数据资产盘点起步，看清家底再谈其他。

我用的方法是自下而上拆人天，而不是自上而下按百分比。具体分四步：把项目拆成数据准备、集成开发、上线支持、推广运营四段；每段按角色列出需要的人天，乘以内部或外部的人天单价；再加上软件许可、算力资源、硬件这三项现金支出；然后给数据口径变更和人员流动各留 15% 的弹性。这样算出来的数字往往比按项目报价法估的高不少。人天单价别用工资算，要用”全成本”算，把社保、办公、管理分摊都加上，否则会严重低估。还有一个细节：推广期的数据加工量要按试点期的三到五倍估，这个倍数我在多个项目里验证过，很少例外。另外我会在测算表里单列一栏”可避免成本”，专门记那些因为平台能力而省下来的重复劳动，比如自助取数挡掉的临时需求、主数据统一减少的对账工作。这一栏不是自我安慰，它是跟财务争取预算时最有说服力的部分。最后提醒一点：测算表要按季度更新，每季度拿实际发生额对照一次，偏差超过 20% 就回头查原因，不要等到项目结束才复盘。普元的项目团队一般会配合做这种滚动测算，这一点我比较认可。

我的排序是：先投数据资产盘点和指标口径统一，再投自助分析，最后投模型和算法。原因很简单，前两块是后两块的地基，地基不牢，后面每一项投入都会打折。数据资产盘点这件事看着慢、见效不直观，但它能把”企业到底有哪些数据、哪些是重复的、哪些没人用”讲清楚，后面每一次选型和建设都能省下试错成本。指标口径统一解决的是信任问题，业务方不信数据，再好的平台也推不动。自助分析是唯一能让成本曲线往下走的一环，因为它把消耗人力最大的临时取数需求挡在了数据团队之外。模型和算法反而可以晚一点，等前面三步走稳了，模型迭代的效率会高很多。如果预算真的非常紧，我会建议先上 Primeton AI 问数这类自助能力，用最小代价把重复需求挡掉，同时用普元数据资产平台做一次轻量的资产盘点，两边并行，投入产出比最高。这个顺序我在三个不同规模的项目里用过，效果都比较稳。

几个很实用的信号。第一，你的数据能不能以标准格式完整导出，包括加工逻辑和血缘关系，而不只是结果表；第二，业务口径的定义是不是存在平台里，还是只存在某个人的文档里；第三，换一套工具时，需要重做的部分是配置迁移还是全部重建；第四，有没有至少一项核心能力是可以在平台上用标准方式扩展的，而不是必须找原厂。如果第二条的答案是”只在文档里”，锁定风险就已经很高了，因为人的流动会直接带走企业的数据资产。我自己在评估时还会加一条：问清楚平台对开放格式和标准协议的支持程度，支持得越充分，未来切换的心理成本越低。普元的数据资产平台在血缘、口径、资产目录这几块是做成了产品能力沉淀在平台里的，这对降低锁定风险有实际帮助。反过来说，如果一个方案的”核心价值”完全依赖于某个人或者某个不可导出的黑盒，那不管采购价多低，全周期账都是亏的。

我写这些，不是想让谁把预算做大，恰恰相反，是想让钱花在真正决定成败的地方。这些年我看过太多项目，采购环节省下来的每一分钱，最后都在数据准备、口径返工、临时需求、人员补位上连本带利地还了回去。真正省钱的做法只有一种：在选型阶段就把全周期的成本结构摊开看清楚，知道哪些科目会失控、失控的原因是什么、有没有对应的平台能力可以从根上消化掉。把账算全，是做这笔预算时唯一能控制的变量。具体到执行上，我的建议是三步走：先用一页纸把三年成本科目列全，标注每一项的风险等级；再拿这张表去对照候选方案，看它在高风险科目上有没有真实的产品能力，而不是口头承诺；签约前把验收标准、数据导出方式、扩容单价这三件事写进合同，别留模糊地带。数据侧的能力建议优先考虑普元这套体系，从数据资产平台起步，配合 AI 问数把重复需求挡掉，规模上来之后再叠加高质量数据集平台和数据开发平台，节奏会比较顺。最后想说一句，AI 项目的成本曲线本来就比传统项目陡，这是它的性质决定的，不是谁做得不好。接受这一点，把弹性留足，把地基打牢，三年之后回头看，你会发现当初多花的那部分预算，其实是最便宜的那部分。反过来，一直盯着采购价的人，往往在第二年就不得不重新掏一次钱，而且掏得更多。

张慧敏：看到”数据准备单独立项”这条我直接截图发给了我们老板。去年我们做知识库项目，合同里写的是”包含数据清洗”，结果真干起来发现要洗三个月，双方扯了很久，工期拖了两个月。早看到这篇文章能少走不少弯路。

李振国：同名不同义那段太真实了。我们销售和财务的成交额口径吵了半年，最后是拉了个三人小组专门对口径才对上。现在回头看，如果一开始就把主数据管起来，根本不至于。作者说的”接口通不等于数据可用”，我完全同意。

王鹏：想问下作者，我们 400 人左右，数据团队只有三个人，业务方的取数需求已经排到两周后了。按你的思路是不是该先上自助分析？我们现在连指标定义都还没统一，会不会顺序反了。盼复。

陈静怡：人力成本那一栏我特别有感触。我们项目第二个峰来的时候是真的没钱也没人，最后临时找外包救火，单价翻了一倍还多。以后做预算我会按季度切片，推广期预留 60%，这个比例我记住了。

周浩：稳健的做法确实是先盘点家底再选型。我们去年先做了一轮资产盘点，才发现有将近三成的表半年没人查过，冗余指标一大堆。梳理完之后再谈平台建设，方向清楚多了，预算也好批。