用 AI 读英文技术文档：我怎么防它“翻译腔”和悄悄漏译
用 AI 读英文技术文档：我怎么防它“翻译腔”和悄悄漏译我英文阅读不算差，但读长篇官方文档还是累 尤其是那种配置参考页、迁移指南、RFC 风格的规范，一页几十屏，读到后面前面的全忘了 所以这两年我读英文文档，基本都会拉上 AI 一起：整段丢进去，让它翻成中文，或者干脆让它讲给我听 一开始我觉得这是纯赚的事 直到有一次按译文改了配置，上线前同事问我：“文档里不是说这个参数只有在另一个开关打开时才生效吗？”我回去翻原文，还真有那么一句 unless 从句，而 AI 给我的中文里，这半句干干净净地消失了 译文读起来非常顺，顺到我完全没怀疑 从那以后我对“AI 翻译技术文档”的态度变了：它很好用，但它的错不是乱码式的错，而是读起来很通顺的错
2026-10-16鱼鱼
盘点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鱼鱼
让 AI 写正则表达式：我现在一定先要它给反例
让 AI 写正则表达式：我现在一定先要它给反例正则大概是我最早放心交给 AI 的活 原因很简单：我自己写正则也是边查边试，每次写完都不太敢相信它 AI 张口就来，还附带逐段解释，看上去比我靠谱多了 用了一阵之后我发现，AI 写的正则有个很稳定的特点：它几乎总能匹配上你给的例子 问题是，正则真正出事的地方从来不在“该匹配的没匹配上”，而在“不该匹配的也匹配上了” 而后者，你不主动问，它不会告诉你 所以我现在有个死规矩：让 AI 写正则，先别要正则，先要反例 那次是要从一堆构建日志里提取版本号，格式是“主版本.次版本.修订号” 我给了 AI 三个例子，它很快给出 \d+\.\d+\.\d+，解释也清清楚楚 我跑了一下，三个例子全中，就提交了
2026-10-16鱼鱼
ES快速入门(I)——分析分词器
ES快速入门(I)——分析分词器本文旨在快速入门Elasticsearch的分词，包括分词分析器的创建和介绍对比等，请确保在阅读前已经搭建好完备的集群 文章基于es7.0+，与稍旧版本的主要区别是没有type 在讨论分词前，我们先看一下es整体创建倒排的分词过程： 我们常说的分词器指的其实是“分析器”analyzer，es将以上常用的逻辑封装起来成为analyzer，但是语义上的分词器是指上面的tokenizer 经过了三层处理后拿到了terms数组建立最终的倒排索引： character filter：一般不会用到这个filter，是在分词前对原有的文档字段内容做转换，例如去除html的标签提取出正文内容，按正则清除和替换某些内容，你可以指定及自定义0个到多个character filter，他们将共同存在，一个文本流在经过character filter处理后，依然是文本流；
![ES快速入门(I)——分析分词器]()
2020-09-01鱼鱼
使用RPC与Restful接口调用服务
使用RPC与Restful接口调用服务在SOA和微服务架构中，远程通信是无法避免的，最常用的远程通信有两种方式： restful的接口，使用Http通信 使用dubbo或是Spring Cloud组件进行 RPC协议远程调用，可选地使用socket通信 不同的人对 RPC调用会有不同的看法，甚至对rpc本身的理解都不甚相同，但我认为 RPC有两种倾向： 一为语义化的 RPC 没有统一的请求规范，数据格式在开发人员中很难达成一致，在使用传统Http调用时，交互的双方需要约定一份“API文档”以保证数据格式的唯一性，这样API格式本身就成为了一道大墙，耽误研发双方的时间 但如果服务间采用语义化 RPC进行交互，双方可能并不需要一份文档，只要一份约定好的代码，并以此作为双方的依赖，在请求时也仅仅是直接调用方法本身，如此强的语义性怎能让人不爱
2021-01-13鱼鱼
分布式系统一致性的分类
分布式系统一致性的分类在分布式系统中的CAP理论中有C(一致性)，大郅表示分布式系统中节点状态或数据具有一致的特性 但一致性有着不同的分类，例如常见的用于取代CAP理论的BASE中的E，最终一致性，不同于强一致性，他强调着事务最终状态趋于一致，但中间态可能不一致，利用此篇文章总结一下分布式系统的一致性分类 根据实际系统的要求，分布式系统的一致性可以大致分为四类： 严格一致性 强一致性（线性一致/原子一致） 顺序一致性 弱一致性（最终一致性） 一个理想概念上的一致性，节点间数据完全一致，对外可表现为单个节点 由于网络延迟和通信等因素的存在，现实中这种一致性不可能存在 强一致性要求在全局时钟相同的条件下，对任何节点的读都相同且等于最后一次写成功的数据，这也就意味着仅仅在所有节点同步到数据后才会被标记为同步成功
2021-03-13鱼鱼
分布式系统中的一致性算法和问题解决
分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同，需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统，他们的数据一致性算法不尽相同，例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法，而最近流行的Consul是raft算法，不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制，利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法，以便于在不同的业务环节上有着各自更贴切的处理 ps：有种观点是一致性算法不是很准确，因为replica也能保证数据某种程度上具有一致性，有人称之为共识算法
2021-03-13鱼鱼
Agent 并行调用工具：哪些能一起跑，哪些必须排队
Agent 并行调用工具：哪些能一起跑，哪些必须排队现在不少模型接口都允许模型在一轮回复里同时发起多个工具调用 对写 Agent 的人来说，这是个很诱人的能力：读五个文件不用等五轮，查三个接口可以一起发，整体耗时一下子降下来 我第一次给自己的 Agent 打开并行执行时，体感确实快了不少 然后就开始出怪事：有一次它在同一批调用里既改了一个文件，又跑了测试，测试跑的却是改之前的代码，结果它看着“通过”的测试，宣布任务完成 还有一次，两个写文件的调用同时改同一个配置文件，后写的把先写的覆盖了，日志里两个调用都显示成功 这些问题让我明白：模型愿意并行，不代表这些调用适合并行 模型给出的只是“我想做这几件事”，至于能不能同时做，得由执行层来判断
2026-10-16鱼鱼
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 帮我看别人的 PR，我怎么避免被它带偏
让 AI 帮我看别人的 PR，我怎么避免被它带偏code review 一直是我又爱又烦的环节 爱的是能提前拦住问题；烦的是有些 PR 又长又绕，下午三点看到，眼睛先花了 后来我开始让 AI 帮忙“先看一眼” 效率确实上来了：它能很快列出一堆疑点，有的还挺准 但用了一阵子，我也被它带偏过——有一次它言之凿凿说某段并发不安全，我跟着在评论区写了很长一段，作者委婉回复：那段代码根本不会并发进入 我再看，确实如此 尴尬归尴尬，也逼我把用法收紧了 这篇不是教你“用 AI 替代 review”，而是聊聊：怎么让它当助手，却不把结论权交出去 先说我自己的体感（不是评测数据，是使用感受） 相对擅长： 扫一眼有没有明显的空指针、资源没关、错误被吞
2026-10-14鱼鱼
浅谈代理-动态代理
浅谈代理-动态代理我们可以很轻松的实现一个简单的代理 实现静态代理是个很简单的事情，最基础的代理只需要定义一个接口(虽然不是必要，但这显然才是标准的设计)、一个被代理类和一个代理类，例如： 定义一个接口： 一个实现类： 和一个代理类： 实际使用时，我们是去调用HelloWorldProxy的方法，其将作为HelloWorld的代理实现 此种方式直接实现的代理太过于死板，因为每一种代理行为都要制定一个代理类，我们熟知的很多基于代理的实现（譬如AOP、事务）显然不可能用静态代理的方式针对每一处类切点都覆写一个代理类，这种时候就需要动态代理 我们所熟知的相当多的框架均基于动态代理开发，JDK本身基于反射(java.lang.reflect)提供了动态代理，我们只需定义代理的行为，而对于代理类的范围并不是固定值
![浅谈代理-动态代理]()
2020-10-13鱼鱼
用 AI 写周报和站会更新：我留下的几条「别丢人」规矩
用 AI 写周报和站会更新：我留下的几条「别丢人」规矩周报和站会更新，我以前最烦：明明一周干了不少事，一提笔就变成「推进了若干事项」「持续跟进中」 后来我开始扔给 AI 起草，效率是上来了，但笑不出来的次数也多了——它会帮你把话说得更像在汇报，却不一定更像在讲真话 这篇文章记我怎么用 AI 写周报/站会，以及几条「别丢人」的硬规矩 不是教大家写漂亮，是教大家少踩那种听起来很满、一问就空的坑 站会更新通常就三五行：昨天做了啥、今天打算啥、有没有卡点 周报稍长一点，但本质一样——用事实把进度钉住 这类文字格式固定、重复度高，很适合让 AI 从 git log、PR 列表、issue 评论里先拼一版草稿 我自己的流程很土： 先导出本周相关 commit / PR 标题（或自己列子弹）
2026-10-15鱼鱼
