三个人吵了两周，我算了一笔账 7 月初，团队为"新项目用哪个 Java AI 框架"吵了两周。三个人，三种意见，各自写了 demo，各自的 benchmark 都证明自己选的更好。 我做了件不太受欢迎的事：把这两周的成本算了出来。 参与讨论：3 人 × 14 天 × 60% 投入 ≈ 25 人日 写
入行第八年，我把这八年做过的选型列了张表 2026 年 3 月，我入行整八年。过年期间我把这些年参与过的重大技术选型整理了一遍，一共 34 项，标上当时的决策理由、实际结果、以及现在的回头看评价。 结果有点难堪：34 项里，现在看是正确决策的 19 项，过早的 6 项，过晚的 5 项，纯错的 4 项
文档下线三天了，客服机器人还在引用它 9 月中旬出了个不大不小的故障。运营下架了一份过期的《海外退换货政策 V1》，三天后还有用户在客服机器人里问到"海外订单 30 天可退"，而新政策是 15 天。用户截图投诉到了客服主管那里。 我查了一圈，问题出在存储架构上。我们当时的 RAG 是这样的： MyS
背景：为下半年的 JDK 21 LTS 提前做验证 四月我们开始评估下半年升级到 JDK 21 LTS 的可行性。GC 是这次升级最敏感的部分——ZGC 在 JDK 21 里终于要兑现「亚毫秒停顿」的承诺，Shenandoah 也迭代到第三代。我拉了 JDK 21 的早期 EA build（当时到
背景：一个 RAG 需求把选型问题拍到了脸上 三月初产品提了个需求：把过去三年积攒的技术工单做成内部知识库，让用户用自然语言提问。核心就一步——向量相似度检索。团队当时在 Milvus、PGVector、Redis 三套方案里反复横跳，谁也说服不了谁。我干脆拉了一台 16C32G 的机器，把三套都跑
架构评审会上，两个人对着吵了四十分钟 2 月中旬的一次架构评审，议题是"下单链路要不要上 Seata"。后端 A 主张用 AT 模式，理由是几乎不用改业务代码；后端 B 坚持用消息队列做最终一致，理由是"我们承受不了 Seata 挂掉导致下单全挂"。 我最后拍板：全都不用，主链路走本地消息表，退款单
面试官问：你们的分布式锁为什么选 Redis 不选 ZK 七月底跳槽面试，被问到分布式锁。我说我们用 Redis + Redisson。面试官追了一句："Redis 锁在主从切换时会丢锁，你们业务能接受？为什么不用 Zookeeper？" 我当时答得挺虚的。回来把三种实现都搭了一遍，用 JMeter
运维问我们：Ubuntu 服务器上装的 JDK 要不要交钱 11 月底，运维在群里发了张截图，是某篇公众号文章的标题："Oracle JDK 开始收费，你们公司准备好被起诉了吗"。他问我们的服务器要不要处理。 我把许可协议翻了一遍，发现事情没那么吓人，但确实得做个决定。这篇是整理出来的结论。 到底改
