周会上被问住了 6 月底的架构周会，组里一个同学问："Spring 官方和 DeepSeek 合作之后，我们要不要把模型调用层切到官方 starter？" 我当时答不上来。这两年"XX 与 XX 达成合作"的新闻太多了，大部分最后落在 PPT 上。我没有花时间验证过，就不能在会上拍板，于是给自己派了
红队测试甩过来一张截图 6 月中旬，安全组在我们客服 Agent 上做了一轮红队测试。第二天他们丢过来一段对话记录，最后一句模型输出是一串完整的身份证号——那是用户第一轮就提供的、我们已经脱敏过的号码。 我们的敏感词库有 12,800 条规则，身份证正则也在里面。为什么没拦住？ 这篇记录我们随后两周
语义缓存上线一个月，命中率 8.3% 三月份我们给客服 Agent 上了语义缓存，预期是「相似问题不用重复问模型，能省一大笔钱」。上线一个月看数据，命中率 8.3%，省下的钱还不够维护缓存本身的成本。 这篇文章记录我们怎么把命中率从 8.3% 提到 41%，以及中途推翻重做的一版设计。 先看为什么这
「客户 A 能看到客户 B 的知识库内容」 三月份的一次安全测试，外部团队提了一个问题：他们用 A 公司的账号登录后，通过构造特定的查询，让 Agent 返回了 B 公司的产品文档片段。 这个问题很严重，我们当天就成立了专项。这篇记录多租户隔离的四层设计、每一层我们实际用的方案，以及成本计量那块（这
向量检索选型：我们算了一笔账，最后没上专业向量库 十月份做知识库检索重构，团队里争论要不要上 Milvus 或者 Qdrant。我们已经在用 PostgreSQL（存业务数据 + 元数据），pgvector 扩展是顺手的选择，但大家都担心性能不行。 最后我们做了完整的压测和成本核算，结论是继续用 p
流式对话服务 OOM，堆转储里有 47 万个 ByteBuffer 十一月中旬的一个周一早上，告警炸了：智能客服服务的三个实例在 20 分钟内相继 OOM 重启。这个服务上线两个月一直很稳，堆 8 GB，平时使用率 40% 左右。 这篇是完整的排查过程。结论不复杂——流式响应没有正确关闭，但排查过程
把 AI 塞进研发流程半年，哪些卡点活下来了 四月份我们开始在研发流程里加 AI 卡点，到这个月正好半年。团队 14 人，一共试过九个卡点，活下来五个。先说总体结论：AI 卡点的价值不在「生成了多少内容」，而在「拦截了多少问题」——纯生成类的（写文档、写注释）普遍活不下来。 我们试过的九个卡点 卡点
客服转来一条投诉：AI 给用户编了个退款政策 十月底，客服同学转来一条用户投诉，附了聊天截图： 用户：我这个订单上周下的，还能退吗？ 机器人：可以的，我们支持 15 天内无理由退款，您直接在订单页面点击申请退款即可。 用户：我看到页面上写的是 7 天？ 机器人：抱歉造成困扰，7 天是普通商品的标准，
两个同事为「提示词改版有没有用」吵了一周 九月份我们改了一版运维 Agent 的系统提示词，主要变化是加了「先确认信息是否充分，再决定调用工具」这一段。改完之后团队内部炸了： 小王说「明显变准了，我测的几个问题都对」；老李说「变差了，现在它老是不干活，一直问我问题」。两人各举了三四个例子，都很有说服
把 AI 服务压到 3000 QPS 之后，GC 曲线完全变了 我们有个文档问答服务，跑在 JDK 21 + G1 上，原来堆 4G，Young 区 1.2G，日均 800 万次调用，GC 表现平平无奇：Young GC 每 8 秒一次，单次 25ms 左右，Full GC 一周见不到一次。 八月份
