概要

普通聊天接口让大模型“回答问题”，Function Calling 则让大模型参与“选择并调用系统能力”。

两者表面上都接收消息并返回结果，但工程目标完全不同：普通聊天主要生成自然语言；Function Calling 需要模型、工具、权限、状态和错误处理共同组成一个执行闭环。

我在企业诊断报告类 AI 项目中设计过兼容 OpenAI Function Calling 格式的轻量工具调用框架，也做过 MCP 客户端与服务端集成。本文从工程角度说明两者的区别，以及什么时候值得引入工具调用。

普通聊天：输入消息，输出文本

概要

老系统不好维护时，团队很容易形成两个极端观点：

• “这个系统已经没救了，必须全部重写”；
• “现在还能跑，千万不要动”。

两种判断都可能有道理，也都可能把项目带入困境。

我参与过大型中台的服务聚合、接口治理、异构平台迁移和领域模型建设。实践中，决定是否重构的关键并不是代码“看起来有多旧”，而是业务价值、风险边界、经济账和演进路径能否同时成立。

在启动重构前，我通常先看以下四项。

一、业务价值：系统问题是否真的阻碍了业务

技术团队常见的不满包括代码重复、框架老旧、分层不标准、测试不足。这些是技术债，但不一定足以支持一场大规模重构。

概要

提到企业大模型应用，很多方案的第一反应都是：把资料放进向量数据库，搭一套 RAG，再做一个聊天页面。

RAG 很有价值，但它解决的是“从非结构化知识中找到相关证据，并辅助模型生成回答”。如果业务真正需要的是精确计算、实时查询、流程执行或规则判断，先上 RAG 反而可能绕远路。

在企业智能问数、知识检索和自动诊断报告的实践中，我越来越倾向于先判断任务类型，再决定使用 RAG、工具调用、规则引擎还是普通软件功能。

场景一：答案必须来自实时结构化数据

例如：

• 查询本月某区域销售额；
• 统计当前库存、订单和告警数量；
• 对比两个时间段的转化率；
• 按组织、产品和客户层级聚合数据。

概要

“这个接口昨天还是 200ms，今天突然变成 5 秒。”

遇到这类问题，最危险的做法是立即改线程池、加缓存或者重启服务。它们有时能暂时缓解问题，却可能掩盖真正原因，并给系统引入新的不确定性。

我做过中台慢接口治理、性能边界压测和高并发服务调优。面对接口变慢，我通常按照“先界定范围，再沿调用链缩小问题”的方式排查，重点检查以下五个位置。

一、先确认“慢”发生在哪里

第一步不是看代码，而是建立事实：

• 是平均耗时变慢，还是 P95/P99 尾延迟变慢？
• 是所有请求都慢，还是某类参数、租户或数据范围慢？
• 是单个实例慢，还是所有实例慢？
• 从什么时间开始？期间是否有发布、配置、数据量或流量变化？
• 服务端处理慢，还是网关排队、客户端网络或重试造成的慢？

概要

企业知识库项目最常见的错觉是：上传几份文档，问几个预先准备好的问题，模型回答得像模像样，于是大家认为项目已经完成了大半。

但 Demo 能回答，不等于系统有人用；有人试用，也不等于能够进入真实业务流程。

我参与过企业智能问数、卡片检索和诊断报告类 AI 应用的设计与交付。实践中真正困难的部分通常不是“把向量数据库接上”，而是让知识、检索、权限、评测和业务动作形成一个可以长期运营的闭环。

本文总结企业知识库从 Demo 走向生产时最容易忽略的五个问题。

一、Demo 验证的是技术链路，用户需要的是任务结果

概要

抗审查网络不是某一个软件，也不是某一个"最强协议"。它更像一套持续演进的网络系统：域名、TLS、反向代理、Xray Core、传输层、客户端、DNS、路由规则、日志和密钥管理共同决定可用性。

这套系统不是一开始就长成现在这样。vpn.chcbz.net 这条链路，经历过一轮很典型的技术演进：

ipset 分流 -> XL2TP/L2TP -> strongSwan/IPsec -> WireGuard -> Xray

概要

程序员的 Windows 主机，通常同时跑着 IDE、Docker、Gradle、Node、Maven、数据库、浏览器几十个标签页……各种东西都在蚕食 C 盘空间和系统资源。

某天突然发现 C 盘红了怎么办？系统盘满了怎么清理？进程锁定了文件怎么删？

本文整理了一套经过实践的 Windows 工作环境优化策略——不重装、不关休眠、不丢数据。

C 盘空间治理：风险分级策略

清理 C 盘最忌讳的就是"看到大的就删"。我用一套风险分级体系：

Tier 1：低风险——直接清理

系统临时文件是第一优先级——安全、量大、不影响任何功能：

概要

当大多数 Web 前端还在用 Vue/React 写表单和列表时，我们做了一个大胆的决定：用游戏引擎来驱动一个策略管理类 Web 应用的前端。

Juyiting（聚义厅）是一个基于 melonJS 游戏引擎 + Vue 3 混合架构的项目。它不是游戏，但它用了游戏的渲染管线、摄像机系统、寻路算法和动画引擎——因为业务场景本身就长着一张"地图"的脸。

本文将解析这套架构的核心设计，以及为什么游戏引擎比传统前端框架更适合某些场景。

为什么用游戏引擎？

业务场景是这样的：一张大厅地图，上面有多个角色（Agent），它们需要在大厅中自主移动、到达指定位置、执行行为。这不就是 RTS 游戏的基本操作吗？

概要

作为一个程序员兼 Minecraft 玩家，迟早会走到这一步——自己写 Mod。

本文记录了用 Minecraft Forge 1.20.6 开发一套自定义物品的过程：包括一个能探测钻石矿的探测器、一把带特效的美弓、一套终极盔甲，以及配套的成就系统和存档持久化。

不夸张地说，写 Minecraft Mod 是一种既能学 Java 又能玩得开心的学习方式。

环境搭建

Forge 1.20.6 使用 MDK（Mod Development Kit），Gradle 构建：

概要

"超有范"（Jia）是一个面向中小企业的全栈微服务平台。它集成了用户体系、OAuth 认证、微信生态（公众号/支付）、客服系统、短信服务、积分商城、任务管理等模块，前后端分离，支持 GraalVM Native Image 编译。

本文将拆解这套系统从零到一的架构设计和关键技术决策。

项目全景

后端架构

基于 Spring Boot 4.0 + Gradle 的多模块 Maven 依赖管理：

// cyf-api-kit 的核心依赖
dependencies {
    implementation "cn.jia:jia-common-starter:$jiaVersion"     // 通用模块
    implementation "cn.jia:jia-oauth-mapper:$jiaVersion"       // OAuth2 认证
    implementation "cn.jia:jia-oauth-resource:$jiaVersion"     // 资源服务器
    implementation "cn.jia:jia-wx-mapper:$jiaVersion"          // 微信生态
    implementation "cn.jia:jia-kefu-mapper:$jiaVersion"        // 客服系统
    implementation "cn.jia:jia-point-mapper:$jiaVersion"       // 积分系统
    implementation "cn.jia:jia-sms-mapper:$jiaVersion"         // 短信服务
    implementation "cn.jia:jia-task-mapper:$jiaVersion"        // 任务管理
    implementation "cn.jia:jia-chat-mapper:$jiaVersion"        // AI 对话
    implementation "cn.jia:jia-material-mapper:$jiaVersion"    // 素材管理
    implementation "cn.jia:jia-dwz-mapper:$jiaVersion"         // 短链接
}