这两年聊AI中台的人明显多了起来但真正把中台建起来、又让业务部门持续用起来的团队说实话不多。我见过好几家公司预算批了、集群买了、平台搭了、标准也定了结果大半年过去业务线还是自己拉人写脚本调API平台最大的作用就是年报PPT里多了一张架构图。问题出在哪我的判断一直很明确不是AI中台这个方向错了而是绝大多数团队把“建设中台”这件事做成了重型工程。AI中台建设应轻型起步——这句话不是一句口号而是我在多个项目里踩坑踩出来的结论。这篇文章不劝你“别建中台”也不给你画一张横跨十几条业务线的大蓝图而是把“为什么必须轻、具体怎么轻、踩过哪些坑”一次讲透适合正在规划AI平台的技术负责人、架构师和想推动AI落地的产品技术团队。1. 为什么AI中台必须“轻型起步”1.1 重型中台的三条死路先说反例。我发现凡是把AI中台做失败的项目几乎都踩进了同样三个坑里。第一个坑叫“先建平台再找场景”。团队花大力气搭好了模型服务平台、数据标注平台、Prompt管理平台GPU集群也到位了然后才开始问业务部门你们有什么AI需求业务部门反过来问这平台能干啥两边对着空气握手。最后平台成了摆设业务该外包外包、该自研自研中台团队沦为“内部云厂商”天天帮人申请资源。平台建设本身变成目的真实业务问题反而没人关心。第二个坑叫“标准先行流程繁重”。为了体现中台的“统一管控”很多团队上线了各种规范所有模型必须统一注册、所有数据必须统一治理、所有需求必须走评审工单。听起来很正规但AI落地这件事本质是快速试错、快速迭代。业务方要的是这周能上线的功能你告诉他得先过三周的标准评审他唯一的回应就是那我不用你的平台了。标准和规范是约束出来的不是设计出来的——这句话我后面还会反复讲。第三个坑叫“服务边界不清”。有的团队把中台定位成“AI能力一切皆可做”结果成了业务方的外包研发今天做个OCR、明天做个推荐、后天做个数字人什么都能接什么都沉淀不下来。年中复盘的时候发现做了30个需求但没有一个需求变成了可复用的平台能力。中台团队变成了AI救火队人力全耗在定制开发上平台资产几乎为零。这三个坑有个共同点它们都不是技术问题而是策略问题。重投入、深流程、宽边界让中台从第一天起就背上了巨大的沉没成本一旦方向错了掉头极难。轻型起步的本质就是把“掉头的成本”控制在最低。1.2 “轻型”不是偷工减料是工程策略有人听到“轻型起步”就担心那我们是不是不用做架构设计了是不是随便拿几个API拼一拼就行不是完全不是。轻型起步不是“不盖地基就住人”而是“先做一个样板间确认业主真的喜欢再浇筑整栋楼”。这里有一个很关键的时代背景今天的AI基础设施已经便宜到了“不需要重资产就能验证价值”的程度。模型调用走API一个月成本可能就几百块开源的模型随便下载本地跑个推理也不是难事向量数据库和编排框架都有成熟的开源方案。这跟五年前“想把AI用起来得先自建一套分布式训练平台”是完全不同的逻辑。基础设施边际成本趋近于零意味着你完全可以先只花很少的资源把业务价值验证清楚再决定哪里值得投入。所以我理解的“轻型”包含着三个原则。第一最小闭环从单个真实业务场景出发两周内跑出一个能用的版本。第二能力可演进哪怕第一版就是“一个脚本调API”也要在代码结构、接口设计上留出后续扩展成平台能力的空间。第三接口向后兼容今天你给业务方的是一个函数明天你给业务方的是一个服务后天你给业务方的是一个自助平台只要接口不破坏迁移成本就低。很多人把“轻型”理解为“将就”但我恰恰认为轻型起步是当前工程环境下的最优策略。你不需要一开始就想清楚中台的全部边界但你必须在每一次迭代里都想清楚这一步做的这件事是不是能被下一步复用。1.3 先问自己你真的需要中台吗再泼一盆冷水不是所有团队都需要AI中台。我见过很多团队AI应用就一两个连“台”的影子都没有就开始规划中台组织、申请中台编制最后养了一个闲团队。判断标准其实很简单如果你的AI能力只有一条业务线在用或者各个业务线各玩各的互不干扰那中台不是必需品你需要的是一个AI应用不是一个平台。那什么时候才真正需要中台有几个信号同时出现的时候。第一两个以上业务线开始重复做类似的事情比如都要搞文档解析、都要做向量检索、都要对接同一个模型这就是“重复建设”的信号。第二基础能力开始拖后腿比如每个项目都自己处理模型权限、审计日志、数据脱敏吃力且不规范这就是“公共能力缺失”的信号。第三业务方对AI的依赖已经不是偶尔尝鲜而是希望有稳定的SLA、有自助服务的入口这就是“平台化”的信号。把这三个信号当作启动中台建设的门槛你就能避免一大半“为了中台而中台”的悲剧。而即使这些信号都出现了我依然建议轻型起步——先把重复建设最严重的那一块收拢成公共能力验证好用了再逐步把其他能力并进来。中台是长出来的不是规划出来的。2. 起步前先做减法场景选型与需求收敛2.1 用一页纸给候选场景打分轻型起步的第一步不是选技术而是选场景。很多团队犯的错是把“AI中台”当成一个整体项目上来就找一堆场景什么都想覆盖。正确的做法是从一堆候选场景里挑出那一个最值得用最小成本验证的场景把它做成标杆再谈扩展。我习惯用一个非常朴素的打分表五到六个维度每个维度1到5分加起来排序。别小看这一页纸它能把感性争论变成理性排序。评估维度打分说明权重参考业务价值解决这个场景的问题能为业务省多少人天或增加多少收入30%痛点强度是“不得不解决”的真痛点还是“有更好没有也行”的伪需求20%数据就绪度相关数据是否已经数字化、可获取、质量可接受20%落地复杂度涉及多少系统改造、多少跨部门协作、是否有流程阻碍15%复用潜力这个能力能否被其他业务线复用成为平台的种子能力10%合规风险是否涉及敏感数据是否有合规上的红线限制5%拿我自己做过的一个排序举例某集团当时有四个候选场景——智能客服工单分类、营销文案生成、经营报表问答、合同关键信息抽取。按这个表格打完分最后胜出的不是看起来最“高大上”的经营报表问答而是工单分类。为什么因为工单分类的业务价值极其清晰客服团队每天几千张工单人工分派费时费力错了还要扯皮数据早就存在工单系统里结构化程度高落地只需要给工单系统开个接口业务侧没有大的流程变化而且“工单分类”这个能力后面完全可以复用到销售线索分配、售后问题派单上复用潜力很高。而报表问答听起来炫酷但数据口径不统一业务部门自己都说不清指标定义做出来大概率是鸡肋。选场景的逻辑用一个生活类比就是哪个房子漏水最严重先修哪个而不是哪个房子装修出来最好看先装哪个。AI中台的第一个项目必须是一个能让业务方挨个点头说“这个真有用”的项目而不是一个让架构师自嗨的项目。2.2 需求收敛的三个技巧场景确定之后紧接着就是需求收敛。这一步做不好轻型起步会直接变成“中型起步”——需求越收越多范围越扩越大和重型起步殊途同归。技巧一只做“单点闭环”不要做“全家桶”。业务方跟你说“我要一个智能客服”你不要真的给他一个完整的智能客服而是拆开来看智能客服包含意图识别、问答检索、工单生成、情绪识别、人机转接等一堆能力每个能力都够一个人团队做半年。轻型起步的做法是从里面挑一个最痛的点比如“工单自动分类”。一个点做到90分好过五个点各做到60分。因为90分的单点能真正进入业务流60分的多点只能停留在演示阶段。技巧二用业务侧的指标反推需求。不要问业务方“你想要什么功能”要问“你现在的关键指标是什么、哪里最痛”。如果业务方说“我们人工分单准确率只有80%每天浪费10个人力在错误流转上”那需求就非常清晰了——把准确率提上去把错误流转降下来。这个指标就是你们共同的北极星后面每一轮迭代都围绕它不跑偏。技巧三给MVP定一个保底时间盒。我的经验是第一个版本的交付周期不能超过半个月。为什么是半个月因为超过半个月业务方的预期就开始变得抽象会不断往里加需求短了又做不出足够可信的效果给业务看。两周出一个真实可用的V1业务方试用后提出的反馈才是真正有价值的需求来源。这三个技巧的本质是同一件事把无限的问题空间压缩到一条可执行的最小路径上。AI项目最容易失控的地方不是技术难度而是需求发散。2.3 从0到1再到N的路径规划单点场景做成功之后很多团队会兴奋然后犯一个错误马上把“全面平台化”提上日程。我建议千万别这么干。从0到1验证的只是一个具体场景你要做的是把1变成N但这个N不是一次性铺开的而是有路径的。我总结过三种最常见的扩展路径。第一种叫“同类场景复制”。工单分类成了那销售线索分类、售后投诉分类本质上都是一样的套路。这种扩展的重点是提炼出“分类”这个公共模式数据接入方式、模型调用方式、效果评估方式都能沉淀成模板。第二种叫“能力升级”。从“工单分类”升级到“工单自动处理建议”从“给你分好类”变成“给你推荐回复策略”。这种扩展意味着底层能力的复杂度上升但价值也更高。第三种叫“横跨业务线共享”。A业务线做完之后B业务线看到效果主动找上门这时候你不需要再从头做一遍因为组件已经沉淀好了。路径规划要解决的另一个关键问题是哪些东西要抽出来做成平台能力哪些东西应该留在业务线。我的原则是——如果两个以上场景都在用同一个组件抽出来如果只有一个人用先留在业务线里。过早抽象是轻型起步的大忌因为你还没搞清楚共性是什么抽象出来的往往是你想象中的共性而不是真实的共性。3. 轻型中台的核心组件怎么选型3.1 模型服务先API后私有化说到组件选型第一个绕不开的就是模型。我见过太多团队上来就自建推理集群采购GPU、部署推理框架、搞弹性伸缩折腾了两个月业务效果还没验证过。这是典型的把“怎么用模型”和“怎么部署模型”两件事混为一谈了。轻型起步的模型策略我总结就一句话先API后私有化。用API方式起步有几个非常实际的好处。一是评估快今天签好服务协议明天就能完成接口联调不必等硬件和网络就位二是成本可控按量付费验证一个场景的真实调用量一个月可能就几百上千块钱相比采购几台GPU服务器的几十万成本几乎可以忽略三是迭代快模型厂商升级版本你改个参数就能用上更强的能力不需要自己维护模型版本。那什么时候才需要私有化部署我的判断标准有三个数据敏感度、规模、成本模型。第一个最硬性如果业务数据绝对不能出域比如涉及核心用户隐私、财务数据等那私有化部署就是合规要求不是技术选择。第二个是规模当API调用量大到月度费用超过自建部署的摊销成本时具备经济性。第三个是定制需求需要对开源模型做微调、蒸馏或者要深度改造推理框架时自建才谈得上有意义。如果你确实需要私有化选开源模型时我强烈建议盯住三个硬指标模型能力、推理成本、生态工具兼容性。模型能力就看公开评测和同行的实际使用经验推理成本要看单位Token的价格和显存占用生态兼容性更重要——你选的模型能不能被现有推理框架比如通用的模型推理服务软件和工具链无缝支持如果每次接入都要自己写一堆适配层成本会迅速失控。3.2 数据接入不要一上来搞数据湖数据是AI项目的另一大坑。很多数据团队一听要建AI中台第一反应就是要先建数据中台把数据湖、数据仓库、数据治理全都先做起来。这个想法在传统数据仓库时代可能还行但在AI时代完全本末倒置。数据治理的本质是给业务用如果AI价值还没验证治理出的数据就是库存不是资产。轻型起步的数据策略是“够用就好按需接入”。比如工单分类这个场景根本不需要什么大数据平台让业务系统的DBA给你开一个只读账号查最近三个月的工单导出成CSV或者通过接口读取可能几千行就够做第一版了。如果要做知识库问答做法也很轻把业务文档整理出来做切分、向量化写入一个开源向量数据库几十行代码就能搞定。这些步骤不依赖任何重型基础设施。那数据治理什么时候才开始补我的经验是当你发现两个以上业务线的AI应用都在依赖同一套数据源而且这套数据源经常出现口径不一致的问题时再启动治理。治理的起点先从一个公共数据模型和一套数据权限规范开始而不是直接建湖建仓。记住数据治理和平台建设一样是需求驱动长出来的不是规划驱动铺出来的。3.3 工具链的差异化取舍AI中台涉及的工具链其实很多Prompt管理、效果评测、安全审核、监控告警、权限管理、模型路由……如果每个都选一款平台产品来部署成本会迅速失控。轻型起步的原则是能用手工和脚本解决的不花钱必须上工具的先选开源或轻量方案实在有硬性需求的再考虑商业化产品。Prompt管理这块初期最靠谱的方式不是上平台而是把Prompt当代码管。每个Prompt作为一个文件放进代码仓库有版本记录、有变更历史、有对应的测试样例。等团队超过三个人都在改Prompt、频繁出现改坏要回滚的情况再考虑上专门的Prompt管理工具。我的观点很直接管理Prompt的最好工具在很长一段时间里就是Git不是某款专门平台。效果评测同理。第一个版本上线不需要复杂的评测框架准备一个一两百条的标准答案集写个脚本批量调用模型计算准确率、召回率输出一个报告就够了。等场景多了、模型迭代频繁了、需要做模型A/B对比了再引入评测平台。但有一块工具链不能省就是安全审核。模型生成内容、业务数据进模型这两条路径都必须有审核机制。轻型起步的做法是三层过滤规则层关键词、敏感词、模型层用审核模型做内容分类、人工抽检层业务方定期抽看。这块如果省了后面出问题就是大问题。4. 实操案例两周搭起一个工单分类AI服务4.1 场景定义与样本准备铺垫了这么多下面分享一个我近期做过的完整案例就是前面提到过的客服工单自动分类。这是一个典型的轻型起步打法场景痛点清晰、业务边界小、见效快非常适合作为AI中台的第一个落地场景。场景定义很直接客服系统里每天新增上千张工单需要人工判断类别后派给对应小组处理。我们做的就是让模型自动输出工单的类别、紧急程度、以及对应的处理小组建议。业务下游直接把模型输出结果作为初始分派依据人工确认后流转。第一步准备样本数据。我从客服工单系统里导出了过去三个月的工单做了一些筛选去掉空白工单、去掉测试工单、去掉内容过短的单子。然后我们和业务方一起把工单类别从原来的二十多个细类归并成八个大类账号问题、订单问题、支付问题、物流问题、售后服务、产品咨询、投诉建议、其他。这一步非常重要——细分类目模型容易分错大类之间的边界清晰模型效果才会好看。最终我们标注了600条工单其中400条做训练参考200条留作验证集。这里有个心得AI应用起步不需要追求海量数据几百条高质量、经过业务方确认的样本远好过上万个自动爬取但噪声很大的数据。但样本一定要业务方参与审核因为只有业务方最清楚哪些类别容易混淆怎么标注是合理的。4.2 接模型一个脚本跑通第一个版本样本就绪后就是接模型。我们当时用的是API调用方式整个过程非常轻核心代码大概几十行。import json import requests # 调用模型完成工单分类 def classify_ticket(ticket_text: str, categories: list[str]) - dict: prompt f你是一名客服工单分类助手。 请将以下工单内容分类到{json.dumps(categories, ensure_asciiFalse)}中的一个类别。 同时判断紧急程度高/中/低并给出建议处理小组。 要求只输出JSON格式如下 {{category: 类别, urgency: 紧急程度, team: 小组, reason: 判断理由}} 工单内容 {ticket_text} resp requests.post( MODEL_API_ENDPOINT, headers{Authorization: fBearer {MODEL_API_KEY}}, json{ model: MODEL_NAME, messages: [{role: user, content: prompt}], temperature: 0.1, # 分类任务要低温度减少随机性 response_format: {type: json_object}, }, timeout30, ) return json.loads(resp.json()[choices][0][message][content]) if __name__ __main__: print(classify_ticket(我买了三天的商品一直显示未发货客服电话也打不通很生气, [账号问题, 订单问题, 支付问题, 物流问题, 售后服务, 产品咨询, 投诉建议, 其他]))整个调用过程没有任何私有化部署没有微调模型就是用现成的大模型API加一个精心设计的Prompt跑了起来。第一版的效果就已经不错准确率有八成多。很多人觉得AI项目很玄但真正落地时第一版往往就是“一个Prompt的事”难的是后面把效果做细、把链路做稳。关于Prompt设计我强调三个要点第一明确角色和任务告诉模型“你是客服工单分类助手”给它一个身份第二明确输出格式要求只输出JSON方便程序解析第三给一到两个示例上面代码里没有展示完整示例但实际项目里建议放上Few-shot能显著提升边缘case的表现。4.3 效果评测与迭代第一版跑通只是开始接下来是最关键的环节效果评测与迭代。我们当时用准备好的200条验证集批量跑了分类结果算出来的整体准确率大概是85%。看起来还行但别急着高兴——要看混淆矩阵也就是“哪些类别的工单被分错了”。结果很有意思90%的错误集中在“订单问题”和“物流问题”这两个类别之间。业务方一看就明白了很多用户咨询的工单里同时包含订单信息和物流信息比如“我的订单怎么还没发货”人工都容易分成两类模型分错很正常。这时候我们做了一次针对性迭代不是去微调模型而是分两个动作一是在Prompt里增加规则——“如果用户同时提到商品状态和物流状态优先归入物流问题并以用户当前最关心的诉求为准”二是增加示例每个有歧义的类别都补了两个典型工单作为few-shot示例。就这么改了Prompt和示例连代码都没大动准确率从85%提到了91%最关键的是“订单/物流”这组纠缠类的准确率提升明显。这个经验可以复制给所有做AI应用的人先看错误分布再针对矛盾点做规则和样例优化而不是盲目换模型或上微调。模型迭代的成本、风险都比改Prompt大得多一定是最后手段。评测集另一个容易被忽视的用途是回归测试。每次改Prompt都用那200条验证集重新跑一遍确保“改好了这个问题没有破坏其他类别”。这批数据是你们的护城河要严格版本管理起来后面换模型、改Prompt、做微调都得拿它当基准。4.4 接入业务系统与灰度上线模型效果达到91%之后就要考虑接入业务系统。这里我不建议一上来就“全自动分单”而是采用“推荐模式”灰度上线工单系统调用分类服务得到的分类结果作为默认值先展示给坐席人员参考坐席可以一键采纳也可以修改后确认。为什么这样做一方面91%准确率意味着还有9%的错误全自动分单会让业务方天天被错误工单烦信任会迅速崩塌另一方面推荐模式能把AI嵌入业务流程让业务方在“用”的过程中建立信心。线上的推荐采纳率才是这个AI服务真正价值的衡量标准而不是准确率本身。上线后我们盯了三个监控指标接口调用量、接口失败率、人工纠正率。前两个是技术指标第三个是业务指标。这里最有用的经验是人工纠正的数据一定要回收每周从纠正样本里抽出几十条和业务方一起看是模型错了还是业务规则变了。这个每周例行的复盘既是效果迭代的来源也是业务方参与感最强的环节。灰度运行两周后人工采纳率稳定在85%左右业务方主动提出可以把推荐结果直接作为分派依据人工只处理低置信度的工单。这个转变就是AI应用从“可用”走向“好用”的标志。5. 平台团队的组织与运营中台怎么活下来5.1 定位做“加速器”而不是做“Owner”技术问题都是能解决的AI中台项目真正容易翻车的地方在组织和运营。很多中台团队一成立就想着“统一规划、统一管控”把业务方当成被管的对象。这个心态会让中台从第一天起就被业务方当成“流程关卡”而不是“能力供给”。我更建议的定位是AI中台团队是业务的“加速器”不是“Owner”。你们不拥有业务场景业务场景永远属于业务团队你们拥有的是公共的AI能力组件以及让业务方用好这些组件的服务流程。落到具体行动上有四条协作规则值得参考。第一试点场景共建初期不要等着业务来提需求中台团队要主动选择一个业务方一起把前面讲的“样板间”做出来。第二能力组件化每次交付不只要交付一个业务功能还要把通用部分沉淀成可复用的组件哪怕只是一个封装好的SDK。第三业务方自服务平台的核心价值就是让业务方不需要通过中台团队也能自己接入AI能力。这需要提供清晰的文档、示例代码和沙箱环境。第四全流程可观测每个业务方的调用量、效果、成本都要透明可见让业务方知道自己花的每一分钱带来了什么。团队的最小配置我建议三到五人一个懂业务的架构师、两个后端/算法工程师、一个懂数据的工程角色。初期不需要单独的前端、测试、运维这些资源可以从公共部门临时借调。中台团队人多了反而容易产出大量内部文档和流程而不是业务价值。5.2 迭代节奏按周交付而不是按季度重型中台喜欢按季度规划每个季度末交付一次重大版本。轻型起步不一样一定要按周迭代。为什么因为AI能力的效果不到业务现场你根本不知道对不对周更短跑可以逼着团队每两周必须向业务方交付一个可感知的变化倒逼大家砍掉不重要的需求。我个人的习惯是每两周一个迭代版本。这个节奏怎么落地分享一个很朴素的工作方式周一开半小时的需求评审会只过未来两周要做的事评判标准就三条——业务价值是否明确、数据是否就绪、是否依赖未完成的其他任务。需求池里永远不保留超过两周的条目放久了就删掉说明它不够重要。有人会觉得这样的节奏太随性没有“规划感”。但实际跑下来半年之后你会发现十几个双周版本叠加起来能力成长速度远快于那种“一年规划、三季实施、最后验收”的模式。在AI这个变化如此快的领域你唯一能预测的事情就是计划一定会变。那不如让计划变得足够短让调整的代价足够小。5.3 用运营指标证明价值最后中台团队一定要回答一个所有老板都会问的问题你们这个中台到底创造了什么价值没有数据支撑这个答案只能沦为“我们在建能力”这样正确但无力的说法。我建议从五个维度建立一套轻量运营指标指标类别具体指标说明使用规模活跃调用业务线数、覆盖场景数、日均API调用量衡量中台被用得有多广效果水平各场景核心准确率/采纳率以及季度趋势衡量能力质量是否在提升效率收益业务节省工时通过抽样测算把价值换算成业务听得懂的语言成本效率单次调用平均成本、单场景月度总成本防止成本失控支持资源决策复用率同一组件被多少个场景复用衡量中台“沉淀”做得怎么样有一件事必须警惕不要为了指标而指标。比如调用量这个指标A业务线每天都用中台调一万次看起来很好但仔细一看其中八千次是缓存命中模型没跑业务方自己都说“用没用都一样”——那这个调用量就是虚的。指标的意义不是为了给老板写汇报而是帮你们自己判断该往哪个方向投入。6. 常见问题与避坑实录6.1 模型幻觉导致业务不信任我遇到过不止一次AI服务上线第一天效果惊艳第二天一个一本正经的“幻觉”回答让业务方直接喊停。比如知识库问答场景模型自信地编造了一个根本不存在的数据业务方立刻对整个AI能力失去信任。应对幻觉我总结了三板斧。第一给答案加引用来源凡是基于知识库的回答模型必须返回来源文档的编号或原文片段业务方可以点开核实有据可查。第二把温度调低并把输出限定在已有文档范围内降低temperature参数同时在Prompt里明确“如果你不确定请回答不知道不要编造”。第三对高风险场景做兜底当模型置信度低或没有检索到相关内容时自动转人工而不是硬答。模型的价值是提高效率不是替人做决定该兜底时坚决兜底。6.2 数据安全与合规红线轻型起步最大的风险不是技术而是合规。数据安全问题一旦出事不是“踩坑”可以带过的。数据进模型前一定要做分级和脱敏。我们的做法是所有涉及用户姓名、手机号、身份证号、地址等敏感信息的字段在送入模型前先做脱敏替换模型返回结果后再映射回来。日志里永远不记录原始敏感信息只记录脱敏后的映射标识。权限隔离也是一样的逻辑中台服务必须支持按业务线做数据和模型的隔离。A业务线不能看到B业务线的Prompt和调用记录。这些规则看起来枯燥但没有它们你的AI项目规模越大风险越大。合规这件事从第一天做和后面补做的成本差距是数量级的。6.3 提示词管理一片混乱Prompt在前期的确可以当代码管但场景多了之后会有一个很现实的痛点同样的一个Prompt可能同时被三个业务场景引用有人改了一句其他场景效果崩了导致线上问题还找不到责任人。这是我在项目里真实遇到过的问题排查了很久才发现是另一个团队改的公共Prompt被连带生效了。解决的思路不是把Prompt锁死不让改而是引入轻量级的版本和评估机制。每个Prompt对应一个评估用例集任何修改都必须先跑评估用例集分数不低于当前版本才能上线。这就是把Promp管理纳入测试体系让改Prompt像改代码一样有测试、有回归、有发布记录。这个习惯越早建立后面越省心。6.4 成本失控API调用初看不贵但用量涨起来之后账单可能一个月比一个月吓人。成本失控最常见的原因有三个一是没有缓存层同样的输入重复调用模型二是不分场景一律用最大最贵的模型三是没有设置按业务线的预算阈值。对应策略也很明确。第一加缓存对知识库问答、工单分类这类输入高度可复用的场景在服务端做一层缓存相同或高度相似的输入直接返回历史结果。第二模型分级把轻量任务比如简单分类路由到性价比更高的小模型只有复杂推理、长文本生成才调用大模型。第三每月出成本报表按业务线拆分让每个业务方清楚自己用了多少、花在哪里。成本管理不难难的是早期有没有这个意识。6.5 业务部门“用不起来”最后一个问题可能是最普遍的平台都建好了功能也演示了模板也给了但业务部门就是不用或者用了一两次又退回去。很多团队这时候骂业务方“不思进取”但我看到的真相往往相反不是业务不想用而是AI能力嵌入业务流程的路径长了业务方每用一次都要额外做一些手工活感觉不到“更省事”。解决办法只有一个陪跑。派人去业务方那里坐两周亲眼看看他们怎么用、在哪个环节停下、为什么手动改回原方案。通常你会发现的不是AI能力不灵而是集成流程太繁琐——比如系统之间来回切换、结果需要二次复制粘贴。把这些摩擦点打磨掉业务方自然就用起来了。记住一个朴素的经验业务方不是不听你的他只是没有充足理由改变现在的工作习惯。你帮他省下一个动作他就愿意往前迈一步。我在多个项目中的真实感受是AI中台不是设计出来的是一步一步“长”出来的。你不需要在第一版就去想清楚所有业务线的所有场景你只需要在每一轮迭代里把当前最高价值的能力沉淀好、包装好、交付好。轻型起步的另一层含义是让中台团队永远保持“创业团队”的饥饿感和响应速度而不是变成“流程部门”的迟钝和被动。今天跑通一个分类明天沉淀一个知识库组件后天接进来第二条业务线中台的价值是被业务方一个场景一个场景用出来的不是写在立项报告里的。最后再分享一个沟通上的小技巧如果你在组织内部推“AI中台建设”阻力重重试试把项目名字改成“AI工程效能提升计划”你会发现很多关于组织边界的争论突然就消失了。