AI 补全和整段生成，我什么时候用哪种
AI 补全和整段生成，我什么时候用哪种用 AI 写代码久了，我会下意识把它分成两种节奏：一种是编辑器里那个“跟着你敲”的补全；另一种是对话框里“给我写一整段 / 一整文件”的生成 表面上都是 AI 在写，体感完全不一样 补全像有人在旁边帮你把下一句顺出来；整段生成像你把需求扔出去，过一会儿收回来一份成品 我早期几乎只用后者，觉得效率高；后来越写越觉得：很多时候，补全才是更省心的那一个 这篇就聊聊我现在怎么选 补全的好处很直观——上下文就在光标周围，你刚写的函数名、变量名、注释，它都能“看见” 你按 tab 接受一行，再敲两下，它继续跟 这种节奏很接近自己写，只是手变快了一点 我特别喜欢在这些场景用补全： 写样板代码：DTO 字段、简单的 getter/mapper、重复的校验
2026-10-14鱼鱼
RAG 在 Coding Agent 里：什么时候有用，什么时候添乱
RAG 在 Coding Agent 里：什么时候有用，什么时候添乱一提到让 Agent “懂我们的代码库”，很多人的第一反应是上 RAG：把仓库切块、嵌入、丢进向量库，提问时先检索再生成 听起来理所当然，我自己也做过 用下来的感受是：RAG 在 coding agent 里不是默认答案，而是一种有代价的缓存与索引策略 用对了能省上下文、提高命中；用错了会检索到似是而非的片段，把模型带进沟里 这篇文章想尽量说人话：哪些场景我愿意上 RAG，哪些场景我宁愿用“直接读文件 / 搜符号 / 开测试”的工具，以及怎么判断它在添乱 图片来源：原创示意图 Coding Agent 跟“企业内部知识问答”不一样 它通常已经有这些能力： 列出目录、按路径读文件；
2026-10-14鱼鱼
Agent 的工具返回太长怎么办：截断、分页与摘要的取舍
Agent 的工具返回太长怎么办：截断、分页与摘要的取舍自己写 Agent 的时候，我最早关心的是工具怎么定义、参数怎么描述、调用失败怎么处理 工具返回什么，反而想得很少：命令跑完了，stdout 拿回来，原样塞进上下文，不就行了？ 后来有一次让 Agent 排查一个线上问题，它调了一下读日志的工具 那个日志文件几十兆，工具老老实实全读回来了 结果要么是请求直接超出上下文上限报错，要么是在我加了粗暴截断之后，它看到前面几千行正常日志，得出结论“日志里没有发现异常” 真正的报错在文件末尾，它根本没看到 这件事让我意识到：工具返回多长、怎么变短，是 Agent 设计里一个独立的问题，而且没有银弹 常见的三种办法——截断、分页、摘要——各有各的代价
2026-10-16鱼鱼
AI 生成测试我怎么取舍：哪些让它写，哪些必须人写
AI 生成测试我怎么取舍：哪些让它写，哪些必须人写用 AI 写业务代码越来越顺手之后，下一件很自然的事就是：让它把测试也补上 说实话，这一步的爽感很强——几分钟冒出一堆 should_xxx，覆盖率数字往上跳，CI 绿灯 问题也正好出在这里：绿灯不等于有保险 我经历过一次挺丢脸的事 AI 帮我补了十几个单测，覆盖率从 40% 拉到 75%，合并后第三天生产就炸了 回头看测试，几乎每个都在验证“mock 对象有没有按我设定的方式被调用”，真正的业务不变量一个都没钉住 测试在保护 mock，不在保护系统 这篇文章想说清楚三件事：哪些测例我愿意交给 AI；哪些我坚持人手写；以及怎么减少“假绿” 图片来源：原创示意图 我不想装清高
2026-10-14鱼鱼
JVM的垃圾回收
JVM的垃圾回收此文介绍Java的基本垃圾回收机制 GC主要回收的是堆区，在堆中是有对象分代的，一个对象每“逃”过一次回收，对象代数便+1，新生对象被称作新生代（如果是占据内存较大的对象直接定义为老年代），当代数一定时对象将由新生代变为老年代 同时在Java1.7之前还有永久代，保存了一些静态变量 总之，内存回收只发生在新生代和老年代之间 除了分代，内存也有分区： 如图，是内存区域分配，其中Eden存储了新建的小对象，当回收时，将Eden中存活的对象转移到To Survivor区中，将From Survivor中的代数高（一般是15）的存活对象转移到老年代中，代数没达到阈值的存活对象转移到To Survivor中
2021-04-07鱼鱼
DDD领域下的架构模式——CQRS架构
DDD领域下的架构模式——CQRS架构//TODO
![DDD领域下的架构模式——CQRS架构]()
2021-06-24鱼鱼
提示词工程与上下文工程：让模型看到“对的信息”
提示词工程与上下文工程：让模型看到“对的信息”写 Agent 时，很多人把精力放在“提示词怎么写得更花哨”上 实际上，更影响效果的往往是：在每一步，模型的上下文里究竟放了什么 这就是近来常被提起的“上下文工程（Context Engineering）” 本文先区分提示词工程与上下文工程，再讲系统提示的结构、上下文的选择/压缩/隔离/外置四种手段，提供一个带 token 预算的上下文组装器（Python）与结构化输出校验（Python + Java），最后总结常见错误、检查清单与 FAQ 上下文窗口里的六个组成部分 很多团队有过这样的经历：换了更强的模型，效果只提升了一点；而把检索结果排序调整了一下、把冗长的工具输出裁剪了一下，效果反而明显改善
2026-10-14鱼鱼
浅析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鱼鱼
Agent 的评估、测试与可观测性：上线前后都要看得见
Agent 的评估、测试与可观测性：上线前后都要看得见Agent 的输出具有不确定性：同一个输入，两次运行的路径可能不同 传统的“写几个单元测试就放心”在这里行不通 本文介绍如何给 Agent 建立 评估（Evaluation） 与 可观测性（Observability） 体系：怎样拆解评估维度、构建评测集、选择打分方式、记录 Trace，并顺带讨论成本与延迟的护栏 文中给出 Python 的回归评测与 Trace 记录代码、Java 的埋点示例，以及常见坑和检查清单 评估分三层：结果层、过程层、效率层 传统软件的行为大多是确定的：相同输入得到相同输出，单元测试通过就有较强的信心 Agent 有三点不同： 非确定性：模型本身有随机性，同一任务可能走不同路径，甚至有时成功有时失败；
2026-10-14鱼鱼
Agent 的工具调用日志：出了问题我先看哪几行
Agent 的工具调用日志：出了问题我先看哪几行Agent 一跑起来，日志可以很热闹：思考摘要、工具名、参数、返回、重试、最终回答……出了问题时，若从头通读，既慢又容易被模型的“自信叙述”带偏 我逐渐养成一个习惯：先不看它怎么说，先看它调用了什么、参数是否离谱、返回是否被误解 这篇文章记我排查 Agent 故障时的日志阅读顺序 偏工程经验，不是某家产品的官方手册 失败时我最想看的其实不是最终答复 答复是渲染后的故事，故事会把中间的错误抹平 更常见的情况是： 所以我把最终答案降级成线索，把工具轨迹升级成证据 图：先证据后故事：工具轨迹优先于最终答复（原创示意图） 只看序列：读文件 → 搜代码 → 改文件 → 跑测试 这种骨架
2026-10-14鱼鱼
数据库的并发、锁机制与MVCC
数据库的并发、锁机制与MVCC在日常开发中，经常遇到数据库进行高并发操作的情况，但是我们处理并发一般都只在代码范畴而并不处理具体的数据库操作，这是因为数据库对基本的数据库操作做了锁处理，让我们可以忽略这一层的并发问题 详细可以参考Mysql的官方文档 注意：这一篇博客是针对MySQL数据库，且实用默认的 引擎InnoDb，使用其他数据库可能存在略微的差异 MySQL默认的数据库引擎InnoDB中Autocommit值为0（即自动提交事务）执行SQL语句的时候，每一条SQL语句都是一条单独的事务，所以并不存在并发的问题，数据库的锁机制已经做了很好的处理 但是当我们开启事务时，若不加处理，可能会产生一系列并发带来的问题
2021-01-24鱼鱼
MySQL tips
MySQL tips一些日常接触到的MySQL优化tips，比较散乱 假设有一个用户表，对于一句很简单的查询语句： 假设name与age字段均有单列索引，容易想到的是，MySQL应该会分别走两次索引，并将其结合起来，EXPLAIN也是如此，大多数时候MySQL会进行优化，我们可能会看到EXPLAIN的结果中有Using union或Using soft union，这是MySQL针对OR做了隐性的优化，但当SQL复杂或数据极端情况下，这一语句极容易变成全表扫描，偶尔使用联合索引可能解决问题，更多情况则是MySQL“昏了头”，即使OR条件均涉及数据条数不多，依旧没能在查询语句中使用索引，此时应调整为UNION语句(可以权衡一下重复及顺序是否有影响，可以使用更快的UNION ALL)：
2021-01-13鱼鱼
