PyCharm与python快速开发
PyCharm与python快速开发Python语言作为“胶水语言”，简单易学，开发周期快，功能和扩展性强大，类库丰富 只依赖一门Java并不适用于所有情况，譬如快速开发一次性脚本(修复数据)，通过使用Python效率更高，本篇文章旨在介绍本人快速入门Python的一些tips 注意，一些Python的基本语法在此不予介绍，推荐前往廖雪峰的博客查看，博客基于Python3.8版本 关于编译器等配置内容参考PyCharm帮助文档 从Python官网下载Python并安装，配置环境变量，安装PyCharm（这里 我们使用它作为IDE），这里略过 pip是python的包管理与安装工具，当你安装python后，pip也会随之被安装
2021-01-16鱼鱼
用 AI 读英文技术文档：我怎么防它“翻译腔”和悄悄漏译
用 AI 读英文技术文档：我怎么防它“翻译腔”和悄悄漏译我英文阅读不算差，但读长篇官方文档还是累 尤其是那种配置参考页、迁移指南、RFC 风格的规范，一页几十屏，读到后面前面的全忘了 所以这两年我读英文文档，基本都会拉上 AI 一起：整段丢进去，让它翻成中文，或者干脆让它讲给我听 一开始我觉得这是纯赚的事 直到有一次按译文改了配置，上线前同事问我：“文档里不是说这个参数只有在另一个开关打开时才生效吗？”我回去翻原文，还真有那么一句 unless 从句，而 AI 给我的中文里，这半句干干净净地消失了 译文读起来非常顺，顺到我完全没怀疑 从那以后我对“AI 翻译技术文档”的态度变了：它很好用，但它的错不是乱码式的错，而是读起来很通顺的错
2026-10-16鱼鱼
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鱼鱼
给仓库写一份 AGENTS.md：让 AI 编程助手少走弯路
给仓库写一份 AGENTS.md：让 AI 编程助手少走弯路用 AI 编程助手久了，你大概会有一种“祥林嫂”式的疲惫：每开一个新会话，就得把同样的话再说一遍 “我们用 pnpm，不是 npm ”“跑测试要加这个参数，不然会连真实数据库 ”“generated 目录下的代码是自动生成的，别改 ”“提交信息要按这个格式写 ” 说一次两次还好，说到第十次，就会开始怀疑人生 更糟糕的是，你偶尔忘了说，AI 就会理直气壮地按自己的默认习惯来，然后你再花时间收拾 解决这个问题的办法其实很朴素：把这些话写下来，放进仓库，让 AI 每次开工前自己读 这就是 AGENTS.md 要干的事 图片来源：rawpixel.com（CC0 1.0） 一句话：给 AI 看的 README
2026-10-14鱼鱼
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听查看源码的顺序就见仁见智了，比较普遍的做法是从IoC入手，了解容器注入的每一个环节，掌握大致的流程 由于使用的是Spring，所以在这里我们引入比较古老的xml配置文件进行bean的配置，首先定义一个bean: 配置描述bean的xml，核心只有一行： 这样一来就可以使用BeanFactory这个容器来注入bean并使用了： 本来有封装好的XmlBeanFactory，这一类现在已经被弃用了，所以采用了他的父类DefaultListableBeanFactory;当然，也可以使用更加方便和常用的ApplicationContext： 当然从xml文件读取bean的配置只是其中一种目前用的不多的加载方式，还有基于包扫描等加载bean的方法，此处仅为理解IoC的基本使用
2020-08-04鱼鱼
AI 生成的 README 和注释，我为什么经常删掉重写
AI 生成的 README 和注释，我为什么经常删掉重写AI 写文档很快：README、函数注释、模块说明，几秒就能铺满 我早期几乎照单全收，后来越来越频繁地整段删掉重写 不是因为文笔不好，而是因为很多生成文档在“正确的废话”和“过时的细节”之间晃，读的人费时间，维护的人更痛苦 这篇文章记我什么时候信它、什么时候动手砍，以及重写时我保什么、扔什么 1. 正确的废话 “本模块用于处理订单相关逻辑，提供创建、查询与更新能力 ”——读完等于没读 它没有告诉我边界、不变量、也没有告诉我别乱用的地方 2. 和代码赛跑的细节 把当前参数列表、每一步实现按行复述一遍 代码一改，注释就撒谎 AI 特别擅长写这种“现在时”的说明，因为它看见的就是此刻源码
2026-10-14鱼鱼
算法：Trie(前缀树、字典树）
算法：Trie(前缀树、字典树）前缀树(Trie，又称字典树)是一种功能倾向性很强的数据结构，通过对词汇的前缀做数结构，很容易实现查询、前缀词推荐系统，例如，我们将如下多个单词放入树结构中： [apple,bat,bee,cat,cap,car]，最终生成的前缀树结构为 通过深度递归，我们很容易用较小的时间复杂度判断出符合前缀的单词在不在 假设Trie的字符集范围是固定的，并且范围不大，例如是上面的纯英文字符，假设忽略大小写总共为26个，可以选择使用桶结构进行存储，即每一个Node都是一个长度为26的bucket数组 这样看来，Trie的结构并不复杂，只通过循环不断提高深度进行遍历即可 假定字符集的范围是未知的，或者范围很大（比如中文汉字），就要放弃使用bucket结构，而是通过一个Map维护，这里使用树结构TreeMap，key为相应节点的字符
2021-01-19鱼鱼
Agent 的规划与任务分解：让复杂任务可控
Agent 的规划与任务分解：让复杂任务可控简单问题一两步就能搞定，但“调研三个竞品并写一份对比报告”这类任务，如果让模型边想边做，很容易跑偏、遗漏或重复 规划（Planning） 就是让 Agent 在动手之前，先把大任务拆成可执行的小步骤 本文从动机讲起，比较三种常见规划模式，给出结构化计划的数据格式，以及一个带依赖调度、失败重试和重规划的完整 Python 示例，并附上 Java 版的计划模型、常见坑和检查清单 三种规划模式：ReAct、Plan-and-Execute 与层次化分解 回忆一下 ReAct：模型每一步只决定“下一步做什么” 这在短链路任务里很灵活，但当任务变长，会出现几类典型问题： 目标漂移：做到第 10 步，模型被中间的工具结果带偏，开始回答另一个问题；
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鱼鱼
让 AI 写 commit message，我留下的几条规矩
让 AI 写 commit message，我留下的几条规矩现在写完一小段改动，我偶尔会让 AI 根据 diff 拟一条 commit message 省事是真省事，翻车也真实翻过：有的标题漂亮得像广告，读完不知道改了什么；有的把半成品猜想写进历史，后来查问题的人会被带沟里 所以我不是禁用，而是给它加了几条规矩 规矩的核心只有一句：说明白改了什么、为什么改；别写套话，别替我编动机 Commit message 是给未来的自己和同事看的 好的 message 能回答：这次动了哪类东西？动机是修 bug、加能力，还是清债？有没有故意不做的范围？ AI 擅长扫 diff、归纳文件级变化，比我在疲惫时随手敲的 fix、update 强 但它也容易：
2026-10-14鱼鱼
用 AI 代替搜索引擎一阵子之后，我又把搜索框请了回来
用 AI 代替搜索引擎一阵子之后，我又把搜索框请了回来有一段时间，我几乎不打开搜索引擎了 遇到不会的东西，第一反应是切到 AI 对话框，把问题一贴，等它给我一段整理好的答案 说实话，这个体验太舒服了：不用在十个标签页之间来回翻，不用忍受广告和那种互相抄来抄去的“技术博客”，看不懂还可以接着追问，它也不会嫌我烦 那阵子我甚至跟同事开玩笑说，搜索框可以退休了 后来发生了几件小事，让我又把搜索框请了回来 现在我两样都用，只是分工比以前清楚多了 这篇就聊聊这个过程，没什么高深的东西，都是日常里的小体会 那天升级了一个依赖的小版本，项目启动直接报错 我把报错堆栈贴给 AI，它很快给了一个解释：大概是某个类加载顺序的问题，建议我调整一下配置，再加一个排除项
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鱼鱼
