「为什么 Agent 调我们的接口总是调错」 去年 12 月，业务方提了个需求：让客服 Agent 能直接查订单、查物流、发起退款。我当时的反应是「这不简单吗，把现有的订单服务接口包一层给 Agent 调就行了」。 两周后我收回这句话。Agent 调用我们接口的失败率是 37%，其中大部分不是超时或
把 AI 塞进研发流程半年，哪些卡点活下来了 四月份我们开始在研发流程里加 AI 卡点，到这个月正好半年。团队 14 人，一共试过九个卡点，活下来五个。先说总体结论：AI 卡点的价值不在「生成了多少内容」，而在「拦截了多少问题」——纯生成类的（写文档、写注释）普遍活不下来。 我们试过的九个卡点 卡点
半年过去了，我们团队到底提效了多少 2024 年 10 月我们组 11 个人开始全面用 AI 编码助手，到今年三月底正好半年。这半年里我在各种场合听到的说法从"提效 50%"到"就是个高级补全"都有，差距大到不像在说同一个东西。所以我们拉了数据自己看了一遍，顺便把踩过的坑和定下的规矩记下来。 数据是
订单系统线程池被一个"智能"功能打满 三月下旬的一个下午，监控突然报警：订单履约服务的 Tomcat 线程池活跃数从平时的 40 冲到 200（最大值），接口 P99 从 180ms 涨到 12s，大量订单卡在"待履约"状态。 排查过程很快。看线程 dump，200 个线程里有 187 个卡在同一个
背景：RestTemplate 越用越别扭 七月我们在预发环境试了 Spring 6.1 的里程碑版本（6.1 当时还没 GA，计划十一月随 Boot 3.2 一起），最让我眼前一亮的是 RestClient 和 HTTP Interface。以前用 RestTemplate，拼 URL、处理异常、
背景：一次全量构建喝了杯咖啡还没好 六月我们一个核心服务模块膨胀到 180 个 Maven 模块，mvn install 一次 6 分半。CI 排队严重，开发等得烦躁。我提议评估迁移 Gradle，但团队一半人不乐意——XML 写惯了，怕 DSL 学习成本。于是我做了个对照实验，用同一份源码分别用
半夜的 OOM，却没留下证据 有天凌晨一个服务 OOM 自杀重启，等我早上到公司，堆已经被 GC 一遍、镜像重建了，啥都看不到。这种"看过现场却没拍照"的故障最折磨人，只能凭日志猜是哪块吃内存，结果猜了一上午猜错方向。从那以后我定下规矩：任何 Java 服务 OOM 必须自动留证，不能让现场随重启蒸
编译一次 8 分钟，改一行代码等半天 5 月中旬，我们的主工程已经长成一个 47 个 package、21 万行的单体。mvn clean install 的时间： $ time mvn clean install -DskipTests [INFO] BUILD SUCCESS [INFO] To
