现有方案的痛点终端里的大量操作有一个共同特征：高频、临时、简单。查个端口、扫个日志、打包个镜像，难的不是算法，是「这条 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，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; ...

现有方案的痛点写 JavaDoc 是一件所有人都觉得该做、但没人愿意做的事。CI/CD 检查会因为缺少文档卡你，Code Review 会因为文档质量不行打回，但真要写的时候，你发现这完全是重复劳动——方法签名已经告诉你参数和返回值，方法体就在眼前，你只是用自然语言复述一遍代码本身就能表达的信息。 市面上的自动生成工具要么只给你空壳模板（@param userId the user id），要么需要你切换到命令行或者外部工具，打断开发流程。而直接用 ChatGPT 或者 Cursor，虽然能生成不错的文档，但每次都要手动复制代码、切换窗口、等结果再贴回来，而且通用 AI 工具加载了大量 Agent、MCP、Skill 上下文，你只是想给一个方法加个文档，也要消耗大量 token。 这个问题的核心其实很简单：输入是光标所在的代码元素，输出是格式化的 JavaDoc 注释，一轮问答就够了。用最轻量的 AI 调用嵌入 IDE，不离开编辑器，不多消耗一个 token，这就是这个插件要做的事。 功能一览 功能 入口 说明 生成 JavaDoc Alt+Enter &# ...

前言说实话，我被 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 能力，做复杂任务很强 ...

这个框架，到底哪里不对劲去年下半年我开始接手一个研发底座的优化工作。什么叫研发底座？说白了就是公司内部那套脚手架和通用组件——鉴权、日志、异常处理、缓存、加解密，这些每个项目都要用的东西，抽象出来形成框架，避免每个团队重复造轮子。 这套底座已经迭代了两年多，支撑着十几个微服务的正常运行。按理说，经过这么长时间的打磨，应该比较成熟了。但当我真正开始读代码的时候，总感觉哪里不太对。不是说它不能用，能用，而且一直在用。而是说，如果你让我从零开始设计一个同样功能的东西，我不会这样做。 这其实是一个挺微妙的位置。作为后来者，你不能一上来就指指点点说这个不行那个要改——每个设计决策背后都有当时的上下文，也许那时候只有两个人，业务急着上线，架构师做了一个在当时最合理的取舍。但问题是，当时的上下文现在可能已经不存在了。团队从三五个人变成了几十个人，服务从两三个膨胀到了十几个，当初那个”先这么写着，后面再说”的设计选择，现在已经变成了后来者的认知负担。 打个比方。我在看网关路由配置的时候，发现一个现象：每个微服务都定义了自己的 context-path： 12345# user-serviceserv ...

📋 背景与挑战业务背景IntelliAI Engine 是一个开源项目，作为 IntelliJ IDEA 插件的统一 AI 服务抽象层，需要对接各种 AI 服务提供商。在实际业务场景中，我们遇到了一个特殊的挑战： 公司内部使用的星辰大模型接入需求： 安全管控约束： 公司内部的星辰大模型无法在外部环境使用 由于插件是开源项目，出于安全管控的原因，不能将内部对接逻辑直接暴露到开源代码中 内部模型的认证、连接等敏感信息必须与开源项目隔离 已有工具项目： 公司内部已经在前端时间通过 Java 实现了一个对接内部星辰大模型的工具类项目 该项目已经完成了 WebSocket 连接、OAuth2 认证、会话管理等核心功能 项目已经能够稳定运行，并通过 Swing 界面为用户提供服务 业务推广需求： 此次因为公司内部推广，需要将星辰大模型接入到现有的 Engine 插件中 需要让公司内部用户能够通过 IntelliJ IDEA 插件使用星辰大模型 架构设计考量： 复用性：希望直接复用已有的工具项目，避免重复开发 安全性：保持开源项目与内部项目的职责分离，确保敏感代码不泄 ...

前言在开发 Markdown Image Kit 插件时，遇到了一个棘手的问题：在 Markdown 文件中粘贴图片时，自定义的粘贴处理逻辑完全不被触发，直接走了 IDEA 默认或Markdown 插件的处理逻辑。经过深入排查，发现问题的根源在于 IntelliJ IDEA 的粘贴处理机制优先级问题。 本文将详细记录问题的排查过程、根本原因分析以及最终的解决方案。 问题背景Markdown Image Kit 是一个 IntelliJ IDEA 插件，主要功能是在 Markdown 文件中粘贴图片时，自动将图片上传到图床或保存到指定路径，并插入相应的Markdown 图片标签。 插件通过拦截 EditorPaste 动作来实现自定义粘贴逻辑： 123<editorActionHandler action="EditorPaste" implementationClass="info.dong4j.idea.plugin.action.paste.PasteImageAction" ...