最近在库拉KULAAI（k.kulaai.cn） 上对比大模型接入方案的时候，翻到不少同行的吐槽帖，发现一个共同的规律：老板拍板要上AI的那天，是全员最快乐的一天；系统上线第一周，是最不快乐的一周。
我自己的经历也没能逃出这个规律。
事情是怎么开始的
去年下半年，老板在某次行业会上看到竞争对手宣布"全面接入大模型"，回来就开会说我们也要搞。
当时公司的需求听着很简单：把GPT接进内部系统，让客服团队用AI辅助回复客户问题，顺便帮运营团队写点文案。
"听着很简单"——后来我才知道这五个字在技术圈是诅咒。
我们团队三个人，一个后端、一个前端、我负责整体方案。老板给了一个月时间。
第一周：demo阶段，所有人都很兴奋
GPT的API接入本身不复杂，半天就跑通了。调了几个prompt模板，扔进去客户常见问题，输出的回答质量居然还不错。
演示给老板看，老板当场拍桌子："这个好，下周上线。"
我跟运维说了一声，运维看了看方案，问了三个问题：数据安全怎么处理、并发扛得住吗、费用谁控。
我当时觉得这些都是小问题，先跑起来再说。
事实证明，运维问的每一个问题都是对的
第一个坑是数据安全。
我们把客户的问题直接发给GPT API处理，一开始没想太多。后来法务找过来问了一句："客户的姓名、地址、订单信息有没有传出去？"
仔细一看prompt模板，还真有。客服直接把客户原文复制进去，里面包含手机号和收货地址。这些数据经过OpenAI的服务器，等于把客户隐私拱手送出去了。
解决方案是加一层数据脱敏，在请求发出之前把敏感信息替换成占位符。做起来不难，但这个事在demo阶段根本不会想到。
第二个坑是并发和延迟。
GPT API的响应速度在低并发下还行，基本两三秒返回。但客服高峰期三十个人同时用，响应时间直接飙到十秒以上，有时候还会超时返回500错误。
客服那边反馈说："等AI回复的时间够我自己打三遍了。"
后来加了请求队列、做了缓存、引入了异步处理，才把体验拉回来。但中间那两周，客服团队怨声载道，说这个AI比没有AI还烦。
第三个坑是费用。
老板以为API调用很便宜，"几毛钱一次嘛"。但他没算过量。客服一天处理八百到一千条咨询，每条咨询平均需要两到三轮对话，每次对话调一次API。
一个月跑下来，光API费用就烧了一万五。老板看到账单的时候表情很微妙，问了句"有没有便宜的方案"。
后来做了几件事压成本：简单问题用本地小模型处理，只把复杂问题路由到GPT；prompt做了压缩，减少每次调用的token消耗；加了缓存层，相似问题不重复调用。三板斧下来，费用砍掉了差不多60%。
第五周：系统能跑了，但人的问题比技术问题大
技术上的坑填得差不多了，更大的问题浮出来了——客服团队不愿意用。
原因很实际：AI生成的回复质量不稳定。大部分时候还行，但偶尔会编造信息、给出错误的退换货政策、或者语气不像公司风格。客服说，与其花时间检查AI写的回复，不如自己直接回复更快。
还有一个心理层面的问题：客服觉得公司在用AI取代他们。虽然老板一直说"是辅助不是替代"，但没人信。
后来怎么解决的？说实话没有完全解决。我们做了一件事效果还行——让客服团队自己参与prompt模板的优化，给他们权限调整AI回复的风格和内容范围。当他们觉得"这东西是我调出来的"，抵触情绪就没那么强了。
回头看，哪些决策是对的
第一，先跑通再优化是对的。如果一开始就想把所有问题都想清楚，这个项目根本启动不了。快速出demo、快速暴露问题、快速迭代，这个节奏没问题。
第二，数据脱敏必须前置。这个不能"上线之后再说"，一旦出事就是安全事故。后来我们把脱敏做成了一层固定的中间件，所有外部API调用都走这层。
第三，混合模型架构是正解。全靠GPT太贵、太慢、太不可控。简单任务用本地模型，复杂任务调GPT，这个分层思路后来成了公司所有AI项目的标准架构。
哪些决策是作死
第一，没提前跟运维对齐。技术方案定了才通知运维，结果部署环境、网络策略、监控报警全是临时补的。运维说"你早说我会这样搞吗"，我无言以对。
第二，没做成本预估就跟老板承诺。老板问"一个月多少钱"，我说"应该不贵"。结果账单一出来，我被叫去单独开会。
第三，忽视了使用者的感受。系统能不能用和愿不愿意用是两件事。再好的技术，一线使用者不买账，就是摆设。
现在回头看
把GPT接入公司系统这件事，技术难度真不大，真正的难度在技术之外——安全合规、成本控制、用户体验、组织接受度。这些问题不会写在任何一份技术文档里，但每一个都能让你的项目翻车。
如果有人现在问我"要不要接GPT"，我的回答是：接，但别急着接。先把脱敏做好、把成本算清、把运维拉进来一起聊，然后再动手。
老板开心不重要，运维不打人才重要。
