让 AI 起变量名和函数名，我留下的几条品味规矩
让 AI 起变量名和函数名，我留下的几条品味规矩命名一直是我写代码时最磨蹭的环节之一 名字起糊了，后面读代码的人（包括一个月后的我）会一直付税 AI 很擅长甩出一串候选名，也很容易甩出看起来专业、读起来空洞的名字 这篇文章记我让它起名时留下的几条规矩——不是语法规范全文，是品味上的取舍 我愿意让 AI 起名，前提是： 我已经能用一句话说明“这个东西在业务里干什么” 我要的是 3–5 个候选，不是一个“最佳答案” 最终选定权在我，尤其是会进公共 API、表字段、事件名的那些 一上来就说“给个好名字”，它常会给你 handleUserData、processInfo、manageService 这类语法正确但语义稀释的词 候选机模式能逼它发散，也逼我比较
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鱼鱼
浅析RPC框架Thrift
浅析RPC框架ThriftThrift是由Facebook开发的 RPC远程调用的框架，使用独有的Thrift协议进行可跨语言的远程调用 有点类似protobuf 无论使用何种语言，首先要准备Thrift编译环境，可以去官网下载相应的Thrift执行文件，下文均以Windows为例 下载后可以选择性的配置环境变量，最终在shell中可执行Thrift 在项目中，预先准备好libthrift依赖，maven写法： 例如： 定义一个testService.thrift（idl文件名不重要），一般都会定义在resources的thrift文件夹下： 这里定义了两个方法，分别返回字符串和int类型，在thrift的idl中，对于变量的定义如下：
2022-03-04鱼鱼
和 AI 结对写了一整天代码，我为什么比自己写还累
和 AI 结对写了一整天代码，我为什么比自己写还累有一天我做了个小实验：从早上到下班，整个需求全程开着 AI 助手，能问它的都问它，能让它写的都让它写 我原本的预期是“今天应该会很轻松” 结果下班的时候，我累得比平时还厉害 不是手累，是脑子那种被掏空的累 回头看产出，确实比平时多一点，但远没有到“轻松翻倍”的程度 那天晚上我想了挺久：问题到底出在哪？ 后来我又观察了自己几周，慢慢摸清楚了一些规律 这篇不讲什么高深技巧，就讲讲这种“沟通疲劳”是怎么来的，以及我试过的、确实有点用的几个办法 我把那天的感受拆了一下，大概有五个来源 一是持续评审 自己写代码时，脑子里是“我要怎么写”；跟 AI 结对时，脑子里一直是“它写得对不对”
2026-10-14鱼鱼
Golang 面试进阶指南：从 GMP 到 pprof，一份面向中高级岗位的系统复习手册
Golang 面试进阶指南：从 GMP 到 pprof，一份面向中高级岗位的系统复习手册如果你已经写过一两年 Go，会用 goroutine、channel，也能把一个 HTTP 服务跑起来，那么在准备中高级岗位面试时，大概率会发现：面试官问的已经不是“goroutine 怎么启动”，而是“一个阻塞的系统调用发生时，调度器会做什么”“nil 的 error 为什么不等于 nil”“线上 goroutine 数量一直涨，你怎么定位” 这类问题考察的不是背诵，而是你对运行时机制的理解，以及把机制翻译成工程判断的能力 这篇文章是一份按主题组织的复习手册 每个主题基本遵循同一个结构：典型面试题 → 参考回答思路 → 常见陷阱 → 简短的代码 内容覆盖调度器、goroutine 生命周期、channel、sync 原语、context、内存模型、GC 与逃逸分析、slice 与 map、interface、defer/panic/recover、泛型、错误处理、反射、并发模式、性能调优、工程实践，最后补充系统设计与行为面试的建议、速答表、学习路线和 FAQ
2026-10-14鱼鱼
多智能体协作的几种常见模式
多智能体协作的几种常见模式一个 Agent 不够用时，自然会想到“多找几个 Agent 分工” 但多智能体并不是数量越多越好——它带来分工优势的同时，也带来了通信成本、调试难度和 token 开销 本文梳理几种常见协作模式及其适用场景，给出主管—工人、评审循环的 Python 示例和 Java 版的消息结构，并总结常见坑、检查清单与 FAQ 从“大而全”的单个 Agent 到“小而专”的分工 单 Agent 加工具，已经能解决很大一类问题 但随着任务变复杂，常见瓶颈会逐渐出现： 上下文被挤满：几十个工具的说明、长长的历史、大量检索结果挤在一个窗口里，模型注意力被稀释； 角色冲突：同一个提示词里既要求“大胆创作”又要求“严格挑错”，两种要求互相拉扯；
2026-10-14鱼鱼
使用RPC与Restful接口调用服务
使用RPC与Restful接口调用服务在SOA和微服务架构中，远程通信是无法避免的，最常用的远程通信有两种方式： restful的接口，使用Http通信 使用dubbo或是Spring Cloud组件进行 RPC协议远程调用，可选地使用socket通信 不同的人对 RPC调用会有不同的看法，甚至对rpc本身的理解都不甚相同，但我认为 RPC有两种倾向： 一为语义化的 RPC 没有统一的请求规范，数据格式在开发人员中很难达成一致，在使用传统Http调用时，交互的双方需要约定一份“API文档”以保证数据格式的唯一性，这样API格式本身就成为了一道大墙，耽误研发双方的时间 但如果服务间采用语义化 RPC进行交互，双方可能并不需要一份文档，只要一份约定好的代码，并以此作为双方的依赖，在请求时也仅仅是直接调用方法本身，如此强的语义性怎能让人不爱
2021-01-13鱼鱼
用 AI 写周报和站会更新：我留下的几条「别丢人」规矩
用 AI 写周报和站会更新：我留下的几条「别丢人」规矩周报和站会更新，我以前最烦：明明一周干了不少事，一提笔就变成「推进了若干事项」「持续跟进中」 后来我开始扔给 AI 起草，效率是上来了，但笑不出来的次数也多了——它会帮你把话说得更像在汇报，却不一定更像在讲真话 这篇文章记我怎么用 AI 写周报/站会，以及几条「别丢人」的硬规矩 不是教大家写漂亮，是教大家少踩那种听起来很满、一问就空的坑 站会更新通常就三五行：昨天做了啥、今天打算啥、有没有卡点 周报稍长一点，但本质一样——用事实把进度钉住 这类文字格式固定、重复度高，很适合让 AI 从 git log、PR 列表、issue 评论里先拼一版草稿 我自己的流程很土： 先导出本周相关 commit / PR 标题（或自己列子弹）
2026-10-15鱼鱼
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鱼鱼
Agent 的重试与换路：失败了再试一次，还是换条路？
Agent 的重试与换路：失败了再试一次，还是换条路？做 Agent 的人，迟早会碰到同一个设计题：工具调用失败了，下一步是原地再试，还是换个策略？ 听起来像工程里的重试策略老话题，放到 Agent 里却更别扭——因为失败的原因经常不是“网络抖了一下”，而是“这条路根本走不通”，或者“模型把错误理解歪了，越重试越执着” 我踩过两边的坑：该重试时太早放弃，任务脆；该换路时死磕重试，账单和日志一起爆炸，最后还是失败 这篇整理一下我现在怎么做判断 不是所有失败都该一视同仁 我大致分成四类： 瞬时故障：超时、限流、连接重置 特征是：同一请求，过一会儿可能就好 输入问题：参数缺了、格式不对、路径不存在 特征是：原样再发，几乎必败 权限/策略拒绝：没权限、被安全策略拦住
2026-10-14鱼鱼
Agent 的流式输出与“停止”按钮：用户点了停止之后，到底该发生什么
Agent 的流式输出与“停止”按钮：用户点了停止之后，到底该发生什么给内部做的一个小 Agent 加“停止”按钮，我原本以为是半天的活：前端加个按钮，点了以后断开流式连接，完事 上线第二天就有同事反馈：他点了停止，文件却还是被改了 我去翻日志，发现事情是这样的：他点停止的时候，模型刚刚生成完一个写文件的工具调用；前端确实停止了渲染，连接也断了，但后端的 Agent 循环根本不知道用户已经喊停，照样把工具执行完了，甚至还又调了一次模型，生成了一段没人看的总结 那之后我才意识到，“停止”这件事远比一个按钮复杂 这篇就聊聊我后来是怎么重新设计的，主要讲三件事：取消信号怎么传到底、中断落在不同阶段该怎么处理、以及中断之后对话历史怎么写 我后来把“停止”拆成了三层，每一层都要单独处理：
2026-10-14鱼鱼
让 AI 写 SQL 和迁移脚本：语法没错，坑全在数据里
让 AI 写 SQL 和迁移脚本：语法没错，坑全在数据里在我日常用 AI 写的各种代码里，SQL 大概是“看起来最省心”的一类 语法它几乎不会写错，连窗口函数、递归 CTE 都信手拈来 让它写个报表查询，或者写个加字段的迁移脚本，几秒钟就好，读一遍也挑不出毛病 但正是这种“挑不出毛病”，让我吃过好几次亏 SQL 的坑很少出在语法上，而是出在语义、数据量和线上环境上——这三样东西，恰恰是 AI 在对话框里看不到的 这篇就把我踩过、或者差点踩到的坑整理一下，最后再说说我现在的做法 先交代背景：我平时主要接触 MySQL，也维护过一些 PostgreSQL 的项目 下面说到具体行为时，我尽量注明是哪个数据库；不同版本之间行为可能有差异，以你用的版本的官方文档为准
2026-10-14鱼鱼
