🧱 后端开发与架构
未读推行代码检查，最难的不是技术代码质量保障是个经典话题。Checkstyle 做格式检查，PMD 做逻辑缺陷检查，SonarQube 做全方位的代码质量度量——这三件套怎么用，网上文档很全。 但真正的挑战从来不是”怎么配置这些工具”，而是**怎么让一个已经运行了两年的、代码量不小的、团队成员流动频繁的项目接受”强制代码检查”**。 想象一下这个场景：你在 CI 管道里加上了 Checkstyle，规则用的是 Google Java Style。第二天，所有 MR 都挂了——不是代码逻辑有问题，而是缩进不对、命名不规范、缺少 Javadoc。开发 leader 来找你：”能不能先关掉，这个需求很急。”你说不能。他说那就先降级为 warn。 然后这个 warn 就永远是 warn 了。没人看 warn。 这不是假设，这就是大部分项目型组织中推行代码质量工具的真实路径。所以我花了大量时间思考的不是”选哪个工具”，而是”怎么让别人愿意用”。 工具分工：各干各的，互相补充先简单过一下三件套的定位。 Checkstyle 管格式。缩进是 4 个空格还是 tab？大括号是同行还是换行？类名是大驼峰还 ...
🖥️ 基础设施与运维
未读背景起因是家里 Homelab 的一台 NUC 升级，给它加了张 Intel X520-2 双口万兆，顺手把 NAS（DS923+）那边也换上了万兆。理论上这套组合应该是”一步到位、全屋万兆起飞”的那种。 但真正测下来，iperf3 从 NUC 打到 NAS 只有大概 950Mbps。 ethtool enp2s0f0 明明写着 Speed: 10000Mb/s 和 Link detected: yes，我盯着那一行看了半天。硬件、线缆、交换机、NAS 全都换过交叉验证过，问题死死卡在这台 NUC 上。 最后折腾下来才发现根本不是硬件的锅，是 Linux 网络里一个经典得不能再经典的坑：ARP Flux——多张网卡挂在同一个子网里，彼此抢答 ARP，导致流量走错路径。 这篇文章把完整的排查链路、每一步的命令和我当时的判断都写出来，既是给未来的自己留个底，也希望你以后踩到类似问题时能少走一圈弯路。 环境说明先把桌面摆开，这台 NUC 上一共挂了 4 张网卡： 接口 IP 类型 Bridge enp2s0f0 192.168.31.99 Intel X520 10G v ...
配置管理，最容易被做烂的事在所有研发底座的能力中，配置管理是最”不起眼”的。它不产生业务价值，不影响接口性能，甚至改坏了也不会马上出问题——配置错误可能在被调用到的时候才暴露。 但正因为它不起眼，它也是最容易被做烂的。框架迭代了两年，不同的人在不同的时期添加不同的配置项，大家的命名习惯、组织方式、使用方式各不相同，最后就形成了一种”配置腐化”。 我接手的时候，框架的配置状况大概是这样的： 有的配置用 @Value 注入： 12@Value("${spring.data.redis.enable:true}")private boolean enable; 有的配置用 @ConfigurationProperties，但前缀混乱。开关配置一部分叫 enable，一部分叫 enabled： 12345678secret: mybatis: enable: false # 这里是 enablegateway: log: access: enabled: false # 这里是 enabled 业务方 ...
前言家里这些年陆陆续续堆起来的服务器，现在打开 ~/.ssh/config 数了一下，大大小小十几个 entry：PVE 主节点、PVE 子节点、NAS、软路由、一堆 LXC、几台跑服务的虚拟机、再加上两台 Mac mini。 多了之后就有个很典型的痛苦场景： “我之前写过一条 ffmpeg 命令把 MKV 转 MP4 的，在哪台机器上来着？” 然后就开始 ssh 每台机器跑一遍 history | grep ffmpeg，还翻不到。因为 zsh 默认的 history 是按机器本地存的，一旦换了机器就没了。更烦的是有时候想在一批新机器上统一跑几条命令（比如同步 docker compose 配置、修 sshd_config），还得一台一台粘贴，粘着粘着就怀疑人生。 我之前也试过 Atuin，功能更花哨，但它的 TUI 相对重一些，而且我只想要一个”跨机器搜索 + 执行时的完整上下文“，并不需要太多仪式感。最后选定了 hishtory，理由很简单： 记录的上下文足够多：命令、cwd、退出码、运行时长、主机名、时间，一条都不少； 自带端到端加密 + 自建后端，数据全在家里机 ...
现有方案的痛点终端里的大量操作有一个共同特征：高频、临时、简单。查个端口、扫个日志、打包个镜像，难的不是算法，是「这条 one-liner 参数怎么拼」。市面上的解决方案各有各的问题： 通用 AI 工具（ChatGPT、Cursor 等）：你得切换窗口、描述需求、从一大段解释里抠出那一行命令。而且通用 AI 工具加载了大量 Agent、MCP、Skill 上下文，你只是想生成一行 find，也要消耗大量 token。 重型 AI CLI（Claude Code、Codex CLI 等）：非常适合复杂任务和多步推理，但为了「删七天前的日志」这种小事进入一整套交互会话，心智与路径都偏重。 查文档 / 搜索引擎：每次都要离开终端、搜索、复制、粘贴，打断心流。 这个场景的 AI 调用其实非常简单：输入是自然语言描述，输出是可执行的 Shell 命令，一轮问答就够了。把这种极简的 AI 调用直接嵌到 IDE 内置终端里，不需要离开编辑器，不多消耗一个 token。 功能一览 功能 入口 说明 TAB 生成命令 终端输入行 + TAB 以触发前缀（默认 #）开头时拦截 ...
🧱 后端开发与架构
未读一个接口，五十几个方法打开缓存组件的 CacheService 接口，我看到的是一个长达 573 行的定义——五十几个方法，从基本的 get/set/delete，到 Hash 操作的 hget/hset，到 List 操作的 lpush/lpop，到 Set 操作，再到各种带过期时间的变体。它像是把 Redis 的所有命令直接翻译成了 Java 方法，然后用一个接口兜住。 这种设计有几个后果。 实现类被迫实现所有方法。 即使某个实现只支持 String 操作，它也得把 Hash、List、Set 的方法全部写上——哪怕方法体是 throw new UnsupportedOperationException()。这是典型的”胖接口”问题，违反了接口隔离原则（ISP）。 使用者不知道什么时候该用什么。 五十几个方法摊在一个接口里，光 IDE 的自动补全列表就要翻好几页。想缓存一个简单的 KV 对，要在一堆 putHash、pushLeft、addSet 里找到正确的 set 方法。 扩展新能力时改的就是这个接口。 每次想加一个缓存操作类型，比如 ...
🏠 HomeLab:中年男人之友
未读背景：我只是想让那块小屏幕别闲着家里那台服务器是主力 Homelab，24 小时跑着 PVE、几个 LXC、几组 Docker。之前监控全靠 Grafana + Nezha，看得很全，但有个问题：每次我想”扫一眼当前状态”，都得掏手机或者切到电脑上的浏览器。 某天翻出一块以前买摄像头配的 7 寸 HDMI 小屏幕，突然就想：要是把它接到服务器 HDMI 口上，常亮挂一个 btop 不就好了？走过服务器旁边看一眼 CPU/内存/磁盘/网络，比掏手机快多了。 理想很美好，现实一接上就踩坑： 开机后屏幕默认停在 getty@tty1 的登录提示符 要看 btop 得先插键盘、输账号密码、btop 回车 我的服务器放在柜子里，键盘根本不在旁边 偶尔掉电重启，每次都要拖一根键盘线过去，心态爆炸 说白了我要的不是”登录系统”，我要的是一块常亮的监控屏。那 tty1 这个位置就不能留给 getty，而应该直接跑 btop。 记录一下最后的方案，顺便留档给未来的自己。 目标 开机后 tty1 直接显示 btop，不需要登录、不需要键盘 屏幕 24 小时常亮做仪 ...
现有方案的痛点市面上 Changelog 生成工具不少，conventional-changelog、git-changelog、release-drafter 都能用，但它们有一个共同前提：团队得严格遵守约定式提交规范。实际项目里，fix bug、update、修复了问题 这种提交满地都是，你没法指望所有人都按规范写。这些工具拿到这种”垃圾进”，只能给你”垃圾出”。 那用 AI 呢？比如把 Git Log 复制到 ChatGPT 或者让 Cursor 帮忙整理，确实能生成不错的内容。但问题是： token 浪费严重：现在的 AI 工具都是大而全的 Agent，接入大量 MCP 和 Skill，你只是想让它整理几条提交记录，它也要加载一堆上下文，消耗的 token 远超实际需要 批量场景撑不住：想为整个项目的提交历史批量生成 Changelog？几次就报上下文超长，得手动切分范围重来 流程割裂：IDE 里选中提交 → 复制 → 切到外部工具 → 粘贴 → 等结果 → 复制回来，每次都要中断开发流程 提交信息本身的困境：不只是整理历史记录痛苦，写 commit message ...
🧱 后端开发与架构
未读一个隐藏了一年的 bug先看一段代码。这是框架里 Response 类的几个静态工厂方法： 1234567891011121314151617public static Response success() { return Response.success(null);}public static <T> Response success(T data) { return new Response().success(data, null);}public static Response success(String message) { return new Response().success(null, message);}public Response success(T data, String message) { this.meta = new Meta(ResponseState.SUCCESS, message); this.data = data; ...
🤖 AI:人工智障
未读现有方案的痛点写 JavaDoc 是一件所有人都觉得该做、但没人愿意做的事。CI/CD 检查会因为缺少文档卡你，Code Review 会因为文档质量不行打回，但真要写的时候，你发现这完全是重复劳动——方法签名已经告诉你参数和返回值，方法体就在眼前，你只是用自然语言复述一遍代码本身就能表达的信息。 市面上的自动生成工具要么只给你空壳模板（@param userId the user id），要么需要你切换到命令行或者外部工具，打断开发流程。而直接用 ChatGPT 或者 Cursor，虽然能生成不错的文档，但每次都要手动复制代码、切换窗口、等结果再贴回来，而且通用 AI 工具加载了大量 Agent、MCP、Skill 上下文，你只是想给一个方法加个文档，也要消耗大量 token。 这个问题的核心其实很简单：输入是光标所在的代码元素，输出是格式化的 JavaDoc 注释，一轮问答就够了。用最轻量的 AI 调用嵌入 IDE，不离开编辑器，不多消耗一个 token，这就是这个插件要做的事。 功能一览 功能 入口 说明 生成 JavaDoc Alt+Enter &# ...
🏠 HomeLab:中年男人之友
未读前言说实话，我被 Samba 配置搞得快疯了。 家里现在有 5 台服务器，有装 Ubuntu 的，有装 CentOS 的，还有两台刷了 OpenWrt 的软路由。每次想共享个文件或者备份点数据，都得去手动配 Samba，真的太烦了。 你可能想，Samba 配置不就那几步吗？装个包，改个配置文件，重启服务不就完了？ 我也是这么想的，但实际用起来你会发现这些坑： 每台机器都要重复操作 - 装 samba、改 smb.conf、设置用户权限… 网络发现很麻烦 - 有时候在 macOS 上能看到，有时候又看不到 端口问题 - 有些网络环境只开了 445 端口，有些又是 139 端口 用户权限混乱 - 这台用 root，那台用 user，记不住哪个是哪个 最烦的是什么？就是当你着急要传个文件的时候，发现找不到共享文件夹，或者连接不上。那种感觉真的会让人抓狂。 我的解决思路既然每台都要配，为什么不写个脚本一键搞定呢？ 💡 核心想法： 用脚本自动化所有重复操作 统一配置标准，避免每次都查文档 加入网络发现功能，让 macOS 和 Windows 能自动找到 支持多个共享目录，一次配置 ...
🧱 后端开发与架构
未读规范这种东西，到底有用没用上一篇文章聊了研发底座的整体架构和一些让我头疼的设计问题。今天深入第一个优化方向：工程与项目规范。 先说实话——规范这个东西，技术人员天然反感。觉得这是管理岗搞出来的条条框框，约束创造力。但我在这个项目中待了一段时间后，反而成了规范最坚定的推动者。为什么？因为一个反直觉的事实：在人员流动性大、技术水平参差不齐的项目中，规范的约束力比框架的技术能力更重要。 框架再牛，也挡不住有人用一百种写法实现同一个功能。Spring Security 配置得好好的，有人非要在 Controller 里手写一个 Token 校验。响应体统一封装好了，有人就是要自己 new 一个 HashMap 返回。日志规范定了，但每个人的埋点格式都不一样。 这不是技术问题，这是没有规范或者规范没有执行的问题。 产品经理圈子里有句老话，叫”把用户当傻子”。意思是让用户减少学习成本、容易上手，是产品设计的核心追求。研发底座本质上也是一个产品——它的用户是研发人员。你不能假设每个使用者技术实力都很强、都有好的编码习惯。你会这么想，是因为你在架构组，你周围的人能力都不差。但业务团队的现实是：有人刚 ...
为什么需要一个独立的 AI 引擎插件做 JavaDoc 插件的时候碰到一个问题：代码里的 AI 调用逻辑、配置管理、凭证存储、UI 组件全部耦合在一个插件里。后来做 Changelog 插件，发现同样的代码要复制一遍。如果再做一个新功能的 AI 插件，又得复制一遍。 每新增一个 AI 服务商，要在每个插件里都适配一次。插件越多，维护成本越高，而且各插件的配置互相独立，用户要反复配 API Key。 把 AI 能力抽成一个独立的底层插件，所有业务插件（JavaDoc、Changelog 等）通过依赖调用，配置统一管理，用户配一次全部生效——这就是 IntelliAI Engine 要解决的问题。 graph TB subgraph Before["抽取之前"] direction TB JD1["JavaDoc 插件<br/>AI 调用 + 配置 + 凭证 + UI"] CL1["Changelog 插件<br/>AI 调用 ...
写在前面最近我一直在反复回答一个问题：为什么我没有去做一个 Claude Code、Codex 那种大而全的 AI 工具，而是先做了几个看起来很”小”的 IDEA 插件？ 这个问题背后，其实是同一个选择题：工具到底要不要把所有事情都做掉。 我现在的答案很明确： 我不想做一个”替你做完所有事”的工具，我只想做一个在关键一刻能帮你省掉重复劳动的工具。 这篇文章我把两部分内容合并到一起讲：一部分是我的真实动机（为什么要做），另一部分是架构上的取舍（为什么要拆 Engine）。 我最早的痛点，不是没有 AI，而是 AI 太重了AI 还没这么普及的时候，我做过一段时间 Javadoc 自动生成。那时候主要靠 PSI 拿代码结构，再套模板拼注释。流程是能跑通，但有两个问题一直很明显： 对方法命名质量依赖很高 生成出来的描述经常”结构正确、语义不对” 说白了就是格式没问题，但意思不一定对，最后还得人工二次修改。 后来 AI 出来后，这件事理论上应该更容易了，但我自己实际用下来又遇到了另一个坑：很多大模型工具太”全能”了，带了很多 MCP、Skill、Agent 能力，做复杂任务很强 ...
