Posts

人物介绍 姚远：某重点大学计算机系研究生，学霸一枚，成绩常年霸榜。外表斯文，戴着一副黑框眼镜。私下里却是个游戏狂魔，Warframe 和 DNF 双修玩家。对美女有着"学术般"的热情，但从不越界，止于欣赏。 第一幕：图书馆的清晨 场景：大学图书馆，早上七点。阳光透过落地窗洒进来。 姚远（低头奋笔疾书，桌上摊开三本厚厚的专业书）： 今天的进度比预期快了二十分钟。很好。 （手机震动。姚远瞥了一眼，嘴角微微上扬。） 姚远： 又是做任务的好日子。Warframe 的警报倒计时还有…… （他迅速心算。） 四小时三十二分。够我把这篇论文的算法部分写完。 画外音： 这是姚远的一天。精确、高效，却也藏着别人看不见的小确幸。 第二幕：午间的"研究" 场景：校园食堂，人声鼎沸。 姚远端着餐盘，正在寻找座位。忽然，他的目光定格。 姚远（内心独白）： 三点钟方向，长发，白裙子，气质型。两点钟方向，短发，运动风，活力型。 （他微微推了推眼镜，露出一个心满意足的微笑。） 姚远： 今日份的欣赏额度，达标。 （他找了个视野最好的位置坐下，一边吃饭一边继续"研究"。） 姚远（自言自语）： 不是好色，是审美。这是对美的尊重。 画外音： 姚远的"好色"从不冒犯任何人。他只是喜欢欣赏美好事物，就像欣赏一道精妙的算法。 第三幕：深夜的游戏世界 场景：姚远的宿舍，晚上十一点。室友们已经睡了。 姚远（戴着耳机，屏幕上 Warframe 的战甲正在刷图）： 这个配卡还是有优化空间……如果换成范围流，效率能提升 15%。 （突然，游戏里跳出一个交易请求。） 陌生玩家： 大佬，这个紫卡多少？ 姚远： 看属性，这个值 200 白金。你急出的话，150 我收了。 陌生玩家： 成交！大佬爽快！ 姚远（满意地笑了）： 又是盆满钵满的一天。 （切屏，DNF 的登录界面出现。） 姚远： 接下来，该去阿拉德大陆转转了。 画外音： 没人知道，这个图书馆里沉默寡言的书呆子，是两个游戏世界里的"大佬"。他用实力证明：学霸也能把游戏玩到极致。 第四幕：友情的温暖 场景：次日下午，宿舍楼下。 我（看着姚远走过来）： 姚远，听说你昨晚又熬夜打游戏了？ 姚远： 凌晨一点就睡了，不算熬夜。而且…… （他从包里掏出一本笔记本递给我。） 姚远： 你上次问的那个算法优化问题，我帮你推了一下，笔记在最后一页。 我（翻开笔记本，里面密密麻麻全是推导过程）： 这……你也太认真了吧！ 姚远（推了推眼镜）： 朋友嘛。而且帮你推导的过程，也巩固了我自己的理解。 我： 你这人，游戏玩得好，学习也好，还这么靠谱。你是怎么做到的？ ...

编者按 这是一次关于大语言模型（LLM）本质的对话。从"相似性"这个直觉出发，聊到预训练、参数、注意力机制，最后聊到一个核心问题：LLM 真的在"理解"吗？有技术细节，也有对 AI 本质的冷静看法。 第一部分：预训练 —— 压缩互联网，不是背书 问：帮我理解 LLM 如何能准确生成正确的答案，它内部是怎么理解知识和上下文的？我之前了解过，似乎就是相似性，通过预训练投喂 LLM 模型。 答：你说的"相似性"是对的，但更准确说是高维空间中的位置关系。 预训练时，模型看了海量文本，但它不是在记忆，而是在压缩规律。想象你要总结一本小说——背下来每一句话是死记硬背，学会"主角遇到困难会怎么做"才是掌握规律。LLM 做的是后者。 它学会的是因果关系、语义关系（“国王 - 王后 ≈ 男 - 女”）、代码缩进规则、数学推理链条……这些规律被压缩进参数（权重）里。 每个词被转成一个向量（比如 12288 维），在这个空间里，“猫"和"狗"距离近，“猫"和"汽车"距离远。相似概念在空间中聚集，不同概念分散。模型通过位置关系"理解"语义。 第二部分：参数 —— 不是输入，是"大脑” 问：通常说的什么 xx B 参数，这个参数怎么理解，和程序开发中的方法参数类的有什么关系？ 答：这两个"参数"完全不是一回事，只是中文翻译撞名了。 程序参数是输入，你调用时传进去的。而 LLM 的"参数"指的是模型内部的权重数量——训练完成后固定在那里的数值。 7B 模型 = 70 亿个权重 70B 模型 = 700 亿个权重 一个简化的例子： # 一个最简单的神经元 def neuron(x, w, b): # x 是输入，w 和 b 是"参数" return w * x + b LLM 有几十亿个这样的 w 和 b，层层连接形成网络。训练就是不断调整这些数，让输出越来越对。 类比一下：程序参数是你给函数的输入，LLM 参数是烘焙师傅 20 年积累的手感。你调用师傅（输入文本），他用手感（参数）做出蛋糕（输出）。 ...

从使用者角度整理的 Hugo 常识，够用就行。 目录结构 blog/ ├── hugo.toml # 主配置文件（也可用 config.toml/yaml） ├── content/ # 所有内容（文章、页面） │ ├── posts/ # 博客文章 │ └── about.md # 单页（/about/） ├── layouts/ # 自定义模板（覆盖主题） │ ├── _default/ │ │ ├── baseof.html # 基础模板 │ │ ├── single.html # 单页模板 │ │ └── list.html # 列表页模板 │ └── partials/ # 可复用片段 ├── themes/ # 主题目录 ├── assets/ # 需要处理的资源 │ └── css/extended/ # 自定义 CSS（自动合并） ├── static/ # 静态文件（直接复制） └── public/ # 构建输出（勿手动编辑） 构建原理 理解 Hugo 的构建流程，关键是看懂各目录的角色： ...

什么是 fail2ban？ 简单来说，fail2ban 就是一个自动封禁 IP 的工具。 当你运行 SSH、Web 服务或者其他网络服务时，总会有人试图暴力破解或者恶意扫描。fail2ban 会监控日志文件，当发现某个 IP 在短时间内多次失败尝试后，自动调用防火墙把这个 IP 封禁一段时间。 为什么需要它？ 我当初上云服务器的第一件事就是装 fail2ban。原因很简单： 减少日志噪音，不用看着满屏的失败登录记录 自动阻止暴力破解 配置好后基本不用管 可以针对不同服务设置不同规则 安装 Ubuntu/Debian sudo apt update sudo apt install fail2ban CentOS/RHEL sudo yum install epel-release sudo yum install fail2ban 安装完成后，服务会自动启动： sudo systemctl enable fail2ban sudo systemctl start fail2ban 基本配置 fail2ban 的配置文件在 /etc/fail2ban/ 目录下： fail2ban.conf - 主配置（一般不用改） jail.conf - 默认规则配置（不要直接修改） jail.local - 本地覆盖配置（在这里自定义） 创建本地配置 sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local 最小可用配置 编辑 /etc/fail2ban/jail.local： ...

欢迎来到我的博客 🎉 这是我的第一篇博客文章，使用 Hugo + PaperMod 主题搭建。 写博客这件事 几年前我也搭建过个人博客。那时写文章流程很完整：定主题、列大纲、理结构、写正文、反复修改润色，最后才发布。认真写了小半年，后来工作生活繁忙，慢慢就搁置了。再后来云服务器到期被收回，文章又没做版本管理，就这么找不到了。 有时真感慨岁月不饶人。这几年起起伏伏，我也经历了多个身份的转变——如今是一位丈夫、一位父亲，年龄也到了 30+。心态与之前有了很大不同，很多个瞬间让我感觉人生到了一个新阶段，提醒我要做出些改变。 前些日子翻看工作生活笔记，看到久远的一些文章草稿，又萌发了自己做博客网站的念头：在写作中沉淀自己，顺着过程中涌现的灵感做些新尝试，保持生活的热情和创造力。 LLM 最近几年很热门，涌现了很多基于其的应用和工具——ChatGPT、Claude、OpenClaw……这次博客我也想尝试些新方式：技术类文章，我会指定主题、大纲、结构和写作偏好，内容通过 prompt、RAG 之类的方式由 LLM 生成，来源是我自己的笔记和相关技术文档，最终生成的文章我会仔细检查修改后发布。看看能不能碰撞出什么火花。 关于这个博客 📝 使用 Markdown 写作 🚀 基于 Hugo 静态生成 🎨 PaperMod 主题 📦 Nginx 反向代理 接下来 在这里我会记录： 技术学习笔记 生活感悟 有趣的项目 感谢访问！

背景 最近在做一个在线文档协作系统，用户可以在平台上编辑文档，编辑完成后触发一系列业务流程——生成版本、数字签名、归档等。文档编辑器选用了 ONLYOFFICE，功能强大，协作体验也好。 看起来是个挺常规的需求，对吧？ 我当初也是这么想的。直到系统上线后，用户反馈"数字签名偶尔会失效"，我才意识到自己踩进了一个不大不小的坑里。 问题出在哪？ ONLYOFFICE 的架构中，文档编辑和文件存储是分离的。用户在编辑器里修改文档，改动先停留在 ONLYOFFICE Document Server 的内存中，并不会立即写入你的存储后端。 ONLYOFFICE 提供了 forcesave 接口，可以强制保存文档。我最初的实现是这样的： // 用户点击"提交"按钮时触发 public void submitDocument(String documentId) { // 1. 调用 forcesave onlyofficeService.forceSave(documentId); // 2. 获取文件内容 byte[] fileContent = storageService.getFile(documentId); // 3. 生成数字签名 String signature = signService.sign(fileContent); // 4. 保存签名记录 recordService.saveSignature(documentId, signature); } 看起来逻辑清晰，没什么问题。但上线后，用户反馈：某些文档的数字签名校验失败。 排查后发现：当用户打开文档验证时，文件内容和签名时不一致——明明签名后没人再编辑过，怎么文件变了？ 根本原因：forcesave 是异步的 翻了 ONLYOFFICE 的文档，才发现 forcesave 的调用流程是这样的： 后端调用 forcesave API ↓ ONLYOFFICE Document Server 接收请求 ↓ Document Server 在内部调度保存任务（异步） ↓ 保存完成后，Document Server 回调后端的 Callback Handler ↓ 后端在回调中收到最新的文件 URL 也就是说，forcesave() 返回时，文件还没保存完成。真正的文件更新是在回调里发生的。 ...

问题从哪里开始 项目里集成了 OnlyOffice 文档编辑器，功能挺好用，但回调处理这块慢慢变成了"噩梦"。 OnlyOffice 会推送各种回调，比如用户保存文档、强制保存、文档关闭等等。每种回调有不同的 status 字段，对应不同的处理逻辑。一开始代码写得很"朴素"： // FileServiceImpl.java - 曾经的模样 public void onlyOfficeCallback(OnlyOfficeCallbackDTO callbackDTO, File file) { if (callbackDTO.getStatus() == 2) { if (callbackDTO.getActions() != null && callbackDTO.getActions().stream().anyMatch(a -> a.getType() == 0)) { // 保存逻辑：下载文档、更新文件... // 几十行代码 } } else if (callbackDTO.getStatus() == 6) { // 强制保存逻辑 // 又是几十行代码 } else if (callbackDTO.getStatus() == 1) { // 正在编辑... } else if (...) { // 更多分支... } } 然后还有 Command 调用——主动向 OnlyOffice 发命令的逻辑，也堆在同一个 Service 里： public void sendCommand(String command, Map<String, Object> params) { if ("forcesave".equals(command)) { // 强制保存命令逻辑 } else if ("info".equals(command)) { // 获取信息命令逻辑 } // 更多分支... } 问题来了： ...

背景 远程开发模式下，代码跑在服务器上，但本地 IDE 更趁手。 问题来了：怎么让本地编辑器直接访问服务器上的文件？ 方案不少：FTP 同步、网盘同步、rsync……但总觉得不够优雅。要么配置繁琐，要么实时性差，要么得装一堆东西。 方案：Samba + SSH 隧道 核心思路： 服务器上跑 Samba — 提供文件共享服务 SSH 隧道转发 — 把 Samba 端口安全地映射到本地 本地挂载 — 像操作本地文件夹一样操作远程文件 这样做的优点： ✅ 无需额外客户端软件 ✅ 实时同步，所见即所得 ✅ SSH 加密，安全可靠 ✅ 本地 IDE 原生支持 服务端配置 Samba 安装 Samba sudo apt update sudo apt install samba 创建共享目录 # 创建共享目录（或使用现有项目目录） mkdir -p ~/projects # 备份原始配置 sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak 编辑配置文件 编辑 /etc/samba/smb.conf，在末尾添加： [projects] path = /home/youruser/projects browseable = yes read only = no create mask = 0644 directory mask = 0755 valid users = youruser 记得把 youruser 和路径换成你自己的。 ...

写在前面 在企业级微服务架构的落地过程中，部署往往是最让人头疼的环节之一。特别是当你的客户要求"断网部署"、“一键安装”、“版本可追溯"时，传统的手动部署或CI/CD流水线方案就显得力不从心了。 这篇文章记录了我为某企业级微服务系统设计的一套离线自动化部署脚本——从背景痛点到架构设计，再到核心实现细节。希望能给同样面临类似场景的同行一些参考。 背景：为什么需要离线自动化部署？ 痛点分析 我们团队负责的系统是基于一个成熟的企业级微服务框架二次开发的，整套系统包含： 13个核心微服务（注册中心、网关、认证、权限等） 多种中间件（MySQL、MongoDB、Redis、MinIO） ONLYOFFICE文档编辑服务 每次给客户现场部署时，我们都要面对这些问题： 耗时漫长：手动部署整套系统需要数小时，而且容易出错 网络限制：很多客户现场是内网环境，无法访问外网镜像仓库 版本混乱：手动记录版本信息容易遗漏，出问题难以追溯 环境差异：开发、测试、生产环境配置各不相同，切换困难 设计目标 基于这些问题，我确定了设计目标： 离线部署 + 一键执行 + 版本可追溯 + 多环境支持 架构设计：模块化脚本职责划分 整体方案采用Shell脚本实现（约450行核心代码），核心思路是职责分离、配置集中。 目录结构 deploy/ ├── deploy.sh # 主入口：环境准备 + 数据库初始化 ├── service.sh # K8s部署核心逻辑（install/uninstall） ├── initChart.sh # Helm Chart生成 + 版本信息SQL ├── services.sh # 服务列表定义（版本化管理） ├── vars.sh # 环境变量集中管理 ├── func.sh # 公共函数（字符串处理、分组解析） ├── k8s/ # K8s资源文件（PV/PVC/Deployment） ├── values/ # Helm Values配置（多环境支持） ├── mysql/ # 数据库初始化SQL ├── images/ # Docker镜像包（离线部署用） └── charts/ # Helm Chart包（离线部署用） 职责划分 脚本 职责 关键功能 deploy.sh 主编排 依赖检查、流程控制、数据库初始化 service.sh K8s操作 服务部署/卸载、镜像导入、Chart生成 initChart.sh Chart管理 模板渲染、版本SQL生成 services.sh 服务清单 版本化服务列表定义 vars.sh 配置中心 环境变量集中管理 func.sh 工具库 正则解析、日志输出等通用函数 这种设计让每个脚本职责单一，修改某个环节不会牵一发动全身。 ...