让 AI 把 Python 脚本改写成 Java：跨语言迁移时它最容易丢的东西
让 AI 把 Python 脚本改写成 Java：跨语言迁移时它最容易丢的东西组里有不少“历史脚本”：某个同事几年前用 Python 写的数据清洗、对账、报表生成，跑在一台机器的定时任务里，没人敢动 最近要把其中几个并进 Java 服务，统一部署、统一监控 这种活交给 AI 再合适不过了：输入输出都明确，代码量不大，几百行 Python，它几分钟就能吐出一份结构工整的 Java 第一份迁移我差点直接合进去 代码能编译，单测能过，命名比原脚本还讲究 后来是跑了一遍真实数据对比，才发现有几十行结果和老脚本对不上 查下来，没有一处是“写错了”，全是两门语言默认行为不一样，AI 按字面翻译了语法，却没翻译语义 这篇整理一下我踩到的这些差异，以及现在怎么让 AI 做迁移才比较放心
2026-10-16鱼鱼
JVM源码解析 从Launcher类浅谈ClassLoader(类加载器及双亲委派)
JVM源码解析 从Launcher类浅谈ClassLoader(类加载器及双亲委派)首先普及ClassLoader的基础：所有的Java类都是由ClassLoader由class文件加载进内存的，对于一个类，其唯一标识就是类名+加载他的ClassLoader（亦即对于不同的 ClassLoader，即使是加载了同一个Class也不能互通，本质上是两个类），其基本的分类如下图： BootstrapClassLoader是一个特殊的ClassLoader，负责启动时加载jre的类库 并不继承于ClassLoader，因为是jvm逻辑的一部分； ExtClassLoader也会加载jre类库，但是会加载那些额外的扩展类库(jre\lib\ext目录)，到这个级别的 类加载器已经可以直接在代码中使用了；
2020-11-28鱼鱼
IO多路复用模型：select、poll、epoll对比
IO多路复用模型：select、poll、epoll对比我们平时提到的I/O几乎都是同步 阻塞模型，譬如网络请求的socket IO，在数据返回前，相应的线程或是进程将会一直 阻塞直到数据返回，比较直接的处理便是针对IO流一对一的监听，但在IO返回前，相应的系统资源会平白无故的浪费，这种处理方式会大大降低服务器的吞吐 如果我们用很少的线程来监听这些IO，就能实现对系统资源的更好利用，在相应的socket有数据返回时才去读取数据 这种方式被称作IO多路复用，在Linux系统中，实现IO多路复用的方式（从古老到新）有select、poll和epoll 现在很多中间件都使用epoll IO多路复用模型才因此有着很高的性能和吞吐 此处简单描述三种方式的实现和区别
2020-08-11鱼鱼
Agent 的人类确认点：哪些操作必须等人点头
Agent 的人类确认点：哪些操作必须等人点头把权限和预算都收紧之后，还剩一个问题：有些动作即使技术上 Agent 做得了，也不该让它独自按下 删除、推远程、改权限、对外部发消息——这类事一旦做错，回滚成本不对称 我把这类关卡叫做人类确认点（human gate）：Agent 可以准备好方案和命令，但执行前必须等人点头 原则很土：能撤销的可自跑，难撤销的先问人 我不太用“重不重要”来划分，而用“做错了能否廉价撤销” 易撤销： 改工作区文件、跑只读测试、本地格式化、生成草稿文档 中等： 本地 commit、加依赖但未推送、改本地配置 难撤销： force push、删数据、改生产配置、对客户发信、扩大公网权限、不可逆迁移 易撤销的，默认自动；难撤销的，默认闸门
2026-10-14鱼鱼
用 AI 写代码越久，我越怕自己“手生”
用 AI 写代码越久，我越怕自己“手生”先说一个可能很多人都有过的瞬间：公司网络抽风，或者 AI 插件突然登录失效，你对着一个空白文件准备写点东西，然后发现自己卡住了 不是不会写，是那种“这个方法的参数顺序是啥来着”“这个异常该在哪一层处理来着”的卡顿 以前这些东西是肌肉记忆，现在得想一想 我第一次意识到这件事的时候，心里咯噔了一下 倒不是怕失业，那个话题太大了，轮不到我在这儿焦虑 我怕的是更具体的东西：当 AI 给出的代码出了问题，我还看不看得出来 这篇文章不打算劝谁少用 AI 我自己每天都在用，而且用得挺开心 我只是想把这种“手生”的感觉拆开看看，它到底是错觉还是真的，以及我目前摸索出来的一些应对办法 说是办法，其实也就是一些习惯，不一定对，供参考
2026-10-14鱼鱼
改了一句系统提示词，Agent 就变了个样：我开始给提示词做版本管理
改了一句系统提示词，Agent 就变了个样：我开始给提示词做版本管理先说一次让我印象很深的翻车 我维护着一个内部用的小 Agent，帮同事查工单、查日志、整理排查结论 有段时间有人反馈它“太啰嗦”，每次回答都要铺垫好几段 我就去后台的配置里，在系统提示词末尾加了一句：“回答尽量简洁 ” 改完自己试了两个问题，回答确实短了，挺满意，就没再管 过了几天，陆续有同事说它“变笨了”：以前问它某个工单的状态，它会先调用查询工具，再基于查到的结果回答；现在它经常不查，直接根据对话里的只言片语给个结论 还有一个多步骤的排查任务，它以前会一步步来，现在倾向于一步跳到结论 我一开始完全没往那句“尽量简洁”上想，在日志里找了半天别的原因 更尴尬的是，我想看看“几天前的提示词长什么样”，发现做不到——提示词存在配置后台，直接在线改，改完就覆盖了，没有历史
2026-10-14鱼鱼
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解CAT是美团点评的一个基于Java开发的异常和性能监控项目，github地址：https://github.com/dianping/cat 本篇文章不是对CAT本身的源码拆解，而是基于本人依赖CAT client开发的代理项目进行拆解，但是并不会纰漏任何技术细节 CAT当前已有很多不同语言的Client，当然暂且是不 CAT本身是通过CAT client收集数据并上报至CAT server，server会进行并，共有六种常见数据格式：Transaction、Event、Problem、Metric、HeartBeat、调用链标记，其实如果不考虑复杂的处理（譬如Metric是可以基于指标生成折线图，Problem可以根据具体的异常类型追溯到相应的会话Track）除去Transaction剩余的数据格式都可以理解为特殊的Event
2020-07-19鱼鱼
AI 写的代码，我是这样 Review 的：一份不太体面的清单
AI 写的代码，我是这样 Review 的：一份不太体面的清单AI 生成的代码有一个很“坑人”的特点：它读起来太顺了 命名规整，注释齐全，结构对称，连日志格式都统一 人写的代码出问题，往往在外观上就有迹可循，比如命名乱、缩进歪、注释写着“TODO 先这样” AI 写的代码出问题，外表通常是光鲜的 这就导致一个很尴尬的局面：越是看起来没毛病的代码，我们越容易放松警惕 所以这篇想聊聊我自己 Review AI 代码时的一份清单 说它“不太体面”，是因为里面很多条看着很基础，甚至有点小心眼 但在我看来，Review AI 代码，恰恰需要一点小心眼 图片来源：John 'Pathfinder' Lester / Flickr（CC BY 2.0）
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鱼鱼
多智能体协作的几种常见模式
多智能体协作的几种常见模式一个 Agent 不够用时，自然会想到“多找几个 Agent 分工” 但多智能体并不是数量越多越好——它带来分工优势的同时，也带来了通信成本、调试难度和 token 开销 本文梳理几种常见协作模式及其适用场景，给出主管—工人、评审循环的 Python 示例和 Java 版的消息结构，并总结常见坑、检查清单与 FAQ 从“大而全”的单个 Agent 到“小而专”的分工 单 Agent 加工具，已经能解决很大一类问题 但随着任务变复杂，常见瓶颈会逐渐出现： 上下文被挤满：几十个工具的说明、长长的历史、大量检索结果挤在一个窗口里，模型注意力被稀释； 角色冲突：同一个提示词里既要求“大胆创作”又要求“严格挑错”，两种要求互相拉扯；
2026-10-14鱼鱼
让 AI 解释陌生代码：我怎么听出它在「圆场」
让 AI 解释陌生代码：我怎么听出它在「圆场」接手陌生模块时，我常会把一段代码丢给 AI，问：「这是在干什么？」它几乎总能讲出一套流畅的故事 问题是——流畅不等于正确，更不等于它真读懂了约束 我越来越在意一种说话方式：它在「圆场」 表面在解释，实际在把不确定的地方用顺滑的因果糊过去 这篇文章记我怎么听、怎么追问、什么时候该停 写给同样会在「哇它好懂」和「等等它是不是编的」之间来回横跳的人 我遇到过的圆场，大概有几类： 因果补全：代码里没写为什么，它给你编一个听起来合理的「因为……所以……」 命名联想：函数叫 refreshCache，它就按「刷新缓存」的教科书含义讲，不管仓库里这个词早就变味 忽略例外路径：主路径讲得很漂亮，catch、降级、兼容分支一笔带过
2026-10-15鱼鱼
Agent 跑批任务时我盯的几个「仪表盘」指标
Agent 跑批任务时我盯的几个「仪表盘」指标把 Agent 丢进一批任务里跑，最容易犯的错是：只盯最终答案 答案对了就庆祝，错了再翻日志 跑多了你会发现——很多失败在中途就已经写在仪表盘上了，只是你没看 这篇文章记我跑批（批量任务、夜间任务、评测集重跑）时会盯的几类指标 不是定行业标准，是我个人反复被坑后留下的观察清单 如果你也在用 Agent 刷题集、批量修测试、批量整理仓库，希望能少踩一点「早上起来只看见成功率」的坑 最终答案是结果，不是过程健康度 两类任务都可能「答对」： 走了一条干净路径，三步完成 绕了四十步，失败重试一堆，最后撞对 只看答案，你会把第二种也当成可上线策略 成本、稳定性、可复现性全被藏起来了
2026-10-15鱼鱼
