Java排坑指南(I)jmap jstack jstat等的使用
Java排坑指南(I)jmap jstack jstat等的使用运用一些Java自带的可执行jar可以从内存的角度更轻松的排除项目中的问题，我们可能会遇到一些不常见却相对很致命的问题，例如： 某些web项目CPU跑到了100%并且飙高不下（一般来说，web应用都为IO密集应用，不太可能出现cpu高占用的情况） 项目中线程出现阻滞、阻塞（网络请求响应速度明显变慢，甚至因为死锁彻底出现阻塞等） 极可能由内存泄漏引发的不明原因的 OOM（没有预兆的或是基础逻辑问题的内存溢出） 当以上问题发生时，通过代码或是日志其实很难定位到原因所在，因为这一般是基于环境或资源导致的全局性问题，通常很难定位，这时可以通过使用Java自带的性能调优jar包更便捷的定位问题（如果没有配置环境变量，可以在jdk的bin目录下找到他们的jar包）
2020-11-28鱼鱼
给 Agent 一个草稿本：为什么 scratchpad 比全塞进 prompt 更稳
给 Agent 一个草稿本：为什么 scratchpad 比全塞进 prompt 更稳做长任务 Agent 时，我最早的做法特别朴素：把所有中间结果、计划、反思，一股脑追加进对话上下文 反正模型“看得见”，多写点总没错 错就错在“多写点” 上下文很快又脏又长：旧计划和新计划并存，失败的工具输出还在，模型开始引用过期结论，或者在同一段推理上打转 更麻烦的是，你很难回答一个基本问题——此刻 Agent 到底相信什么？ 后来我给 Agent 加了一个显式的“草稿本”（scratchpad）：工作记忆外置到一块可读写的状态里，prompt 里只放当前需要的摘要和指针 稳定性和可调试性都好了不少 这篇讲讲为什么，以及我怎么划分什么该进草稿本 1. 噪声淹没信号 工具返回动辄几千字，失败堆栈、HTML 片段、长 JSON，全进上下文
2026-10-14鱼鱼
多智能体协作的几种常见模式
多智能体协作的几种常见模式一个 Agent 不够用时，自然会想到“多找几个 Agent 分工” 但多智能体并不是数量越多越好——它带来分工优势的同时，也带来了通信成本、调试难度和 token 开销 本文梳理几种常见协作模式及其适用场景，给出主管—工人、评审循环的 Python 示例和 Java 版的消息结构，并总结常见坑、检查清单与 FAQ 从“大而全”的单个 Agent 到“小而专”的分工 单 Agent 加工具，已经能解决很大一类问题 但随着任务变复杂，常见瓶颈会逐渐出现： 上下文被挤满：几十个工具的说明、长长的历史、大量检索结果挤在一个窗口里，模型注意力被稀释； 角色冲突：同一个提示词里既要求“大胆创作”又要求“严格挑错”，两种要求互相拉扯；
2026-10-14鱼鱼
Spring源码解析(3) IoC容器配置读取和容器refresh
Spring源码解析(3) IoC容器配置读取和容器refresh在文章Spring源码解析(I) 基于SSM看Spring的使用和Spring启动监听中，讲述了web容器启动后会触发的方法实现中生成Context的部分，回顾下核心方法： 我们已经分析到了0.处，他对我们生成的容器做了一个判断，对于web.xml监听初始化的Context，其生成的WebApplicationContext都是ConfigurableWebApplicationContext的子类，所以必然会进入if分支 首先通过loadParentContext先加载了父容器，默认是null 然后调用了configureAndRefreshWebApplicationContext方法进行初始化和配置项的读取
2020-08-09鱼鱼
让 AI 写正则表达式：我现在一定先要它给反例
让 AI 写正则表达式：我现在一定先要它给反例正则大概是我最早放心交给 AI 的活 原因很简单：我自己写正则也是边查边试，每次写完都不太敢相信它 AI 张口就来，还附带逐段解释，看上去比我靠谱多了 用了一阵之后我发现，AI 写的正则有个很稳定的特点：它几乎总能匹配上你给的例子 问题是，正则真正出事的地方从来不在“该匹配的没匹配上”，而在“不该匹配的也匹配上了” 而后者，你不主动问，它不会告诉你 所以我现在有个死规矩：让 AI 写正则，先别要正则，先要反例 那次是要从一堆构建日志里提取版本号，格式是“主版本.次版本.修订号” 我给了 AI 三个例子，它很快给出 \d+\.\d+\.\d+，解释也清清楚楚 我跑了一下，三个例子全中，就提交了
2026-10-16鱼鱼
什么是 AI Agent？从 ReAct 循环讲起
什么是 AI Agent？从 ReAct 循环讲起最近一年，“Agent”这个词几乎出现在每一篇 AI 文章里 但很多人写了半天 Agent，其实只是把一个大模型接口包了层壳 这篇文章从最小的模型出发，讲清楚 Agent 到底是什么，以及它的核心运行机制——ReAct 循环 读完之后，你应该能回答三个问题：Agent 和普通聊天有什么本质区别？一个 Agent 的每一步到底在发生什么？怎样用几十行代码搭出一个能跑的最小 Agent，并知道它会在哪里出问题？ ReAct 循环：思考 → 行动 → 观察，直到给出最终答案 早期使用大模型，基本是“一问一答”：把问题写进提示词，模型返回一段文字 这种方式对写文案、翻译、解释概念很好用，但一遇到下面这些需求就力不从心：
2026-10-14鱼鱼
提示词工程与上下文工程：让模型看到“对的信息”
提示词工程与上下文工程：让模型看到“对的信息”写 Agent 时，很多人把精力放在“提示词怎么写得更花哨”上 实际上，更影响效果的往往是：在每一步，模型的上下文里究竟放了什么 这就是近来常被提起的“上下文工程（Context Engineering）” 本文先区分提示词工程与上下文工程，再讲系统提示的结构、上下文的选择/压缩/隔离/外置四种手段，提供一个带 token 预算的上下文组装器（Python）与结构化输出校验（Python + Java），最后总结常见错误、检查清单与 FAQ 上下文窗口里的六个组成部分 很多团队有过这样的经历：换了更强的模型，效果只提升了一点；而把检索结果排序调整了一下、把冗长的工具输出裁剪了一下，效果反而明显改善
2026-10-14鱼鱼
AI 生成测试我怎么取舍：哪些让它写，哪些必须人写
AI 生成测试我怎么取舍：哪些让它写，哪些必须人写用 AI 写业务代码越来越顺手之后，下一件很自然的事就是：让它把测试也补上 说实话，这一步的爽感很强——几分钟冒出一堆 should_xxx，覆盖率数字往上跳，CI 绿灯 问题也正好出在这里：绿灯不等于有保险 我经历过一次挺丢脸的事 AI 帮我补了十几个单测，覆盖率从 40% 拉到 75%，合并后第三天生产就炸了 回头看测试，几乎每个都在验证“mock 对象有没有按我设定的方式被调用”，真正的业务不变量一个都没钉住 测试在保护 mock，不在保护系统 这篇文章想说清楚三件事：哪些测例我愿意交给 AI；哪些我坚持人手写；以及怎么减少“假绿” 图片来源：原创示意图 我不想装清高
2026-10-14鱼鱼
接手陌生代码库的第一周，我让 AI 当向导
接手陌生代码库的第一周，我让 AI 当向导前阵子我接手了一个老服务 说它老，不是说技术栈有多古早，而是它经历过好几拨人：最早写它的人早就转岗了，中间有人加过功能，也有人做过“临时方案”，README 停留在两年前的某次重构之前 给我的熟悉时间大概是一周，之后就要开始接需求 以前遇到这种情况，我的套路是从启动类开始一路点进去，点到头晕，再去翻提交记录，看看谁改得最多，厚着脸皮去问 这次我换了个方式：让 AI 陪我读 一周下来，感受挺复杂的——它确实让我快了不少，但也有几次差点把我带进沟里 这篇就记一下我是怎么用的，哪些地方好用，哪些地方我后来学乖了 我犯的第一个错，就是一上来问它：“帮我介绍一下这个项目的整体架构 ”
2026-10-14鱼鱼
MySQL tips
MySQL tips一些日常接触到的MySQL优化tips，比较散乱 假设有一个用户表，对于一句很简单的查询语句： 假设name与age字段均有单列索引，容易想到的是，MySQL应该会分别走两次索引，并将其结合起来，EXPLAIN也是如此，大多数时候MySQL会进行优化，我们可能会看到EXPLAIN的结果中有Using union或Using soft union，这是MySQL针对OR做了隐性的优化，但当SQL复杂或数据极端情况下，这一语句极容易变成全表扫描，偶尔使用联合索引可能解决问题，更多情况则是MySQL“昏了头”，即使OR条件均涉及数据条数不多，依旧没能在查询语句中使用索引，此时应调整为UNION语句(可以权衡一下重复及顺序是否有影响，可以使用更快的UNION ALL)：
2021-01-13鱼鱼
AI 补全和整段生成，我什么时候用哪种
AI 补全和整段生成，我什么时候用哪种用 AI 写代码久了，我会下意识把它分成两种节奏：一种是编辑器里那个“跟着你敲”的补全；另一种是对话框里“给我写一整段 / 一整文件”的生成 表面上都是 AI 在写，体感完全不一样 补全像有人在旁边帮你把下一句顺出来；整段生成像你把需求扔出去，过一会儿收回来一份成品 我早期几乎只用后者，觉得效率高；后来越写越觉得：很多时候，补全才是更省心的那一个 这篇就聊聊我现在怎么选 补全的好处很直观——上下文就在光标周围，你刚写的函数名、变量名、注释，它都能“看见” 你按 tab 接受一行，再敲两下，它继续跟 这种节奏很接近自己写，只是手变快了一点 我特别喜欢在这些场景用补全： 写样板代码：DTO 字段、简单的 getter/mapper、重复的校验
2026-10-14鱼鱼
AI 写的代码，我是这样 Review 的：一份不太体面的清单
AI 写的代码，我是这样 Review 的：一份不太体面的清单AI 生成的代码有一个很“坑人”的特点：它读起来太顺了 命名规整，注释齐全，结构对称，连日志格式都统一 人写的代码出问题，往往在外观上就有迹可循，比如命名乱、缩进歪、注释写着“TODO 先这样” AI 写的代码出问题，外表通常是光鲜的 这就导致一个很尴尬的局面：越是看起来没毛病的代码，我们越容易放松警惕 所以这篇想聊聊我自己 Review AI 代码时的一份清单 说它“不太体面”，是因为里面很多条看着很基础，甚至有点小心眼 但在我看来，Review AI 代码，恰恰需要一点小心眼 图片来源：John 'Pathfinder' Lester / Flickr（CC BY 2.0）
2026-10-14鱼鱼
