让 AI 帮我看别人的 PR,我怎么避免被它带偏

让 AI 帮我看别人的 PR,我怎么避免被它带偏code review 一直是我又爱又烦的环节 爱的是能提前拦住问题;烦的是有些 PR 又长又绕,下午三点看到,眼睛先花了 后来我开始让 AI 帮忙“先看一眼” 效率确实上来了:它能很快列出一堆疑点,有的还挺准 但用了一阵子,我也被它带偏过——有一次它言之凿凿说某段并发不安全,我跟着在评论区写了很长一段,作者委婉回复:那段代码根本不会并发进入 我再看,确实如此 尴尬归尴尬,也逼我把用法收紧了 这篇不是教你“用 AI 替代 review”,而是聊聊:怎么让它当助手,却不把结论权交出去 先说我自己的体感(不是评测数据,是使用感受) 相对擅长: 扫一眼有没有明显的空指针、资源没关、错误被吞
让 AI 帮我看别人的 PR,我怎么避免被它带偏2026-10-14鱼鱼

Agent 的评估、测试与可观测性:上线前后都要看得见

Agent 的评估、测试与可观测性:上线前后都要看得见Agent 的输出具有不确定性:同一个输入,两次运行的路径可能不同 传统的“写几个单元测试就放心”在这里行不通 本文介绍如何给 Agent 建立 评估(Evaluation) 与 可观测性(Observability) 体系:怎样拆解评估维度、构建评测集、选择打分方式、记录 Trace,并顺带讨论成本与延迟的护栏 文中给出 Python 的回归评测与 Trace 记录代码、Java 的埋点示例,以及常见坑和检查清单 评估分三层:结果层、过程层、效率层 传统软件的行为大多是确定的:相同输入得到相同输出,单元测试通过就有较强的信心 Agent 有三点不同: 非确定性:模型本身有随机性,同一任务可能走不同路径,甚至有时成功有时失败;
Agent 的评估、测试与可观测性:上线前后都要看得见2026-10-14鱼鱼

AI 编程工程化迭代中的混沌风险:从规格熵到四个工程控制面

AI 编程工程化迭代中的混沌风险:从规格熵到四个工程控制面过去两年,我们团队把 AI 编程工具真正用进了日常研发:补全式的 Copilot、IDE 里的对话助手,以及能自己读写文件、跑命令的 Agent 收益是实打实的,样板代码、单元测试、脚本、联调、陌生框架的第一版实现,速度都明显提升 但用得越深,我越确信一件事:AI 工程化迭代最危险的地方,不是它“不会写代码”,而是它太会写了 在缺少稳定工程约束的时候,它会持续、高速地产出“单独看都挺合理,放在一起却彼此矛盾”的局部方案 这些矛盾的方案不会立刻表现为一个 Bug 它们表现为一种缓慢累积的混乱:同一个纠正反复被推翻,数据库越改越别扭,代码里一个概念长出两三个名字,线上出事时拼不出一条完整的因果链
AI 编程工程化迭代中的混沌风险:从规格熵到四个工程控制面2026-10-14鱼鱼

AI 写的代码,我是这样 Review 的:一份不太体面的清单

AI 写的代码,我是这样 Review 的:一份不太体面的清单AI 生成的代码有一个很“坑人”的特点:它读起来太顺了 命名规整,注释齐全,结构对称,连日志格式都统一 人写的代码出问题,往往在外观上就有迹可循,比如命名乱、缩进歪、注释写着“TODO 先这样” AI 写的代码出问题,外表通常是光鲜的 这就导致一个很尴尬的局面:越是看起来没毛病的代码,我们越容易放松警惕 所以这篇想聊聊我自己 Review AI 代码时的一份清单 说它“不太体面”,是因为里面很多条看着很基础,甚至有点小心眼 但在我看来,Review AI 代码,恰恰需要一点小心眼 图片来源:John 'Pathfinder' Lester / Flickr(CC BY 2.0)
AI 写的代码,我是这样 Review 的:一份不太体面的清单2026-10-14鱼鱼

Java排坑指南(I)jmap jstack jstat等的使用

Java排坑指南(I)jmap jstack jstat等的使用运用一些Java自带的可执行jar可以从内存的角度更轻松的排除项目中的问题,我们可能会遇到一些不常见却相对很致命的问题,例如: 某些web项目CPU跑到了100%并且飙高不下(一般来说,web应用都为IO密集应用,不太可能出现cpu高占用的情况) 项目中线程出现阻滞、阻塞(网络请求响应速度明显变慢,甚至因为死锁彻底出现阻塞等) 极可能由内存泄漏引发的不明原因的 OOM(没有预兆的或是基础逻辑问题的内存溢出) 当以上问题发生时,通过代码或是日志其实很难定位到原因所在,因为这一般是基于环境或资源导致的全局性问题,通常很难定位,这时可以通过使用Java自带的性能调优jar包更便捷的定位问题(如果没有配置环境变量,可以在jdk的bin目录下找到他们的jar包)
Java排坑指南(I)jmap jstack jstat等的使用2020-11-28鱼鱼

扫盲——加密那些事

扫盲——加密那些事扫盲加密解密算法 日常开发中我们经常接触MD5算法,以此进行简单的文件完整性校验或者是后台密码验证,MD5是最常见也是最简单快捷的散列算法,常用于参数或文件完整性校验,譬如网络请求发起方与接收方分别对参数做MD5编码,一旦不一致便判断请求被篡改从而拒绝该请求,从而保证信息安全,编码后的字符串是编码前文本的一个简要梗概,因此它也被称作是信息摘要算法 这个算法的特点就是不可逆,只用于信息准确性和防篡改的校验,当然,MD5作为老牌的散列算法,很多经典的编码已经可以被反向解码出来(依靠正向的暴力穷举)以及被碰撞模仿(王小云院士团队的"破解"能够根据MD5编码后串码模拟原始消息,即使它可能与原信息不同),类似的还有SHA1,因此衍生了SHA224、SHA256、SHA512等更多安全的散列算法
扫盲——加密那些事2021-05-14鱼鱼

数据库的并发、锁机制与MVCC

数据库的并发、锁机制与MVCC在日常开发中,经常遇到数据库进行高并发操作的情况,但是我们处理并发一般都只在代码范畴而并不处理具体的数据库操作,这是因为数据库对基本的数据库操作做了锁处理,让我们可以忽略这一层的并发问题 详细可以参考Mysql的官方文档 注意:这一篇博客是针对MySQL数据库,且实用默认的 引擎InnoDb,使用其他数据库可能存在略微的差异 MySQL默认的数据库引擎InnoDB中Autocommit值为0(即自动提交事务)执行SQL语句的时候,每一条SQL语句都是一条单独的事务,所以并不存在并发的问题,数据库的锁机制已经做了很好的处理 但是当我们开启事务时,若不加处理,可能会产生一系列并发带来的问题
数据库的并发、锁机制与MVCC2021-01-24鱼鱼

让 AI 写 SQL 和迁移脚本:语法没错,坑全在数据里

让 AI 写 SQL 和迁移脚本:语法没错,坑全在数据里在我日常用 AI 写的各种代码里,SQL 大概是“看起来最省心”的一类 语法它几乎不会写错,连窗口函数、递归 CTE 都信手拈来 让它写个报表查询,或者写个加字段的迁移脚本,几秒钟就好,读一遍也挑不出毛病 但正是这种“挑不出毛病”,让我吃过好几次亏 SQL 的坑很少出在语法上,而是出在语义、数据量和线上环境上——这三样东西,恰恰是 AI 在对话框里看不到的 这篇就把我踩过、或者差点踩到的坑整理一下,最后再说说我现在的做法 先交代背景:我平时主要接触 MySQL,也维护过一些 PostgreSQL 的项目 下面说到具体行为时,我尽量注明是哪个数据库;不同版本之间行为可能有差异,以你用的版本的官方文档为准
让 AI 写 SQL 和迁移脚本:语法没错,坑全在数据里2026-10-14鱼鱼

给 Agent 设计工具:参数与错误返回怎么约定才好用

给 Agent 设计工具:参数与错误返回怎么约定才好用做 Agent 久了会发现:模型“聪不聪明”常常不是瓶颈,工具好不好用才是 同一个模型,换一套清晰的工具契约,成功率能差一截;换一套含糊的,它就会在重试里空转,或者把半成功当成成功继续往下跑 我踩过的坑大多长这样:工具返回一句 "failed",模型不知道是参数错了、权限不够,还是下游超时;于是它换个说法再调一次,参数其实没变 或者工具抛了未捕获异常,框架把它变成空字符串,模型以为“没结果”就去编造 这篇文章只谈两件事:参数怎么设计,以及错误怎么返回,让工具对模型可观测、对系统可重试 图片来源:原创示意图 能用枚举就别用字符串 比如 priority: "high"|"normal"|"low",不要 priority: string 然后在文档里写“建议传 high”
给 Agent 设计工具:参数与错误返回怎么约定才好用2026-10-14鱼鱼

AI 补全和整段生成,我什么时候用哪种

AI 补全和整段生成,我什么时候用哪种用 AI 写代码久了,我会下意识把它分成两种节奏:一种是编辑器里那个“跟着你敲”的补全;另一种是对话框里“给我写一整段 / 一整文件”的生成 表面上都是 AI 在写,体感完全不一样 补全像有人在旁边帮你把下一句顺出来;整段生成像你把需求扔出去,过一会儿收回来一份成品 我早期几乎只用后者,觉得效率高;后来越写越觉得:很多时候,补全才是更省心的那一个 这篇就聊聊我现在怎么选 补全的好处很直观——上下文就在光标周围,你刚写的函数名、变量名、注释,它都能“看见” 你按 tab 接受一行,再敲两下,它继续跟 这种节奏很接近自己写,只是手变快了一点 我特别喜欢在这些场景用补全: 写样板代码:DTO 字段、简单的 getter/mapper、重复的校验
AI 补全和整段生成,我什么时候用哪种2026-10-14鱼鱼

浅谈锁机制、主流锁设计方案

浅谈锁机制、主流锁设计方案本文旨在探讨通用的锁机制实现逻辑,以Java中常见的锁实现为例 本文提到的锁,是指通过限制并发/并行访问所添加的安全措施,本质上是通过限制线程/进程同时更改数据或是读取数据与写入数据产生时序差从而造成数据问题 锁机制中,有一些常见特性: 可重入性 指同一线程/进程携带相同的标识可以反复多次加锁,每次加锁和释放锁对应的重入次数+1/-1; 读写锁/独享共享 是锁的不同运作模式,分为读写锁,读锁与写锁、写锁与写锁是互斥的,但多个线程/进程可以同时对一个逻辑添加读锁,独享共享是另一种叫法 公平性 锁分为 公平锁和非 公平锁, 公平锁指锁释放和获取的顺序严格按照索取的顺序,非 公平锁则是等待锁的对象共同进行锁释放机会的争抢
浅谈锁机制、主流锁设计方案2024-10-15鱼鱼

Redis原理-源码解析:数据结构3 sorted set(zset))

Redis原理-源码解析:数据结构3 sorted set(zset))Redis的set数据结构在此不多讲,同Java中原理一样,set也可以理解为是hash剥离了value的数据结构,即同为dic 但是zset(有序集合)其实在底层原理上完全不同于set 所有原理实现基于Redis版本6.0.9 先看一下基本的指令实现,着重注意中文注解的地方 t_zset.c 可以看出zset的数据结构不是固定的,在其元素数或是元素的字符串过长时,其结构为zset;否则使用ziplist数据结构(像hash一样为了节省空间),二者的创建方法如下: ziplist的代码和原理可以参考我的博客Redis原理-源码解析:数据结构2 list-鱼鱼的Java小站,就是一个节省内存的压缩的链表结构
Redis原理-源码解析:数据结构3 sorted set(zset))2021-02-28鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}