<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>知识积累</title><link>https://hanhua.asia/</link><description>Recent content on 知识积累</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Sun, 24 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://hanhua.asia/index.xml" rel="self" type="application/rss+xml"/><item><title>网站更新日志</title><link>https://hanhua.asia/about/single/</link><pubDate>Sun, 24 May 2026 00:00:00 +0000</pubDate><guid>https://hanhua.asia/about/single/</guid><description>&lt;p>这个页面用于记录网站本身的结构、功能、页面与导航更新。&lt;/p>
&lt;p>&lt;strong>规则：&lt;/strong>&lt;/p>
&lt;ul>
&lt;li>只有网站本身发生变化时才记录在这里，例如：新增搜索页、调整首页按钮、修改导航、调整页面结构、增加新的静态功能。&lt;/li>
&lt;li>&lt;strong>新增文章不记入这里。&lt;/strong>&lt;/li>
&lt;/ul>
&lt;h2 id="2026-05-24">2026-05-24&lt;/h2>
&lt;ul>
&lt;li>首页“关于”入口改为“网站更新日志”。&lt;/li>
&lt;li>新增单独搜索页，并在首页按钮和顶部导航中加入“搜索”入口。&lt;/li>
&lt;/ul></description></item><item><title>自己搭建一个可用的 SillyTavern</title><link>https://hanhua.asia/posts/build-a-usable-sillytavern/</link><pubDate>Sun, 24 May 2026 00:00:00 +0000</pubDate><guid>https://hanhua.asia/posts/build-a-usable-sillytavern/</guid><description>&lt;p>作者：寒花（助手：GPT-5.4）&lt;/p>
&lt;p>SillyTavern 是一个面向大模型聊天与角色扮演的前端工具。它本身不是模型服务，而是一个把聊天、角色卡、世界书、预设、语音、图片生成和扩展能力集中到一起的操作界面。&lt;/p>
&lt;p>它的作用，不只是把模型回复显示出来，而是把“长期使用 AI”这件事做成一个可以积累、可以整理、可以持续调教的环境。你可以在里面管理角色、整理设定、保存对话、切换预设，也可以继续往上接 TTS、图片生成和其他扩展能力。对于想把 AI 聊天真正当成一个长期使用环境来配置的人来说，SillyTavern 会比单纯在某个网页里直接对话更灵活。&lt;/p>
&lt;p>这篇文章写的就是一套适合个人服务器使用的 SillyTavern 搭建与配置思路。重点不放在命令本身，而放在技术实现路径、模块拆分方式，以及这些功能为什么要这样接。&lt;/p>
&lt;h2 id="一先明确要搭成什么样">一、先明确要搭成什么样&lt;/h2>
&lt;p>在开始之前，先把目标想清楚。对我来说，一套真正可用的 SillyTavern 环境，至少应该满足这些要求：&lt;/p>
&lt;ul>
&lt;li>能长期稳定运行&lt;/li>
&lt;li>能通过浏览器正常访问&lt;/li>
&lt;li>配置和聊天记录可以保留&lt;/li>
&lt;li>后续接 API、世界书、预设、语音和图片功能时，不需要推倒重来&lt;/li>
&lt;li>即使重建容器，主要数据也不会丢&lt;/li>
&lt;/ul>
&lt;p>如果只是临时体验，直接在本机跑一个实例当然更快；但如果希望它成为一套长期使用的环境，那么从一开始就要把结构想清楚，而不是只追求“先跑起来”。&lt;/p>
&lt;h2 id="二为什么我更推荐用-docker-来搭">二、为什么我更推荐用 Docker 来搭&lt;/h2>
&lt;p>SillyTavern 这类前端，真正麻烦的通常不是第一次安装，而是后面越用越复杂。&lt;/p>
&lt;p>今天接一个 API，明天导入一批角色卡，过几天再加上世界书、预设、TTS 和图片功能，如果一开始部署方式就很随意，后期会很难维护。也正因为这样，我更推荐直接用 Docker 来跑。&lt;/p>
&lt;p>这样做的好处主要有几个：&lt;/p>
&lt;ul>
&lt;li>程序本体和数据可以分开&lt;/li>
&lt;li>重建容器时不需要重做全部配置&lt;/li>
&lt;li>升级和迁移更容易控制&lt;/li>
&lt;li>后续要加插件、扩展或适配器时，更容易拆分层次&lt;/li>
&lt;/ul>
&lt;p>Docker 不会自动让一切变简单，但它能帮你把“容器本体”和“长期积累的数据”切开。对 SillyTavern 来说，这一点非常重要。&lt;/p>
&lt;h2 id="三搭建时先想目录不要先想功能">三、搭建时先想目录，不要先想功能&lt;/h2>
&lt;p>很多人第一次搭 SillyTavern，会先关心页面能不能打开、模型能不能回字。这个顺序不能说错，但如果你想长期使用，那么更值得先想清楚的其实是目录结构。&lt;/p>
&lt;p>因为真正长期有价值的东西，不是容器本身，而是后面积累出来的这些内容：&lt;/p>
&lt;ul>
&lt;li>配置文件&lt;/li>
&lt;li>用户数据&lt;/li>
&lt;li>聊天记录&lt;/li>
&lt;li>世界书&lt;/li>
&lt;li>预设&lt;/li>
&lt;li>扩展文件&lt;/li>
&lt;li>前端改动内容&lt;/li>
&lt;/ul>
&lt;p>所以更合理的做法，是一开始就把这些内容按职责拆开。这样做之后，整个环境会有几个明显好处：&lt;/p>
&lt;ul>
&lt;li>重建容器不会影响历史数据&lt;/li>
&lt;li>配置改动和前端改动更容易定位&lt;/li>
&lt;li>备份时不需要整包乱拷&lt;/li>
&lt;li>后面迁移到新机器时更省事&lt;/li>
&lt;/ul>
&lt;p>对长期实例来说，目录规划这一步其实比“先接几个功能”更重要。因为前面偷懒，后面大概率要花更多时间补回来。&lt;/p>
&lt;h2 id="四基础搭建过程核心不是启动命令而是顺序">四、基础搭建过程，核心不是启动命令，而是顺序&lt;/h2>
&lt;p>SillyTavern 的基础搭建本身并不复杂。官方文档里也给了 Docker 安装方式，思路很直接：&lt;/p>
&lt;ul>
&lt;li>使用官方镜像&lt;/li>
&lt;li>把配置目录和数据目录挂载出来&lt;/li>
&lt;li>暴露访问端口&lt;/li>
&lt;li>启动容器&lt;/li>
&lt;/ul>
&lt;p>但真正影响后续体验的，不是你有没有把命令敲对，而是你搭建时采用什么顺序。&lt;/p>
&lt;p>我更推荐这样的流程：&lt;/p></description></item><item><title>自己搭建一个可用的域名邮箱</title><link>https://hanhua.asia/posts/build-your-own-domain-mail/</link><pubDate>Wed, 20 May 2026 00:00:00 +0000</pubDate><guid>https://hanhua.asia/posts/build-your-own-domain-mail/</guid><description>&lt;p>作者：寒花（助手：GPT-5.4）&lt;/p>
&lt;p>如果你想拥有一个真正属于自己的邮箱，比如 &lt;code>me@yourdomain.com&lt;/code>，最直接的思路通常是：准备一台服务器，部署邮件服务，配置域名解析，然后接入邮件客户端使用。&lt;/p>
&lt;p>实际操作时，真正的关键不在于“有没有装上邮件软件”，而在于你选择的服务器是否适合承担公网邮件入口。如果服务器能够稳定接收来自互联网的 SMTP 投递，那么可以走标准邮件服务器方案；如果服务器不适合直接开放 25 端口收件，那么更适合采用“平台代收入口、本机负责邮箱本体”的方案。&lt;/p>
&lt;p>这篇文章写的就是一套适合个人使用的域名邮箱搭建思路，并且尽量按教程的方式组织，方便后续整理成给 agent 执行的操作文档。&lt;/p>
&lt;h2 id="一先明确要实现什么">一、先明确要实现什么&lt;/h2>
&lt;p>这套方案完成后，目标应当包括：&lt;/p>
&lt;ul>
&lt;li>拥有自己的域名邮箱账号，例如 &lt;code>admin@yourdomain.com&lt;/code>&lt;/li>
&lt;li>能接收外部邮箱发来的邮件&lt;/li>
&lt;li>能从自己的域名邮箱向外发信&lt;/li>
&lt;li>能接入 Thunderbird 等邮件客户端&lt;/li>
&lt;li>能继续扩展普通邮箱账号、别名和 catch-all&lt;/li>
&lt;li>能通过脚本完成基础收发测试&lt;/li>
&lt;/ul>
&lt;p>如果只是为了自用，不需要一开始就追求企业级邮件平台。先做出一套可收、可发、可登录客户端、可长期维护的系统，比堆很多附加组件更重要。&lt;/p>
&lt;h2 id="二准备条件">二、准备条件&lt;/h2>
&lt;p>开始之前，先准备好以下资源。&lt;/p>
&lt;h3 id="1-服务器">1. 服务器&lt;/h3>
&lt;p>至少需要一台 Linux 服务器，建议条件如下：&lt;/p>
&lt;ul>
&lt;li>1GB 内存起步，2GB 更稳&lt;/li>
&lt;li>至少 10GB 磁盘空间&lt;/li>
&lt;li>能通过 SSH 登录&lt;/li>
&lt;li>系统为常见 Linux 发行版&lt;/li>
&lt;li>能正常安装 Docker、Python 和基础依赖&lt;/li>
&lt;/ul>
&lt;p>如果服务器上已经运行了很多服务，建议先确认还有足够可用内存，避免邮箱服务部署后长期处于资源紧张状态。&lt;/p>
&lt;h3 id="2-域名">2. 域名&lt;/h3>
&lt;p>需要一个自己的域名，例如：&lt;/p>
&lt;ul>
&lt;li>&lt;code>yourdomain.com&lt;/code>&lt;/li>
&lt;/ul>
&lt;p>建议同时预先规划一个邮件服务地址，例如：&lt;/p>
&lt;ul>
&lt;li>&lt;code>mail.yourdomain.com&lt;/code>&lt;/li>
&lt;/ul>
&lt;p>它可以用于 IMAP、SMTP、证书、客户端配置以及后续标准化管理。&lt;/p>
&lt;h3 id="3-cloudflare-账号">3. Cloudflare 账号&lt;/h3>
&lt;p>如果你的服务器不适合直接开放公网 25 端口，那么需要：&lt;/p>
&lt;ul>
&lt;li>一个 Cloudflare 账号&lt;/li>
&lt;li>域名 DNS 托管在 Cloudflare&lt;/li>
&lt;li>能使用 Cloudflare Email Routing&lt;/li>
&lt;li>能部署 Cloudflare Worker&lt;/li>
&lt;/ul>
&lt;p>如果你的服务器可以直接收 25 端口邮件，那么 Cloudflare 不是必须条件，只要你能正常配置 DNS 即可。&lt;/p></description></item><item><title>第一篇文章</title><link>https://hanhua.asia/posts/first-post/</link><pubDate>Mon, 18 May 2026 00:00:00 +0000</pubDate><guid>https://hanhua.asia/posts/first-post/</guid><description>&lt;p>这是博客的第一篇文章。&lt;/p>
&lt;h2 id="关于这个博客">关于这个博客&lt;/h2>
&lt;p>这里用来记录技术学习、日常思考和折腾的过程。&lt;/p>
&lt;h2 id="主题">主题&lt;/h2>
&lt;p>博客使用 Hugo + PaperMod 主题，部署在 GitHub Pages 上。&lt;/p></description></item></channel></rss>