用 AI 写代码越久，我越怕自己“手生”
用 AI 写代码越久，我越怕自己“手生”先说一个可能很多人都有过的瞬间：公司网络抽风，或者 AI 插件突然登录失效，你对着一个空白文件准备写点东西，然后发现自己卡住了 不是不会写，是那种“这个方法的参数顺序是啥来着”“这个异常该在哪一层处理来着”的卡顿 以前这些东西是肌肉记忆，现在得想一想 我第一次意识到这件事的时候，心里咯噔了一下 倒不是怕失业，那个话题太大了，轮不到我在这儿焦虑 我怕的是更具体的东西：当 AI 给出的代码出了问题，我还看不看得出来 这篇文章不打算劝谁少用 AI 我自己每天都在用，而且用得挺开心 我只是想把这种“手生”的感觉拆开看看，它到底是错觉还是真的，以及我目前摸索出来的一些应对办法 说是办法，其实也就是一些习惯，不一定对，供参考
2026-10-14鱼鱼
接手陌生代码库的第一周，我让 AI 当向导
接手陌生代码库的第一周，我让 AI 当向导前阵子我接手了一个老服务 说它老，不是说技术栈有多古早，而是它经历过好几拨人：最早写它的人早就转岗了，中间有人加过功能，也有人做过“临时方案”，README 停留在两年前的某次重构之前 给我的熟悉时间大概是一周，之后就要开始接需求 以前遇到这种情况，我的套路是从启动类开始一路点进去，点到头晕，再去翻提交记录，看看谁改得最多，厚着脸皮去问 这次我换了个方式：让 AI 陪我读 一周下来，感受挺复杂的——它确实让我快了不少，但也有几次差点把我带进沟里 这篇就记一下我是怎么用的，哪些地方好用，哪些地方我后来学乖了 我犯的第一个错，就是一上来问它：“帮我介绍一下这个项目的整体架构 ”
2026-10-14鱼鱼
分布式系统中的一致性算法和问题解决
分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同，需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统，他们的数据一致性算法不尽相同，例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法，而最近流行的Consul是raft算法，不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制，利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法，以便于在不同的业务环节上有着各自更贴切的处理 ps：有种观点是一致性算法不是很准确，因为replica也能保证数据某种程度上具有一致性，有人称之为共识算法
2021-03-13鱼鱼
扫盲——加密那些事
扫盲——加密那些事扫盲加密解密算法 日常开发中我们经常接触MD5算法，以此进行简单的文件完整性校验或者是后台密码验证，MD5是最常见也是最简单快捷的散列算法，常用于参数或文件完整性校验，譬如网络请求发起方与接收方分别对参数做MD5编码，一旦不一致便判断请求被篡改从而拒绝该请求，从而保证信息安全，编码后的字符串是编码前文本的一个简要梗概，因此它也被称作是信息摘要算法 这个算法的特点就是不可逆，只用于信息准确性和防篡改的校验，当然，MD5作为老牌的散列算法，很多经典的编码已经可以被反向解码出来（依靠正向的暴力穷举）以及被碰撞模仿（王小云院士团队的"破解"能够根据MD5编码后串码模拟原始消息，即使它可能与原信息不同），类似的还有SHA1，因此衍生了SHA224、SHA256、SHA512等更多安全的散列算法
2021-05-14鱼鱼
算法：Trie(前缀树、字典树）
算法：Trie(前缀树、字典树）前缀树(Trie，又称字典树)是一种功能倾向性很强的数据结构，通过对词汇的前缀做数结构，很容易实现查询、前缀词推荐系统，例如，我们将如下多个单词放入树结构中： [apple,bat,bee,cat,cap,car]，最终生成的前缀树结构为 通过深度递归，我们很容易用较小的时间复杂度判断出符合前缀的单词在不在 假设Trie的字符集范围是固定的，并且范围不大，例如是上面的纯英文字符，假设忽略大小写总共为26个，可以选择使用桶结构进行存储，即每一个Node都是一个长度为26的bucket数组 这样看来，Trie的结构并不复杂，只通过循环不断提高深度进行遍历即可 假定字符集的范围是未知的，或者范围很大（比如中文汉字），就要放弃使用bucket结构，而是通过一个Map维护，这里使用树结构TreeMap，key为相应节点的字符
2021-01-19鱼鱼
让 AI 帮我看别人的 PR，我怎么避免被它带偏
让 AI 帮我看别人的 PR，我怎么避免被它带偏code review 一直是我又爱又烦的环节 爱的是能提前拦住问题；烦的是有些 PR 又长又绕，下午三点看到，眼睛先花了 后来我开始让 AI 帮忙“先看一眼” 效率确实上来了：它能很快列出一堆疑点，有的还挺准 但用了一阵子，我也被它带偏过——有一次它言之凿凿说某段并发不安全，我跟着在评论区写了很长一段，作者委婉回复：那段代码根本不会并发进入 我再看，确实如此 尴尬归尴尬，也逼我把用法收紧了 这篇不是教你“用 AI 替代 review”，而是聊聊：怎么让它当助手，却不把结论权交出去 先说我自己的体感（不是评测数据，是使用感受） 相对擅长： 扫一眼有没有明显的空指针、资源没关、错误被吞
2026-10-14鱼鱼
给 Agent 设计工具：参数与错误返回怎么约定才好用
给 Agent 设计工具：参数与错误返回怎么约定才好用做 Agent 久了会发现：模型“聪不聪明”常常不是瓶颈，工具好不好用才是 同一个模型，换一套清晰的工具契约，成功率能差一截；换一套含糊的，它就会在重试里空转，或者把半成功当成成功继续往下跑 我踩过的坑大多长这样：工具返回一句 "failed"，模型不知道是参数错了、权限不够，还是下游超时；于是它换个说法再调一次，参数其实没变 或者工具抛了未捕获异常，框架把它变成空字符串，模型以为“没结果”就去编造 这篇文章只谈两件事：参数怎么设计，以及错误怎么返回，让工具对模型可观测、对系统可重试 图片来源：原创示意图 能用枚举就别用字符串 比如 priority: "high"|"normal"|"low"，不要 priority: string 然后在文档里写“建议传 high”
2026-10-14鱼鱼
AI 补全和整段生成，我什么时候用哪种
AI 补全和整段生成，我什么时候用哪种用 AI 写代码久了，我会下意识把它分成两种节奏：一种是编辑器里那个“跟着你敲”的补全；另一种是对话框里“给我写一整段 / 一整文件”的生成 表面上都是 AI 在写，体感完全不一样 补全像有人在旁边帮你把下一句顺出来；整段生成像你把需求扔出去，过一会儿收回来一份成品 我早期几乎只用后者，觉得效率高；后来越写越觉得：很多时候，补全才是更省心的那一个 这篇就聊聊我现在怎么选 补全的好处很直观——上下文就在光标周围，你刚写的函数名、变量名、注释，它都能“看见” 你按 tab 接受一行，再敲两下，它继续跟 这种节奏很接近自己写，只是手变快了一点 我特别喜欢在这些场景用补全： 写样板代码：DTO 字段、简单的 getter/mapper、重复的校验
2026-10-14鱼鱼
Agent 的流式输出与“停止”按钮：用户点了停止之后，到底该发生什么
Agent 的流式输出与“停止”按钮：用户点了停止之后，到底该发生什么给内部做的一个小 Agent 加“停止”按钮，我原本以为是半天的活：前端加个按钮，点了以后断开流式连接，完事 上线第二天就有同事反馈：他点了停止，文件却还是被改了 我去翻日志，发现事情是这样的：他点停止的时候，模型刚刚生成完一个写文件的工具调用；前端确实停止了渲染，连接也断了，但后端的 Agent 循环根本不知道用户已经喊停，照样把工具执行完了，甚至还又调了一次模型，生成了一段没人看的总结 那之后我才意识到，“停止”这件事远比一个按钮复杂 这篇就聊聊我后来是怎么重新设计的，主要讲三件事：取消信号怎么传到底、中断落在不同阶段该怎么处理、以及中断之后对话历史怎么写 我后来把“停止”拆成了三层，每一层都要单独处理：
2026-10-14鱼鱼
给 Agent 设超时和步数预算：别让它无限跑
给 Agent 设超时和步数预算：别让它无限跑第一次把 Agent 接到真实仓库时，我犯过一个很土的错：只盯着“它能不能做完”，没盯着“它最多能跑多久、最多能走几步” 结果某次工具调用卡在外部接口，它一边重试一边换策略，token 和墙钟时间一起烧，最后我手动杀掉，现场还一堆半成品文件 从那以后，我把超时和步数预算当成和权限同级的安全项 不是为了虐待 Agent，而是承认：自动化一旦没有硬上限，失败模式会从“报错”变成“悄悄耗尽” Agent 的轨迹很会制造希望：每一步都有日志，每一步都像在进步 可进步不等于收敛 常见假象包括： 同一类错误换着措辞重试 在几个文件间来回改，测试始终红 搜索范围越扩越大，上下文越来越脏
2026-10-14鱼鱼
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鱼鱼
动态路由数据源（多租户）解决方案
动态路由数据源（多租户）解决方案当下有很多服务都使用了多数据源，或是出于跨库查询或是分库分表、读写分离等，多数据源解决方案早已不是稀罕事 常见的解决方案包括使用多数据源框架(例如Shareding-Jdbc)、在数据库端做代理（例如MYCAT）、对于固定的几个数据源连接，也可以直接手动配置多个数据源，这种相关处理有很多源码，我在github上也有简单的实现：fishstormX/dynamicDataSource: 动态数据源的实现，基于maven自定义多模块骨架 Spring Boot2.0.x，本文实现的是动态数据源，主要为了解决 多租户问题（不同的用户群组有不同的数据源和配置，强调数据的隔离性） 本文技术能实现的是动态数据源，基于Spring框架，即能够将注入的Datasource根据租户不同使用不同的来源，同时根据租户增减动态的增删和缓存数据源（增是因为会有新增租户可能使用到项目启动后的数据源，减是因为租户数不可预料，不可直接缓存所有的数据源）
2021-01-07鱼鱼
