⭐️ RAG 实战项目推荐
推荐一个笔者开源的实战项目，基于 Spring Boot 4.0 + Java 21 + Spring AI + PostgreSQL + pgvector + RustFS + Redis，实现简历智能分析、AI模拟面试、知识库 RAG 检索等核心功能。非常适合作为学习和简历项目，学习门槛低。
系统架构如下：
大家好，我是 Guide。前面分享过 IDEA 搭配 Qoder 插件的实战、Trae 接入大模型的实战 和 Claude Code 接入第三方模型的实战，这篇换个角度，聊聊 Claude Code 的使用方法与技巧。
大家好，我是 Guide。前面聊了 Claude Code 的使用技巧，这篇来看看 OpenAI 阵营的主力编程工具——Codex。
OpenAI 在 2025 年推出了 Codex 系列产品线，涵盖基于 o3 模型的云端软件工程智能体（codex-1）和开源的终端编码助手 Codex CLI。它和传统的代码补全不同，能自己读代码、跑测试、提 PR，完成从理解到交付的完整闭环。但想让它真正好用，提示工程、工具配置、安全策略这几环缺一不可。
大家好，我是 Guide。前面分享过 IDEA 搭配 Qoder 插件的实战和 Trae 接入大模型的实战，分别覆盖了 JetBrains 体系和 VS Code 体系下的 AI 辅助编码。这篇换个角度，聊聊 Claude Code 接入第三方模型 的实战体验。
Claude Code 本身是 Anthropic 官方的 CLI 编码工具，但它支持通过环境变量切换底层模型。这意味着你不必局限于 Claude 系列，完全可以接入其他模型来使用。本文以 GLM-5.1 作为示例，但接入方式是通用的——换成其他兼容模型，流程基本一致。
大家好，我是 Guide。如果你是 JetBrains IDE 的重度用户，大概率有过这样的纠结：想用 AI 辅助编程，但主流工具——Cursor、Trae、Qoder——大多基于 VS Code。切过去？舍不得 JetBrains 调试和重构体验。不切？又感觉错过了 AI 的效率红利。
有朋友会说：Claude Code、Gemini CLI 这些终端工具不是挺香的吗？确实香，但说实话，CLI 模式也有明显的短板：没有原生 UI 交互，看代码、审 diff 都不够直观。虽然可以通过一些开源项目（如 vibe kanban、1Code）来缓解，但在做复杂项目时，还是存在一些局限性。
大家好，我是 Guide。前面分享过一篇 IDEA 搭配 Qoder 插件的实战，那篇主要讲在 JetBrains 体系内用 AI 辅助编码。这篇换个角度，聊聊 Trae IDE 接入大模型 的实战体验。
Trae 是字节跳动推出的 AI 编程 IDE，基于 VS Code 生态，支持接入多种大模型。本文使用 MiniMax M2.7 作为示例，但 Trae 的接入方式是通用的——换成 Claude、GPT 等其他模型，流程基本一致。
腾讯面试的时候，面试官问我：“用过什么 AI 编程工具？”。我说：“Trae。”
空气突然安静了两秒。我搞不清楚为什么面试官沉默了，当时我还在想：“是不是我回答得不够高级？”。
面试被挂后才意识到：Trae 是字节的，腾讯家的是 CodeBuddy，阿里家的是 Qoder。
段子归段子！今天 Guide 分享 9 道当下校招和社招技术面试中经常会被问到的 AI 编程开放性问题，希望对你有帮助。
- ⭐ AI 编程 IDE：Cursor、Claude Code 等工具的使用技巧
- ⭐ AI 对后端开发的影响：AI 会淘汰初级程序员吗？最大风险是什么？
- ⭐ 未来核心竞争力：3 年后端工程师的核心竞争力是什么？
这是一个挺有意思的问题，很多公司也在面试中问过。挺简单的，不知道大家平时在重置密码的时候有没有想过这个问题。
回答这个问题其实就一句话：因为服务端也不知道你的原密码是什么。存原密码的程序员已经被开了 🤣。
如果服务端知道你的原密码，那就是严重的安全风险问题了。
我们这里来简单分析一下。
JDK 26 于 2026 年 3 月 17 日 发布，这是一个非 LTS（非长期支持版）版本。上一个长期支持版是 JDK 25，下一个长期支持版预计是 JDK 29。
JDK 26 共有 10 个新特性，这篇文章会挑选其中较为重要的一些新特性进行详细介绍：
- JEP 517: HTTP/3 for the HTTP Client API (为 HTTP Client API 引入 HTTP/3 支持)
- JEP 522: G1 GC: Improve Throughput by Reducing Synchronization (G1 GC 吞吐量优化)
- JEP 516: Ahead-of-Time Object Caching with Any GC (AOT 对象缓存支持任意 GC)
- JEP 500: Prepare to Make Final Mean Final (准备让 final 真正不可变)
- JEP 526: Lazy Constants (延迟常量, 第二次预览)
- JEP 525: Structured Concurrency (结构化并发, 第六次预览)
- JEP 530: Primitive Types in Patterns, instanceof, and switch (模式匹配支持基本类型, 第四次预览)
- JEP 524: PEM Encodings of Cryptographic Objects (加密对象 PEM 编码, 第二次预览)
- JEP 529: Vector API (向量 API, 第十一次孵化)
- JEP 504: Remove the Applet API (移除 Applet API)
在数据库性能优化中，索引是最直接有效的优化手段之一。然而，建了索引并不等于一定能用上索引。实际开发中，我们经常遇到这样的困惑：明明在字段上建立了索引，查询却依然慢如蜗牛，通过 EXPLAIN 分析发现居然是全表扫描。
导致索引失效的原因多种多样，既有 SQL 语句写法问题，也有索引设计不当的因素。有些失效场景是显性的（如违背最左前缀原则），有些则非常隐蔽（如隐式类型转换）。如果不深入了解这些失效场景，很容易在生产环境中埋下性能隐患。
本文将系统总结 MySQL 索引失效的常见场景，分析失效背后的原理机制，并提供相应的优化建议，帮助你在日常开发和排查问题中快速定位并解决索引失效问题。