2026-10-24

Java 项目 VS Code / Qoder 插件配置指南

适用场景：Spring Boot 多模块项目、基于 Git worktree 的多分支并行开发核心原则：Pack 装一次到位，子扩展不重复安装；通用效率插件按需取舍；插件不在多，在闭环。

一、核心套件（2 个 Pack 即完整）

插件	说明
Extension Pack for Java	微软官方 Java 套件，装它等于安装齐下表中的 6 个 Java 成员
Spring Boot Extension Pack	Spring 官方套件，装它等于安装齐下表中的 3 个 Spring 成员

装完这两个包后，Java 编写、调试、测试、构建和 Spring 配置提示的完整流程即可打通，不需要再逐个挑选组件。

二、包内成员（已被包含，不要单独再装）

Java 成员

插件	作用
Language Support for Java(TM) by Red Hat	JDT LS 语言服务器：补全、跳转、重构、语法与编译诊断
Debugger for Java	断点调试、启动配置、变量查看、单步与热替换
Test Runner for Java	JUnit / TestNG 用例运行与调试
Maven for Java	执行 goal、跑生命周期、生成工程原型
Gradle for Java	Gradle 任务视图与构建执行，替代命令行 `./gradlew`
Project Manager for Java	项目结构与依赖视图、classpath 管理、导出 jar

Spring 成员

插件	作用
Spring Boot Tools	`application.yml/properties` 补全校验、Bean 与配置项跳转、运行时信息
Spring Boot Dashboard	本地应用一键启停、查看端点与运行状态
Spring Initializr Java Support	向导式生成新的 Spring Boot 工程

2026-10-24

DeepSeek Harness（dsh）安装与使用指南

本文基于官方仓库 tag dsh-v0.1.7-rc.2 的 README、CLI 说明、模型配置、网络代理与安全文档整理，并补充 CC Switch 的协作方案。整理时间：2026-10-23。DSH 仍处于开发者预览阶段，官方明确会有破坏兼容性的变更；执行前请以 dsh --help、dsh web --help 和官方文档为准。

1. 简介

DeepSeek Harness（命令名 dsh）是 DeepSeek AI 开源的 agent harness（智能体框架），采用「一切皆插件」的架构，由 Cordis 驱动。模型、工具、技能、会话、沙箱、存储等能力都通过插件组合，无需改框架源码即可替换或扩展。

官网文档：https://deepseek-harness.github.io/deepseek-harness/
仓库：https://github.com/deepseek-ai/deepseek-harness
许可证：MIT
设计论文：A Programming Paradigm for Spatiotemporal Composability（arXiv:2608.25512）

它能做什么：

读取和编辑工作区文件、运行命令；
委派子任务、维护计划；
按权限策略在执行敏感操作前请求审批；
以 Web UI、无头（headless）、SDK、ACP 等多种形态运行。

阅读全文

JVM 宕机分析实战：从 hs_err 日志到 GDB / jhsdb / SA 的完整指南

编辑

2026-11-06

学习记录

JVM 宕机分析实战：从 hs_err 日志到 GDB / jhsdb / SA 的完整指南

JVM 突然宕机是后端开发中最令人头疼的问题之一。进程无声无息地消失，日志里可能什么都没有，重启后一切“正常”，直到下一次崩溃再次发生。这篇文章会梳理一套从“第一现场”到“深度尸检”的分析流程，重点讲清楚 hs_err_pid 日志怎么读，以及 gdb、jhsdb、sa-jdi.jar 这三个工具分别在什么场景下用、怎么用。

先分清：JVM 宕机的两种“死法”

在动手之前，首先要判断 JVM 是怎么“死”的，因为这直接决定了后续该看什么文件、用什么工具。

第一种：JVM 自己崩了（Native 层致命错误）。 典型信号是 SIGSEGV（段错误）、SIGBUS、SIGABRT，或者 JVM 内部断言失败、Native 内存分配失败。这种情况下，JVM 会在“临死前”尽量生成一个 hs_err_pid<pid>.log 文件，如果系统开启了 core dump，还会留下一个 core 文件。

第二种：进程被操作系统“杀掉”了。 最常见的是 Linux OOM Killer 因为系统内存不足，直接发 SIGKILL（信号 9）干掉 JVM。这种情况下 JVM 来不及做任何反应，不会生成 hs_err 文件，core 文件里看到的信号也是 SIGKILL。你需要去查 /var/log/messages 或 dmesg 里的 oom-killer 记录。

还有一种容易混淆的情况：Java 堆 OOM（OutOfMemoryError）不是 JVM 宕机。它是 Java 层可捕获的异常，JVM 还活着，不会生成 hs_err 日志。处理方式是 heap dump 分析，和本文讨论的“宕机”是两码事。

2026-11-05

简介

ThinkRail 是 JetBrains 开源（Apache-2.0）的 agentic IDE，官网一句话定位是 “the agentic IDE that gets better every time you use it”。它自己不实现 agent，而是把 pi 编码 agent 以库的形式跑在自己进程里，外面包一层真正的 IDE：Monaco 编辑器、文件树、真实 PTY 终端、实时 git diff。它最核心的两个主张是 —— 一个 workspace 就是一个 git worktree（独立分支、独立目录、独立终端和会话，agent 并行干活也不脏你的 main），以及 spec 是唯一事实来源（SPEC.md 图谱放在代码旁边，agent 用专门的工具去读、搜、维护它，意图不会随会话结束而蒸发）。

截至 2026-11-04 我核对官方数据时的状态：仓库 JetBrains/thinkrail 7.5k+ star，最新 stable 是 v0.3.1（2026-11-01 发布），nightly 已经走到 v0.4.0-nightly.4（2026-11-03），内嵌的 pi 引擎固定在 1.5.0。官网顶部的 Docs 目前还是 Coming soon，thinkrail.ai/docs 返回 404 —— 也就是说现阶段唯一可靠的文档是 README、仓库里那些 SPEC.md 和官方博客，本文也完全依据这些一手材料写的。

2026-11-05

简介

Oh My Pi（命令行名 omp）是一款跑在终端里的 AI 编码智能体，官方口号是「一个内置 IDE 能力的编程智能体」（A coding agent with the IDE wired in）。它由 Stencil Labs 维护，派生自 Mario Zechner 的 Pi，整体重写为专注编程工作流的智能体：会话、子智能体、斜杠命令、扩展全部用 TypeScript 编写，底层搜索、Shell、AST、PTY、桌面控制等热路径用约 8 万行 Rust 实现并以 N-API 插件形式链接进同一个进程，全部代码采用 MIT 许可。

官方给出的规模数字：60+ 个模型提供商、31 个内置工具、14 种 LSP 操作、28 种 DAP 操作、约 80000 行 Rust 核心代码。同一个 omp 二进制可运行于 macOS、Linux 和 Windows，不需要 WSL 桥接。

官网：https://omp.sh/
文档：https://omp.sh/docs
仓库：https://github.com/can1357/oh-my-pi
npm 包：@oh-my-pi/pi-coding-agent（bin 名为 omp）
Discord：https://discord.gg/4NMW9cdXZa

阅读全文