🤖 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 能力，做复杂任务很强 ...
🧱 后端开发与架构
未读这个框架，到底哪里不对劲去年下半年我开始接手一个研发底座的优化工作。什么叫研发底座？说白了就是公司内部那套脚手架和通用组件——鉴权、日志、异常处理、缓存、加解密，这些每个项目都要用的东西，抽象出来形成框架，避免每个团队重复造轮子。 这套底座已经迭代了两年多，支撑着十几个微服务的正常运行。按理说，经过这么长时间的打磨，应该比较成熟了。但当我真正开始读代码的时候，总感觉哪里不太对。不是说它不能用，能用，而且一直在用。而是说，如果你让我从零开始设计一个同样功能的东西，我不会这样做。 这其实是一个挺微妙的位置。作为后来者，你不能一上来就指指点点说这个不行那个要改——每个设计决策背后都有当时的上下文，也许那时候只有两个人，业务急着上线，架构师做了一个在当时最合理的取舍。但问题是，当时的上下文现在可能已经不存在了。团队从三五个人变成了几十个人，服务从两三个膨胀到了十几个，当初那个”先这么写着，后面再说”的设计选择，现在已经变成了后来者的认知负担。 打个比方。我在看网关路由配置的时候，发现一个现象：每个微服务都定义了自己的 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" ...
🎉 高能分享
未读那个让我后怕的早晨12 月 10 号，我还在发朋友圈说因为 Next.js(准确的说应该是 React) 的漏洞需要升级 Dify, 不过因为时间的原因只是将几个受影响的 Next 服务下架, 并没有进行升级。 今天有点时间打算全部升级一下, 结果才发现——我其实在 12 月 5 号就已经被攻击了。 这是我第一次因为第三方服务的漏洞遭遇真实攻击。虽然最终没有造成更严重的后果，但从”被动挨打”到”定位证据、完成处置”，整个过程给了我巨大的冲击。那种感觉，就像你早上醒来发现家里被翻了个遍，但你还不知道丢了什么。 所以，我决定把这次被攻击的全过程记录下来——一方面梳理教训、为后续安全防控留出可复盘的参考，另一方面也提醒其他 Next.js 用户这次事故的严重性，尽快完成升级。 相关漏洞信息： Next.js 官方公告 Critical Security Vulnerability in React Server Components Denial of Service and Source Code Exposure in React Server Components CV ...
简介本文是 Spring AI 入门教程的第一部分，将带你从零开始搭建一个 Spring AI 应用，集成 OpenAI（通义千问兼容模式）和 Anthropic（Claude）两个聊天模型，并解决实际开发中可能遇到的各种问题。 参考文档：Your First Spring AI 1.0 Application 刚刚新开了一个 Spring AI 的 教程项目, 欢迎大家 star 和 fork！ 准备工作在上一篇 在 Docker 中部署 PostgresML 实现数据库内机器学习 中，已经成功在 PostgresML 中创建了数据库，并成功进行了 PostgresML 的相关测试。现在我们将以 PostgresML 为底层数据库，基于 Spring AI 来完成一个示例项目，学习 Spring AI 的相关概念以及 API 的使用。 项目初始化打开 Spring Initializr，在你的项目里添加以下依赖： PgVector (PostgreSQL 的向量扩展) GraalVM Native Support (GraalVM 原生镜像支持) Actuator (应 ...
🤖 AI:人工智障
未读背景随着人工智能技术的快速发展，Java 开发者也在积极探索如何将 AI 能力集成到企业级应用中。Spring 团队发布的 Spring AI 项目为 Java 生态带来了强大的 AI 集成能力。特别是 Spring AI 1.1.0 版本的正式发布，使得使用 Java 开发 AI 应用变得更加便捷。 在 AI 应用开发中，向量数据库扮演着重要角色，特别是在处理文本嵌入和语义搜索场景下。PostgresML 作为一个强大的 PostgreSQL 扩展，能够直接在数据库内部实现机器学习功能，为 AI 应用提供了高效的向量存储和检索能力。 本文将详细介绍如何在 Docker 环境中部署和配置 PostgresML，为后续的 AI 应用开发打下坚实基础。 简介PostgresML 是一个强大的 PostgreSQL 扩展，它将机器学习功能直接集成到数据库内部。通过 pgml 扩展，开发者可以在数据库层面实现文本嵌入、语义搜索等 AI 功能，无需额外的外部服务依赖。 在 Docker 容器中部署 PostgresML 具有以下优势： 环境一致性：确保开发、测试和生产环境的一致性 快 ...
🏠 HomeLab:中年男人之友
未读前言在群晖上整点”高级”的网络配置 —— 比如加个反向代理、换个监听端口、写条 URL Rewrite —— 我第一反应都是： 直接去改 /etc/nginx/nginx.conf 不就好了？ 然后就被坑了。具体坑法是：配置当场生效，重启一次就没了。 我当时还以为是自己改错了文件权限或者 reload 命令不对，反复核对了好几次，最后才反应过来 —— 群晖的 Nginx 配置根本不是一个”手写”的文件，而是开机时用模板生成出来的。你改得再仔细，系统一重启就用模板重新写一份，你的改动被原样冲掉。 这篇把整个机制说清楚，再给一个我自己一直在用的”不碰模板、不丢配置“的做法。 群晖 Nginx 的配置是怎么来的先 SSH 上群晖看一眼： 12sudo -ils /usr/syno/share/nginx/ 能看到一堆 .mustache 文件： 1234WWWService.mustacheWWW_Main.mustacheDSM.mustache... （还有十几个） 这就是群晖 Nginx 配置的”源头”。DSM 每次启动（或者你在 WebStation、控制面板里动配置 ...
🙉 Zeka.Stack
未读🧑💻 简介作为一个 Java 后端工程师，我相信你一定遇到过下面这些问题： 使用 IDEA 启动一个 Spring Boot 项目，第一行就出现红色告警：发现多个 slf4j 实现类，提示你要排除一个； 本地开发一切正常，一部署到测试环境却报错：找不到某个 class； 项目中的 pom.xml 有上百个依赖，不知道哪个服务哪个功能，谁也不敢轻易动； 多模块之间彼此依赖，模块 A 引用模块 B，模块 B 又反过来依赖模块 A，形成“依赖闭环”； …… 经历过大大小小的 Spring Boot 项目后我发现，不论是大厂还是小团队，很多项目对 Maven 的依赖管理都重视不足。 重复引入、版本冲突、依赖混乱、模块耦合这些问题，几乎是通病。 好一点的团队会搭建一个公司级的 parent 项目来统一依赖版本；大多数直接沿用 spring-boot-starter-parent；更差的，哪缺啥引啥，能跑就行，构建配置几乎没人管。 为什么要重新思考 Maven 项目的组织结构? 因为当项目开始变大：%% %% 依赖管理就成了地雷阵，一改就炸； 多人协作时，版本不一致、依赖冲突 ...
🙉 Zeka.Stack
未读📖 简介在上一篇 🧪 Maven Profiles 的使用场景案例分享 我们通过 Profiles 的实际案例大致了解了它的使用方式, 并详细梳理了 Profiles 的优先级, 不过也挖了一个坑: 为啥我要将 settings.xml 和项目代码放在一起? 比如 arco-supreme 项目的代码结构为: 12345678910111213141516$ tree -a -I '.git|.idea'.├── .editorconfig├── .gitignore├── .mvn│ ├── jvm.config│ ├── maven.config│ ├── settings.xml│ └── wrapper│ ├── maven-wrapper.properties│ └── MavenWrapperDownloader.java├── LICENSE├── mvnw├── mvnw.cmd├── pom.xml└── README.md 可以看到 settings.xml 文件放在了 .mvn 目录下, 且 ...
