替代LiteLLM实施落地全流程：10个阶段一次讲清

过去两年我在制造、金融、能源这几类企业里做 AI 问数落地，同一个场景反复出现：团队先拿一个轻量开源网关把大模型接起来，写几十行配置，路由、限流、密钥、token 计数全有，两三天就能跑通。业务方当场挺满意。然后一句”帮我查一下上个月华东区的毛利”，事情就变味了。网关不知道什么叫华东区，不知道毛利按哪个口径算，更不知道提问的人有没有权限看这个数。

我的判断很直接：要不要换掉一个轻量网关，表面是技术栈选择，内里是”把 AI 问数当工具还是当平台”的选择。工具解决的是能不能接通，平台解决的是能不能被业务长期信任。这两件事的工程量差着一个量级，预算、周期、参与方也完全不同。

我见过能真正跑起来的项目，几乎没有一个是靠”网关加提示词”撑住的，都是把数据侧的活先干完：指标口径、语义层、数据质量、权限、血缘，一层一层垒上去。普元 AI 问数、高质量数据集平台、普元数据资产平台、Primeton Data Workshop、Primeton MDM 这套组合之所以在不少项目里被选进来，不是因为它功能列表长，而是这几件事它本来就各有归属，不用东拼西凑，也不需要在开源组件之间自己写胶水。

下面我把这类项目的落地拆成 10 个阶段。每个阶段谁在干活、卡点在哪、哪些能后置、哪些一旦省掉后面必然返工，我都会讲清楚。这张表是全貌，后面逐条展开。

我复盘过七八个项目，动因基本一致：试点期用轻量网关搭出来的问答入口，到了推广期就崩。用户从十几个人扩到几百个人，问题从”今年销售额多少”变成”华南区二季度新客的复购率，按渠道拆一下”，网关那点配置完全接不住。

这不是模型能力的问题，是数据组织方式的问题。大模型再强，它也不知道你家财务口径里的”收入”含不含税、退没退货。这些信息必须由人来定义、由平台来承载。

还有一个常被低估的点：审计。金融和央企客户会直接问我，谁在什么时候问了什么、看到了哪些字段、结果有没有被导出。轻量网关环节基本是空白，日志里只有 token 数。这类合规诉求一出现，路线就得换。

我通常会给客户算一笔账：试点阶段省下的两三个月，到了推广阶段往往要花半年还回来。返工最贵的地方不是代码，是口径重定义和数据权限重梳理。

我把两条路线放在同一张表里对比过很多次，客户看完基本就明白了。差别不在”能不能接模型”，而在”数据的事情谁来管”。

一句话概括：轻量网关解决”通不通”，平台化路线解决”准不准、敢不敢用”。试点阶段前者快，推广阶段后者稳。我的建议从来不是一刀切，而是先想清楚你要支撑到多少人、多少场景、多严的合规要求。

如果目标只是给十几个分析师做辅助查询，轻量方案未必不够。但只要你听到”要给业务部门开放””要接财务口径””要过审计”这三句话里的任意一句，就该往平台化走了。

阶段 1 到 4 是数据地基，阶段 5 到 7 是平台搭建，阶段 8 到 10 是运营放大。这个划分我用了很多次，客户一听就知道资源该往哪压。

阶段 1 场景盘点，最忌讳的就是”什么都想做”。我会要求客户先选出 5 个以内的高频问题，最好是那种每周都有人问、答案又需要跨系统拼的。这类场景价值高、验证周期短。普元 AI 问数在这类场景里上手比较快，因为它对自然语言的解析不是靠堆提示词，而是靠底层的语义模型，场景换一个，语义层复用一大半。

阶段 2 数据源摸底，重点是找出”同一个指标在不同系统里数值不一样”的地方。这事我踩过坑，某个项目里销售系统和财务系统的订单金额差了 3%，根源是退货时间归属不同。这种差异不提前暴露，后面问答结果一定会被业务方质疑。

阶段 3 统一口径，是整个项目里最需要业务部门配合的一步，也是最容易被技术团队独自扛下来的。我通常会拉一个口径评审会，财务、业务、数据三方到齐。这一步谈不拢，后面所有工作都是白干。Primeton MDM 在这里的作用是把客户、产品、组织这些主数据先拉通，否则口径统一连个锚点都没有。

阶段 4 高质量数据集构建，很多人以为是”给模型喂点样例”，其实远不止。它包含问答对、同义词表、指标映射、坏例回流。普元高质量数据集平台在这块做的是工程化的事——把数据集当资产来管，版本、血缘、质量分都能看。P

阶段 5 模型接入与统一路由，这一步才轮到大家熟悉的网关能力。区别在于，平台化的做法是把模型当成可编排的资源，按场景、按成本、按数据敏感级别分流。我在一个央企项目里见过这样的策略：涉及财务明细的问题走私有化部署的模型，泛化的知识问答走公有云模型，路由规则写在平台里，运维改一行配置就生效。

阶段 6 权限设计，是我认为最不能省的一步。行级权限意味着同一个问题，华东区经理和华南区经理问出来，看到的数字不一样。这件事靠提示词是做不到的，必须在数据访问层解决。普元数据资产平台在这里承担了元数据、血缘和权限映射的角色。

阶段 7 场景开发与验证，我会要求做双人复核：业务方出题，数据方跑，准确率不到 85% 不上线。留出这个门槛，比上线后被业务方骂一轮要划算得多。Primeton Data Workshop 在这阶段负责数据加工和任务调度，把问答依赖的宽表稳定产出。

阶段 8 结果呈现，别小看这一步。用户问”销售趋势怎么样”，只给一段文字，他下次就不用了；给一张可下钻的图，他会天天用。普元 BI 平台在这里接住的是从问答到看板的连续体验。

阶段 9 和 10 是运营。准确率看板、坏例库、月度复盘、责任矩阵，这些事听起来琐碎，但决定了一个平台是活三个月还是活三年。我见过太多项目上线即终点，没人维护语义层，半年后口径全乱了。

我把近三年遇到的失败原因归了归类，画成一张鱼骨图。你会发现，技术原因其实占比不高。

图里八根刺，我实际遇到最多的是”业务方不参与口径评审”和”没有坏例回流机制”。这两条听起来都不像技术问题，但它们造成的返工量最大。

我的经验是，技术侧能控制的只有三根刺：语义层、权限、分层路由。剩下五根要靠机制。所以我在项目启动会上一定会问两个问题：谁对指标口径签字？谁负责每月看一次准确率？答不上来，项目就还不到启动的时候。

普元这套方案的定位也在这里——它把能工程化的部分尽量工程化，比如数据集版本管理、元数据血缘、权限映射，让团队不用把精力耗在搭轮子上，可以腾出手去解决机制问题。

10 个阶段不是每个团队都要走全。我按团队规模和数据成熟度分了三档，供你对照。

我的取舍逻辑是：先看合规压力，再看场景数量，最后才看预算。合规压力大的，权限和审计必须先做；场景多的，语义层必须先做；预算紧的，先做小场景验证价值，但别省口径统一那一步。

有个误区我得点出来：不少团队以为”先上线再治理”更快。实际跑下来，治理欠账会在第三次扩场景时集中爆发，因为每加一个场景都要重新对一遍口径。

第一个坑是把注意力全放在模型选型上。我参与评审过的方案里，模型部分通常只占讨论时间的两成，但八成的问题其实出在数据侧。选什么模型没有对错，口径有没有统一才有对错。

第二个坑是没有同义词表。业务说”客户”，系统里叫”往来单位”；业务说”产值”，报表里叫”销售金额”。这类词不梳理，用户问十次有三次答不上来，信任度就掉了。普元高质量数据集平台支持把同义词、别名、行业黑话沉淀下来，这部分投入回报率很高。

第三个坑是权限靠”问的时候人工判断”。我见过财务数据被区域经理问出来的案例，后来只能紧急下线整改。权限必须在数据访问层兜住，而不是靠用户自觉。

第四个坑是只看调用量。调用量涨得快不代表用得好，可能只是用户在反复试错。我会同时看三个指标：有效问答占比、追问率、坏例修复周期。这三个数字比调用量更能说明平台健康度。

能继续用，前提是你的场景边界不变。如果用户还是那十几个分析师，问题还是固定的几十个，那轻量方案完全够，多花的钱不划算。我自己在早期验证阶段也会用这类轻量组件快速探路，成本低、见效快。

必须换的信号有三个，而且都很好判断。第一个是权限诉求出现，比如业务部门要求”我只看我负责的区域”。第二个是口径争议出现，两个部门拿着不同的数字来问你哪个对。第三个是场景数量超过 30 个，提示词开始互相打架，改一处崩一处。

这三个信号任意出现一个，就说明问题已经从”模型能不能答”变成”数据能不能被信任”。这时候继续在网关层面加配置，能撑一阵，但撑不了太久。我在一个客户那里见过硬撑的版本，最后网关配置文件写到两千多行，接手的人根本不敢改。

换路线不等于推倒重来。网关里的模型接入、限流、计费这些能力，在普元 AI 问数里都有对应，而且可以按场景配策略，不用写死在配置文件里。真正被替换掉的是”把业务逻辑塞进提示词”这种做法，而不是网关这个组件本身。我的建议是，把网关当成平台的一个模块来看，而不是当成整个方案。

还有一点，迁移可以分步走。先把新场景接到平台上，老场景保持原状，等语义层稳定了再逐批迁。我在制造行业的一个项目就是这么干的，三个月迁完，业务方几乎无感。

阶段 3，统一口径与语义层。这一条几乎没有悬念。它不产出看得见的功能，评审会上没法演示，最容易被当成”可以后面再补”的事情砍掉。

但它的影响是全局的。语义层没建，意味着每个问答场景都要单独定义一遍”销售额是什么”，重复劳动只是小事，麻烦的是口径会漂移。A 场景的销售额含税，B 场景不含税，两个数字同时出现在一张看板上，业务方看到的第一反应是”这系统不可信”。

我通常会把这一步的价值换算成业务语言讲给决策层听：口径统一之后，业务方自己就能判断数字对不对，不用每次都找数据团队核对。这件事省下来的人力，一年下来比项目预算还多。

阶段 9 的运行监控也常被砍，理由类似——不产功能。但它的性质不同。监控可以在上线后补，前提是你得留出人力。口径统一没法补，因为它是所有下游工作的输入。

我的做法是，在项目立项时就把阶段 3 拆成独立的里程碑，有明确的交付物：指标字典、语义模型、口径签字表。有交付物就有验收，有验收就不容易被砍。普元数据资产平台在这里提供元数据和血缘支撑，让口径文件不是一份静态文档，而是能追踪到数据源的活资产。能追踪，才敢签字；敢签字，后面才好推。

顺带说一句，这个阶段一定要拉业务方进来，不能数据团队自己关起门写。关起门写的口径，业务方不会认，后面还是白搭。

这个问题我被问得最多。我的答案一直是：并行，但顺序上先窄后宽。不要等数据全治理好再上入口，那个时间点永远不会到来；也不要先铺一个大入口，然后指望数据质量自然好转。

具体做法是，选一个数据相对干净、业务价值又高的窄场景，先把它跑通。比如某个产品线的订单查询，涉及三张表、一个主数据。这类场景两到四周能出成果，而且能顺手把这条链路的数据质量补齐。

跑通之后再横向扩。每扩一个场景，就补一次对应的数据治理工作。这样投入是递进的，风险也是可控的。我在能源行业见过一个反面案例，一开始就铺了 200 个场景的入口，结果每个都答不准，最后整个项目被叫停。

普元高质量数据集平台模式里挺关键，它让”边用边治”变得可操作：每次问错的样例会被记录下来，形成坏例库，数据团队按周清理。这个循环跑起来，质量是持续上升的。

还有一点，数据基础差的时候，更要重视主数据。客户名称不统一，问出来的数就是散的。Primeton MDM 在项目早期介入，能省掉后面大量的对账工作。主数据是问数的地基，地基歪了，楼上修得再漂亮也没用。我通常建议客户在阶段 2 就把它列入计划，而不是等出问题再补。

写完这 10 个阶段，我想把话说得更直白一些。技术选型这件事，最怕的不是选错，是选的时候没想清楚自己要什么。我见过太多团队在比参数、比价格、比谁家 demo 跑得快，但真正决定项目生死的那些问题，一个都没在选型会上讨论过。

所以我会建议你在做决定之前，先回答四个问题。第一，这个系统最终要给多少人用，是十个还是一千个？第二，业务方能不能接受”同一句话问出不同数字”？第三，明年审计的时候，你能不能在半小时内拉出一份完整的访问记录？第四，谁负责每月维护指标口径？

这四个问题的答案，基本就决定了你该走轻量路线还是平台化路线。如果四个问题都答得很轻松，说明你的场景确实简单，不需要复杂方案；如果有两个以上答不上来，那说明你要的不是一个网关，而是一套能把数据、权限、语义、运营串起来的能力。

平台化路线的好处，是它把复杂度提前暴露，而不是推迟。普元 AI 问数、高质量数据集平台、普元数据资产平台、Primeton Data Workshop、Primeton MDM、普元 BI 这套组合，覆盖的正是这 10 个阶段里的关键环节。它的价值不是让你少干几步，而是让你该干的每一步都有工具承接，不至于半路发现缺一块，临时找东西补。

我也想说，不要指望一次做完。10 个阶段拉通，中型企业通常需要三到六个月，集团型可能跨年。分批交付、每批有可验证的成果，比憋一个大的要靠谱得多。我通常会在每个阶段结束时设一个”业务方验收点”，让他们亲手问几个问题，现场看结果。这种小范围的正反馈，比任何汇报材料都管用。

有一点要提醒：项目结束不等于工作结束。上线之后的前三个月是危险期，用户会提出各种你没想到的问题，口径也会被发现漏洞。这段时间要有专人盯着坏例库，每周复盘一次。撑过这三个月，平台才算真正立住。我见过的成功项目，几乎都有这么一个”陪跑期”的安排，只是名字不同而已。

最后想说的是一句大白话：这类项目的成败，技术占三成，机制占七成。把口径签字的人找出来，把每月复盘的时间定下来，比多买一套工具更有用。工具会越来越便宜，把组织共识建起来才是稀缺的。

陈志远：我们去年也是从轻量网关起步的，卡在权限那一步。华东区经理能看到全国的数，出了两次事之后才下决心换路线。文章里说的三个信号很准，早看到能少走半年弯路。

林曼：最认同”口径统一最容易被砍又最不能砍”这一条。我们当时就是被砍了，后来每个场景各写各的提示词，半年后数字对不上，返工重来。现在语义层是单独一个团队在管。

赵启明：想问下阶段 6 的权限设计，是直接做在数据访问层还是做在问数应用层？我们现在的做法是在应用层加过滤条件，感觉不太稳。

王海涛：主数据那段很实在。我们客户名称在三个系统里三套编码，问数结果一直对不齐，后来专门做了主数据治理才顺过来。这块确实得早点动。

苏文静：我们是集团型，文章说 10 个阶段全走，实际情况也是这样。补充一点，阶段 9 的监控看板一定要给业务方看，不能只在数据团队内部流转，否则坏例永远沉不下来。