让 AI 帮我把项目升到 Spring Boot 3：它扛了体力活，也埋了几个坑
让 AI 帮我把项目升到 Spring Boot 3：它扛了体力活，也埋了几个坑我们组有个内部服务，一直跑在 Spring Boot 2 上 2.x 早就停止开源免费维护了，安全扫描隔三岔五报一堆依赖漏洞，升级这件事拖了很久，终于排到了我头上 这次我决定全程拉着 AI 一起干 前后大概用了一周多（中间还穿插着别的需求），最后顺利上线 回头看，AI 确实帮我扛了大部分体力活，但也有几个坑是它挖的，或者至少是它没提醒我的 这篇把过程和教训记下来，给同样准备升级的同学参考 先声明：下面说的都是我们这个项目的情况，每个项目的依赖和历史包袱不一样，具体以 Spring 官方的迁移指南为准 一开始我问 AI：“把这个项目从 Spring Boot 2 升到 3，需要改什么？”它给了一份清单，大方向没错：Java 版本要 17 以上、javax 包要换成 jakarta、Spring Security 的配置写法变了，等等
2026-10-14鱼鱼
和 AI 结对写了一整天代码，我为什么比自己写还累
和 AI 结对写了一整天代码，我为什么比自己写还累有一天我做了个小实验：从早上到下班，整个需求全程开着 AI 助手，能问它的都问它，能让它写的都让它写 我原本的预期是“今天应该会很轻松” 结果下班的时候，我累得比平时还厉害 不是手累，是脑子那种被掏空的累 回头看产出，确实比平时多一点，但远没有到“轻松翻倍”的程度 那天晚上我想了挺久：问题到底出在哪？ 后来我又观察了自己几周，慢慢摸清楚了一些规律 这篇不讲什么高深技巧，就讲讲这种“沟通疲劳”是怎么来的，以及我试过的、确实有点用的几个办法 我把那天的感受拆了一下，大概有五个来源 一是持续评审 自己写代码时，脑子里是“我要怎么写”；跟 AI 结对时，脑子里一直是“它写得对不对”
2026-10-14鱼鱼
用 AI 写代码越久，我越怕自己“手生”
用 AI 写代码越久，我越怕自己“手生”先说一个可能很多人都有过的瞬间：公司网络抽风，或者 AI 插件突然登录失效，你对着一个空白文件准备写点东西，然后发现自己卡住了 不是不会写，是那种“这个方法的参数顺序是啥来着”“这个异常该在哪一层处理来着”的卡顿 以前这些东西是肌肉记忆，现在得想一想 我第一次意识到这件事的时候，心里咯噔了一下 倒不是怕失业，那个话题太大了，轮不到我在这儿焦虑 我怕的是更具体的东西：当 AI 给出的代码出了问题，我还看不看得出来 这篇文章不打算劝谁少用 AI 我自己每天都在用，而且用得挺开心 我只是想把这种“手生”的感觉拆开看看，它到底是错觉还是真的，以及我目前摸索出来的一些应对办法 说是办法，其实也就是一些习惯，不一定对，供参考
2026-10-14鱼鱼
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”前阵子我想补一块还不熟的中间件知识 打开文档、丢给 AI 一句“帮我讲讲原理和常见坑”，它讲得很顺，例子也漂亮 读完我心里有种熟悉的错觉：好像已经懂了 第二天动手搭一个最小示例，卡在配置项和错误信息上 再回头看昨晚的“懂”，其实只是跟着叙述走了一遍，脑子里没有自己踩过的脚印 这种“看完就觉得自己会了”，是我用 AI 学习时最常踩的坑 这篇文章不是反 AI，而是记我现在怎么用它学新技术，又怎么强制自己露馅、再补洞 写的都是个人习惯，不保证适合每个人，但对我自己很管用 AI 很擅长把陌生概念讲成一条平滑的故事线 平滑本身没问题，危险在于：故事线会掩盖你还不知道自己不知道的地方
2026-10-14鱼鱼
Java中的协程（虚拟线程）探究
Java中的协程（虚拟线程）探究在Java最新的LTS版本 21中，终于实装了协程这一特性 当然，在这些诸如python、golang等轻量级语言中被称为协程的东西，在Java中有个全新的代号——虚拟线程，为了将协程与线程做区分，在Java21中，原Thread被称之为平台线程 下文中，将统一使用线程/协程的方式称呼 我们都知道，Java中引入了线程的概念，区别于系统中的进程 作为并发执行的最小单元，在一定的条件下，使用多个线程同时运作可以有效提高程序的运转效率 而线程这一能力源于系统本身而并非JVM 之所以说是在一定条件下，是因为受限于机器配置情况（CPU的运作机制、核心数），线程的同时运作并不能线性的提升运行性能，单个cpu并不能同时处理多线程任务，实际的运作方式是基于时间片分片，各个线程抢占式执行代码，这样能减少一些无效的io等待（例如网络io、磁盘io实际是会阻塞等待io结果），同时在多核心场景下也能有效利用cpu
![Java中的协程（虚拟线程）探究]()
2024-10-28鱼鱼
网络时延、异步IO、Pipeline
网络时延、异步IO、Pipeline通过使用多线程是能提高网络延迟带来的负面效应的，也就是在IO密集型的应用中（尤其是网络IO密集应用中），通过异步操作或能显著提高性能，本篇讨论相关问题 并不是异步（多线程）定能提高性能，有这种讨论也是发现经常有人会滥用多线程 通常会有一种说法：如果想要采用多线程的来执行一段任务，为了提高性能，假设服务器中有N个核心，推荐在CPU密集型的应用中启用N个线程，而在IO密集型的任务中启用2*N个线程 本人不是很认同此种说法，他只能代表一个大致的度量，在实际应用中几乎可以说完全不准确，一般来说，权衡系统资源与性能后，前者可能需要更少的线程数，而后者根据实际情况也许适宜分配更多的线程数 这个概念大家一般都不是很陌生，在此再次科普下：所谓IO密集型任务，即是任务的资源消耗多集中在系统IO上，这里的IO本来包括磁盘IO和网络IO等，但是磁盘IO涉及文件句柄操作等系统限制不在本篇讨论，所以此篇文章所提主要指网络IO，高网络IO也是绝大多数web应用的特性
2021-04-21鱼鱼
AI 编程工程化迭代中的混沌风险：从规格熵到四个工程控制面
AI 编程工程化迭代中的混沌风险：从规格熵到四个工程控制面过去两年，我们团队把 AI 编程工具真正用进了日常研发：补全式的 Copilot、IDE 里的对话助手，以及能自己读写文件、跑命令的 Agent 收益是实打实的，样板代码、单元测试、脚本、联调、陌生框架的第一版实现，速度都明显提升 但用得越深，我越确信一件事：AI 工程化迭代最危险的地方，不是它“不会写代码”，而是它太会写了 在缺少稳定工程约束的时候，它会持续、高速地产出“单独看都挺合理，放在一起却彼此矛盾”的局部方案 这些矛盾的方案不会立刻表现为一个 Bug 它们表现为一种缓慢累积的混乱：同一个纠正反复被推翻，数据库越改越别扭，代码里一个概念长出两三个名字，线上出事时拼不出一条完整的因果链
2026-10-14鱼鱼
浅谈代理-动态代理
浅谈代理-动态代理我们可以很轻松的实现一个简单的代理 实现静态代理是个很简单的事情，最基础的代理只需要定义一个接口(虽然不是必要，但这显然才是标准的设计)、一个被代理类和一个代理类，例如： 定义一个接口： 一个实现类： 和一个代理类： 实际使用时，我们是去调用HelloWorldProxy的方法，其将作为HelloWorld的代理实现 此种方式直接实现的代理太过于死板，因为每一种代理行为都要制定一个代理类，我们熟知的很多基于代理的实现（譬如AOP、事务）显然不可能用静态代理的方式针对每一处类切点都覆写一个代理类，这种时候就需要动态代理 我们所熟知的相当多的框架均基于动态代理开发，JDK本身基于反射(java.lang.reflect)提供了动态代理，我们只需定义代理的行为，而对于代理类的范围并不是固定值
![浅谈代理-动态代理]()
2020-10-13鱼鱼
kasper的算法（从0到1）
kasper的算法（从0到1）https://javaguide.cn/cs-basics/data-structure/linear-data-structure.html https://javaguide.cn/cs-basics/algorithms/linkedlist-algorithm-problems.html 项目地址：https://github.com/labuladong/fucking-algorithm 在线文档地址：https://labuladong.gitee.io/algo/home/ http://fishmaple.cn/blog/topicBlog?topicId=7
![kasper的算法（从0到1）]()
2023-10-23kasper
ES快速入门(I)——分析分词器
ES快速入门(I)——分析分词器本文旨在快速入门Elasticsearch的分词，包括分词分析器的创建和介绍对比等，请确保在阅读前已经搭建好完备的集群 文章基于es7.0+，与稍旧版本的主要区别是没有type 在讨论分词前，我们先看一下es整体创建倒排的分词过程： 我们常说的分词器指的其实是“分析器”analyzer，es将以上常用的逻辑封装起来成为analyzer，但是语义上的分词器是指上面的tokenizer 经过了三层处理后拿到了terms数组建立最终的倒排索引： character filter：一般不会用到这个filter，是在分词前对原有的文档字段内容做转换，例如去除html的标签提取出正文内容，按正则清除和替换某些内容，你可以指定及自定义0个到多个character filter，他们将共同存在，一个文本流在经过character filter处理后，依然是文本流；
![ES快速入门(I)——分析分词器]()
2020-09-01鱼鱼
多智能体协作的几种常见模式
多智能体协作的几种常见模式一个 Agent 不够用时，自然会想到“多找几个 Agent 分工” 但多智能体并不是数量越多越好——它带来分工优势的同时，也带来了通信成本、调试难度和 token 开销 本文梳理几种常见协作模式及其适用场景，给出主管—工人、评审循环的 Python 示例和 Java 版的消息结构，并总结常见坑、检查清单与 FAQ 从“大而全”的单个 Agent 到“小而专”的分工 单 Agent 加工具，已经能解决很大一类问题 但随着任务变复杂，常见瓶颈会逐渐出现： 上下文被挤满：几十个工具的说明、长长的历史、大量检索结果挤在一个窗口里，模型注意力被稀释； 角色冲突：同一个提示词里既要求“大胆创作”又要求“严格挑错”，两种要求互相拉扯；
2026-10-14鱼鱼
动态路由数据源（多租户）解决方案
动态路由数据源（多租户）解决方案当下有很多服务都使用了多数据源，或是出于跨库查询或是分库分表、读写分离等，多数据源解决方案早已不是稀罕事 常见的解决方案包括使用多数据源框架(例如Shareding-Jdbc)、在数据库端做代理（例如MYCAT）、对于固定的几个数据源连接，也可以直接手动配置多个数据源，这种相关处理有很多源码，我在github上也有简单的实现：fishstormX/dynamicDataSource: 动态数据源的实现，基于maven自定义多模块骨架 Spring Boot2.0.x，本文实现的是动态数据源，主要为了解决 多租户问题（不同的用户群组有不同的数据源和配置，强调数据的隔离性） 本文技术能实现的是动态数据源，基于Spring框架，即能够将注入的Datasource根据租户不同使用不同的来源，同时根据租户增减动态的增删和缓存数据源（增是因为会有新增租户可能使用到项目启动后的数据源，减是因为租户数不可预料，不可直接缓存所有的数据源）
2021-01-07鱼鱼
