AI 补全和整段生成，我什么时候用哪种
AI 补全和整段生成，我什么时候用哪种用 AI 写代码久了，我会下意识把它分成两种节奏：一种是编辑器里那个“跟着你敲”的补全；另一种是对话框里“给我写一整段 / 一整文件”的生成 表面上都是 AI 在写，体感完全不一样 补全像有人在旁边帮你把下一句顺出来；整段生成像你把需求扔出去，过一会儿收回来一份成品 我早期几乎只用后者，觉得效率高；后来越写越觉得：很多时候，补全才是更省心的那一个 这篇就聊聊我现在怎么选 补全的好处很直观——上下文就在光标周围，你刚写的函数名、变量名、注释，它都能“看见” 你按 tab 接受一行，再敲两下，它继续跟 这种节奏很接近自己写，只是手变快了一点 我特别喜欢在这些场景用补全： 写样板代码：DTO 字段、简单的 getter/mapper、重复的校验
2026-10-14鱼鱼
让 AI 帮我把项目升到 Spring Boot 3：它扛了体力活，也埋了几个坑
让 AI 帮我把项目升到 Spring Boot 3：它扛了体力活，也埋了几个坑我们组有个内部服务，一直跑在 Spring Boot 2 上 2.x 早就停止开源免费维护了，安全扫描隔三岔五报一堆依赖漏洞，升级这件事拖了很久，终于排到了我头上 这次我决定全程拉着 AI 一起干 前后大概用了一周多（中间还穿插着别的需求），最后顺利上线 回头看，AI 确实帮我扛了大部分体力活，但也有几个坑是它挖的，或者至少是它没提醒我的 这篇把过程和教训记下来，给同样准备升级的同学参考 先声明：下面说的都是我们这个项目的情况，每个项目的依赖和历史包袱不一样，具体以 Spring 官方的迁移指南为准 一开始我问 AI：“把这个项目从 Spring Boot 2 升到 3，需要改什么？”它给了一份清单，大方向没错：Java 版本要 17 以上、javax 包要换成 jakarta、Spring Security 的配置写法变了，等等
2026-10-14鱼鱼
子 Agent 的上下文隔离：派活时给什么，收回来要什么
子 Agent 的上下文隔离：派活时给什么，收回来要什么我第一次在自己的 Agent 里用“子 Agent”，动机很朴素：主任务的上下文太长了 主 Agent 在帮我做一次跨模块的重构，前面已经读了一堆文件、讨论了好几轮方案，这时候它需要搞清楚“仓库里有哪些地方调用了某个旧接口” 这种搜索很费上下文：要翻很多文件，大部分都是无关的 于是我想，把这个搜索派给一个子 Agent 去做，让它搜完只汇报结果，主 Agent 的上下文就干净了 想法没问题，但我前后改了三版才算勉强满意 这篇就聊聊这个过程里我对“上下文隔离”的理解：为什么要隔离、派活时给什么、收回来要什么，以及哪些情况其实不该隔离 最开始我图省事，直接把主 Agent 的完整对话历史复制给子 Agent，再加一句“请找出所有调用旧接口的地方”
2026-10-14鱼鱼
AI 生成测试我怎么取舍：哪些让它写，哪些必须人写
AI 生成测试我怎么取舍：哪些让它写，哪些必须人写用 AI 写业务代码越来越顺手之后，下一件很自然的事就是：让它把测试也补上 说实话，这一步的爽感很强——几分钟冒出一堆 should_xxx，覆盖率数字往上跳，CI 绿灯 问题也正好出在这里：绿灯不等于有保险 我经历过一次挺丢脸的事 AI 帮我补了十几个单测，覆盖率从 40% 拉到 75%，合并后第三天生产就炸了 回头看测试，几乎每个都在验证“mock 对象有没有按我设定的方式被调用”，真正的业务不变量一个都没钉住 测试在保护 mock，不在保护系统 这篇文章想说清楚三件事：哪些测例我愿意交给 AI；哪些我坚持人手写；以及怎么减少“假绿” 图片来源：原创示意图 我不想装清高
2026-10-14鱼鱼
用 AI 代替搜索引擎一阵子之后，我又把搜索框请了回来
用 AI 代替搜索引擎一阵子之后，我又把搜索框请了回来有一段时间，我几乎不打开搜索引擎了 遇到不会的东西，第一反应是切到 AI 对话框，把问题一贴，等它给我一段整理好的答案 说实话，这个体验太舒服了：不用在十个标签页之间来回翻，不用忍受广告和那种互相抄来抄去的“技术博客”，看不懂还可以接着追问，它也不会嫌我烦 那阵子我甚至跟同事开玩笑说，搜索框可以退休了 后来发生了几件小事，让我又把搜索框请了回来 现在我两样都用，只是分工比以前清楚多了 这篇就聊聊这个过程，没什么高深的东西，都是日常里的小体会 那天升级了一个依赖的小版本，项目启动直接报错 我把报错堆栈贴给 AI，它很快给了一个解释：大概是某个类加载顺序的问题，建议我调整一下配置，再加一个排除项
2026-10-14鱼鱼
给 Agent 设计工具：参数与错误返回怎么约定才好用
给 Agent 设计工具：参数与错误返回怎么约定才好用做 Agent 久了会发现：模型“聪不聪明”常常不是瓶颈，工具好不好用才是 同一个模型，换一套清晰的工具契约，成功率能差一截；换一套含糊的，它就会在重试里空转，或者把半成功当成成功继续往下跑 我踩过的坑大多长这样：工具返回一句 "failed"，模型不知道是参数错了、权限不够，还是下游超时；于是它换个说法再调一次，参数其实没变 或者工具抛了未捕获异常，框架把它变成空字符串，模型以为“没结果”就去编造 这篇文章只谈两件事：参数怎么设计，以及错误怎么返回，让工具对模型可观测、对系统可重试 图片来源：原创示意图 能用枚举就别用字符串 比如 priority: "high"|"normal"|"low"，不要 priority: string 然后在文档里写“建议传 high”
2026-10-14鱼鱼
Kafka服务端集群原理
Kafka服务端集群原理kafka是家喻户晓的消息队列，也因“纯粹”而闻名（高性能高吞吐、扩展较少较为简单），此篇文章整理Kafka的基本架构，将按照Kafka的版本迭代分别展示架构的演进（截至版本3.0） 我们在这里暂且只讨论Kafka服务端，对于生产者和消费者的逻辑简单带过 扫盲一下Kafka的部分概念： Producer mq生产者通用叫法 作为消息的生产者，在生产完消息后需要将消息投送到指定的目的地（某个topic的某个partition） Producer可以根据指定选择partition的算法或者是随机方式来选择发布消息到哪个partition； Consumer mq生产者通用叫法 消息消费者，向Kafka broker读取消息的客户端;，负责订阅和消费消息
2022-03-10鱼鱼
AI 时代的编程语言选型：Python、Go、TypeScript、Rust 与 Java 怎么选
AI 时代的编程语言选型：Python、Go、TypeScript、Rust 与 Java 怎么选“该学哪门语言”“新项目该用什么语言”，这类问题每隔几年就会被重新讨论一次，而大模型的出现让它又多了几个新变量：模型和推理框架主要活在哪个生态里？AI 写代码时哪种语言更省心？Agent 要同时调用几十个工具、开几百个连接，并发模型撑得住吗？本文不做“语言排行榜”，也不宣布谁是赢家，而是从 AI 时代的选型维度出发，深入比较 Python、Go、TypeScript、Rust 四门语言，兼顾这个 Java 爱好者博客的主角 Java，再简要看看 C++ 与 C#，给出同一小任务的代码对照、一张综合对比表、按场景的选型建议、多语言组合架构思路，以及常见坑与 FAQ AI 时代选型新增的七个考量点
2026-10-14鱼鱼
Java的SPI机制
Java的SPI机制SPI（Service Provider Interface） 是JDK内部提供的一种用于服务能力扩展的机制 在服务中通过不同的下沉方法实现能够加载不同的接口实现类，从而实现功能的热插拔 相比一些类似的设计模式（例如策略模式）， SPI作为Java自带的实现特性，相对更加灵活和开放 我们常见的JDBC、日志框架slf4j、JavaMail、Spring等组件都基于 SPI实现（例如JDBC针对不同数据源的驱动） 之所以说区别于Java的一些设计模式，因为Java有一些实现能实现 SPI的动态加载 首先让我们定义 SPI对外提供抽象能力的接口类，这里为了便于理解展示包路径：
2024-10-14鱼鱼
提示词工程与上下文工程：让模型看到“对的信息”
提示词工程与上下文工程：让模型看到“对的信息”写 Agent 时，很多人把精力放在“提示词怎么写得更花哨”上 实际上，更影响效果的往往是：在每一步，模型的上下文里究竟放了什么 这就是近来常被提起的“上下文工程（Context Engineering）” 本文先区分提示词工程与上下文工程，再讲系统提示的结构、上下文的选择/压缩/隔离/外置四种手段，提供一个带 token 预算的上下文组装器（Python）与结构化输出校验（Python + Java），最后总结常见错误、检查清单与 FAQ 上下文窗口里的六个组成部分 很多团队有过这样的经历：换了更强的模型，效果只提升了一点；而把检索结果排序调整了一下、把冗长的工具输出裁剪了一下，效果反而明显改善
2026-10-14鱼鱼
让 AI 起变量名和函数名，我留下的几条品味规矩
让 AI 起变量名和函数名，我留下的几条品味规矩命名一直是我写代码时最磨蹭的环节之一 名字起糊了，后面读代码的人（包括一个月后的我）会一直付税 AI 很擅长甩出一串候选名，也很容易甩出看起来专业、读起来空洞的名字 这篇文章记我让它起名时留下的几条规矩——不是语法规范全文，是品味上的取舍 我愿意让 AI 起名，前提是： 我已经能用一句话说明“这个东西在业务里干什么” 我要的是 3–5 个候选，不是一个“最佳答案” 最终选定权在我，尤其是会进公共 API、表字段、事件名的那些 一上来就说“给个好名字”，它常会给你 handleUserData、processInfo、manageService 这类语法正确但语义稀释的词 候选机模式能逼它发散，也逼我比较
2026-10-14鱼鱼
用 AI 读英文技术文档：我怎么防它“翻译腔”和悄悄漏译
用 AI 读英文技术文档：我怎么防它“翻译腔”和悄悄漏译我英文阅读不算差，但读长篇官方文档还是累 尤其是那种配置参考页、迁移指南、RFC 风格的规范，一页几十屏，读到后面前面的全忘了 所以这两年我读英文文档，基本都会拉上 AI 一起：整段丢进去，让它翻成中文，或者干脆让它讲给我听 一开始我觉得这是纯赚的事 直到有一次按译文改了配置，上线前同事问我：“文档里不是说这个参数只有在另一个开关打开时才生效吗？”我回去翻原文，还真有那么一句 unless 从句，而 AI 给我的中文里，这半句干干净净地消失了 译文读起来非常顺，顺到我完全没怀疑 从那以后我对“AI 翻译技术文档”的态度变了：它很好用，但它的错不是乱码式的错，而是读起来很通顺的错
2026-10-16鱼鱼
