企业官网建设流程全解析

这两年聊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分，加起来排序。别小看这一页纸，它能把感性争论变成理性排序。

拿我自己做过的一个排序举例：某集团当时有四个候选场景——智能客服工单分类、营销文案生成、经营报表问答、合同关键信息抽取。按这个表格打完分，最后胜出的不是看起来最“高大上”的经营报表问答，而是工单分类。为什么？因为工单分类的业务价值极其清晰：客服团队每天几千张工单，人工分派费时费力，错了还要扯皮；数据早就存在工单系统里，结构化程度高；落地只需要给工单系统开个接口，业务侧没有大的流程变化；而且“工单分类”这个能力，后面完全可以复用到销售线索分配、售后问题派单上，复用潜力很高。而报表问答听起来炫酷，但数据口径不统一，业务部门自己都说不清指标定义，做出来大概率是鸡肋。

选场景的逻辑，用一个生活类比就是：哪个房子漏水最严重，先修哪个，而不是哪个房子装修出来最好看，先装哪个。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_ascii=False)}中的一个类别。 同时判断紧急程度（高/中/低），并给出建议处理小组。 要求：只输出JSON，格式如下： {{"category": "类别", "urgency": "紧急程度", "team": "小组", "reason": "判断理由"}} 工单内容： {ticket_text} """ resp = requests.post( MODEL_API_ENDPOINT, headers={"Authorization": f"Bearer {MODEL_API_KEY}"}, json={ "model": MODEL_NAME, "messages": [{"role": "user", "content": prompt}], "temperature": 0.1, # 分类任务要低温度，减少随机性 "response_format": {"type": "json_object"}, }, timeout=30, ) 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 用运营指标证明价值

最后，中台团队一定要回答一个所有老板都会问的问题：你们这个中台，到底创造了什么价值？没有数据支撑，这个答案只能沦为“我们在建能力”这样正确但无力的说法。

我建议从五个维度建立一套轻量运营指标：

有一件事必须警惕：不要为了指标而指标。比如调用量这个指标，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工程效能提升计划”，你会发现，很多关于组织边界的争论，突然就消失了。