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
DDD领域下的架构模式——CQRS架构
DDD领域下的架构模式——CQRS架构//TODO
![DDD领域下的架构模式——CQRS架构]()
2021-06-24鱼鱼
AI 生成的 README 和注释，我为什么经常删掉重写
AI 生成的 README 和注释，我为什么经常删掉重写AI 写文档很快：README、函数注释、模块说明，几秒就能铺满 我早期几乎照单全收，后来越来越频繁地整段删掉重写 不是因为文笔不好，而是因为很多生成文档在“正确的废话”和“过时的细节”之间晃，读的人费时间，维护的人更痛苦 这篇文章记我什么时候信它、什么时候动手砍，以及重写时我保什么、扔什么 1. 正确的废话 “本模块用于处理订单相关逻辑，提供创建、查询与更新能力 ”——读完等于没读 它没有告诉我边界、不变量、也没有告诉我别乱用的地方 2. 和代码赛跑的细节 把当前参数列表、每一步实现按行复述一遍 代码一改，注释就撒谎 AI 特别擅长写这种“现在时”的说明，因为它看见的就是此刻源码
2026-10-14鱼鱼
给仓库写一份 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鱼鱼
Springboot源码原理：从启动方法看配置加载
Springboot源码原理：从启动方法看配置加载首先看一个springboot项目的配置，我们可以定义一个application.yml，对于不同的环境有时也通过profile配置项指定不同的配置文件（譬如application-dev.yml），也可以通过命令行覆写具体的VM options配置项（举个栗子，启动时执行 java -jar xxx.jar --server.port=8080），此文讲解这些配制的读取原理 整体配置项的优先级从高到低为： 命令行配置； 系统属性(System.getProperties()) 系统环境变量 jar包外的主配置文件（带有） jar包内的主配置文件 jar包外的次要配置文件（由spring.profile指定的）
2021-03-09鱼鱼
盘点redis中特殊的数据类型 HyperLogLog Bitmap
盘点redis中特殊的数据类型 HyperLogLog Bitmap 基数计数(cardinality counting)通常用来统计一个集合中不重复的元素个数，例如统计某个网站的UV，或者用户搜索网站的关键词数量 数据分析、网络监控及数据库优化等领域都会涉及到基数计数的需求 要实现基数计数，最简单的做法是记录集合中所有不重复的元素集合S_uSu，当新来一个元素x_ixi，若S_uSu中不包含元素x_ixi，则将x_ixi加入S_uSu，否则不加入，计数值就是S_uSu的元素数量 这种做法存在两个问题： 当统计的数据量变大时，相应的存储内存也会线性增长 当集合S_uSu变大，判断其是否包含新加入元素x_ixi的成本变大 大数据量背景下，要实现基数计数，首先需要确定存储统计数据的方案，以及如何根据存储的数据计算基数值；另外还有一些场景下需要融合多个独立统计的基数值，例如对一个网站分别统计了三天的UV，现在需要知道这三天的UV总量是多少，怎么融合多个统计值
![盘点redis中特殊的数据类型 HyperLogLog Bitmap]()
2022-01-12鱼鱼
Agent 的规划与任务分解：让复杂任务可控
Agent 的规划与任务分解：让复杂任务可控简单问题一两步就能搞定，但“调研三个竞品并写一份对比报告”这类任务，如果让模型边想边做，很容易跑偏、遗漏或重复 规划（Planning） 就是让 Agent 在动手之前，先把大任务拆成可执行的小步骤 本文从动机讲起，比较三种常见规划模式，给出结构化计划的数据格式，以及一个带依赖调度、失败重试和重规划的完整 Python 示例，并附上 Java 版的计划模型、常见坑和检查清单 三种规划模式：ReAct、Plan-and-Execute 与层次化分解 回忆一下 ReAct：模型每一步只决定“下一步做什么” 这在短链路任务里很灵活，但当任务变长，会出现几类典型问题： 目标漂移：做到第 10 步，模型被中间的工具结果带偏，开始回答另一个问题；
2026-10-14鱼鱼
PyCharm与python快速开发
PyCharm与python快速开发Python语言作为“胶水语言”，简单易学，开发周期快，功能和扩展性强大，类库丰富 只依赖一门Java并不适用于所有情况，譬如快速开发一次性脚本(修复数据)，通过使用Python效率更高，本篇文章旨在介绍本人快速入门Python的一些tips 注意，一些Python的基本语法在此不予介绍，推荐前往廖雪峰的博客查看，博客基于Python3.8版本 关于编译器等配置内容参考PyCharm帮助文档 从Python官网下载Python并安装，配置环境变量，安装PyCharm（这里 我们使用它作为IDE），这里略过 pip是python的包管理与安装工具，当你安装python后，pip也会随之被安装
2021-01-16鱼鱼
子 Agent 的上下文隔离：派活时给什么，收回来要什么
子 Agent 的上下文隔离：派活时给什么，收回来要什么我第一次在自己的 Agent 里用“子 Agent”，动机很朴素：主任务的上下文太长了 主 Agent 在帮我做一次跨模块的重构，前面已经读了一堆文件、讨论了好几轮方案，这时候它需要搞清楚“仓库里有哪些地方调用了某个旧接口” 这种搜索很费上下文：要翻很多文件，大部分都是无关的 于是我想，把这个搜索派给一个子 Agent 去做，让它搜完只汇报结果，主 Agent 的上下文就干净了 想法没问题，但我前后改了三版才算勉强满意 这篇就聊聊这个过程里我对“上下文隔离”的理解：为什么要隔离、派活时给什么、收回来要什么，以及哪些情况其实不该隔离 最开始我图省事，直接把主 Agent 的完整对话历史复制给子 Agent，再加一句“请找出所有调用旧接口的地方”
2026-10-14鱼鱼
MCP 协议入门：给 Agent 一个统一的“工具接口”
MCP 协议入门：给 Agent 一个统一的“工具接口”当 Agent 需要接入越来越多的外部能力——文件系统、数据库、GitHub、内部系统——每个工具都要自己写一套适配代码，非常繁琐 MCP（Model Context Protocol，模型上下文协议） 就是为了解决这个问题而提出的开放协议，由 Anthropic 发布，目标是让“AI 应用”和“外部工具/数据源”之间有一套统一的对接标准 本文从动机出发，讲清楚 MCP 的角色、能力、消息流程，带你用 SDK 写一个最小 Server，再用不依赖 SDK 的方式手写一遍协议交互来理解本质，最后总结安全注意事项、常见坑和 FAQ 从 N×M 到 N+M：Host、Client 与 Server 的分工
2026-10-14鱼鱼
让 AI 解释陌生代码：我怎么听出它在「圆场」
让 AI 解释陌生代码：我怎么听出它在「圆场」接手陌生模块时，我常会把一段代码丢给 AI，问：「这是在干什么？」它几乎总能讲出一套流畅的故事 问题是——流畅不等于正确，更不等于它真读懂了约束 我越来越在意一种说话方式：它在「圆场」 表面在解释，实际在把不确定的地方用顺滑的因果糊过去 这篇文章记我怎么听、怎么追问、什么时候该停 写给同样会在「哇它好懂」和「等等它是不是编的」之间来回横跳的人 我遇到过的圆场，大概有几类： 因果补全：代码里没写为什么，它给你编一个听起来合理的「因为……所以……」 命名联想：函数叫 refreshCache，它就按「刷新缓存」的教科书含义讲，不管仓库里这个词早就变味 忽略例外路径：主路径讲得很漂亮，catch、降级、兼容分支一笔带过
2026-10-15鱼鱼
