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
你好,这是一篇测试博客
你好,这是一篇测试博客这是一篇由助手代为撰写的测试博客 今天天气不错,适合写点东西 以后会在这里记录一些有趣的想法和学习笔记,欢迎大家多多交流
![你好,这是一篇测试博客]()
2026-09-30鱼鱼
让 AI 帮我看别人的 PR，我怎么避免被它带偏
让 AI 帮我看别人的 PR，我怎么避免被它带偏code review 一直是我又爱又烦的环节 爱的是能提前拦住问题；烦的是有些 PR 又长又绕，下午三点看到，眼睛先花了 后来我开始让 AI 帮忙“先看一眼” 效率确实上来了：它能很快列出一堆疑点，有的还挺准 但用了一阵子，我也被它带偏过——有一次它言之凿凿说某段并发不安全，我跟着在评论区写了很长一段，作者委婉回复：那段代码根本不会并发进入 我再看，确实如此 尴尬归尴尬，也逼我把用法收紧了 这篇不是教你“用 AI 替代 review”，而是聊聊：怎么让它当助手，却不把结论权交出去 先说我自己的体感（不是评测数据，是使用感受） 相对擅长： 扫一眼有没有明显的空指针、资源没关、错误被吞
2026-10-14鱼鱼
和 AI 结对写了一整天代码，我为什么比自己写还累
和 AI 结对写了一整天代码，我为什么比自己写还累有一天我做了个小实验：从早上到下班，整个需求全程开着 AI 助手，能问它的都问它，能让它写的都让它写 我原本的预期是“今天应该会很轻松” 结果下班的时候，我累得比平时还厉害 不是手累，是脑子那种被掏空的累 回头看产出，确实比平时多一点，但远没有到“轻松翻倍”的程度 那天晚上我想了挺久：问题到底出在哪？ 后来我又观察了自己几周，慢慢摸清楚了一些规律 这篇不讲什么高深技巧，就讲讲这种“沟通疲劳”是怎么来的，以及我试过的、确实有点用的几个办法 我把那天的感受拆了一下，大概有五个来源 一是持续评审 自己写代码时，脑子里是“我要怎么写”；跟 AI 结对时，脑子里一直是“它写得对不对”
2026-10-14鱼鱼
让 AI 当「橡皮鸭」：不问答案，先逼自己把问题说清楚
让 AI 当「橡皮鸭」：不问答案，先逼自己把问题说清楚调试时对着一只橡皮鸭把问题讲一遍，很多 bug 会自己露馅——这招老程序员都听过 我后来发现，AI 其实是一只很会追问的橡皮鸭：它不会嫌你啰嗦，还会在你讲不清的地方打断你 前提是：你别一上来就问“怎么修”，先逼自己把问题说清楚 这篇文章记我怎么把 AI 当橡皮鸭用，而不是当自动答题机 写的都是个人习惯，不保证适合每个人，但对我自己很管用 以前我的坏习惯是：报错一贴，再加一句“帮我修” AI 很快给一串可能原因和改法，我挑一个试，不行再试下一个 看起来很高效，其实经常在还没定义清楚问题的情况下乱开枪 典型症状： 修完 A，B 又坏了，才发现根因根本不是 A AI 给的方案依赖一个我其实没有的前提（比如“你用的是某某版本默认配置”）
2026-10-14鱼鱼
长任务 Agent 的上下文压缩：摘要什么、丢什么、什么必须原样留着
长任务 Agent 的上下文压缩：摘要什么、丢什么、什么必须原样留着我自己写的那个编程 Agent，最早只用来做一些小改动，十几轮对话就结束了，上下文从来不是问题 后来我开始让它做跨很多文件的迁移，比如把一批旧接口的调用换成新接口 这种任务一跑就是几十轮：读文件、搜索、改代码、跑测试、看报错、再改 每一轮的工具输出都往上下文里堆，没多久就逼近了模型的上下文上限 于是我做了第一版“压缩”：上下文超过某个阈值，就让模型把之前的历史总结成一段话，然后用这段总结替换掉原来的历史，继续往下跑 听起来很合理，跑起来问题一大堆 这篇就讲讲我前后几次改动的过程，以及现在比较稳定的做法 都是在我自己这个 Agent 上摸索出来的经验，换个场景未必完全适用 第一版用的是自由发挥式的摘要，提示大概就是“请总结上面的对话，保留重要信息”
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鱼鱼
用 AI 写周报和站会更新：我留下的几条「别丢人」规矩
用 AI 写周报和站会更新：我留下的几条「别丢人」规矩周报和站会更新，我以前最烦：明明一周干了不少事，一提笔就变成「推进了若干事项」「持续跟进中」 后来我开始扔给 AI 起草，效率是上来了，但笑不出来的次数也多了——它会帮你把话说得更像在汇报，却不一定更像在讲真话 这篇文章记我怎么用 AI 写周报/站会，以及几条「别丢人」的硬规矩 不是教大家写漂亮，是教大家少踩那种听起来很满、一问就空的坑 站会更新通常就三五行：昨天做了啥、今天打算啥、有没有卡点 周报稍长一点，但本质一样——用事实把进度钉住 这类文字格式固定、重复度高，很适合让 AI 从 git log、PR 列表、issue 评论里先拼一版草稿 我自己的流程很土： 先导出本周相关 commit / PR 标题（或自己列子弹）
2026-10-15鱼鱼
AI 自动补全抢方向盘：什么时候该关掉它
AI 自动补全抢方向盘：什么时候该关掉它AI 补全（或行内建议）最迷人的地方，是它常常「猜对你下一句」 最烦人的地方也是这个——它猜对下一句时，也可能把你带离本来要开的那条路 我不是补全黑名单派 体力活、重复模式、测试样板，我开着很香 但这篇文章想写清楚：哪些时刻我会主动关掉或忽略它，以及为什么「一直开着」会偷偷伤到设计质量 写给那些已经习惯 Tab，却说不清「这段到底是我想的还是它推的」的人 典型场景： 你正要抽一个接口，光标停在名字上，它已经按旧习惯补出一个「很大很全」的方法签名 你在探索两种方案，它持续把你推向仓库里更常见的那一种 你想写个丑但明确的临时实现，它不停建议「更优雅」的抽象 命名还没想清，它已经用空心词把名字钉死了
2026-10-15鱼鱼
JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析
JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析在Spring获取Context的源代码中，我们看到了对ClassUtil的方法调用，通过给定ClassName和ClassLoader进行Class的加载： ClassUtil.forName是仅供于Spring内部使用的获取Class对象的方法，来看一下源码： 首先 对于缓存的Class一块，在类的静态块中就能看出其逻辑： 在上面的resolvePrimitiveClassName方法中，先对长度做了一个判断，因为较长的packagename会影响执行的性能： 最终加载Class依旧是通过ClassLoader的，先来看一下获取ClassLoader的方法实现： 此处优先使用了ContextClassLoader作为 类加载器而非默认的AppClassLoader，在JVM源码解析 从 Launcher类浅谈ClassLoader中，提到了关于 类加载器的相关知识，使用ContextClassLoader是为了弥补双亲委派加载机制的对于自定义 类加载器的缺憾：那些自定义的 类加载器并没有机会上场，在使用了AppClassLoader后我们的自定义ClassLoader所加载的Class是无法被加载进去的，使用ContextClassLoader，我们可以在定义线程时，通过Thread的init方法(子线程调用，私有方法)或是setContextClassLoader直接指定使用自定义的ClassLoader
![JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析]()
2020-08-16鱼鱼
AI 生成的 README 和注释，我为什么经常删掉重写
AI 生成的 README 和注释，我为什么经常删掉重写AI 写文档很快：README、函数注释、模块说明，几秒就能铺满 我早期几乎照单全收，后来越来越频繁地整段删掉重写 不是因为文笔不好，而是因为很多生成文档在“正确的废话”和“过时的细节”之间晃，读的人费时间，维护的人更痛苦 这篇文章记我什么时候信它、什么时候动手砍，以及重写时我保什么、扔什么 1. 正确的废话 “本模块用于处理订单相关逻辑，提供创建、查询与更新能力 ”——读完等于没读 它没有告诉我边界、不变量、也没有告诉我别乱用的地方 2. 和代码赛跑的细节 把当前参数列表、每一步实现按行复述一遍 代码一改，注释就撒谎 AI 特别擅长写这种“现在时”的说明，因为它看见的就是此刻源码
2026-10-14鱼鱼
多轮对话里的「目标漂移」：Agent 跑着跑着忘了你要什么
多轮对话里的「目标漂移」：Agent 跑着跑着忘了你要什么和 Agent 多轮协作久了，会遇到一种安静的失败：它一直很忙，工具也在调，中间步骤看起来都“合理”，可收工时你发现——干的已经不是你起初要的那件事 我把这叫目标漂移（goal drift） 不是偶发幻觉那么简单，更像是上下文变长后，约束被一步步冲淡 这篇文章记我怎么发现漂移、怎么在过程中拉回，以及设计 Agent 时能做哪些防漂 常见几种面孔： 每一步单独看都有道理：重构有益、修复积极、干净也好 合起来却违背委托 危险在于局部合理、全局偏航 图：目标漂移四种脸：膨胀、替换、偷换、遗忘（原创示意图） 我的个人理解（含推测）： 所以漂移不完全是“模型不听话”，也是交互方式与系统设计的结果
2026-10-14鱼鱼
