公司要求数据不出境，得换模型 四月底法务下了个通知：客服对话数据不能出境，我们正在用的海外模型必须换掉。当时系统基于 Spring AI 写的，第一反应是"换个 base-url 应该就行"，实际折腾了两周才稳定上线。 这篇记录接入国内模型的过程，主要是 Spring AI Alibaba 和 Op
我们用传统架构设计 AI 应用，处处别扭 过去一年半我做了三个 AI 项目：客服知识库、智能质检、合同审核助手。回头看，第一个项目（2023 年底的知识库）踩的坑最多，原因不是技术不熟，而是我在用设计传统后端系统的方式设计它。 具体表现是：设计了标准的三层架构（Controller / Servic
3200 行的 OrderService，AI 说拆成六个类 四月初我接手了一个历史模块的重构。OrderServiceImpl 单个文件 3218 行，包含下单、支付回调、退款、履约、对账、通知六种职责，方法之间互相调用，改一个地方要心惊胆战地检查半小时。这活儿我拖了两周没敢动。 后来试着把整个文
CR 时跟同事吵了一架 上周做订单模块的代码评审，同事设计的新表里有个 ext_data 字段，类型 json，里面塞了发票信息、优惠券信息、配送偏好、渠道来源，一共十几个子字段。他的理由是"这些字段每个订单不一定都有，建十几个列太浪费"。 我在评论里提了反对意见，他回了一句"MySQL 8 原生支
风控要在 200ms 内给出决策，而模型要 150ms 我们电商风控原来是一套 Drools 规则引擎，几百条规则，命中就拦截。去年底开始加模型：用用户最近 5 分钟的行为序列算实时特征，喂给一个轻量模型打分，超过阈值就拦截。 难在时间预算。风控决策必须在用户下单后 200ms 内返回，而模型推理本
订单系统线程池被一个"智能"功能打满 三月下旬的一个下午，监控突然报警：订单履约服务的 Tomcat 线程池活跃数从平时的 40 冲到 200（最大值），接口 P99 从 180ms 涨到 12s，大量订单卡在"待履约"状态。 排查过程很快。看线程 dump，200 个线程里有 187 个卡在同一个
半年过去了，我们团队到底提效了多少 2024 年 10 月我们组 11 个人开始全面用 AI 编码助手，到今年三月底正好半年。这半年里我在各种场合听到的说法从"提效 50%"到"就是个高级补全"都有，差距大到不像在说同一个东西。所以我们拉了数据自己看了一遍，顺便把踩过的坑和定下的规矩记下来。 数据是
压测卡在 400 QPS 上不去 知识库问答系统三月中旬做上线前压测，目标 800 QPS，结果压到 400 就开始大量超时。看 Grafana 面板，网关 CPU 才 40%，数据库连接池很闲，但整体 P99 已经飙到 3.2s。 拿 async-profiler 抓了 60 秒火焰图，TIME_
产品说"用户上传截图自动填工单" 三月中旬产品提了个需求：用户报障时经常甩一张截图过来，客服要手工把里面的订单号、错误码、时间点一个个敲进工单系统，平均 90 秒一条，希望系统能自动识别和填充。听起来简单，做下来发现"看懂一张图"这件事在工程上的复杂度远超我的预期。 这篇记录我们在 Java 应用里
早上九点收到的一条额度告警 2025 年 2 月底的一个周一，我刚进公司就收到运维的消息："模型供应商账户额度用了 78%，平时这个时候只有 15%。" 紧接着业务群炸了，客服系统开始大面积报 429 Too Many Requests。 查了半小时，根因很朴素：上周五上线的智能质检功能有个循环调用
