从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 这个栏目不打算做成读书笔记的搬运。我做了八年 Java 和 AI，又自己跑过出海盘子、也清零过两次，读这些书
入行第八年，回头看自己踩过的坑 十月底做年度复盘，翻出了 2018 年到现在的 git 提交记录和几份老的设计文档。有些代码现在看会脸红，但正是那些代码让我走到了现在。这篇不写技术，写成长路径上几个真实的转折点和代价。 前两年：我以为技术就是知道更多 API 2018 年刚入行，在一家做仓储系统的公
两个同事为「提示词改版有没有用」吵了一周 九月份我们改了一版运维 Agent 的系统提示词，主要变化是加了「先确认信息是否充分，再决定调用工具」这一段。改完之后团队内部炸了： 小王说「明显变准了，我测的几个问题都对」；老李说「变差了，现在它老是不干活，一直问我问题」。两人各举了三四个例子，都很有说服
分代 ZGC 在我们的网关上跑了一年 去年十月，我们把 API 网关从 G1 换成了分代 ZGC，到这个月正好一年。这篇是完整的数据总结，包括参数、遇到的四个问题、以及我现在的看法。 先说结论：换成 ZGC 是我们这一年最值的一次技术决策，但它不是银弹，而且代价被大多数人低估了。 背景：为什么要换
同一个问题跑五次，得到三种不同的结果 九月初用户反馈我们的运维 Agent 有时会给出错误的重启建议——明明是磁盘满了，它建议重启服务。我们拿到 session ID 去复现，同一个问题、同一份上下文，跑了五次： 次数 结论 步数 耗时 token 1 磁盘满，建议清理日志（正确） 4 18s 21
把 AI 服务压到 3000 QPS 之后，GC 曲线完全变了 我们有个文档问答服务，跑在 JDK 21 + G1 上，原来堆 4G，Young 区 1.2G，日均 800 万次调用，GC 表现平平无奇：Young GC 每 8 秒一次，单次 25ms 左右，Full GC 一周见不到一次。 八月份
给公司内部的 CMDB 写了个 MCP Server 八月份我们决定把内部 CMDB、发布系统、监控平台接进 Agent。一开始想的是直接写 Function Calling，写了两周发现每个 Agent 框架（我们内部有 Spring AI 和 LangChain4j 两套）都要实现一遍，工具定义
半年过去了，我们团队到底提效了多少 2024 年 10 月我们组 11 个人开始全面用 AI 编码助手，到今年三月底正好半年。这半年里我在各种场合听到的说法从"提效 50%"到"就是个高级补全"都有，差距大到不像在说同一个东西。所以我们拉了数据自己看了一遍，顺便把踩过的坑和定下的规矩记下来。 数据是
从 3.3.5 升到 3.5.3，踩了四个坑 八月底我们把手上 11 个服务从 Spring Boot 3.3.5 升到了 3.5.3。原本计划两天搞定，实际花了九天，中间回滚了一次。这篇记录升级过程和四个值得说的坑。 先说结论：值得升，但别在业务高峰期前升。ServiceConnection 和结
工单：「你们的 Agent 是不是失忆了」 六月份客服转过来一批工单，其中有条写得挺扎心：「你们的运维助手，我上周三让它排查过一次订单服务超时，昨天又超时了，它从零开始问我要服务名、要时间范围，像完全没见过我一样。是不是失忆了？」 我看了下那两个 session，确实是两套完全独立的对话。我们当时只
审计日志里那条被拦截的命令，让我出了一身冷汗 有天早上巡检，我在运维 Agent 的审计日志里翻到这么一条： { "ts": "2025-07-29T03:14:22.118Z", "sessionId": "sess-7f3a91c0", "userId": "u_zhangwei",
早上九点收到的一条额度告警 2025 年 2 月底的一个周一，我刚进公司就收到运维的消息："模型供应商账户额度用了 78%，平时这个时候只有 15%。" 紧接着业务群炸了，客服系统开始大面积报 429 Too Many Requests。 查了半小时，根因很朴素：上周五上线的智能质检功能有个循环调用
三十多个工具方法散在各处 去年底我们把内部运维助手接上了大模型，能查订单、查库存、重启任务。当时图快，工具方法用 Spring AI 的 @Tool 直接写在各个业务服务里，谁需要谁加。到 2025 年 2 月一数，散在 6 个服务里总共 37 个工具方法，问题就来了：网关那边的对话服务要用库存工具
实习生问我：为什么文档喂得越多，答案越差 七月份团队来了个实习生，负责维护我们的文档问答系统。他有天跑来问我一个问题：「我把 topK 从 5 调到 20，召回率肯定上去了吧？但测试集准确率从 71% 掉到 63%，是不是哪儿写错了？」 我看了下代码，没写错。这不是 bug，这是我们一直没认真对待的
四个服务里塞了四份大模型调用代码 年初我们把 AI 能力往业务里铺的时候，图快，哪个服务需要就直接引一份 spring-ai-openai，配个 key 开干。到六月底盘点，订单服务、客服服务、商品服务、报表服务里各有一套调用代码，四份 application.yml 里躺着四个 API Key。
组里的实习生问我"Java 是不是没前途了" 2025 年春节后回来的第一周，组里新来的实习生私下问我："现在 AI 不都是 Python 写的吗，我学 Java 是不是选错方向了？" 这话我没法用一句"不会"糊弄过去，因为他说的是事实的一部分——过去两年所有模型层的创新确实都在 Python 生态
