早上九点收到的一条额度告警 2025 年 2 月底的一个周一，我刚进公司就收到运维的消息："模型供应商账户额度用了 78%，平时这个时候只有 15%。" 紧接着业务群炸了，客服系统开始大面积报 429 Too Many Requests。 查了半小时，根因很朴素：上周五上线的智能质检功能有个循环调用
四个服务里塞了四份大模型调用代码 年初我们把 AI 能力往业务里铺的时候，图快，哪个服务需要就直接引一份 spring-ai-openai，配个 key 开干。到六月底盘点，订单服务、客服服务、商品服务、报表服务里各有一套调用代码，四份 application.yml 里躺着四个 API Key。
我们有个 WebFlux 服务，没人愿意改它 我们有个网关服务是 2021 年用 WebFlux 写的，三个接口、两千多行，但组里除了我没人愿意碰它。原因很简单：那套 Mono/Flux 的链式调用，加上 .flatMap() 里嵌套 .zip() 的写法，改起来要花两倍时间，而且出错后堆栈完全看不
三个团队写了三套几乎一样的东西 今年三月做季度复盘时，我们数了一下公司的 AI 建设：客服知识库、智能质检、合同审核，三个项目分属三个团队，各自实现了一遍模型调用封装、限流、审计日志、向量库接入、prompt 管理。代码重复度我粗略估了一下有 40% 以上。 更现实的问题是：三个项目都踩了同样的坑（
我们用传统架构设计 AI 应用，处处别扭 过去一年半我做了三个 AI 项目：客服知识库、智能质检、合同审核助手。回头看，第一个项目（2023 年底的知识库）踩的坑最多，原因不是技术不熟，而是我在用设计传统后端系统的方式设计它。 具体表现是：设计了标准的三层架构（Controller / Servic
客服机器人上线两周，P95 首字延迟 4.2 秒 9 月初，我们给内部工单系统做的智能客服上了线。第三天开始收到投诉："问一句话要等四五秒才出字"。我拉了 Grafana 看，数据比投诉描述的还难看： gateway_request_duration_seconds{quantile="0.95",
团队想给客服系统加 AI 能力，产品经理一句"接个大模型"听起来轻巧。真要做时，我发现最大的问题不是模型效果，而是：AI 该放在系统哪一层？和现有业务怎么融？出错了怎么办？这层边界不清，迟早把核心交易拖下水。 边界划分：AI 是增强，不是核心 我的第一原则是：AI 能力必须处在非关键路径。下单、扣款
去年底老板拍板：核心交易系统去 Oracle。理由很直接——一年 380 万的授权费，加上审计合规越来越严。我接手时第一反应是：这活儿坑比想象多，不是导出 SQL 再导入就完事。 先盘家底 系统跑了九年，Oracle 里不止 SQL。我用了两周做依赖盘点，列了一张表： 依赖类型 数量 风险 存储过程
把命运交給一家供应商太冒险 工单助手全量依赖 OpenAI，某次它区域性抖动 40 分钟，我们的自动回复全挂，运营被迫人工顶上，积压了上千条工单。AI 能力已经是生产依赖，就不能有单点。我搭了一套多模型路由加降级，核心：多供应商接入、健康检查、自动降级兜底。上线后两次抖动都平稳度过。 多供应商统一接
给内部文档做个能问答的机器人 公司几百份技术文档散在 Wiki，搜起来费劲——关键词搜只能匹配字面，问"怎么处理订单超时"搜不到"订单 30 分钟未支付自动关单"的那段。我想用 RAG（检索增强生成）做个问答，让模型"先查资料再回答"。2023 年初这套链路在 Java 侧得自己拼，没有现成框架，正
