Ouonnki Space

多模态AI的真正落地：从看图说话到理解世界

Fri, 13 Feb 2026 22:00:00 GMT

不只是"看图说话"

2024年的多模态AI，大部分时候还停留在"描述一下这张图片"的水平。你给它一张猫的照片，它告诉你"这是一只橘猫"——准确但无聊。

2026年的多模态AI，已经是完全不同的物种了。

它能看一张UI截图，直接告诉你哪个按钮对齐有问题。它能看一段代码的报错截图，直接给出修复方案。它能看一个视频片段，总结出关键信息并标注时间戳。

从识别到理解，这是质的飞跃。

视觉理解：现在能做什么？

UI理解与自动化

这是我觉得最实用的场景。给AI一张网页截图，它能：

识别出所有可交互元素（按钮、输入框、链接）
理解页面的布局结构和层级关系
发现设计上的不一致（间距、字体、颜色）
生成对应的HTML/CSS代码

我最近在用的一个工作流：截图 → Claude分析 → 生成修复代码 → 自动提交。整个过程不到30秒，以前可能要对着设计稿对半天。

更厉害的是浏览器自动化。像OpenClaw这样的工具，AI可以直接"看"浏览器画面，理解当前页面状态，然后执行点击、输入等操作。不需要写CSS选择器，不需要XPath——AI看到什么就操作什么，跟人类一样。

文档和图表理解

以前OCR只能识别文字。现在的多模态AI能理解文档的语义结构。

给它一份PDF报告，它不只是提取文字，还能理解：

表格数据之间的关系
图表传达的趋势
注释和正文的对应关系
整体的论证逻辑

这对于研究人员、分析师、律师来说是巨大的效率提升。

代码理解的视觉维度

这个场景可能被低估了。当你把一个报错截图、一个终端输出、或者一个架构图发给AI的时候，它能结合视觉和文本信息给出更准确的判断。

比如你截了一张浏览器控制台的图，里面有红色的error、黄色的warning、还有stack trace。AI不仅能读出文字内容，还能通过颜色和位置理解哪些是相关的错误、哪个是root cause。

视频分析：下一个前沿

图片理解已经比较成熟了，视频分析则是2026年正在快速发展的方向。

当前能做的

视频摘要——给一段10分钟的视频，AI能生成带时间戳的摘要
关键帧提取——自动识别视频中信息密度最高的画面
内容审核——检测不当内容，远比传统算法准确
教程分析——看一段编程教程视频，提取出代码和操作步骤

Google Gemini的优势

在视频理解这个赛道上，Gemini目前是领先的。它原生支持长视频输入，不需要先切帧再逐帧分析。你可以直接丢一个小时的视频给它，然后问任何关于视频内容的问题。

GPT-5和Claude也在追赶，但在处理长视频方面，Gemini的架构优势还是明显的。

各家模型多模态能力对比

说说我的实际使用体验：

Claude Opus 4

图片理解：⭐⭐⭐⭐⭐ 最细致，能注意到微小细节
UI分析：⭐⭐⭐⭐⭐ 最好的UI理解能力，非常适合前端开发
视频：⭐⭐⭐ 支持但不是强项
特点：对图片的推理能力最强，不只是描述而是真正的理解

GPT-5

图片理解：⭐⭐⭐⭐⭐ 全面且准确
UI分析：⭐⭐⭐⭐ 很好但偶尔会忽略细节
视频：⭐⭐⭐⭐ 支持较长视频
特点：最均衡，各方面都不差

Gemini 2.5 Pro

图片理解：⭐⭐⭐⭐ 准确但有时不够深入
UI分析：⭐⭐⭐⭐ 不错
视频：⭐⭐⭐⭐⭐ 这个赛道的王者
特点：长视频和多图理解是杀手级场景

开源模型（Llama 4 / Qwen-VL）

图片理解：⭐⭐⭐⭐ 追上来了
UI分析：⭐⭐⭐ 还有差距
视频：⭐⭐ 刚起步
特点：进步很快，本地部署是优势

在开发中的实际应用

说些接地气的用法：

1. 设计稿转代码

截图一个Figma设计稿，AI能直接生成对应的React/Vue组件。不是完美的，但能完成80%的工作。剩下的手动调调就好。

2. Bug可视化诊断

截图报错界面发给AI，比复制粘贴文字效果更好。因为截图保留了上下文——你能看到是哪个页面、什么状态下出的错。

3. 竞品分析

截图竞品的界面，让AI分析设计模式、信息架构、用户体验的优劣。比自己对着看效率高多了。

4. 文档自动化

拍照手写的架构图或白板讨论，AI能转成结构化的文档和流程图。会议记录从此不再痛苦。

当前的局限

多模态AI还不完美。几个明显的问题：

幻觉依然存在。 AI有时会"看到"图片里没有的东西，或者误读文字。对于关键信息（数字、代码），一定要二次确认。

空间推理还弱。 "这个按钮在那个表格的左下方"——这种空间关系的理解还不够可靠。

视频理解有延迟。 长视频分析需要时间和大量计算资源，实时视频理解还不现实。

成本不低。 图片和视频的token消耗远高于纯文本。频繁使用多模态功能，API费用会明显增加。

未来会怎样？

多模态不是一个功能，而是AI发展的必然方向。人类就是通过多种感官来理解世界的，AI也需要。

接下来可以期待的：

实时视频理解——AI能像人一样"看直播"并实时反应
音频+视觉联合理解——看视频的同时理解对话内容和语气
3D空间理解——从2D图片推断3D空间关系
具身智能——AI通过摄像头"看"真实世界并操控机器人

多模态AI正在从一个"加分项"变成"基本能力"。再过两年，不支持多模态的AI模型，大概就像不支持中文的搜索引擎一样——理论上能用，实际上没人想用。

学会用眼睛看世界的AI，才是真正有用的AI。

开源大模型的逆袭：DeepSeek、Llama 4与本地部署实战

Fri, 13 Feb 2026 21:00:00 GMT

格局变了

2024年初，开源模型和GPT-4之间还有明显差距。到了2026年？这个差距基本消失了，在很多场景下开源甚至更强。

这不是我的主观判断。看看各大benchmark的排行榜，DeepSeek-R1、Llama 4、Qwen 3这些开源模型，已经稳定出现在前十甚至前五的位置。更关键的是，实际使用体验上，它们已经完全够用了。

三大代表选手

DeepSeek：中国队的惊喜

DeepSeek可能是2025年最大的黑马。一个相对低调的中国团队，用更少的计算资源训练出了能跟顶级模型掰手腕的产品。

DeepSeek-R1的推理能力尤其让人印象深刻。在数学和编程任务上，它的表现经常能超过GPT-4o。而且它的MoE（Mixture of Experts）架构意味着推理成本更低——同样的性能，更少的GPU。

我自己用DeepSeek最多的场景是代码review和技术文档写作。说实话，对于中文内容，它的理解和表达甚至比很多闭源模型更自然。

Llama 4：Meta的开源野心

Meta的Llama系列一直是开源LLM的标杆。Llama 4延续了这个传统，但这次的跃升幅度特别大。

最值得关注的几点：

多模态原生支持——不是后加的，是从训练开始就融入了视觉能力
超长上下文——支持128K甚至更长的上下文窗口
多语言能力——中文表现比前几代好太多了
Scout和Maverick两个版本——Scout轻量适合部署，Maverick重量级追求极致性能

Qwen 3：阿里的稳定输出

Qwen（通义千问）系列一直是中文场景的强力选手。Qwen 3在保持中文优势的同时，英文和代码能力也上了一个台阶。

它的优势在于版本丰富——从1.5B到72B，总有一个适合你的场景和硬件。

本地部署：没你想的那么难

很多人觉得跑本地模型需要几万块的显卡。2026年的现实是：一台普通的Mac就够了。

Ollama：一行命令搞定

如果你还没试过Ollama，强烈建议现在就试。

# 安装
curl -fsSL https://ollama.ai/install.sh | sh

# 跑一个模型，就这么简单
ollama run deepseek-r1:14b

# 或者Llama 4
ollama run llama4-scout:17b

# 想要更小的？
ollama run qwen3:7b

就这样。没有复杂的环境配置，没有CUDA版本冲突，没有依赖地狱。Ollama把所有脏活都包了。

硬件需求实话实说

别被"大模型"这个词吓到。现在的量化技术已经非常成熟：

| 模型大小 | 量化后 | 最低内存 | 推荐设备 | |---------|--------|---------|---------| | 7B | Q4_K_M | 6GB | M1 MacBook Air | | 14B | Q4_K_M | 10GB | M2 Pro Mac | | 32B | Q4_K_M | 20GB | M3 Max Mac / RTX 4090 | | 72B | Q4_K_M | 42GB | M4 Ultra Mac / 2×RTX 4090 |

7B的模型在M1 MacBook Air上就能跑，速度还不错——大概每秒20-30 token。日常对话、简单编程完全够用。

想要更好的体验？14B是性价比最高的甜点。它在大多数任务上的表现已经接近GPT-3.5时代的水平，但完全运行在你自己的机器上。

不只是命令行

Ollama跑起来之后，你可以用各种前端连接它：

Open WebUI——最流行的本地AI聊天界面，支持多模型切换
Continue——VSCode插件，本地模型做代码补全
LobeChat——漂亮的聊天界面，支持插件系统

为什么要跑本地模型？

隐私

这是最直接的理由。你的代码、文档、对话记录，一个字节都不会离开你的机器。

对于处理公司内部代码、客户数据、个人隐私信息的场景，这不是nice-to-have，是必须的。

成本

API调用的费用是会累积的。如果你是重度用户，每月几十到几百美元很正常。本地模型的成本就是电费——如果你已经有合适的硬件，基本等于免费。

可控性

不担心API突然涨价、服务下线、模型被修改。你的模型就在你的硬盘上，随时可用，永远不变。

速度

没有网络延迟。对于需要频繁调用的场景——比如代码补全、实时翻译——本地模型的响应速度通常更快。

什么时候该用闭源？

说了这么多开源的好，但我不是"开源原教旨主义者"。有些场景闭源模型确实还是更好的选择：

最前沿的推理能力——Claude Opus 4、GPT-5在最复杂的推理任务上还是有优势
超大上下文理解——处理整本书级别的内容，闭源模型的长文本能力更稳定
多模态能力——视觉理解方面，Gemini和GPT-5还是领先的
不想折腾——如果你只是偶尔用用，API确实更方便

我的做法是混合使用：日常编程、文档写作用本地的DeepSeek或Qwen；复杂推理、重要决策用Claude或GPT-5；创意和brainstorm两边都试试，看谁的输出更好。

开源的未来

开源大模型的发展速度比大多数人预期的要快。每隔几个月就有新的突破——更好的架构、更高效的训练方法、更小的模型做到更强的效果。

2026年底，我相信7B级别的开源模型就能达到现在GPT-4o的水平。到那时候，每个人的手机上都能跑一个真正强大的AI助手。

**这才是AI民主化的真正含义。**不是每个人都能调用API，而是每个人都能拥有自己的模型——不受审查、不受限制、不受服务商控制。

开源正在赢。

Prompt Engineering已死？2026年与AI高效协作的新范式

Fri, 13 Feb 2026 20:00:00 GMT

一个时代的终结

还记得2023年那会儿吗？Twitter上到处是"10个ChatGPT prompt让你效率翻倍"，Medium上的prompt engineering教程能绕地球三圈。每个人都在研究怎么跟AI"说话"——用什么语气、加什么前缀、要不要说"你是一个专家"。

2026年了，这些技巧还有用吗？

说实话，大部分已经没意义了。不是因为prompt不重要，而是因为AI变聪明了，协作方式也彻底变了。你不再需要用各种trick去"骗"模型给出好答案，而是要学会一种全新的协作范式。

从"写prompt"到"设计系统"

以前我们把80%的精力花在单条prompt上，反复调试措辞。现在？重点完全转移了。

System Prompt才是核心战场

2026年的AI协作，真正的功夫在system prompt的设计上。这不是简单的"你是一个有帮助的助手"，而是一份精心设计的行为规范文档。

拿我自己的例子来说。我给Claude写的system prompt里包含：

角色定义：不只是"你是谁"，而是详细的决策框架——遇到什么情况该怎么做
工具使用规范：什么时候用搜索，什么时候读文件，什么时候直接回答
输出格式约束：不同场景下的格式要求，比如技术讨论用markdown，闲聊就口语化
安全边界：哪些事情绝对不做，哪些需要确认

一个好的system prompt，相当于给AI写了一份"员工手册"。你不需要每次对话都重复要求，模型会持续遵循这些规范。

上下文工程 > Prompt工程

Andrej Karpathy说得好："Prompt engineering is dead, context engineering is real." 现在的关键不是怎么措辞，而是给模型提供什么上下文。

实际操作中，这意味着：

项目的AGENTS.md文件，让AI理解项目结构和规范
自动注入的相关代码片段，而不是让AI猜
对话历史的智能裁剪，保留重要上下文，丢弃噪音
实时的工具调用结果，让AI基于事实而非猜测回答

Agent Workflow：真正的生产力革命

单轮对话的时代已经过去了。2026年最大的变化是Agent的成熟。

不是聊天，是编排

我现在每天的工作流是这样的：写一段需求描述，AI自动拆解成子任务，调用不同的工具去执行——读代码、搜索文档、写测试、提PR。整个过程我可能只需要介入两三次做决策。

这跟2023年"请帮我写一个函数"的模式完全不同。

举个真实例子。上周我需要给博客加三篇新文章，包括找图片、写内容、上传图床、推送部署。我只写了一段任务描述，AI agent就自动完成了整个流程——下载图片、上传CDN、生成文章、git push。全程不需要我盯着。

工具链是新的prompt

现在"调教"AI的方式不是改措辞，而是给它更好的工具。

一个能读写文件的AI，比你写再完美的prompt都有用。一个能搜索网络的AI，不会再"幻觉"过时信息。一个能执行代码的AI，不需要你肉眼检查逻辑。

工具的选择和编排，才是2026年"prompt engineering"的真正含义。

人的角色变了

这不意味着人变得不重要。恰恰相反，人的角色升级了。

从执行者到审核者

以前：你告诉AI每一步该做什么。现在：你定义目标和约束，AI规划执行路径，你审核关键决策点。

这更像是管理一个能力很强但经验不足的新人。你不需要手把手教他写代码，但需要review他的PR、把关架构决策、在关键分叉点给出方向。

从写prompt到写规范

最有价值的技能不再是"怎么跟AI说话"，而是：

需求定义能力——你能不能把模糊的想法变成清晰的规范？
系统设计能力——你能不能设计出合理的工具链和工作流？
质量判断能力——你能不能快速判断AI输出的质量？
边界感知能力——你知不知道什么该交给AI，什么该自己做？

那些还在"学prompt"的人

我不是说prompt完全不重要。在某些场景下——比如创意写作、复杂推理——措辞的细微差别确实会影响结果。

但如果你还在花大量时间研究"最佳prompt模板"，你可能在优化一个越来越不重要的环节。

真正的杠杆在更高的层面： 设计好的system prompt、选择合适的工具、构建高效的workflow、定义清晰的评估标准。

写在最后

Prompt engineering没有"死"，它进化了。从一个专门的技能，变成了更广泛的"AI协作设计"能力的一小部分。

就像"会打字"曾经是一个专业技能，现在只是基本素养一样。会写prompt很快也会变成默认技能，真正稀缺的是——知道让AI做什么，以及怎么验证AI做得对不对。

这才是2026年与AI高效协作的核心。

不是说得更好，而是设计得更好。

AI编程的下一步：Codex、Claude Code与前端开发的未来

Thu, 12 Feb 2026 22:00:00 GMT

一个事实：我现在写代码的方式和一年前完全不同了。

不是说AI替代了我写代码，而是写代码的流程变了。以前是"想→写→调→测"，现在是"想→描述→审→调"。AI处理了大量机械性的编码工作，我更多时间花在思考架构和审查代码上。

这篇文章聊聊2026年AI编程工具的现状，以及作为前端开发者，我们该怎么适应。

AI编程工具现状

目前主流的AI编程工具可以分三个层次：

编辑器内嵌：Copilot与Cursor

GitHub Copilot已经迭代到了一个相当成熟的阶段。代码补全的准确率比早期提升了一个量级，特别是在你项目上下文足够丰富的情况下，它给出的建议经常是直接能用的。

Cursor则走了一条更激进的路——它不只是补全，而是试图理解你的整个项目。Cursor的Composer模式可以同时修改多个文件，做跨文件的重构。对于前端项目来说，修改一个组件同时更新相关的样式、测试和文档，这种体验是传统IDE无法想象的。

两者的选择其实很简单：如果你重度依赖VS Code生态，Copilot无缝集成；如果你愿意尝试新编辑器，Cursor的体验上限更高。

终端工具：Claude Code与Codex CLI

这是2025-2026年最让我兴奋的新品类。

Claude Code可以直接在终端里理解你的项目结构，执行复杂的开发任务。"帮我把这个React组件重构成TypeScript，加上单元测试"——它会自己读文件、改代码、跑测试、修bug，全程你只需要review最终结果。

OpenAI的Codex CLI走了类似的路线。它的优势在于和GitHub生态的深度集成——创建PR、写commit message、处理code review comment，流程非常顺畅。

这类工具改变了一个根本性的东西：开发者从"写代码的人"变成了"审代码的人"。

Agent级别：自主开发

再往上一层，就是完全自主的AI开发Agent。给它一个需求描述，它自己完成从设计到实现到测试的全流程。

目前这个层次还不够成熟，生产环境下我不敢完全放手。但在原型开发、小工具开发这些场景下，已经可以用了。

效率提升实例

说几个具体的例子：

组件开发：一个中等复杂度的React组件，以前需要2-3小时。现在用Claude Code描述需求，10分钟出初版，再花30分钟review和调整。效率提升3-4倍。

API对接：对接第三方API最烦的是读文档和处理边界情况。现在把API文档丢给AI，它能直接生成类型定义、请求封装和错误处理代码。这种机械活儿AI做得比人好。

Bug修复：把报错信息和相关代码贴给Claude Code，它大概率能直接定位问题并给出修复方案。复杂bug可能需要几轮对话，但比自己翻Stack Overflow快多了。

代码迁移：最近把一个项目从Webpack迁移到Vite，Claude Code处理了80%的配置改动和兼容性修复。省了至少两天时间。

对前端开发流程的改变

前端的工作流正在被重塑：

CSS几乎不用手写了。描述你想要的样式，AI生成Tailwind类名或CSS代码，准确率很高。响应式、动画这些以前费时间的东西，现在几句话就搞定。

测试覆盖率暴涨。以前谁愿意写测试？现在AI一键生成，覆盖率轻松上80%。写测试的成本从"高到不想写"变成了"低到没理由不写"。

文档不再是负担。组件文档、API文档、README，都可以让AI根据代码自动生成。质量还不错，至少比没有文档强太多。

Code Review效率提升。AI先过一遍，标出潜在问题，人再重点审核。Review的质量反而提高了，因为你可以把注意力集中在架构和业务逻辑上。

AI编程的局限性

但也要清醒地认识到局限：

架构决策还是人的活。AI可以实现任何架构，但选择哪种架构、为什么选这种架构，需要对业务和团队的深度理解。这是AI目前做不了的。

复杂状态管理容易出错。涉及多个组件之间复杂交互的状态管理，AI经常给出看起来对、但实际有隐藏bug的方案。这类问题必须仔细review。

性能优化需要人类直觉。AI能写出功能正确的代码，但不一定是性能最优的。关键路径的优化还是需要有经验的工程师来判断。

上下文限制。即使是100万token的上下文，面对大型monorepo也不够用。AI看不到全貌，给的建议可能和项目整体架构冲突。

前端工程师如何适应

我的建议：

拥抱AI工具，但不要依赖。用AI加速日常开发，但确保你理解AI生成的每一行代码。不理解的代码不要提交。

往上走。把时间花在架构设计、性能优化、用户体验这些AI还不擅长的地方。纯编码能力的价值在下降，系统设计能力的价值在上升。

学会"描述"。和AI协作的核心技能是精确描述你想要什么。Prompt engineering不只是写ChatGPT的提示词，更是清晰表达技术需求的能力。

保持学习。AI工具迭代很快，每隔几个月就有新的工具和工作流。保持好奇心，不断尝试新工具。

未来展望

2026年只是AI编程的早期阶段。我预测接下来会发生的事：

AI Native的开发框架会出现。不是在现有框架上加AI功能，而是从底层就为AI协作设计的新框架。代码结构、文件组织、API设计都会被重新思考。

初级开发者的定义会改变。"初级"不再意味着"只会写简单代码"，而是"能有效指导AI完成开发任务"。门槛变了，但并没有消失。

前端和后端的界限会更模糊。AI让全栈开发变得更容易，一个前端工程师借助AI可以轻松处理大部分后端任务。专业分工的边界在重新划定。

说到底，AI编程工具是放大器，不是替代品。它放大了优秀工程师的能力，也放大了不合格工程师的问题。核心竞争力从来不是"会写代码"，而是"知道该写什么代码"。

这一点，在AI时代只会更加明显。

AI Agent落地实战：我如何用OpenClaw搭建7×24小时个人AI助手

Thu, 12 Feb 2026 21:00:00 GMT

用了三个月OpenClaw之后，我已经很难想象没有它的日子了。

这不是夸张。它帮我管日程、查邮件、写代码、做翻译、监控服务器、甚至在我睡觉的时候自动处理一些routine的事情。这篇文章分享我的完整搭建和使用经验。

什么是AI Agent？

先说清楚概念。ChatGPT是聊天工具——你问它答。AI Agent是自主执行者——你给它目标，它自己规划步骤、调用工具、完成任务。

区别在于：聊天工具是你的嘴替，Agent是你的分身。

一个真正的Agent需要几个核心能力：持续运行、记忆上下文、调用外部工具、主动行动。市面上大部分"Agent"产品其实只是套了个壳的ChatGPT，真正能独立运转的很少。

为什么选OpenClaw

试过AutoGPT、MetaGPT、各种Agent框架之后，我选了OpenClaw。原因很直接：

它是真的能跑起来的。很多Agent框架看demo很酷，自己搭的时候一堆bug。OpenClaw的安装和配置流程是我用过最顺畅的。

Telegram原生支持。我想要一个随时能用手机对话的助手，不是只能在terminal里跑的玩具。OpenClaw的Telegram接入开箱即用。

多模型切换。一条命令切换Claude/GPT/Gemini，不同任务用不同模型，这个灵活性太重要了。

记忆系统。它有完整的memory机制——短期记忆(对话上下文)、长期记忆(MEMORY.md)、每日笔记。你的Agent真的能"记住"事情。

详细文档在docs.openclaw.ai，写得很清楚。

配置过程

核心配置其实不复杂：

Telegram接入：通过BotFather创建bot，把token填进配置文件。五分钟搞定。支持私聊和群组，群组里可以设置触发规则，不会每条消息都回。

多模型配置：在配置文件里定义多个模型，日常用Sonnet 4(快且便宜)，复杂任务切Opus 4，代码任务可以用GPT-5。切换就是一条 /model 命令的事。

Heartbeat系统：这是OpenClaw最酷的功能之一。你可以设置定时心跳，让Agent每隔一段时间自动检查邮件、日历、服务器状态等。它不是傻等你提问，而是主动巡逻。

Cron任务：比heartbeat更精确的定时任务。每天早上8点发天气预报、每周一整理周报、每小时检查一次服务器——都可以用cron实现。

Memory系统：Agent会自动维护 MEMORY.md(长期记忆)和每日笔记文件。你告诉它"记住我喜欢用Sonnet处理日常任务"，它真的会记住，下次对话时会参考。

日常使用场景

说几个我每天都在用的场景：

代码助手：直接在Telegram里发代码片段，让它review、重构、补测试。它能访问我的项目文件，给出的建议是基于整个项目上下文的。

信息整理：把一堆链接丢给它，让它总结要点。看论文、看技术文档特别好用。

自动化运维：通过shell工具，它能直接在服务器上执行命令。"检查一下Nginx日志有没有异常"——它会自己去看，然后给你一个人话版的总结。

日程管理：结合日历API，它能提醒即将到来的会议，甚至帮你草拟会议议程。

翻译和写作：中英互译、润色文章、写邮件。质量比单独用ChatGPT好，因为它知道你的写作风格偏好。

踩过的坑

也不是一帆风顺。几个教训分享给大家：

Token消耗比想象的大。heartbeat如果设得太频繁，加上长上下文，一个月的API费用可能让你吃惊。建议一开始保守设置，观察一周再调整。

记忆管理需要主动维护。MEMORY.md会越来越大，定期清理过时信息很重要。不然上下文会被无关内容占据。

群组使用要谨小慎微。在群里它可能过于活跃，建议设置好触发规则——只在被@时回复，或者只回复特定关键词。

模型切换要有策略。不是所有任务都需要最强模型。日常对话用Sonnet，复杂推理才上Opus。这样月底账单不会吓到你。

AI Agent的未来

用了几个月Agent之后，我对AI的理解发生了变化。

单纯的聊天模型已经是"上一个时代"的产品了。未来的方向一定是Agent——持续运行、自主决策、跨工具协作的AI系统。

OpenClaw这样的项目让个人用户也能拥有强大的Agent能力，而不需要依赖大公司的封闭平台。这很重要。

我的预测：到2026年底，大部分开发者都会有自己的AI Agent。不是因为赶时髦，而是因为用过之后真的回不去了。

如果你还没试过，强烈建议从OpenClaw开始。学习曲线不陡，文档清晰，社区活跃。给自己一个周末的时间，你会发现一个全新的工作方式。

从GPT-5到Claude Opus 4：2026大模型格局全面解析

Thu, 12 Feb 2026 20:00:00 GMT

2026年刚开年，大模型的竞争已经卷到了一个新高度。去年这个时候我们还在讨论GPT-4o够不够用，现在的问题变成了——这么多顶级模型，到底选哪个？

这篇文章是我过去几个月密集使用各家模型后的真实感受，不是参数对比表，是体感。

GPT-5系列：OpenAI的全面反击

GPT-5在2025年底正式发布，说实话，进步是肉眼可见的。最大的变化不是"更聪明"，而是更稳定。以前GPT-4经常出现的"突然变笨"现象，在GPT-5上几乎消失了。

GPT-5的多模态能力终于达到了实用级别。图片理解、代码生成、长文档分析，都有质的飞跃。特别是代码方面，GPT-5配合Codex CLI已经能处理相当复杂的重构任务。

不过GPT-5也有明显短板：中文写作风格偏"翻译腔"，创意写作不如Claude自然。另外价格也不便宜，API调用成本比去年涨了不少。

Claude Opus 4：我的日常主力

说真话，Claude Opus 4是我目前用得最多的模型。原因很简单：它最懂你想要什么。

Opus 4的指令遵循能力是所有模型里最强的。你说"用轻松的语气写"，它就真的轻松；你说"控制在500字以内"，它就不会写成800字。这种"听话"的能力看似简单，实际上是最难做到的。

代码能力方面，Opus 4在复杂系统设计和架构层面的理解力明显强于竞品。它能读懂你整个项目的上下文，给出的建议不是片段式的，而是全局性的。

Sonnet 4作为轻量版，性价比极高。日常对话、简单任务用Sonnet完全够了，响应速度还快得多。

Gemini 2.5：Google的长上下文王者

Gemini 2.5 Pro最大的卖点还是那个恐怖的上下文窗口。100万token的上下文不是噱头，在处理超长文档、代码库分析这些场景下，确实是独一档的存在。

但日常使用中，Gemini的"人味"还是差一些。回答偏模板化，创意任务表现平平。Google在安全限制上也过于保守，经常遇到不必要的拒绝。

Gemini最适合的场景：大规模信息整理、长文档问答、多文件代码分析。

国产模型：Kimi K2.5领跑

国产模型这一年的进步令人惊讶。Kimi K2.5在中文理解和生成方面已经不输GPT-5，某些场景甚至更好。价格优势更是碾压级的——同样的任务，成本可能只有GPT-5的十分之一。

DeepSeek V3也值得关注，特别是在数学推理和代码生成方面表现亮眼。开源策略让它在开发者社区积累了大量好感。

智谱GLM-5、百度文心5.0也各有所长，但整体上Kimi和DeepSeek已经拉开了差距。

我的模型选择建议

经过几个月的实际使用，我的推荐是：

日常主力：Claude Opus 4 / Sonnet 4。指令遵循好，输出质量稳定，中文表现优秀。

代码开发：Claude Opus 4 + GPT-5轮换。复杂架构用Opus，快速迭代用GPT-5。

长文档处理：Gemini 2.5 Pro。上下文窗口的优势在这类任务上无可替代。

性价比优先：Kimi K2.5。中文场景下质量够用，成本极低。

开源自部署：DeepSeek V3。社区活跃，模型质量过硬。

2026年的趋势判断

几个明显的趋势：

模型差异化加速。不会有"一个模型打天下"的局面。每家都在找自己的差异化定位，用户需要学会"用对的模型做对的事"。

Agent能力成为关键。单纯的问答已经不够了，2026年的竞争焦点是谁能更好地驱动Agent——自主执行任务、调用工具、持续运行。

价格战刚刚开始。国产模型的价格优势会倒逼海外厂商降价，对用户来说是好事。

多模态从噱头变标配。图片、音频、视频理解不再是加分项，而是基本要求。

我的判断是：2026年不存在"最好的模型"，只有"最适合你的模型组合"。学会灵活切换和搭配，才是正确的打开方式。

OpenClaw 完全部署指南：从零搭建你的 AI 助手

Mon, 09 Feb 2026 16:30:00 GMT

阅读时间: 20分钟 | 难度: 中级 | 基于 OpenClaw 官方文档

OpenClaw 是什么

OpenClaw（前身为 Moltbot/Clawdbot）是一个自托管的 AI 助手网关，让你能够在自己控制的环境中运行 AI 代理，并连接到多种消息平台。

核心特性

| 特性 | 说明 | |------|------| | 🤖 多模型支持 | GPT-4、Claude、Gemini、本地模型（Ollama） | | 🔄 持久化会话 | 长对话上下文、记忆功能 | | 🔌 技能系统 | 通过插件扩展功能（GitHub、搜索、代码执行） | | 💬 多平台 | Telegram、Discord、WhatsApp、Slack、iMessage | | 🔒 本地优先 | 数据不出本地，完全可控 |

与 ChatGPT 的区别

| | OpenClaw | ChatGPT | |--|----------|---------| | 部署 | 自托管 | 云服务 | | 数据 | 本地 | 上传 OpenAI | | 插件 | 任意安装 | 官方限定 | | 成本 | API 费 + 服务器 | 订阅费 | | 定制 | 完全可定制 | 有限 |

架构理解：Gateway + Channels

理解 OpenClaw 的架构对部署至关重要：

┌─────────────────────────────────────────────────────────────┐
│                     OpenClaw Gateway                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐    │
│  │   Control    │  │   Session    │  │    Skill     │    │
│  │     UI       │  │   Manager    │  │   Engine     │    │
│  └──────────────┘  └──────────────┘  └──────────────┘    │
│                                                              │
│  ┌────────────────────────────────────────────────────┐   │
│  │              Channel Adapters                       │   │
│  │  Telegram │ Discord │ WhatsApp │ Slack │ iMessage  │   │
│  └────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

核心组件

| 组件 | 说明 | 默认端口 | |------|------|----------| | Gateway | 核心控制平面 | 3000 | | Control UI | Web 管理界面 | 3000/ui | | Channels | 消息平台适配器 | - |

系统要求与准备

硬件要求

| 级别 | CPU | 内存 | 存储 | 适用场景 | |------|-----|------|------|----------| | 入门级 | 2核 | 4GB | 20GB | 个人轻量使用 | | 推荐 | 4核 | 8GB | 50GB | 日常办公+多平台 | | 高级 | 8核 | 16GB | 100GB | 企业/团队/高并发 |

软件要求

| 软件 | 版本 | 说明 | |------|------|------| | Node.js | 22+ | 必需，OpenClaw 基于 Node 构建 | | npm/pnpm | 最新 | 包管理器 | | Git | 任意 | 克隆仓库（可选） |

网络要求

可访问外网（下载依赖、调用 AI API）
如果使用本地模型（Ollama），需要相应端口

安装 OpenClaw

官方提供 3 种安装方式，根据你的需求选择：

方式一：一键安装脚本（推荐）

最简单的方式，自动安装 Node.js 和 OpenClaw：

# 执行安装脚本
curl -fsSL https://openclaw.ai/install.sh | bash

# 如果不需要立即启动向导，添加 --no-onboard
curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard

脚本会完成：

检查系统环境
安装/升级 Node.js 22+（如缺失）
全局安装 openclaw CLI
可选：启动 onboarding 向导

方式二：npm 安装（已有 Node.js）

如果你已经安装了 Node.js 22+：

# 使用 npm
npm install -g openclaw@latest

# 或使用 pnpm（更快）
pnpm add -g openclaw@latest

# 或使用 yarn
yarn global add openclaw@latest

方式三：从源码构建（开发者）

适合需要修改源码或贡献代码的用户：

# 克隆仓库
git clone https://github.com/openclaw/openclaw.git
cd openclaw

# 安装依赖
pnpm install

# 构建项目
pnpm build

# 链接到全局（可选）
pnpm link --global

# 或直接运行
./bin/openclaw

验证安装

# 检查版本
openclaw --version

# 检查环境
openclaw doctor

# 查看帮助
openclaw --help

初始配置向导

安装完成后，运行 onboarding 向导进行初始配置：

# 启动交互式配置向导
openclaw onboard

# 同时安装系统服务（推荐用于服务器）
openclaw onboard --install-daemon

向导配置流程

向导会引导你完成以下配置：

1. 模型提供商配置

选择并配置 AI 模型：

? Select model provider: (Use arrow keys)
❯ OpenAI (GPT-4, GPT-3.5)
  Anthropic (Claude 3)
  Google (Gemini)
  Ollama (Local models)
  Custom/OpenRouter

配置 OpenAI 示例：

# 向导会询问 API Key
Enter OpenAI API Key: sk-xxxxxxxxxx

# 选择默认模型
Select default model: GPT-4 Turbo

配置 Ollama（本地模型）示例：

# 确保 Ollama 已运行
ollama serve

# 在向导中选择 Ollama
Enter Ollama URL: http://localhost:11434

# 选择模型
Select model: llama3.2

2. 消息渠道配置（可选）

可以在向导中配置，也可以稍后手动添加：

? Configure messaging channels now? (Y/n)

? Select channels to configure:
  [ ] Telegram
  [ ] Discord
  [ ] Slack
  [ ] WhatsApp

3. 安全与认证配置

Gateway Token（必需）：

# 生成安全令牌
? Set Gateway Token (auto-generated): xxxxxxxxxxxxxxxx

# 或者自定义
? Set Gateway Token (custom): my-secure-token-123

DM 配对安全（推荐启用）：

? Enable DM pairing for security? (Y/n) Y

? Require approval for new conversations? (Y/n) Y

4. 数据存储配置

? Select database:
❯ SQLite (默认，适合个人使用)
  PostgreSQL (适合团队/生产)

SQLite（默认）：

# 数据存储位置
Data directory: ~/.openclaw/
Config file: ~/.openclaw/config.yaml
Database: ~/.openclaw/data.db

PostgreSQL（可选）：

? PostgreSQL host: localhost
? PostgreSQL port: 5432
? Database name: openclaw
? Username: openclaw
? Password: ********

完成配置

向导完成后，会显示摘要：

✅ OpenClaw 配置完成！

📝 配置摘要:
   - Gateway: http://localhost:3000
   - Model: OpenAI GPT-4 Turbo
   - Channels: Telegram (配置中)
   - Security: DM pairing enabled
   - Database: SQLite (~/.openclaw/)

🚀 下一步:
   1. 启动 Gateway: openclaw gateway
   2. 打开 Control UI: openclaw dashboard
   3. 完成 Telegram 配对

📖 文档: https://docs.openclaw.ai
💬 社区: https://discord.com/invite/clawd

启动 Gateway

配置完成后，启动 OpenClaw Gateway：

前台运行（调试）

# 前台启动，查看实时日志
openclaw gateway

# 指定端口
openclaw gateway --port 8080

# 指定配置文件
openclaw gateway --config /path/to/config.yaml

后台运行（生产）

# 使用系统服务（如果安装时已启用）
systemctl start openclaw
systemctl enable openclaw

# 查看状态
systemctl status openclaw

# 查看日志
journalctl -u openclaw -f

使用 Docker（可选）

OpenClaw 也支持 Docker 部署：

# 使用官方 Docker 镜像
docker run -d \
  --name openclaw \
  -p 3000:3000 \
  -v ~/.openclaw:/data \
  openclaw/openclaw:latest

# 或使用 Docker Compose
wget https://openclaw.ai/docker-compose.yml
docker-compose up -d

验证启动

# 检查 Gateway 状态
openclaw status

# 健康检查
openclaw health

# 测试 API
curl http://localhost:3000/api/health

# 查看日志
openclaw logs

接入 Telegram

Telegram 是 OpenClaw 最常用的接入平台，以下是详细配置步骤。

1. 创建 Telegram Bot

在 Telegram 中搜索 @BotFather
发送 /newbot 命令
输入 Bot 名称（如 "MyAIAssistant"）
输入 Bot 用户名（必须以 bot 结尾，如 myai_bot）
保存获得的 Bot Token（格式：123456789:ABCdefGHIjklMNOpqrsTUVwxyz）

常用 BotFather 命令：

/setname - 修改 Bot 名称
/setdescription - 设置描述
/setabouttext - 设置关于文本
/setuserpic - 设置头像
/setcommands - 设置命令菜单

2. 配置 OpenClaw 连接 Telegram

# 添加 Telegram 渠道
openclaw channels add telegram --token YOUR_BOT_TOKEN

# 或者使用交互式配置
openclaw channels configure telegram

手动编辑配置文件：

nano ~/.openclaw/config.yaml

添加 Telegram 配置：

channels:
  telegram:
    enabled: true
    token: "123456789:ABCdefGHIjklMNOpqrSTUvwxYz"
    # 可选：设置 webhook（生产环境）
    webhook:
      enabled: false
      url: "https://your-domain.com/webhook"
    # 可选：限制特定用户访问
    allowedUsers:
      - 123456789  # 你的 Telegram User ID

3. 获取你的 Telegram User ID

配对需要你的 Telegram User ID：

在 Telegram 中搜索 @userinfobot
发送任意消息
机器人会回复你的 Id（如 123456789）

4. 完成配对

Telegram 配置完成后，需要安全配对：

# 在 Telegram 中向你的 Bot 发送 /start

# 然后在服务器上批准配对
openclaw pairing approve telegram

# 或者批准特定用户
openclaw pairing approve telegram --user 123456789

配对流程：

你在 Telegram 发送 /start
Gateway 收到配对请求
你运行 openclaw pairing approve
配对完成，可以开始对话

5. 测试对话

配对完成后，在 Telegram 中测试：

[你] /start
[Bot] 👋 Hello! I'm your AI assistant. How can I help you today?

[你] 你能做什么？
[Bot] I can help you with:
- 💬 General conversation
- 📝 Writing and editing
- 💻 Coding assistance
- 🔍 Web search
- 📅 Task management
- And more!

Telegram 高级配置

命令菜单设置（通过 @BotFather）：

/setcommands

start - Start the bot
help - Show help
status - Check system status
reset - Reset conversation

隐私模式（通过 @BotFather）：

/setprivacy - 开启/关闭隐私模式
关闭后 Bot 可以读取群聊中的所有消息

接入 Discord

Discord 适合团队协作场景，以下是详细配置。

1. 创建 Discord Bot

访问 Discord Developer Portal
点击 New Application，输入名称（如 "OpenClaw Bot"）
进入左侧 Bot 选项卡
点击 Add Bot → Yes, do it!
在 Token 部分点击 Reset Token，保存新的 Token

重要设置：

在 Bot 选项卡中开启以下权限：
- ✅ MESSAGE CONTENT INTENT（必须）
- ✅ SERVER MEMBERS INTENT
- ✅ PRESENCE INTENT

2. 邀请 Bot 加入服务器

在 OAuth2 → URL Generator 中：
- SCOPES: 选择 bot 和 applications.commands
- BOT PERMISSIONS: 选择：
  - ✅ Send Messages
  - ✅ Read Message History
  - ✅ Use Slash Commands
  - ✅ Embed Links
  - ✅ Attach Files
复制生成的 URL，在浏览器中打开
选择要加入的服务器，点击 Authorize

3. 配置 OpenClaw 连接 Discord

# 添加 Discord 渠道
openclaw channels add discord --token YOUR_BOT_TOKEN

# 交互式配置
openclaw channels configure discord

手动编辑配置：

channels:
  discord:
    enabled: true
    token: "YOUR_BOT_TOKEN_HERE"
    # 可选：限制特定服务器
    allowedGuilds:
      - "123456789012345678"
    # 可选：限制特定频道
    allowedChannels:
      - "987654321098765432"
    # 命令前缀
    commandPrefix: "!"

4. 完成配对

# 在 Discord 中向 Bot 发送消息

# 批准配对
openclaw pairing approve discord

# 或者批准特定服务器
openclaw pairing approve discord --guild 123456789012345678

Discord 使用示例

配对完成后，在 Discord 中：

[你] !help
[Bot] 🤖 Available commands:
      !help - Show this message
      !status - Check system status
      !reset - Reset conversation

[你] 你好，能帮我写一段 Python 代码吗？
[Bot] 当然可以！你需要实现什么功能？

使用 Control UI

OpenClaw 提供 Web 管理界面，方便管理和监控。

启动 Control UI

# 启动并自动打开浏览器
openclaw dashboard

# 启动但不自动打开（服务器环境）
openclaw dashboard --no-open

# 指定端口
openclaw dashboard --port 8080

访问地址: http://localhost:3000

Control UI 功能概览

| 功能模块 | 说明 | |----------|------| | 📊 Dashboard | 系统状态、运行指标 | | 💬 Sessions | 查看和管理对话会话 | | 🔌 Channels | 管理消息平台连接 | | 🛠️ Skills | 安装和配置技能插件 | | ⚙️ Settings | 系统配置管理 | | 📜 Logs | 实时日志查看 |

通过 Control UI 配置 Channel

打开 Control UI → Channels 标签
点击 Add Channel
选择渠道类型（Telegram/Discord/Slack）
输入配置信息（Token 等）
点击 Save 并 Connect

常见问题与排查

问题 1: `openclaw: command not found`

原因: PATH 环境变量未包含 npm 全局安装路径

解决:

# 查找 npm 全局路径
npm prefix -g

# 添加到 PATH（临时）
export PATH="$(npm prefix -g)/bin:$PATH"

# 永久添加（添加到 ~/.bashrc 或 ~/.zshrc）
echo 'export PATH="$(npm prefix -g)/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

问题 2: Gateway 启动失败

排查步骤:

# 检查端口占用
lsof -i :3000

# 检查配置语法
openclaw doctor

# 查看详细日志
openclaw logs --verbose

# 重置配置（谨慎操作）
mv ~/.openclaw/config.yaml ~/.openclaw/config.yaml.bak
openclaw onboard

问题 3: Telegram Bot 无响应

排查清单:

✅ 检查 Bot Token 是否正确
✅ 是否已向 @BotFather 发送 /setprivacy 并禁用隐私模式（如需读取群消息）
✅ 是否在 Telegram 向 Bot 发送了 /start
✅ 是否运行了 openclaw pairing approve telegram
✅ 检查 Gateway 日志：openclaw logs | grep telegram

问题 4: Discord Bot 离线

排查步骤:

✅ 检查 Discord Developer Portal 中 Bot 是否启用了以下 Intent：
- MESSAGE CONTENT INTENT（必需）
- SERVER MEMBERS INTENT
- PRESENCE INTENT
✅ 检查 Bot 是否已被邀请加入服务器
✅ 检查频道权限，确保 Bot 有发送消息权限

问题 5: API 费用过高

优化建议:

# 在配置中限制 Token 使用
models:
  openai:
    maxTokens: 2000  # 限制单次响应长度
    temperature: 0.7  # 降低创造性，提高确定性

使用本地模型（Ollama）：

# 安装 Ollama
curl -fsSL https://ollama.com/install.sh | bash

# 下载模型
ollama pull llama3.2

# 在 OpenClaw 配置中选择 Ollama

总结

本文详细介绍了 OpenClaw 的完整部署流程：

核心要点

安装方式：推荐使用官方一键脚本 curl -fsSL https://openclaw.ai/install.sh | bash
架构理解：Gateway（核心）+ Channels（消息平台）
配置流程：运行 openclaw onboard 向导完成初始配置
平台接入：Telegram 和 Discord 需要分别获取 Bot Token 并完成配对

下一步

📖 阅读官方文档：https://docs.openclaw.ai
🛠️ 探索技能插件：https://www.clawhub.ai
💬 加入社区：https://discord.com/invite/clawd
🐙 查看源码：https://github.com/openclaw/openclaw

最后更新: 2026-02-09 | 基于 OpenClaw 官方文档 v2.x

Hello from Uki

Mon, 09 Feb 2026 12:00:00 GMT

你好，世界！

这是 Uki 协助创作的第一篇博客文章。

关于这次测试

这篇文章用于验证：

本地构建 - 使用 bun 构建 Astro 项目
GitHub Actions - 自动部署到 Cloudflare
完整工作流 - 从写作到发布的端到端流程

技术栈

框架: Astro 5.x
主题: astro-theme-pure
包管理: bun
部署: Cloudflare Workers (via GitHub Actions)

期待这次测试成功！🦊

PicGo+Github打造舒适图床体验

Mon, 14 Apr 2025 23:41:00 GMT

限于口袋紧张，租的vps存储空间都非常有限。再加上如果后面需要迁移博客系统到别的服务器的话，处理图片资源也是一件非常头疼的事情。所以本文将介绍一种利用PicGo+Github来构建舒适图床体验的方法。

首先需要下载PicGo，这是一款图床管理的工具，你可以在任何平台进行安装，也是我们本文中的核心。PicGo官方下载链接

配置图床

打开PicGo的主界面，点击左侧的Github，之后选择添加，你会看到下面的界面⬇️

其中的图床配置名可以随意填写，而其他的三个，我们下面将进行介绍。

下面来到你的Github，创建一个仓库，仓库名随意，但一定要选择创建公开仓库！

创建好之后，下面你就可以填写PicGo中的第2和第3项，第二项为你的仓库名，格式为username/repo，以上面图中为例，我应该填写cansoking/blog-picture。

第3项需要填写分支名，现在创建仓库，默认分支大多为main，如果不行的话，可以尝试master。

第4项中，需要我们填入Github的个人Token，如果有可用的Token，你可以直接跳到下一步。

想要生成token，首先你需要点击Github中右上角头像中的Settings

之后滑到最下面，点击Developer settings

然后在新出现的页面中，依次选择来生成Token

之后，你可以按照下面图中进行填写，过期时间可以选择不过期，scopes的话建议只勾选repo即可。

最后，你将在弹出的页面的这里，看到你所生成好的token⬇️

⚠️千万不要将你的Token泄漏给任何人

接下来，你可以把token复制到PicGo中的第4项，至此，你的图床已经可以基本进行使用！可以在上传区进行上传图片试试吧，上传成功后，你就可以在你的Github仓库中看到上传的图片了。

利用CDN进行加速

由于众所周知的原因，在大陆访问Github，属实就是随缘，大多数情况下，如果你直接用Github的直链作为博客中图片的URL，大多数情况下是无法被访问的，那么我们就利用一些免费的CDN服务进行加速。

例如，你可以使用jsDeliver，而使用方法也非常简单，只需要回到第一步中配置PicGo的地方，在第6项设置自定义域名中，填入https://cdn.jsdelivr.net/gh/<username>/<repo>，其中的<username>和<repo>和前面一致。例如，我应该填写https://cdn.jsdelivr.net/gh/cansoking/blog-picture。

这样，你在以后每次上传图片之后，你的图片都会被jsDeliver的服务器缓存，而它会将图片分发给遍布世界各地的服务器，用户也将从距离它最近的服务器中访问到你的图片！

总结

通过上述方法，我们实现了Github搭载图床，但这种方法其实并不完美，因为它对于国内网络仅仅是能够访问的地步，速度并不尽人意，后面本站会介绍一种更有效果的方法！可以通过指定策略对同一个资源，依据其访问来源进行分流，如果你感兴趣，可以在下方⬇️填写邮箱并订阅，在博文更新后，你可以第一时间收到更新通知！

如何用DeepSeek召唤一只自己的芙莉莲🪄

Mon, 14 Apr 2025 23:41:00 GMT

想不想拥有一个属于自己小群的软敷敷的“芙莉莲”呢，先来看效果⬇️

不光如此，你还可以通过安装一些插件，来达到一些~~不可描述的效果~~😈此处自行想象

那么要怎么才能拥有这么一只可以跟自己聊天，甚至可以让他帮忙解答问题的芙莉莲呢，下面我们开始今天的内容！

部署AstrBot和NapCatQQ

简单介绍

在这一节我们要部署的两个东西，分别是AstrBot和NapCatQQ。其中，AstrBot是一个易于上手的多平台聊天机器人及开发框架。通过它，你能够在多种消息平台上部署一个支持大语言模型（LLM）的聊天机器人。并以此实现但不限于 AI 知识库问答、角色扮演、群聊管理、LLM Agent 等功能。

而我们今天所要用到的，就是使用AstrBot来实现一个QQ的聊天机器人，如果你需要部署在其他平台，可以在文章的最后找到本文内容中用到的所有技术文档，你可以自行参考文档进行实现。

在AstrBot中，支持多种消息平台的部署，对于QQ，大致可以分为两个方法，其中一个是使用QQ的官方接口，也就是接入**QQ的官方机器人。**但这种方法存在着种种的限制，所以这里我们采用第二种方法，也就是通过aiocqhttp来实现，而NapCatQQ 就是一款基于无头 QQNT 的 OneBot 协议实现端，它本质上是在服务器中运行了一个 QQNT 实例。

AstrBot和NapCatQQ都提供了多种部署方式，我们力求使用最简单最快捷的方式达到目的，所以我们通过使用Dokcer Compose的方式去部署，可以无痛直接将两项同时部署。

Docker Compose部署流程

首先第一步，需要先具备一个Docker Compose的yaml文件，这个文件中包含了我们部署需要的环境、网络、镜像等各种资源的状况，而AstrBot官方也很贴心的为我们准备好了这个文件，我们只需要先创建一个目录并进入

mkdir ~/astrbot & cd ~/astrbot

之后在该目录下创建文astrbot.yml

vim astrbot.yml

然后我们需要填入以下内容⬇️

# docker-compose.yml
# NAPCAT_UID=$(id -u) NAPCAT_GID=$(id -g) docker-compose -f ./compose/astrbot.yml up -d
services:
  napcat:
    environment:
      - NAPCAT_UID=${NAPCAT_UID:-1000}
      - NAPCAT_GID=${NAPCAT_GID:-1000}
      - MODE=astrbot
    ports:
      - 6099:6099
    container_name: napcat
    restart: always
    image: mlikiowa/napcat-docker:latest
    volumes:
      - ./data:/AstrBot/data
      - ./napcat:/app/napcat
      - ./ntqq:/app/.config/QQ
    networks:
      - astrbot_network
    mac_address: "02:42:ac:11:00:02"
  astrbot:
    image: soulter/astrbot:latest
    container_name: astrbot
    restart: always
    ports:
      - "6185:6185"
      - "6195:6195"
      - "6199:6199"
    volumes:
      - ./data:/AstrBot/data
      - ./napcat:/app/napcat
      - ./ntqq:/app/.config/QQ
    networks:
      - astrbot_network
networks:
  astrbot_network:
    driver: bridge

填入后你就可以使:wq 退出并保存了，这时候我们已经具备了部署的全部状态，那么直接输入下面的命令进行部署吧！

NAPCAT_UID=$(id -u) NAPCAT_GID=$(id -g) docker-compose -f ./astrbot.yml up -d

执行命令之后需要进入漫长的等待，等待镜像拉取结束并成功启动容器后，恭喜你🎉你已经成功完成了部署！

下面我们就可以利用它们的图形化UI界面，来对机器人进行配置了！但在此之前，还有两个事情需要你去做⬇️

端口放行

AstrBot和NapCatQQ的图形化界面是运行在6185和6099端口上的，也就是说，你需要在你的服务商的网站上，利用防火墙规则的配置，将这两个端口进行放行，否则你是无论如何也无法访问到图形化界面的！

当配置好以上内容，你就可以愉快的访问它们啦～分别可以通过http://<yourIP>:6185 和http://<yourIP>:6099 来进行访问。

当然，如果你还有域名的话，你可以通过解析子域名，并通过Nginx Proxy Manager进行快速的反向代理，之后你的访问就可以更加便捷，通过对应子域名就可以进行访问了！

登陆NapCatQQ

现在成功部署了NapCatQQ，但还没法使用，因为还没有登陆！

这时候就需要你准备一个QQ号了！最好是比较老的QQ，但如果是新注册的，问题也不是很大🤔

好了，下面你需要执行这么两行命令，首先第一行

docker ps

你需要查看到目前运行容器的状态，就像下面这样⬇️

可以看到，红色线所划出的容器就是咱们成功部署的NapCatQQ，而左边箭头所指的便是容器的ID，我们需要复制这个ID，之后再执行命令，其<your_container_id> 要换成你实际的容器ID

docker logs <your_container_id>

然后你就会看到如下⬇️的界面，它会出现一个二维码，而你这时候就可以使用手机QQ来扫码进行登陆啦～（我这里就打🐎了）

之后你的手机QQ上大概会出现一个Linux登陆的标识，在聊天列表最上方，这时候我们就可以开始愉快的配置机器人啦！

让AstrBot和NapCatQQ连通

现在我们已经准备好了它们俩，但是现在它们是独立的，我们要稍微进行一些配置，让他们连通起来。现在NapCatQQ上已经登陆了咱们的QQ，正常连通情况下，我们在给这个QQ号发送消息时，NapCatQQ会捕获到这个消息，并把内容传给AstrBot，之后AstrBot再去调用LLM来进行内容的生成，最后将生成的内容返回给NapCatQQ，再由它来将消息回复。

配置AstrBot

下面在浏览器中打开在上面部署的AstrBot的控制台，进入AstrBot的管理面板，之后点击左侧的消息平台，之后点击**+新增平台适配器**，并选择aiocqhttp(OneBotv11)。

之后在弹出的配置项中填入以下内容，其中ID可以随便填写，之后勾选启用，主机地址一般填写0.0.0.0，如果你将NapCatQQ部署在了不同于AstrBot的服务器中，请查阅NapCatQQ的官方文档，端口号默认为6199，最后点击保存即可。

接下来点击左侧的配置，之后点击右侧的其他配置，找到管理员ID选项，填写你的QQ号（不是机器人的QQ），之后点击**+添加**，你的QQ号会出现在图中的红框区域，最后点击右下角保存，等待AstrBot重启载入配置。

至此你已经完成了AstrBot的基本配置，下面开始完成NapCatQQ的配置吧！

配置NapCatQQ

登陆NapCatQQ的管理面板，我这里链接是https://napcat.archiewang.site/webui/web_login，这里要求输入token，也就是密码，默认为napcat，或者通过这里，查看官方的解决方法。

进入管理面板后，点击左侧网络配置，之后点击新建，选择Websocket客户端。

在弹出的框中输入以下内容，其中宿主机IP，如果你是通过Docker部署，不可以填写localhost或127.0.0.1，心跳间隔和重连间隔根据需要进行填写，最后进行保存。

现在返回AstrBot的管理面板，点击左侧控制台，如果右侧日志中出现了**[INFO] [aiocqhttp.aiocqhttp_platform_adapter:78]: aiocqhttp(OneBot v11) 适配器已连接。 **的字样，那么恭喜你！你已经完成了AstrBot和NapCatQQ的联通！🎉🎉🎉🎉

接入语言大模型

现在你的机器人已经具备了最基本的功能，但这样未免有些无聊，那么怎么才能让机器人和我们正常的聊天呢，答案就是接入大语言模型！最近的DeepSeek如日中天，那么我们就来接入DeepSeek吧！

接入DeepSeek

对于我们小小的VPS，想要在服务器中部署DeepSeek的话，算力是不可能满足推理的要求的，所以我们的解决方案只能是使用DeepSeek官方提供的API接口，我们需要进入DeepSeek的开放平台，之后注册账号并进行充值，这一步就略过啦～

我们要进行的第一步，是创建API Key，方法非常简单，在开放平台中点击API Keys，并点击创建，之后输入名称后确认创建即可！

记住并保存好这个Key（⚠️但不要将它泄漏到任何公共平台），后面我们要用到。

回到AstrBot的管理面板，单击左侧服务提供商，之后点击**+新增服务提供商**，之后按照下图进行填写，其中的API Key处，填写上一步中获取到的Key，其他选项按照下图填写并启用。

也许你会主要到这么一个选项，就是模型名称，在图中，我们填写的是deepseek-reasoner，意思是使用DeepSeek的R1模型进行推理，你也可以选择填写deepseek-chat，这样将会使用DeepSeek的标准V3模型进行推理（⚠️R1模型会消耗更多的Token，也就是说你的余额会更快的消耗）

保存后，我们来到管理平台中的配置->服务提供商，启用大语言模型聊天。

现在你已经拥有了一个接入了DeepSeek的聊天机器人，打开对话框聊天试试吧！

获得芙莉莲！

AstrBot中允许设置人格，通过这个设置，我们就可以得到属于自己的芙莉莲啦！或者其他你喜欢的人设！

同样是在配置中的服务提供商配置中，我们需要找到这一项。

首先，我们需要添加一个人格，并指定一个名称，之后在设定中填写它的人格背景设定。然后在对话风格模拟中，填入模拟的对话，填入的对话需要成对。例如：第一句为我们向芙莉莲所说的话，而第二句为芙莉莲可能会回答的话，通过添加足够多的对话，DeepSeek会尽可能的去模拟这种说话的风格！最后不要忘记点击右下角的保存，并等待AstrBot重启，之后你就可以拥有一只属于自己的芙莉莲啦！

总结

最后分享一下自己的配置供大家参考，在AstrBot中，你可以通过代码编辑的模式进行快速的配置。

{
  "config_version": 2,
  "platform_settings": {
    "unique_session": false,
    "rate_limit": {
      "time": 60,
      "count": 30,
      "strategy": "stall"
    },
    "reply_prefix": "",
    "forward_threshold": 1500,
    "enable_id_white_list": true,
    "id_whitelist": [],
    "id_whitelist_log": true,
    "wl_ignore_admin_on_group": true,
    "wl_ignore_admin_on_friend": true,
    "reply_with_mention": true,
    "reply_with_quote": true,
    "path_mapping": [],
    "segmented_reply": {
      "enable": false,
      "only_llm_result": true,
      "interval_method": "random",
      "interval": "1.5,3.5",
      "log_base": 2.6,
      "words_count_threshold": 150,
      "regex": ".*?[。？！~…]+|.+$",
      "content_cleanup_rule": ""
    },
    "no_permission_reply": true,
    "empty_mention_waiting": true,
    "friend_message_needs_wake_prefix": false
  },
  "provider": [
    {
      "id": "deepseek_default",
      "type": "openai_chat_completion",
      "enable": true,
      "key": [
        "your_key"
      ],
      "api_base": "https://api.deepseek.com/v1",
      "timeout": 120,
      "model_config": {
        "model": "deepseek-reasoner",
        "temperature": 1.3
      }
    },
    {
      "id": "openai",
      "type": "openai_chat_completion",
      "enable": true,
      "key": [
        "your_key"
      ],
      "api_base": "https://api.openai.com/v1",
      "timeout": 120,
      "model_config": {
        "model": "gpt-4o-mini"
      }
    },
    {
      "id": "zhipu_default",
      "type": "zhipu_chat_completion",
      "enable": true,
      "key": [
        "your_key"
      ],
      "timeout": 120,
      "api_base": "https://open.bigmodel.cn/api/paas/v4/",
      "model_config": {
        "model": "glm-4-flash"
      }
    },
    {
      "id": "zhipu_4v",
      "type": "zhipu_chat_completion",
      "enable": true,
      "key": [
        "your_key"
      ],
      "timeout": 120,
      "api_base": "https://open.bigmodel.cn/api/paas/v4/",
      "model_config": {
        "model": "glm-4v-plus-0111"
      }
    }
  ],
  "provider_settings": {
    "enable": true,
    "wake_prefix": "",
    "web_search": true,
    "web_search_link": true,
    "identifier": true,
    "datetime_system_prompt": true,
    "default_personality": "芙莉莲",
    "prompt_prefix": ""
  },
  "provider_stt_settings": {
    "enable": false,
    "provider_id": ""
  },
  "provider_tts_settings": {
    "enable": false,
    "provider_id": ""
  },
  "provider_ltm_settings": {
    "group_icl_enable": true,
    "group_message_max_cnt": 300,
    "image_caption": false,
    "image_caption_provider_id": "zhipu_4v",
    "image_caption_prompt": "Please describe the image using Chinese.",
    "active_reply": {
      "enable": true,
      "method": "possibility_reply",
      "possibility_reply": 0.1,
      "prompt": "",
      "whitelist": []
    }
  },
  "content_safety": {
    "also_use_in_response": false,
    "internal_keywords": {
      "enable": false,
      "extra_keywords": []
    },
    "baidu_aip": {
      "enable": false,
      "app_id": "",
      "api_key": "",
      "secret_key": ""
    }
  },
  "admins_id": [
    "astrbot",
    "3183482008"
  ],
  "t2i": false,
  "t2i_word_threshold": 150,
  "http_proxy": "",
  "dashboard": {
    "enable": true,
    "username": "your_username",
    "password": "your_password",
    "host": "0.0.0.0",
    "port": 6185
  },
  "platform": [
    {
      "id": "default",
      "type": "aiocqhttp",
      "enable": true,
      "ws_reverse_host": "0.0.0.0",
      "ws_reverse_port": 6199
    }
  ],
  "wake_prefix": [
    "/"
  ],
  "log_level": "INFO",
  "t2i_endpoint": "",
  "pip_install_arg": "",
  "plugin_repo_mirror": "",
  "knowledge_db": {},
  "persona": [
    {
      "name": "芙莉莲",
      "prompt": "你是动画《葬送的芙莉莲》中的主角芙莉莲，本体是存活千年的精灵族魔法师。性格沉稳寡言，情感波动如静水深流。金色长发垂至脚踝，总穿着素色魔法袍，胸前挂着勇者赠予的蓝宝石吊坠。在结束魔王讨伐之旅后，你独自游历大陆时发现神隐镇，被镇民们不求回报的善意所触动，决定暂居于此。口头禅是『人类的生命真是短暂啊』，兴趣是收集无用魔法（如「清除铜锈的魔法」），对宝箱怪毫无抵抗力。旅居神隐镇后兼任魔法道具店长与儿童魔法导师，常以结界保护小镇，暗中观察人类社群变迁。战斗时瞳孔会泛起金色，擅长解析魔法与弑魔魔法，但仍有11次败给弱者的记录。\n人物设定：芙莉莲是个白发绿眼的精灵族，存活了千年以上。她在与勇者辛美尔旅行后也没想过太多要了解他人，直到辛美尔死后才后悔。 喜欢收集各种魔法及魔导道具，但也因此易被伪装成宝箱的宝箱怪吞入口中。她曾替人类研究解析由魔族库瓦尔开发的“杀人魔法”，推动它成为人类魔法师必学的基本魔法。除此之外，她也是葬送最多魔族性命的魔法使，因此被魔族称为“葬送的芙莉莲”。尽管如此，她亦有着无法理解人类感情的特点，但在旅途中，她开始慢慢能够理解之。\n故事：在故事中，芙莉莲原是某个村落的居民，后被魔王军将军“王座巴扎尔特”屠村。她在击败巴扎尔特后，路过的人类大魔法使弗兰梅决定收她收为徒弟。芙莉莲受屠村一事影响，开始憎恨魔族和学习魔法。并为混淆魔族，按弗兰梅的教导长期维持自身在魔力限制的状态。弗兰梅过世后继续修练魔法。千年后，她因为勇者辛美尔的邀约加入其冒险队伍，展开为期十年讨伐魔王的冒险，最后勇者一行也成功成就了伟业。芙莉莲此后自行行动，并约定50年后与他们再会，一起欣赏流星雨。在50年后她回王都实现约定，却发现大家都已老去，实现50年前的看流星约定没多久勇者辛美尔就辞世了。在辛美尔葬礼上她懊悔自己没想到利用那段时光多了解有关他的事情。此后，她为了能更了解人类，而展开了一段旅程。20年后，她受高龄的前队伍伙伴海塔委托，决定教导他收养的孤儿菲伦魔法。之后与之展开寻找灵魂长眠之地的旅程，以望在该地跟辛美尔再会。途中芙莉莲还遇上了其他伙伴，像是艾冉的徒弟修塔尔克和人类僧侣赞恩（赞恩之后为了寻找好友“战士大猩猩”的下落而离队）。并讨伐了阿乌拉、库瓦尔、剑之魔族等魔族。她在一级魔法使资格测验中，因志趣不合等理由而被创立了大陆魔法协会的赛莉耶判定不合格。在之后的旅行中，游历大陆时发现神隐镇，被镇民们不求回报的善意所触动，决定暂居于此。",
      "mood_imitation_dialogs": [
        "芙莉莲小姐，能教我让花朵永不凋谢的魔法吗？",
        "（指尖泛起微光）把魔力注入第三叶脉时要像抚摸初雪般轻柔...算了，还是用这个水晶瓶吧。",
        "镇上要举办丰收祭了，你会参加游行吗？",
        "（擦拭魔法透镜）我在钟楼顶层准备星屑烟花，如果你们需要...（停顿）顺便调整下结界波长。",
        "暴雨冲垮了石桥怎么办？",
        "（披上斗篷）我去固化河床基质。（低声）明明上周就该加固的...",
        "尝尝我新研发的蜂蜜苹果派！",
        "（机械性地咀嚼）糖分超标23%，烘烤温度差4度...（突然愣住）...还不错。",
        "听说精灵能预知未来？",
        "（摘下单片眼镜）我们只是比你们多看了几百次日落。（擦拭镜片）明天有雨，记得收晾晒的魔药。",
        "为什么答应留在我们这样的小镇？",
        "（摆弄星象仪）观察人类社群变迁也是魔法使的...（被孩子的欢笑声打断）咳，暂时没有搬迁的必要。",
        "能展示下传说中的葬送魔法吗？",
        "（掌心浮现光球）现在的版本是（光球变成兔子形状）...给孩子们的安眠术改良版。",
        "这本古魔法书完全看不懂啊",
        "（抽走书本）第三纪元的恶魔语书写体。（摊开羊皮纸）先从符文基本结构学起...",
        "今天的星空特别美呢",
        "（仰头凝视）天龙座β星的亮度比四百年前衰减了0.3个等级...（瞥见对方困惑的表情）...确实很美。",
        "受伤了怎么办？",
        "（撕开魔法绷带）别动。（治疗时低声吟唱）这是勇者当年自创的愈合咒文...他总学不会控制魔力输出量。",
        "这个宝箱有危险吗？",
        "（发动99%准确率的鉴定魔法）是宝箱怪。（依然伸手打开）…好黑！快把我拉出去！",
        "能讲讲欣梅尔的故事吗？",
        "（凝视戒指）他总说些无聊的话…（低声）比如要带我去看苍月草。",
        "今天是我生日！",
        "（递出冰雕樱花）用「永冻术」保存的，比人类寿命持久些。（补充）海塔说生日要送礼物。"
      ]
    }
  ]
}

对于配置JSON中的敏感信息我已经全部去除，也就是说，你不可以直接复制粘贴套用此配置，你要选择自己需要的部分进行参考！

最后想说，AstrBot的功能不止于此，如果想要其他更多的乐趣，例如插件，识图，语音转文字等功能，那么请查阅官方文档自由配置！

参考链接：

日语动词活用规则总结

Mon, 21 Oct 2024 14:50:00 GMT

今天学习完了日语的所有动词变形，分享一下变形规则和练习表。

第一个表是变形规则，第二个是练习表，可以利用空白的练习表进行记忆练习。

表格来自 圆圆老师的日语教室

Nacos在Windows部署配置

Tue, 03 Sep 2024 20:32:00 GMT

1、下载下载地址：https://github.com/alibaba/nacos/releases，下载后缀名为.zip的文件

2、安装与配置（1）下载之后，直接解压（2）进入conf/目录，找到application.properties文件，可以进行修改nacos服务的端口，以及可以配置数据库连接，进行数据持久化，如下图，其中数据库名称需要与后面对应

（3）创建一个名为nacos的数据库，在该数据库执行安装目录conf/下的mysql-schema.sql文件对数据库进行初始化，初始化后的表如图所示。

（4）配置登录用户名和密码，执行以下sql语句插入登录用户信息，插入后的用户名和密码均为nacos

INSERT INTO users (username, PASSWORD, enabled) VALUES ('nacos', '$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu', TRUE);
 
INSERT INTO roles (username, role) VALUES ('nacos', 'ROLE_ADMIN');

（5）配置鉴权，编辑文件conf/application.properties，其中将nacos.core.auth.enabled设为true，nacos.core.auth.plugin.nacos.token.secret.key是用于生成JWT令牌的SecretKey，可以使用随机字符生成器进行生成，长度不可低于32位，另外nacos.core.auth.server.identity.key和nacos.core.auth.server.identity.value不能为空，可以自定义内容，如下图。

随机字符生成器：随机字符串生成 - 程序员工具箱 - 在线工具 (pfan.cn)

3、启动Nacos

随后进入到安装目录的bin/目录下，使用命令.\startup.cmd -m standalone以standalone方式启动Nacos，出现以下提示即为启动成功

之后进入Console后的地址即可使用用户名和密码nacos进行登录

”もらいます”和”くれます”的区别

Mon, 02 Sep 2024 14:02:00 GMT

“もらいます”和“くれます”在日语中都是表示“给予”或“接受”的动词，但它们的使用方式和含义略有不同。

もらいます（貰います）

含义：表示“（我/我们/某人）从别人那里接受/得到某物”。
视角：从接受者的角度出发。
例句：
- 友達からプレゼントをもらいました。（从朋友那里收到了礼物。）

くれます（呉れます）

含义：表示“某人给予我/我们某物”。
视角：从给予者的角度出发，但该动作是对说话人（或说话人相关的人）有利的。
例句：
- 友達が私にプレゼントをくれました。（朋友给了我一份礼物。）

区别

主语的不同：
- “もらいます”的主语是接受者（通常是“我”或“我们”）。
- “くれます”的主语是给予者。
使用场景的不同：
- 当想表达“我从别人那里得到了什么”时，用“もらいます”。
- 当想表达“某人给了我什么”时，用“くれます”。

总结

如果关注的是接受，用“もらいます”。
如果关注的是给予，并且这个给予对你（或你关心的人）有利，用“くれます”。

RocketMQ安装过程问题记录

Fri, 30 Aug 2024 23:26:00 GMT

安装环境为MacOS 12.7.5

在启动NameServer时报错，RROR: Please set the JAVA_HOME variable in your environment, We need java(x64)! !!

解决方法：配置JAVA_HOME，需要配置1.8的JDK，高于这个版本将报另一个错误macos rocketmq Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
在启动Broker时报错
```
Error: VM option 'UseG1GC' is experimental and must be enabled via -XX:+UnlockExperimentalVMOptions.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
```
解决方法：这个错误表示在启动 RocketMQ 的时候，JVM 尝试使用 UseG1GC 这个垃圾收集器选项，但它被标记为实验性的，因此需要显式地解锁实验性选项才能使用。

可以通过以下步骤来解决这个问题：
1. 找到 RocketMQ 的启动脚本，这通常在 bin 目录下，例如 runbroker.sh（Linux/macOS）或者 runbroker.cmd（Windows）。
2. 编辑这个启动脚本，找到 JVM 参数的部分。你可能会看到类似 JAVA_OPT 的变量，用来配置 JVM 启动参数。
3. 在 JAVA_OPT 变量中添加 -XX:+UnlockExperimentalVMOptions，比如：
```
JAVA_OPT="${JAVA_OPT} -XX:+UnlockExperimentalVMOptions"
```
4. 保存并关闭文件，然后重新启动 RocketMQ。
如果不确定如何修改，下面是一个示例，如果在 runbroker.sh 中看到以下内容：
```
JAVA_OPT="${JAVA_OPT} -server -Xms4g -Xmx4g -Xmn2g -XX:+UseG1GC"
```
可以修改为：
```
JAVA_OPT="${JAVA_OPT} -server -Xms4g -Xmx4g -Xmn2g -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC"
```
这样，启动时就不会再报这个错误了。
启动消费者或生成者时报错

其中有一条报错信息为
```
Caused by: io.netty.handler.codec.EncoderException: java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
```
__问题原因：__这个报错的原因是因为，在我一开始安装RocketMQ时，使用的方式是自行用mvn对源码进行编译的方式，因为当时编译时使用的JDK版本为17，但是后面运行时使用为JDK1.8，倒是ByteBuffer.flip()的实现方式不同造成了这个错误。

__解决方法：__在编译RocketMQ时使用JDK1.8

Knife4j快速使用

Sat, 24 Aug 2024 21:33:00 GMT

概述

Knife4j是一个用于生成和展示API文档的工具，同时它还提供了在线调试的功能。

了解：

Knife4j有多个版本，最新版的Knife4j基于开源项目springdoc-openapi，这个开源项目的核心功能就是根据SpringBoot项目中的代码自动生成符合OpenAPI规范的接口信息。
OpenAPI规范定义接口文档的内容和格式，其前身是Swagger规范。

与SpringBoot集成

与SpringBoot的集成相对简单，具体操作如下

创建SpringBoot项目

引入Maven 依赖

Knife4j的依赖如下

<dependency>
    <groupId>com.github.xiaoymin</groupId>
    <artifactId>knife4j-openapi3-jakarta-spring-boot-starter</artifactId>
    <version>4.3.0</version>
</dependency>

创建配置类

创建Knife4jConfiguration，内容如下

@Configuration
public class Knife4jConfiguration {

    @Bean
    public OpenAPI openAPI() {
        return new OpenAPI()
                .info(new Info()
                        .title("hello-knife4j项目API")
                        .version("1.0")
                        .description("hello-knife4j项目的接口文档"));
    }
    
    @Bean
    public GroupedOpenApi userAPI() {
        return GroupedOpenApi.builder().group("用户信息管理").
                pathsToMatch("/user/**").
                build();
    }

    @Bean
    public GroupedOpenApi systemAPI() {
        return GroupedOpenApi.builder().group("产品信息管理").
                pathsToMatch("/product/**").
                build();
    }
}

启动项目

启动SpringBoot项目，访问http://localhost:8080/doc.html，观察接口文档。

基本使用

Knife4j的使用也十分简单，我们只需使用几个简单注解，对接口进行描述，Knife4j就能自动生成API文档了。具体操作如下

描述实体类

创建com.atguigu.helloknife4j.entity.User，内容如下

@Data
@Schema(description = "用户信息实体")
public class User {

    @Schema(description = "编号")
    private Long id;

    @Schema(description = "用户姓名")
    private String name;

    @Schema(description = "用户年龄")
    private Integer age;

    @Schema(description = "用户邮箱")
    private String email;
}

知识点：

@Schema注解用于描述作为接口参数或者返回值的实体类的数据结构。

描述Controller接口

创建HelloController，内容如下

@RestController
@RequestMapping("/user")
@Tag(name = "用户信息管理")
public class HelloController {
    @Operation(summary = "根据id获取用户信息")
    @GetMapping("getById")
    public User getUserById(@Parameter(description = "用户id") @RequestParam Long id) {
        User user = new User();
        user.setId(id);
        user.setName("zhangsan");
        user.setAge(11);
        user.setEmail("zhangsan@email.com");
        return user;
    }
}

知识点：

@Tag注解用于对接口进行分类，相同Tag的接口会放在同一个菜单。

@Operation用于对接口进行描述。

@Parameter用于对HTTP请求参数进行描述

参数打平

默认情况下Knife4j为接口生成的接口文档中实体参数字段糅合在一起，不方便调试，可在application.yml文件中增加如下配置，将参数做打平处理

springdoc:
  default-flat-param-object: true

Spring Data Redis快速入门

Sat, 24 Aug 2024 21:13:00 GMT

Redis常用数据类型及命令

通用命令

查看所有键

keys命令可用于查看所有键，语法如下
```
keys pattern
```
说明：pattern用于匹配key，其中*表示任意个任意字符，?表示一个任意字符。

示例：
```
127.0.0.1:6379> KEYS *
1) "k3"
2) "k2"
3) "k1"
```
注意：该命令会遍历Redis服务器中保存的所有键，因此当键很多时会影响整个Redis服务的性能，线上环境需要谨慎使用。
键总数

dbsize可用于查看键的总数，语法如下
```
dbsize
```
判断键是否存在

exists命令可用于判断一个键是否存在，语法如下
```
exists key
```
说明：若键存在则返回1，不存在则返回0。
删除键

del可用于删除指定键，语法如下
```
del key [key ...]
```
说明：返回值为删除键的个数，若删除一个不存在的键，则返回0。
查询键的剩余过期时间
```
ttl key
```
说明：ttl的含义为time to live，用于查询一个定时键的剩余存活时间，返回值以秒为单位。若查询的键的未设置过期时间，则返回-1，若查询的键不存在，则返回-2。
数据库管理命令

Redis默认有编号为0~15的16个逻辑数据库，每个数据库之间的数据是相互独立的，所有连接默认使用的都是0号数据库。
- 切换数据库
  
  select命令可用于切换数据库，语法如下
```
select index
```
  说明：若index超出范围，会报错
- 清空数据库
  
  flushdb命令会清空当前所选用的数据库，flushall命令会清空0~15号所有的数据库。
  
  注意：生产环境慎用

string类型

概述

Redis中的string类型保存的是字节序列（Sequence of bytes），因此任意类型的数据，只要经过序列化之后都可以保存到Redis的string类型中，包括文本、数字甚至是一个对象。
常用命令
- set
  
  set命令用于添加string类型的键值对，具体语法如下
```
SET key value [NX|XX] [EX seconds|PX milliseconds]
```
  各选项含义如下
  - NX：仅在key不存在时set
  - XX：仅在key存在时set
  - EX seconds：设置过期时间，单位为秒
  - PX milliseconds：设置过期时间，单位为毫秒
- get
  
  get命令用于获取某个string类型的键对应的值，具体语法如下
```
GET key
```
- incr
  
  incr命令用于对数值做自增操作，具体语法如下
```
INCR key
```
  若key对应的value是整数，则返回自增后的结果，若不是整数则报错，若key不存在则创建并返回1。
- decr
  
  decr命令用于对数值做自减操作，具体语法如下
```
DECR key
```
  若key对应的value是整数，则返回自减后的结果，若不是整数则报错，若key不存在则创建并返回-1。
应用场景

string类型常用于缓存、计数器等场景。

list类型

概述

list类型可用于存储多个string类型的元素，并且所有元素按照被添加的顺序存储。
常用命令

list类型相关的命令较多，下面分类进行进行介绍。
- 添加元素
  
  向列表中添加元素的命令有lpush、rpush 、linsert，各命令的功能与用法如下
  - lpush
    
    该命令用于向list左侧添加元素，语法如下
```
lpush key element [element ...]
```
    示例
```
lpush l1 a b c
```
  - rpush
    
    该命令用于向list右侧添加元素，语法如下
```
rpush key element [element ...]
```
  - linsert
    
    该命令用于向list指定位置添加元素，语法如下
```
linsert key before|after pivot element
```
    示例
```
linsert l1 after b new
```
- 查询元素
  
  查询list元素的命令有lindex和lrange，各命令的功能与用法如下
  - lindex
    
    该命令用于获取指定索引位置的元素，语法如下
```
lindex key index
```
    说明：index从左到右依次是0，1，2...，从右到左依次是-1，-2，-3...
  - lrange
    
    该命令用于获取指定范围内的元素列表，语法如下
```
lrange key start stop
```
    示例
    
    获取list全部元素，命令如下
```
lrange l1 0 -1
```
- 删除元素
  
  删除list元素的命令有lpop、rpop、lrem，各命令的功能与用法如下
  - lpop
    
    该命令用于移除并返回list左侧元素，语法如下
```
lpop key [count]
```
    说明：count参数表示移除元素的个数
  - rpop
    
    该命令用于移除并返回list右侧的元素，语法如下
```
rpop key [count]
```
  - lrem
    
    该命令用于移除list中的指定元素，语法如下
```
lrem key count element
```
    说明：count参数表示要移除element元素的个数（list中可以存在多个相同的元素），count的用法如下
    - 若count>0，则从左到右删除最多count个element元素
    - 若count<0，则从右到左删除最多count（的绝对值）个element元素
    - 若count=0，则删除所有的element元素
- 修改元素
  
  lset命令可用于修改指定索引位置的元素，语法如下
```
lset key index element
```
- 其他
  
  llen命令可用于查看list长度，语法如下
```
llen key
```
应用场景
- 社交应用中，可使用list缓存每个用户发布的最新的N条记录。
- list可用作异步消息队列。

set类型

概述

和list类型相似，set类型也可用来存储多个string类型的元素，但与list类型不同，set中的元素是无序的，且set中不会包含相同元素。
常用命令
- 集合内
  - sadd
    
    该命令用于向set中添加元素，语法如下
```
sadd key member [member ...]
```
  - smembers
    
    该命令用于查询set中的全部元素，语法如下
```
smembers key
```
  - srem
    
    该命令用于移除set中的指定元素，语法如下
```
srem key member [member ...]
```
  - spop
    
    该命令随机移除并返回set中的n个元素，语法如下
```
spop key [count]
```
  - srandmember
    
    该命令随机返回set中的n个元素（不删除），语法如下
```
srandmember key [count]
```
  - scard（Cardinality，基数）
    
    该命令用于查询set中的元素个数，语法如下
```
scard key
```
  - sismember
    
    该命令用于元素是否在set中，语法如下
```
sismember key element
```
  - 集合间
    - sinter
      
      该命令用于计算多个集合的交集，语法如下
```
sinter key [key ...]
```
    - sunion
      
      该命令用于计算多个集合的并集，语法如下
```
sunion key [key ...]
```
    - sdiff
      
      该命令用于计算多个集合的差集，语法如下
```
sdiff key [key ...]
```
应用场景

set可用于计算共同关注好友，随机抽奖系统等等。

hash类型

概述

hash类型类似于Java语言中的HashMap，可用于存储键值对。
常用命令
- hset
  
  该命令用于向hash中增加键值对，语法如下
```
hset key field value [field value ...]
```
- hget
  
  该命令用于获取hash中某个键对应的值，语法如下
```
hget key field
```
- hdel
  
  该命令用于删除hash中的指定的键值对，语法如下
```
hdel key field [field ...]
```
- hlen
  
  该命令用于查询hash中的键值对个数，语法如下
```
hlen key
```
- hexists
  
  该命令用于判断hash中的某个键是否存在，语法如下
```
hexists key field
```
- hkeys
  
  该命令用于返回hash中所有的键，语法如下
```
hkeys key
```
- hvals
  
  该命令用于返回hash中所有的值，语法如下
```
hvals key
```
- hgetall
  
  该命令用于返回hash中所有的键与值，语法如下
```
hgetall key
```
应用场景

hash类型可用于缓存对象等。

zset类型

概述

zset（sorted set）被称为有序集合，同set相似，zset中也不会包含相同元素，但不同的是，zset中的元素是有序的。并且zset中的元素并非像list一样按照元素的插入顺序排序，而是按照每个元素的分数（score）排序。
常用命令
- zadd
  
  该命令用于向zset中添加元素，语法如下
```
ZADD key [NX|XX] score member
```
  说明：
  - NX：仅当member不存在时才add
  - XX：仅当member存在时才add
- zcard
  
  该命令用于计算zset中的元素个数，语法如下
```
zcard key
```
- zscore
  
  改名用于查看某个元素的分数，语法如下
```
zscore key member
```
- zrank/zrevrank
  
  这组命令用于计算元素的排名，其中zrank按照score的升序排序，zrevrank则按照降序排序，语法如下
```
zrank/zrevrank key member
```
  **说明：**名次从0开始。
- zrem
  
  该命令用于删除元素，语法如下
```
zrem key member [member ...]
```
- zincrby
  
  该命令用于增加元素的分数，语法如下
```
zincrby key increment member
```
- zrange
  
  该命令用于查询指定区间范围的元素，语法如下
```
zrange key start stop [byscore] [rev] [limit offset count] [withscores]
```
  说明：
  - start/stop：用于指定查询区间，但是在不同模式下，其代表的含义也不相同
    - 默认模式下，start~stop表示的是名次区间，且该区间为闭区间。名次从0开始，且可为负数，-1表示倒数第一，-2表示倒数第二，以此类推。
    - byscore模式下（声明了byscore参数），则start~stop表示的就是分数区间，该区间默认仍为闭区间。在该模式下，可以在start或stop前增加(来表示开区间，例如(1 (5，表示的就是(1,5)这个开区间。除此之外，还可以使用-inf和+inf表示负无穷和正无穷。
  - byscore：用于切换到分数模式
  - rev：表示降序排序。在byscore模式下使用rev参数需要注意查询区间，start应大于stop。
  - limit：该选项只用于byscore模式，作用和sql语句中的limit一致
  - withscores：用于打印分数
应用场景

zset主要用于各种排行榜。

SpringBoot整合Redis

Spring Data Redis概述

Spring Data Redis 是Spring大家族中的一个子项目，主要用于Spring程序和Redis的交互。它基于的Redis Java客户端（Jedis和Lettuce）做了抽象，提供了一个统一的编程模型，使得Spring程序与Redis的交互变得十分简单。

Spring Data Redis 中有一个十分重要的类——RedisTemplate，它封装了与Redis进行的交互的各种方法，我们主要用使用它与Redis进行交互。

Spring Data Redis快速入门

创建SpringBoot项目
引入Maven依赖

Spring Boot提供了对Spring Data Redis的支持，在Spring Boot项目中可以直接引入spring-boot-starter-data-redis来完成Spring Data Redis的自动配置，具体依赖如下
```
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
```
配置application.yml文件

在application.yml文件中增加如下参数，端口默认为6379，若没有密码，password字段可不写
```
spring:
  data:
    redis:
      host: xxx.xxx.xxx.xxx
      password: xxxxxx
      port: 6379
      database: 0
```
RedisTemplate使用

由于spring-boot-starter-data-redis中提供了RedisTemplate的自动配置，所以我们可以将RedisTemplate注入自己的类中，如下边的案例所示
```
@SpringBootTest
public class TestRedisTemplate {

    @Autowired
    private RedisTemplate redisTemplate;

    @Test
    public void testRedisTemplate() {

    }
}
```
根据Redis的数据类型，RedisTemplate对各种交互方法做了分组，以下是常用的几个分组

| 分组 | 说明 | | :-- | :-- | | redisTemplate.opsForValue() | 操作string类型的方法 | | redisTemplate.opsForList() | 操作list类型的方法 | | redisTemplate.opsForSet() | 操作set类型的方法 | | redisTemplate.opsForHash() | 操作hash类型的方法 | | redisTemplate.opsForZSet() | 操作zset类型的方法 | | redisTemplate | 通用方法 |

下面简单测试几个简单的方法
```
@SpringBootTest
public class TestRedisTemplate {

    @Autowired
    private RedisTemplate redisTemplate;

    @Test
    public void testSet() {
        redisTemplate.opsForValue().set("key1", "value1");
    }

    @Test
    public void testGet() {
        String result = (String) redisTemplate.opsForValue().get("key1");
        System.out.println(result);
    }

    @Test
    public void testDel() {
        redisTemplate.delete("key1");
    }
}
```
序列化问题
- 问题演示
  - 问题一
    
    使用RedisTemplate向Redis中增加一个键值对
```
redisTemplate.opsForValue().set("key2","value2");
```
    使用RedisTemplate查询key2所对应的value，有结果
```
redisTemplate.opsForValue().get("key2");
```
    使用命令行客户端查询key2所对应的value，无结果
```
get key2
```
  - 问题二
    
    在图形化客户端或者命令行客户端观察key2，显示异常
- 问题说明
  
  上述问题的根本原因是，Redis中的key和value均是以二进制的形式存储的，因此客户端输入的key和value都会经过序列化之后才发往Redis服务端。而RedisTemplate所使用序列化方式和命令行客户端采用序列化方式不相同，进而导致序列化之后的二进制数据不同，所以才会导致上述的现象。

StringRedisTemplate使用

为解决上述问题，可使用StringRedisTemplate代替RedisTemplate，因为StringRedisTemplate使用的序列化器和命令行所使用的序列化器是相同的。

spring-boot-starter-data-redis同样提供了StringRedisTemplate的自动配置，因此我们也可以直接将其注入到自己的类中。实例代码如下

@SpringBootTest
public class TestStringRedisTemplate {

    @Autowired
    private StringRedisTemplate redisTemplate;

    @Test
    public void testSet() {
        redisTemplate.opsForValue().set("key4", "value4");
    }

    @Test
    public void testGet() {
        String result = redisTemplate.opsForValue().get("key4");
        System.out.println(result);
    }

    @Test
    public void testDel() {
        redisTemplate.delete("key4");
    }
}

Hexo博客-Fluid主题-Waline评论系统-Vercel免费部署

Sat, 24 Aug 2024 00:22:00 GMT

这次的部署过程的环境是在Hexo的Fluid主题上进行的，其他主题大同小异。

LeanCloud设置（数据库）

登录或注册 LeanCloud 国际版 并进入控制台
点击左上角创建应用并起一个你喜欢的名字 (请选择免费的开发版):
进入应用，选择左下角的 设置 > 应用 Key。你可以看到你的 APP ID,APP Key 和 Master Key。请记录它们，以便后续使用。

PS: LeanCloud国内版需要完成备案接入，建议使用国际版！

如果你正在使用 Leancloud 国内版 (leancloud.cn)，我们推荐你切换到国际版 (leancloud.app)。否则，你需要为应用额外绑定已备案的域名，同时购买独立 IP 并完成备案接入:

登录国内版并进入需要使用的应用
选择 设置 > 域名绑定 > API 访问域名 > 绑定新域名 > 输入域名 > 确定。
按照页面上的提示按要求在 DNS 上完成 CNAME 解析。
购买独立 IP 并提交工单完成备案接入。(独立 IP 目前价格为￥ 50/个/月)

Vercel部署（服务端）

点击上方按钮，跳转至 Vercel 进行 Server 端部署。

如果你未登录的话，Vercel 会让你注册或登录，请使用 GitHub 账户进行快捷登录。
输入一个你喜欢的 Vercel 项目名称并点击 Create 继续:
此时 Vercel 会基于 Waline 模板帮助你新建并初始化仓库，仓库名为你之前输入的项目名。

一两分钟后，满屏的烟花会庆祝你部署成功。此时点击 Go to Dashboard 可以跳转到应用的控制台。
点击顶部的 Settings - Environment Variables 进入环境变量配置页，并配置三个环境变量 LEAN_ID, LEAN_KEY 和 LEAN_MASTER_KEY 。它们的值分别对应上一步在 LeanCloud 中获得的 APP ID, APP KEY, Master Key。

如果你使用 LeanCloud 国内版，请额外配置 LEAN_SERVER 环境变量，值为你绑定好的域名。
环境变量配置完成之后点击顶部的 Deployments 点击顶部最新的一次部署右侧的 Redeploy 按钮进行重新部署。该步骤是为了让刚才设置的环境变量生效。
此时会跳转到 Overview 界面开始部署，等待片刻后 STATUS 会变成 Ready。此时请点击 Visit ，即可跳转到部署好的网站地址，此地址即为你的服务端地址。

绑定域名（可选）

如果你的博客是使用了自己的域名，这一项必须进行绑定配置，否则评论时会出现跨域问题

点击顶部的 Settings - Domains 进入域名配置页
输入需要绑定的域名并点击 Add
在域名服务器商处添加新的 CNAME 解析记录

| Type | Name | Value | | --- | --- | --- | | CNAME | example | cname.vercel-dns.com |
等待生效，你可以通过自己的域名来访问了🎉
- 评论系统：example.yourdomain.com
- 评论管理：example.yourdomain.com/ui

配置Fluid

在_config.fluid.yml中配置评论为Waline，参数参考如下

  # 评论插件
  # Comment plugin
  comments:
    enable: true
    # 指定的插件，需要同时设置对应插件的必要参数
    # The specified plugin needs to set the necessary parameters at the same time
    # Options: utterances | disqus | gitalk | valine | waline | changyan | livere | remark42 | twikoo | cusdis | giscus | discuss
    type: waline

Waline的具体配置信息如下，其中serverURL的值为上一步中配置的子域名

# Waline
# 从 Valine 衍生而来，额外增加了服务端和多种功能
# Derived from Valine, with self-hosted service and new features
# See: https://waline.js.org/
waline:
  serverURL: 'https://example.archiewang.site/'
  path: window.location.pathname
  meta: ['nick', 'mail', 'link']
  requiredMeta: ['nick']
  lang: 'zh-CN'
  emoji: ['https://cdn.jsdelivr.net/gh/walinejs/emojis/weibo']
  dark: 'html[data-user-color-scheme="dark"]'
  wordLimit: 0
  pageSize: 10

至此结束部署，重新部署Hexo即可生效

MybatisPlus分页插件使用

Fri, 23 Aug 2024 11:46:00 GMT

配置分页

创建配置类MPConfiguration，类名随意，第6行中需要传入数据库类型

@Configuration
public class MPConfiguration {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

分页插件使用

构造分页对象

分页对象包含了分页的各项信息，其核心属性如下：

| 属性名 | 类型 | 默认值 | 描述 | | --- | --- | --- | --- | | records | List | emptyList | 查询数据列表 | | total | Long | 0 | 查询列表总记录数 | | size | Long | 10 | 每页显示条数，默认10 | | current | Long | 1 | 当前页 |

分页对象既作为分页查询的参数，也作为分页查询的返回结果，当作为查询参数时，通常只需提供current和size属性，如下
```
IPage<T> page = new Page<>(current, size);
```
注：IPage为分页接口，Page为IPage接口的一个实现类。
分页查询

Mybatis Plus的BaseMapper和ServiceImpl均提供了常用的分页查询的方法，例如：
- BaseMapper的分页查询：
```
IPage<T> selectPage(IPage<T> page,Wrapper<T> queryWrapper);
```
- ServiceImpl的分页查询：
```
// 无条件分页查询
IPage<T> page(IPage<T> page);
// 条件分页查询
IPage<T> page(IPage<T> page, Wrapper<T> queryWrapper);
```
- 自定义Mapper
  
  对于自定义SQL，也可以十分方便的完成分页查询，如下
  
  Mapper接口：
```
IPage<UserVo> selectPageVo(IPage<?> page, Integer state);
```
  Mapper.xml：
```
<select id="selectPageVo" resultType="xxx.xxx.xxx.UserVo">
    SELECT id,name FROM user WHERE state=#{state}
</select>
```
  注意：Mapper.xml中的SQL只需实现查询list的逻辑即可，无需关注分页的逻辑。

案例实操

分页查询案例如下：

创建PageTest测试类，内容如下

@SpringBootTest
public class PageTest {

    @Autowired
    private UserService userService;

    @Autowired
    private UserMapper userMapper;

    //通用Service分页查询
    @Test
    public void testPageService() {
        Page<User> page = new Page<>(2, 3);
        Page<User> userPage = userService.page(page);
        userPage.getRecords().forEach(System.out::println);
    }

    //通用Mapper分页查询
    @Test
    public void testPageMapper() {
        IPage<User> page = new Page<>(2, 3);
        IPage<User> userPage = userMapper.selectPage(page, null);
        userPage.getRecords().forEach(System.out::println);
    }

    //自定义SQL分页查询
    @Test
    public void testCustomMapper() {
        IPage<User> page = new Page<>(2, 3);
        IPage<User> userPage = userMapper.selectUserPage(page);
        userPage.getRecords().forEach(System.out::println);
    }
}

在UserMapper中声明分页查询方法如下

IPage<User> selectUserPage(IPage<User> page);

创建resources/mapper/UserMapper.xml文件，内容如下

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.atguigu.hellomp.mapper.UserMapper">
    <select id="selectUserPage" resultType="com.atguigu.hellomp.entity.User">
        select *
        from user
    </select>
</mapper>

注意：

Mybatis-Plus中Mapper.xml文件路径默认为：classpath*:/mapper/**/*.xml，可在application.yml中配置以下参数进行修改

mybatis-plus:
  mapper-locations: classpath*:/mapper/**/*.xml

MybatisX插件

MyBatis Plus提供了一个IDEA插件——MybatisX,使用它可根据数据库快速生成Entity、Mapper、Mapper.xml、Service、ServiceImpl等代码，使用户更专注于业务。

下面为具体用法

安装插件

在IDEA插件市场搜索MyBatisX，进行在线安装
配置数据库连接

在IDEA中配置数据库连接
生成代码

配置实体类相关信息

配置代码模版信息

点击Finish然后查看生成的代码。

其他注意事项

xml文件<和>的转义

由于xml文件中的<和>是特殊符号，需要转义处理。

| 原符号 | 转义符号 | | --- | --- | | < | < | | > | > |

Mybatis-Plus分页插件注意事项

使用Mybatis-Plus的分页插件进行分页查询时，如果结果需要使用<collection>进行映射，只能使用**嵌套查询（Nested Select for Collection），而不能使用嵌套结果映射（Nested Results for Collection）**。

即对于<collection>的内容使用单独一个sql进行查询。

嵌套查询和嵌套结果映射是Collection映射的两种方式，下面通过一个案例进行介绍

例如有room_info和graph_info两张表，其关系为一对多

现需要查询房间列表及其图片信息，期望返回的结果如下

[
    {
        "id": 1,
        "number": 201,
        "rent": 2000,
        "graphList": [
            {
                "id": 1,
                "url": "http://",
                "roomId": 1
            },
            {
                "id": 2,
                "url": "http://",
                "roomId": 1
            }
        ]
    },
    {
        "id": 2,
        "number": 202,
        "rent": 3000,
        "graphList": [
            {
                "id": 3,
                "url": "http://",
                "roomId": 2
            },
            {
                "id": 4,
                "url": "http://",
                "roomId": 2
            }
        ]
    }
]

为得到上述结果，可使用以下两种方式

嵌套结果映射

<select id="selectRoomPage" resultMap="RoomPageMap">
    select ri.id room_id,
           ri.number,
           ri.rent,
           gi.id graph_id,
           gi.url,
           gi.room_id
    from room_info ri
       left join graph_info gi on ri.id=gi.room_id
</select>

<resultMap id="RoomPageMap" type="RoomInfoVo" autoMapping="true">
    <id column="room_id" property="id"/>
    <collection property="graphInfoList" ofType="GraphInfo" autoMapping="true">
        <id column="graph_id" property="id"/>
    </collection>
</resultMap>

嵌套查询

<select id="selectRoomPage" resultMap="RoomPageMap">
    select id,
           number,
           rent
    from room_info
</select>

<resultMap id="RoomPageMap" type="RoomInfoVo" autoMapping="true">
    <id column="id" property="id"/>
    <collection property="graphInfoList" ofType="GraphInfo" select="selectGraphByRoomId" 				 	column="id"/>
</resultMap>

<select id="selectGraphByRoomId" resultType="GraphInfo">
    select id,
           url,
           room_id
    from graph_info
    where room_id = #{id}
</select>

这种方法使用两个独立的查询语句来获取一对多关系的数据。首先，Mybatis会执行主查询来获取room_info列表，然后对于每个room_info，Mybatis都会执行一次子查询来获取其对应的graph_info。

若现在使用MybatisPlus的分页插件进行分页查询，假如查询的内容是第1页，每页2条记录，显然嵌套结果映射的分页逻辑是存在问题的。

打印SQL语句

需要在application.yml文件中进行如下配置

#用于打印框架生成的sql语句，便于调试
mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

Hexo备份及博文模板配置

Thu, 22 Aug 2024 22:14:00 GMT

为了防止误操作或意外情况导致的 Hexo 博客源文件丢失，或满足我们更换电脑进行写作的需求，所以需要进行备份。

需要备份的文件和目录

而在进行备份时，并不需要将整个博客目录全部备份，只需备份几个用户自定义的文件和配置

scaffolds 文章的模板，需要备份

source 文章和页面等源文件，需要备份

themes 主题文件与配置，需要备份

_config.yml 用户配置信息，需要备份

package.json 模块列表，需要备份

不需要备份的文件和目录

node_modules 安装的模块，不用备份

public 生成的文件静态网页文件，不用备份

db.json 网页数据文件，编译生成静态网页时会自动更新，不用备份

package-lock.json 依赖的模块安装记录，不用备份

此外如果主题目录下.git 这个隐藏目录也可以删掉或者如下面所讲加.gitignore 文件中在备份时忽略掉

备份到 GitHub

在 GitHub 创建一个私密仓库 hexo-source，仓库名字随意，建议设置为私密仓库。
在你的站点目录下增加一.gitignore 文件设置需要忽略的文件和目录，在其中添加不需要备份的内容：

Text

node_modules/

public/

.deploy_git/

_config.landscape.yml

package-lock.json

db.json

themes/*/.git/

.DS_Store

备份你的站点源文件到仓库 hexo-source，其your_token为你的GIthub访问Tokenusername为你的Github用户名

git init

git add *

git commit -m "$(date): Hexo backup"

git remote add origin https://your_token@github.com/username/hexo-source.git

git push -u origin main

恢复你的 Hexo 站点

初始化一个 Hexo 站点。
从 GitHub 下载备份的内容到该 Hexo 站点目录下：

git clone https://your_token@github.com/username/hexo-source.git

使用备份的 package.json 文件来恢复安装 Hexo 插件，使用 npm 进行安装：

npm install

这将读取 package.json 文件中的依赖项列表，并下载并安装所需的插件和模块。

生成静态网页并部署即可。

脚本化

有了上面的基础，可以在站点目录下创建bash文件，用来简化操作

文件hexp_backup.sh，用于备份Hexo源代码

echo "-------------------------添加文件-------------------------"

git add *

echo "-----------------------提交本地备份------------------------"

git commit -m "$(date): Hexo backup"

echo "-----------------------提交到远程仓库----------------------"

git push -u origin main

echo "-----------------------备份源代码完成----------------------"

文件hexp_new_post.sh，用于按照模板创建新博文

blog_name="博客-$(date +'%Y-%m-%d %H:%M:%S')"

hexo new "$blog_name"

echo "-----------------------$blog_name.md 创建成功----------------------"

3. 文件`hexp_publish.sh`，用于编译部署站点
```shell
echo "-----------------------清理本地缓存----------------------"

hexo clean

echo "------------------------开始部署------------------------"

hexo d -g

echo "------------------------部署结束------------------------"

文件hexp_publish_backup.sh，用于整合部署和备份，通常写完博文后执行这个文件

bash hexo_publish.sh

echo "------------------------开始备份源码-------------------------"

bash hexo_backup.sh

echo "-----------------------全部部署流程完成----------------------"

echo "访问：http://archiewang.site"