概要

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

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

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

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

例如：

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

概要

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

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

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

概要

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

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

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

为什么用游戏引擎？

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

概要

"超有范"（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"         // 短链接
}

概要

在企业中台建设过程中，一个绕不开的难题是：如何让同一个服务接口在不同场景下，路由到不同的后端实现，并施加不同的鉴权策略？

传统做法是硬编码 if-else 或维护分散的配置文件，但随着业务场景膨胀——区域维度、产品线维度、客户维度交叉组合——这套方式很快就失控了。

我们设计了一套场景路由编排引擎，通过可视化的配置界面 + 规则引擎，实现了服务路由和鉴权的配置化、版本化管理。本文将分享其中的设计思路和关键技术细节。

核心概念

概要

接手一个运行多年的企业级中台系统，面对的问题是：代码耦合严重、模块边界模糊、改一个功能需要理解整个系统。

经过半年的渐进式改造，我们完成了 DDD（领域驱动设计）四层架构的搭建，将"大泥球"拆分为通用模块、运营中心、全链路三个独立模块。本文记录了这个过程中的关键决策和实践经验。

改造前的状况

中台系统经过多年迭代，积累了大量技术债：

• 功能边界不清：不同应用间通过私有服务直接调用，没有登记到 API 中心，没有订阅关系，溯源困难
• 前端直调外部服务：绕过了中台网关，鉴权和限流形同虚设
• 存量功能维护成本高：改一行代码需要理解几千行上下文
• 技术架构不统一：开发人员不熟悉公共平台和框架，重复造轮