复盘：一次被迫停更的迭代 四月那次版本上线前夜，我盯着依赖图发呆——一个订单核心模块被 27 个地方引用，改一处要回归 40 个用例，测试同学直接摆烂说「这版先别动它」。这不是第一个被技术债拖住的需求。入行第六年，我越来越觉得，技术债不是写烂代码，是「明知该改但一直没改」的累积。 债务识别：先把账算
问题代码：第一版大模型调用把线程池打满了 四月我们想给工单系统接一个大模型做自动摘要。第一版我图省事，用 RestTemplate 直接 POST 到 OpenAI 兼容接口，同步等返回。压测一上来就出问题：模型平均响应 3 秒，线程池 200 个线程 10 秒就被占满，QPS 卡在 60 上不去。
告警：凌晨三点的慢查询邮件 四月某天早上，运维把一封告警邮件转给我：「日志检索接口 P95 超过 8 秒，ES 集群 CPU 打满」。我们的应用日志一直存在 Elasticsearch 里，单日写入约 30 亿条，随着业务量涨，ES 的堆内存和查询延迟都快撑不住了。老板提了个方向：能不能把明细日志搬
背景：一个 RAG 需求把选型问题拍到了脸上 三月初产品提了个需求：把过去三年积攒的技术工单做成内部知识库，让用户用自然语言提问。核心就一步——向量相似度检索。团队当时在 Milvus、PGVector、Redis 三套方案里反复横跳，谁也说服不了谁。我干脆拉了一台 16C32G 的机器，把三套都跑
给内部文档做个能问答的机器人 公司几百份技术文档散在 Wiki，搜起来费劲——关键词搜只能匹配字面，问"怎么处理订单超时"搜不到"订单 30 分钟未支付自动关单"的那段。我想用 RAG（检索增强生成）做个问答，让模型"先查资料再回答"。2023 年初这套链路在 Java 侧得自己拼，没有现成框架，正
每天 300 万条的对账 财务对账原来用 crontab + 一个 main 方法跑，失败了从头来，半夜崩了没人管。最惨的一次，任务跑到一半数据库连接断了，已处理的 150 万条没记录，重跑又重复处理了一遍，对账差了几十万。换成 Spring Batch 后，断点续跑和重试才真正可控，凌晨的 job
中文向量化的尴尬 做知识库检索时，第一步就是把文档切块转成向量。英文世界有现成的 sentence-transformers，中文呢？2023 年初这块还很青涩，我踩了一圈坑，记下来给后来者省时间。当时我们想给内部 Wiki 做语义搜索，先用英文模型试，中文召回烂得一塌糊涂，才意识到"中文 embe
一次没顶住的流量 去年大促，预估峰值 8000 QPS，实际来了 1.4 万，订单服务被打挂 12 分钟。复盘发现：我们的容量评估靠的是"去年×2"的拍脑袋，没有真实压测支撑，对系统的真实拐点一无所知。那天凌晨告警炸了，扩容来不及，限流没配，全靠手动重启扛，资损不小。这次我把容量评估正经做了一遍，把
几个年头里反复踩的坑 建表时随手选类型，上线后不是慢就是错。我整理了团队里最高频的几类字段选型问题，新项目开工前照着过一遍。这些坑每一个都对应过一次线上事故或一次漫长的数据迁移，所以值得写下来反复提醒。 varchar 长度 有人图省事一律 varchar(255)，其实 MySQL 在 utf8m
Java 也要有自己的 AI 抽象层 2023 年初，Python 侧 LangChain 已经热闹非凡，Java 这边还在各自调 OpenAI 的 HTTP。我们团队想给内部系统接个问答能力，结果每个项目都自己封装一套 OkHttp 调用，模型一换全部重写。Spring 社区开始孵化一个叫 Spr
