普通聊天接口让大模型“回答问题”，Function Calling 则让大模型参与“选择并调用系统能力”。
两者表面上都接收消息并返回结果，但工程目标完全不同：普通聊天主要生成自然语言；Function Calling 需要模型、工具、权限、状态和错误处理共同组成一个执行闭环。
我在企业诊断报告类 AI 项目中设计过兼容 OpenAI Function Calling 格式的轻量工具调用框架，也做过 MCP 客户端与服务端集成。本文从工程角度说明两者的区别，以及什么时候值得引入工具调用。
老系统不好维护时，团队很容易形成两个极端观点：
两种判断都可能有道理，也都可能把项目带入困境。
我参与过大型中台的服务聚合、接口治理、异构平台迁移和领域模型建设。实践中，决定是否重构的关键并不是代码“看起来有多旧”，而是业务价值、风险边界、经济账和演进路径能否同时成立。
在启动重构前，我通常先看以下四项。
技术团队常见的不满包括代码重复、框架老旧、分层不标准、测试不足。这些是技术债，但不一定足以支持一场大规模重构。
“这个接口昨天还是 200ms，今天突然变成 5 秒。”
遇到这类问题，最危险的做法是立即改线程池、加缓存或者重启服务。它们有时能暂时缓解问题，却可能掩盖真正原因，并给系统引入新的不确定性。
我做过中台慢接口治理、性能边界压测和高并发服务调优。面对接口变慢，我通常按照“先界定范围，再沿调用链缩小问题”的方式排查，重点检查以下五个位置。
第一步不是看代码，而是建立事实：
Java 提供稳定的运行时、并发模型和生态；Spring Boot 解决应用装配与生产化能力；微服务体系解决多团队、多服务环境下的治理问题。三者不能混为一谈：Spring Boot 应用并不天然是微服务，微服务也不等于“把单体拆成更多进程”。
高级工程师的判断标准是：服务是否具备清晰边界、可预测的失败行为、可观测性和安全控制，以及拆分后是否真正获得独立演进或独立伸缩的收益。
作为一个程序员兼 Minecraft 玩家，迟早会走到这一步——自己写 Mod。
本文记录了用 Minecraft Forge 1.20.6 开发一套自定义物品的过程：包括一个能探测钻石矿的探测器、一把带特效的美弓、一套终极盔甲，以及配套的成就系统和存档持久化。
不夸张地说，写 Minecraft Mod 是一种既能学 Java 又能玩得开心的学习方式。
Forge 1.20.6 使用 MDK（Mod Development Kit），Gradle 构建：
你是否也曾为微服务架构的复杂性而头疼？是否在寻找一个开箱即用的企业级解决方案？今天要介绍的 Jia 框架，或许就是你一直在寻找的那个答案！
Jia 是一个基于 Spring Cloud 的微服务 DevOps 云服务管理框架，它不仅仅是一个简单的脚手架，更是一套完整的企业级解决方案——从后台管理到服务接口，再到门户首页，一站式搞定！
核心技术
Jia 采用的是业界主流且成熟的技术栈，让你用得放心、学得舒心：
在企业中台建设过程中，一个绕不开的难题是：如何让同一个服务接口在不同场景下，路由到不同的后端实现，并施加不同的鉴权策略？
传统做法是硬编码 if-else 或维护分散的配置文件，但随着业务场景膨胀——区域维度、产品线维度、客户维度交叉组合——这套方式很快就失控了。
我们设计了一套场景路由编排引擎，通过可视化的配置界面 + 规则引擎，实现了服务路由和鉴权的配置化、版本化管理。本文将分享其中的设计思路和关键技术细节。
2024-2025 年 AI 领域最火的关键词，除了大模型本身，**MCP（Model Context Protocol）**一定排在前列。Anthropic 提出的这套协议，让 AI 模型能够以标准化的方式调用外部工具和数据源，一夜之间成了 AI Agent 的事实标准。
Spring 社区反应极快——Spring AI 1.0.0-M7 已经内置了完整的 MCP Server 支持。本文将带你从零搭建一个 MCP Database Server，让 AI 助手能够直接查询你的数据库。
接手一个运行多年的企业级中台系统，面对的问题是：代码耦合严重、模块边界模糊、改一个功能需要理解整个系统。
经过半年的渐进式改造，我们完成了 DDD（领域驱动设计）四层架构的搭建，将"大泥球"拆分为通用模块、运营中心、全链路三个独立模块。本文记录了这个过程中的关键决策和实践经验。
中台系统经过多年迭代，积累了大量技术债：
在微服务架构中，认证和授权是绕不开的基础设施。Spring Security OAuth2 是 Java 生态中的事实标准，但也因为配置繁琐、概念众多劝退了不少开发者。
本文从实际项目经验出发，梳理 OAuth2 的核心概念、常见授权模式，以及在 Spring 生态中的落地实践。
OAuth2 本质上是一套委托授权协议——让用户在不暴露密码的情况下，授权第三方应用访问自己的资源。
四个核心角色：
| 角色 | 职责 | 示例 |
|---|---|---|
| Resource Owner | 拥有资源的用户 | 张三 |
| Client | 请求访问资源的应用 | 微信公众号后台 |
| Authorization Server | 认证并颁发令牌 | 统一认证中心 |
| Resource Server | 存储并保护资源 | 订单服务、用户服务 |
