第七曜变异点

SillyTavern PWA 功能折腾记录

Tue, 06 Jan 2026 00:00:00 +0000

一直很喜欢 L 站支持的 PWA 功能，然后想在 SillyTavern 中也使用它。昨天尝试了一下，发现 SillyTavern 本身就支持 PWA 功能。能够直接用 Chrome 或 Firefox “安装”到桌面。“安装”到桌面后就非常沉浸了，会全屏显示，隐藏地址栏。

推荐使用 Chrome 或 Chromium 内核浏览器，对 PWA 支持比较好。
不推荐 Firefox，除非你是使用的在线的服务。Firefox 对自签证书支持较差。
Safari 没有测试，下面不会提及。
测试使用的是 Windows 11 和 HyperOS 3（Android 16）。

在线版 SillyTavern

如果使用的是在线的或者别人搭建的 SillyTavern 服务的话，如果是通过 https 连接的，应该可以直接安装（Chrome、Firefox）。

本地运行的情况

本地运行的话，可以采用下面的方案之一（本地我个人只推荐用 Chrome，Firefox 对自签证书支持不太好）。方案一比较麻烦，但相对安全一点。方案一安全的前提是妥善保管 CA 证书的私钥文件。方案一也可以不使用 OpenSSL，换成 mkcert，当然内容会不一样。如果不介意 http 的话，直接使用方案二更方便。

方案一（Https）：在本地创建自签证书

需要一个可以使用 OpenSSL 的环境。如果你安装了 Git，一般都会带着它。需要在路由器的 DHCP 设置里面给 PC 分配静态 IP（按 MAC 绑定 IP），让 PC 始终拿到内网的同一个 IP。大概逻辑是利用 OpenSSL 在本地生成一套自签 CA（1年有效期），并用它签发服务端证书（1年有效期），服务端证书绑定的 IP 是 PC 的IP。

PC 端配置

第一部分：CA 证书

进入安装 SillyTavern 的根目录。
创建新的文件夹，重命名为 certs。
进入 certs 文件夹，右键选择新建文本文档，重命名为 ca.conf。
将下面的内容复制到 ca.conf 中，并保存。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


[req]
distinguished_name = dn
x509_extensions = v3_ca
prompt = no

[dn]
C = CN
O = SillyTavern
OU = Home
CN = SillyTavern Home CA

[v3_ca]
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer

在 certs 目录的空白处右键，选择 Open Git Bash here。
在弹出的窗口中输入下面的指令。这条指令会根据 ca.conf 生成两个密钥文件。
- 公钥：ca.crt 是包含公钥的 CA 证书，后续要把它导入到手机中
- 私钥：ca.key 是私钥，务必妥善保存，不要把它导入到手机中。推荐执行下面完全部步骤后把它从电脑上直接删除。

1
2


openssl genrsa -aes256 -out ca.key 4096
openssl req -x509 -new -days 365 -key ca.key -out ca.crt -config ca.conf -sha256

执行上面的命令会提示 Enter PEM pass phrase:，就是让你输密码，输入完成后需要回车。总共三次，输入、确认、再次输入。需要记住这个密码。

第二部分：服务端证书

回到 certs 文件夹，右键选择新建文本文档，重命名为 server.conf。
将下面的内容复制到 server.conf 中，并保存。需要手动修改其中的 IP 地址。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


[req]
distinguished_name = dn
req_extensions = v3_server
prompt = no

[dn]
C = CN
O = SillyTavern
OU = Server
# 请确保下面的 IP 替换为你的主机 IP。比如路由器给电脑分配的 IP 是 192.168.1.1，就修改为 192.168.1.1。
CN = 192.168.x.xx

[v3_server]
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
# 请确保下面的 IP 替换为你的主机 IP。比如路由器给电脑分配的 IP 是 192.168.1.1，就修改为 192.168.1.1。
IP.1 = 192.168.x.xx

在 certs 目录的空白处右键，选择 Open Git Bash here。
在弹出的窗口中输入下面的指令。这条指令会根据 server.conf 生成两个密钥文件（专门给 SillyTavern 用的）。

1
2


openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -config server.conf

然后执行下面的命令。执行后会提示 Enter PEM pass phrase:，输入第 7 步设置的密码。

1
2


openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
 -out server.crt -days 365 -sha256 -extfile server.conf -extensions v3_server

最后只需要保留 ca.crt、server.crt 和 server.key 就行。其他全部删除，尤其是 ca.key，不建议联网的 PC 上保留这个文件。
- 我选择删除了 ca.key 这个文件的话是为了降低误用风险，代价是后续 IP 变化/一年期限到了的话需要从头跑一遍上面的整个流程。

在 SillyTavern 中开启 SSL：

进入安装 SillyTavern 的根目录。
找到 config.yaml 文件。
打开 config.yaml 文件，搜索 ssl。
找到跟下面一致的配置文件，然后把配置改成下面这样。

1
2
3
4


ssl:
 enabled: true
 certPath: "certs/server.crt"
 keyPath: "certs/server.key"

手机端配置（Android）：

关闭手机上的 Chrome，并确保 Chrome 的后台也被杀死了。
将之前生成的 ca.crt 文件导入到手机。
进入手机的设置，直接搜索证书。
找到 安装证书，选择 CA 证书。
无视警告或者选择仍然安装（对于这种局域网内自己操作的情况是相对安全的，如果是来路不明的证书不要安装）。
然后选择之前导入的 ca.crt 文件。
打开 Chrome，现在再连接之前的 SillyTavern 监听地址应该就可以设置 PWA 了（选择 添加到主屏幕）。
- 需要注意，之前是使用 http 连接的，现在已经是 https 了。例如之前是 http://192.168.1.1:8000，现在就改为 https://192.168.1.1:8000。

方案二（Http）：

此方案无需生成证书，通过浏览器 Flags 强制开启。这个选项可能会因为 Chrome 版本更新而失效。

在地址栏输入 chrome://flags （Chromium 内核的都一样）。
搜索或找到其中的 Insecure origins treated as secure 。
在这个选项的空白框处输入你本地链接 SillyTavern 的地址。
- 例如：你手机连接的地址是 http://192.168.1.1:8000 ，就在这个空白框里面输入 http://192.168.1.1:8000 。
将边上的 已停用 更改为 已启动。
重启浏览器。

适合个人开发者的大善人

Mon, 15 Dec 2025 00:00:00 +0000

下面是一些适合个人开发者使用的不需要绑卡就能使用部分服务的平台。

平台 / 方案	类型 / 用途	免费额度 / 限制	绑卡要求
Cloudflare Workers	边缘 Serverless 计算	100,000 请求/日；每次请求 10ms CPU；静态资源请求免费且不限量	无需绑卡
Cloudflare Pages	静态网站托管、Jamstack、Pages Functions	500 次构建/月；1 个并发构建；每项目 100 个自定义域名；静态请求和带宽不限量	无需绑卡
Netlify Free	网站托管、函数计算、边缘函数	300 credits/月；官方 Free 方案说明包含 100GB 带宽、300 分钟构建时间、125,000 次 Functions、100 万次 Edge Functions、10GB 存储	无需绑卡
Vercel Hobby	前端托管、Serverless 函数	100 万次函数调用；4 CPU 小时；360 GB 小时内存；100GB 快速数据传输；6,000 分钟构建时间	无需绑卡
GitHub Actions	CI/CD 自动化构建与部署	2,000 分钟/月；500MB Artifact 存储；10GB 缓存存储	无需绑卡
Supabase Free	后端即服务、数据库、用户认证、对象存储、边缘函数	500MB 数据库；50,000 月活跃用户；1GB 存储；10GB 总带宽；500,000 次 Edge Function 调用；最多 2 个活跃项目	无需绑卡
Neon Free	Serverless PostgreSQL、用户认证	100 个项目；每项目 100 CU-hours/月；每项目 0.5GB 存储；Neon Auth 支持 60,000 月活跃用户	无需绑卡
Turso Free	云端 SQLite 数据库、边缘同步	100 个数据库；5GB 总存储；每月 5 亿行读取；每月 1,000 万行写入；3GB 同步流量/月；1 天时间点恢复	无需绑卡
Upstash Redis Free	Redis 缓存、限流	1 个数据库；256MB 数据；500,000 条命令/月；10GB 月带宽	无需绑卡
Tailscale Personal	VPN、零信任组网、内网访问	6 个用户；用户设备不限量；50 个带标签资源；1,000 分钟/月临时资源	无需绑卡
PostHog Free	产品分析、用户行为分析	1 个项目；产品分析 1,000,000 events/月；1 年数据保留；用量封顶在免费层	无需绑卡
Sentry Developer	应用监控、错误追踪、链路追踪	1 个用户；5,000 个错误事件；5GB 日志；5GB 应用指标；500 万 spans；50 个回放；1 个可用性监控；1 个定时任务监控	无需绑卡

Using AutoHotkey to Quickly Switch Between Multiple Input Languages

Mon, 10 Nov 2025 00:00:00 +0000

提示: 本文英文译文由 LLM（大语言模型）辅助翻译，可能存在不准确之处，请以中文原文为准。
Note: The English translation in this post was assisted by an LLM and may contain inaccuracies.

Why Abandon Windows’ Native Switching?

Windows’ default input language switching hotkeys become painfully inefficient once you have more than two languages. I regularly type in three languages, and using the default shortcut to cycle through them was frustrating. So I used AutoHotkey to repurpose a few spare keys on my keyboard to switch directly to a specific input language/keyboard layout. This turns sequential (cycling) switching into deterministic switching: press one key and land on the language you want.

My Personal Solution

My keyboard is a 108-key model with four built-in multimedia keys. I rarely use these keys, so I chose them as my language switching keys. With AutoHotkey, I mapped each key to switch directly to a specific input language/keyboard layout.

My mappings are as follows:

Key	Switch to
`Mute`	`English Input`
`Volume -`	`Chinese Input`
`Volume +`	`Japanese Input`

Implementation Logic

I use the PostMessage function to send a system input-language change request to the active window. The target language’s LCID is included in the parameters, which is what makes the switch deterministic.

The specific code is as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


#Requires AutoHotkey v2.0

; Force only one script instance to run.
; If the script is already running, launching it again will automatically replace the old instance.
; This is convenient when you tweak the script and want the changes to take effect immediately.
#SingleInstance Force

; --- Key Mapping Section ---
; Logic: Intercept media keys -> Call switch function -> Pass the corresponding language ID (LCID)
; Note: The original media functions of these keys (mute / volume control) will be completely overridden.

Volume_Mute::SwitchToLang(0x0409) ; 0x0409 = English (United States)
Volume_Down::SwitchToLang(0x0804) ; 0x0804 = Chinese (Mainland China)
Volume_Up::SwitchToLang(0x0411) ; 0x0411 = Japanese

; --- Core Function ---
SwitchToLang(LangID) {
 ; PostMessage: Places a message into the target window's message queue (returns immediately, fast)
 ; Parameter details:
 ; 1. 0x50 : Message code WM_INPUTLANGCHANGEREQUEST (request an input language change)
 ; 2. 0 : wParam (system flag). 0 means "use default behavior"
 ; 3. LangID : lParam (language identifier), e.g., 0x0409 passed in above
 ; 4. (empty): Control (control name). Left empty since we send to the whole window
 ; 5. "A" : The currently active window

 PostMessage(0x50, 0, LangID,, "A")
}

Common LCID Reference

You can replace the LCIDs according to your needs.

Language/Layout	LCID
Chinese (Simplified)	`0x0804`
English (United States)	`0x0409`
Japanese	`0x0411`
Korean	`0x0412`
Chinese (Traditional - Taiwan)	`0x0404`
Chinese (Traditional - Hong Kong)	`0x0C04`

Scope of Application & Limitations

This method switches the input language / keyboard layout. It works best when each language maps to a single input method:

✅ Suitable: One language → one IME/layout (e.g., Chinese only uses Microsoft Pinyin, Japanese only uses Microsoft Japanese, English only uses the US keyboard)
❌ Not ideal: One language → multiple IMEs (e.g., Chinese has both Rime and Microsoft Pinyin). If you want to switch to a specific IME within the same language, this approach is usually not enough.

In the second case, you typically need to use HKL to target a specific input method. I haven’t needed that, so I won’t expand on it here.

How to Find Key Names to Customize Your Mappings?

Use AutoHotkey’s built-in Key History and Script Info window.

First run the script above (or any AutoHotkey script)
Find the AutoHotkey icon in the taskbar
Right-click and select Open or Help (may vary by version)
In the window that opens, click View at the top
Select Key history and script info
Press the key you want to bind, then refresh the page (default: F5). You’ll see the corresponding name in the log.

Once you know the key name, you can modify the code above (like this):

1

YourKeyName::SwitchToLang(0x0409)

How to Set Up Auto-Start on Boot?

There are two methods below: placing it in the Startup folder, or using Task Scheduler.

Method 1: Place in the Startup Folder

Press Win + R
Enter shell:startup
Drop a shortcut to your .ahk script into that folder

This method is very simple. However, in some apps/windows, administrator privileges may be required for the script to work.

Method 2: Task Scheduler

If you find that some apps/windows can’t use this script, you may need to run the AutoHotkey script with administrator privileges.

General approach:

Use Windows search to find Task Scheduler, then open it
Select Create Task (not Create Basic Task)
Name it whatever you want
In the General tab → Security options, check Run only when user is logged on, and check Run with highest privileges
Switch to the Actions tab, click New, and set the program/script to your .ahk file path

Pro tip: There’s a Hidden option in the General tab. If you check it, Task Scheduler will start the task without popping up a UAC confirmation window.

Potential Risks

Tools like AutoHotkey may be flagged as cheating tools by anti-cheat systems in certain games. If your game uses aggressive anti-cheat, it’s safer not to use AutoHotkey scripts—or exit AutoHotkey while playing.

使用 AHK 来实现多语言输入法快捷切换

Wed, 05 Nov 2025 00:00:00 +0000

为何抛弃 Windows 原生切换？

Windows 默认的输入法切换键位在超过两种语言时，切换效率会变得极其低下。俺是有三种语言的输入需求，使用默认的切换键位痛苦不已。便借助 AutoHotKey 实现了使用键盘上多余的键位来进行输入法切换的功能。从“轮询切换”变为“确定性切换”。

个人的解决方法

俺的键盘是 108 键的，它自带了 4 个多媒体按键。这几个按键对于我来说是低频按键，因此我选择它们作为我的语言切换按键。俺使用了 AutoHotKey 将这几个键位映射为了不同输入法的切换键。

俺的映射如下：

按键	切换到
`静音`	`英文输入`
`音量 -`	`中文输入`
`音量 +`	`日语输入`

实现逻辑

使用 PostMessage 函数，直接伪装成系统，向窗口发送一条切换输入语言的消息。并在参数里面附带目标语言的 LCID。这样就可以做到确定性的切换。

具体代码如下。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#Requires AutoHotkey v2.0

; 强制只运行一个脚本实例。
; 如果脚本已经在运行，再次启动会自动替换旧实例，方便修改代码后直接生效。
#SingleInstance Force

; --- 键位映射区域 ---
; 逻辑：拦截媒体键 -> 调用切换函数 -> 传入对应的语言 ID (LCID)
; 注意：这些键的原始媒体功能（静音/调节音量）将被完全覆盖。

Volume_Mute::SwitchToLang(0x0409) ; 0x0409 = 英语 (美国)
Volume_Down::SwitchToLang(0x0804) ; 0x0804 = 中文 (中国大陆)
Volume_Up::SwitchToLang(0x0411) ; 0x0411 = 日语

; --- 核心功能函数 ---
SwitchToLang(LangID) {
 ; PostMessage: 将消息放入目标窗口的消息队列中（不等待结果直接返回，速度快）
 ; 参数详解：
 ; 1. 0x50 : 消息代码 WM_INPUTLANGCHANGEREQUEST (请求切换输入语言)
 ; 2. 0 : wParam (系统标志位)，0 表示使用默认行为
 ; 3. LangID : lParam (语言标识符)，即上面传入的 0x0409 等
 ; 4. (空) : Control (控件名)，此处留空因为是对整个窗口发送
 ; 5. "A" : 当前活动窗口

 PostMessage(0x50, 0, LangID,, "A")
}

常用的 LCID 参考如下

可以根据自己的需求替换其中的 LCID。

语言/布局	LCID
中文 (简体)	`0x0804`
英文 (美国)	`0x0409`
日文	`0x0411`
韩文	`0x0412`
中文 (繁体 - 台湾)	`0x0404`
中文 (繁体 - 香港)	`0x0C04`

适用范围 & 局限

这个方法切的是“语言/键盘布局”，所以在下面这种情况下体验最好：

✅ 适合：一个语言对应一个输入法的情况（例如：中文只有微软拼音、日语只有微软日语、英文只有美式键盘）
❌ 不太适合：同一种语言下有多个输入法的情况（例如：中文有小狼毫、微软拼音两种输入法。然后你想指定切换到小狼毫的话，这个方法就不太适合）

如果是上面第二种情况的话，通常需要用 HKL 去定位到具体的输入法。我没有遇到这个需求，所以也不展开讲了。

如何找“按键名称”方便自己该映射？

用 AHK 自带的 Key history and script info。

先运行上面的脚本（或者随便一个 AHK 的脚本）
在任务栏中找到 AHK 图标
右键选择 Open 或 Help（不同版本可能有差异）
然后在打开的界面顶部选择 View
选择其中的 Key history and script info
然后按下你想绑定的按键，再刷新页面（默认是 F5）。就能看到界面日志里面对应的名称。

知道名称之后，你就可以修改上面的代码（像下面这样）：

1

YourKeyName::SwitchToLang(0x0409)

如何设置开机自启动？

下面有两种方式。一种是直接放入启动文件夹。另一种是利用任务计划程序。

方式 1：放入启动文件夹

Win + R
弹出的窗口输入 shell:startup
把 .ahk 脚本快捷方式丢进去就行

这个方法非常简单。但在有些程序的窗口下，可能需要管理员权限才能够使用 AHK 脚本。

方式 2：任务计划程序

如果你发现有些软件或窗口无法使用这个脚本，可能需要以管理员权限运行 AHK 脚本。

大致思路：

直接用 Windows 自带的搜索，搜「任务计划程序」。然后打开它
选择 创建任务，不要选择 创建基本任务
名称随便取
在「常规」页中找到「安全选项」，勾选其中的「只在用户登录时运行」，勾选「使用最高权限运行」
将界面切到「操作」页，选择「新建」，将你的 AHK 脚本路径填进去

PS：「常规」页中有一个「隐藏」的选项。如果勾选这个选项的话，启动是不会弹那个需要手动确认管理员权限的窗口。

可能的风险

AHK 这类工具在某些游戏环境里可能会被反作弊系统判定为作弊程序。如果你游玩的游戏反作弊比较激进，建议不要使用 AHK 脚本或在游戏时退出 AHK 程序。

如何使用 LLM 反思工作流提升译文质量？

Thu, 16 Oct 2025 00:00:00 +0000

1. 为什么单次 AI 翻译还不够稳定？

我平时会高频使用 LLM 来处理日语/英语翻译。最开始使用的方法很简单，跟传统的机械翻译一样：输入原文，让模型直接输出译文。这个方法很简单而且效率很高，我认识的人多数都会使用这个方法。

在模型选择上，尤其是使用 Flash 模型，刚输入完原文过几秒译文就出现了。速度虽然很快，但产生的译文只能作为参考，如果要投入到生产中还需要大量的人工修改。

单次翻译很难稳定解决漏译、术语一致性和语气控制等问题。后来我开始使用反思工作流，把翻译、审校和最终整合拆成几个环节，由不同节点各自处理。我发现通过这个思路构建的工作流产生的译文质量明显比单次翻译的好。

2. 吴恩达的 Translation Agent 思路

在后续的使用和学习中，我发现了吴恩达的 Translation Agent 这个项目。

https://github.com/andrewyng/translation-agent

它的核心是三步：初步翻译 ➡️ 反思与评价 ➡️ 改进与润色。我借鉴了这个项目的思路，在 Dify 中构建了一个自己的反思工作流。

3. 个人工作流总览

4. 每一阶段的设计思路

这个工作流就是把翻译任务拆分成不同阶段：输入、文本切片、知识检索、初译、反思、合并。每个阶段只负责一类明确的任务，这样可以减少长文本翻译中的各种问题。

4.1 输入阶段

工作流的起点，我会设置几个基础变量：

source_doc：需要翻译的文件
source_text：需要翻译的文本
source_lang：原始语言
target_lang：目标语言
country：目标语言的国家或使用场景

这个节点的变量是让后续所有节点知道“文本从哪里来、要翻译成什么语言、面向的国家或者使用场景是什么”。在翻译实践中，经常有一个误区就是：中文就是中文，英语就是英语，法语就是法语。但实际上不同国家或者地区的同一语言是有些许不同的。打个比方，同样的英语翻译为中文，面向中国大陆的中文、面向港澳台地区的中文以及面向新加坡的中文是不一样的，部分用词和语气可能都不同；同样的日语翻译为中文，面向商品资料、客服邮件、技术说明的不同情况时，表达方式也都是不一样的。这也是 LLM 相比于传统的机器翻译的优势之一：可以使用 Prompt 来自定义输出的风格。

这个节点主要是确定翻译任务的各种条件，避免模型自由发挥。通过变量传递，更好地让模型遵守语言和地区的设定。

4.2 文档提取阶段

这一阶段主要是检测输入的是纯文本还是文档，如果检测到文档就使用特定的功能来提取文档内的内容。也就是把source_doc转换为文本。如果输入的是source_text，那就会直接跳过这一阶段。

这一阶段没有任何 LLM 参与的内容，主要都是程序自动转换。需要注意的是，常规的翻译接触到的可能都是 Word、Excel 等带有复杂格式的文件，这类就不适合直接输入到工作流中让程序自动转换。这类最好使用 CAT 软件来提取文档内容，然后再输入到工作流之中。CAT 软件最大的优势就是格式保持。

4.3 变量聚合阶段

文档或者文本经过上一个阶段后，会进入变量聚合器。它可以把文档中提取出来的文本或用户直接输入的文本统一成一个新的变量。使用这个新的变量将文本继续传递下去。这一目的是让后续的节点只需要接受一个统一的文本，而不需要关心这些文本是由文档输入的还是文本输入的。

概括一下：

如果用户上传了文档，则使用文档提取器提取文本。（上一节点）

如果用户直接输入了文本，则直接使用用户输入的文本。

将统一后的待翻译内容命名为source_content

这一步虽然很简单，但对于自动化工作流来说是很有必要的。它让整个流程可以兼容短文本、长文本和文档内容。

4.4 文本切片阶段

这是第一个代码执行节点。在这个节点会使用代码将上面输入的文本按照段落进行切片，我使用的是 Python 来处理这部分内容。这样做的原因是模型在处理长文本翻译时很容易出现这几个问题：上下文注意力分散，后半段质量暴跌，格式混乱，术语前后不一致等问题。虽然现在的 LLM 的上下文都很大了，但随着上下文内容的增多，模型更容易出现注意力分散和精度下降的情况。按照段落切片后，每一段都可以进入独立的翻译、反思和合并流程。每个小切片更容易让模型稳定处理，也方便后续逐段检查。

切片的原则如下：

优先按照正常的段落切分
保留标题和正文的相邻关系
控制每个切片的长度
避免把同一句话或者同一个列表切散
给每个切片保留顺序编号

4.5 知识检索阶段

这个阶段使用的是迭代节点。切片会逐个经过知识检索节点。这个节点会根据当前段落的内容，从知识库中检索相关术语、固定译法、背景信息或者一些翻译规范，然后把这些信息作为备注一起输入给下一节点。

利用 LLM 进行翻译很令人头痛的一点就是术语不统一。比如，A 在某个行业应该翻译为 B，但由于 A 在其他行业可以翻译为 C，所以 LLM 把这个 A 翻译为了 C，这就导致译文前后容易不一致。

知识节点可以添加下面的文本内容：

各类术语
产品名称
固定表达
品牌名称
etc.

这个节点涉及到了知识库维护的内容，需要使用 Embedding 模型。由于这篇文章主要分享的是工作流思路，故不涉及这部分的内容。

4.6 术语去重阶段

知识检索阶段过后，工作流会进入第二个代码执行节点。这部分我也使用的 Python 进行处理。主要是对上一个节点的内容做去重和整理。在长文本的情况下，知识检索很大概率会检索到多个相似条目，出现很多重复术语。直接把这些内容交给 LLM，更容易导致混乱而且增加不必要的 API 花费。

这部分代码的主要工作内容如下：

删除重复术语
保留优先级更高的译法
保留和当前段落最相关的术语
控制术语参考的长度

4.7 LLM 1：初译阶段

这一阶段终于开始进行翻译了，它负责生成第一版译文。这个阶段的目标是准确且完整地把原文翻译为目标语言。它不需要过度的润色，也不需要改动原文的结构。在我的实践中，第一版译文越是稳定，后面的反思和合并节点就越容易发挥作用。

在模型的选择上，不是需要严谨表达的文章可以选择参数量比较小的模型以平衡成本，比如各类 Flash 模型。

这一阶段的 Prompt 的重点如下：

忠于原文
保留全部信息
参考传递的术语参考内容
保留原文的格式
根据目标地区调整用词

4.8 LLM 2：反思阶段

这一阶段需要对上一阶段的翻译质量进行检查。这个节点需要同时读取原文、初译和输入的术语参考内容，然后从中发现问题并提出修改意见。

这个阶段重点是发现问题，所以我会要求模型输出结构化的审校意见，而不是在初译的基础上重写译文。结构化的输出更容易被后面阶段利用，也方便人工审查时思考哪些意见值得采纳。在翻译实践中，很多译文看起来通顺，但很多问题在对照原文的情况下才更容易发现。

在模型选择上，我建议选择性能最好的模型，这个阶段是最重要的。比如选择 Claude Opus、Gemini Pro、ChatGPT 带思考的系列。

这一阶段的 Prompt 的重点如下：

对照原文来检查初译
找出其中的问题
检查术语是否符合参考内容
检查语气是否符合场景
检查文章格式
给出具体的修改建议以及理由

4.9 LLM 3：合并阶段

这一阶段会根据原文、初译和反思节点给出的建议，生成最终的译文。这个阶段由 LLM 做取舍，采纳或舍弃建议。目标是输出一版准确、自然、更适合交付的译文。

这一阶段的 Prompt 重点如下：

以原文为准
参考初译和反思意见
采纳合理建议
保留术语一致性
输出最终译文
避免引入新的信息

4.10 输出阶段

每个切片完成直译、反思和合并后，工作流把所有切片按照原始顺序重新汇总，输出完整译文。这一阶段还是需要人工审查，避免长文本输出错误。我会着重检查顺序、否定句、条件句、专有名词、产品规格，这些内容出错的话会比表达错误产生的问题更大。

5. 这个流程适合哪些翻译场景？

5.1 技术文档与产品说明书

这类文章通常包含大量行业专有名词、公司的内部表达、产品规格，单次翻译很容易出错。

5.2 跨境电商营销文案与独立站

可以通过这个工作流针对不同国家的消费者调整语气，既要说服力强，又要包含特定的 SEO 关键词。可以利用这个工作流将原文译为有本土吸引力的文案。RAG 可以确保品牌名和核心卖点不被错误翻译。

5.3 商品资料与本地化 QA

商品标题、规格参数、卖点描述和客服话术都对术语一致性有较高要求。通过这个思路也可以让译文的准确度、风格和品牌惯用表达上更加稳定。

6. 成本、限制和质量风险

这个工作流可以一定程度上提升译文的稳定性，但它会带来额外的成本。相比于单次翻译，即：「输入原文 ➡️ 直接输出译文」的方式，反思工作流至少会经历初译、反思、合并三个阶段。整个流程的 token 消耗、处理时间和调试成本都会明显增加。

因此，这个流程更适合有一定质量要求的文本，例如上面提到的技术文档、产品说明书、商品资料、本地化内容等。对于非常短、风险很低、只需要快速浏览的文本，单次翻译通常是足够的。反思工作流的价值主要体现在「需要交付质量」的场景，而不是所有翻译场景。

虽然我们都会在三个不同节点中通过 Prompt 来限制 LLM 的行为，但也有概率出现问题。比如 LLM 2 的反思节点过分挑刺，LLM 3 的节点产生了新的额外内容等情况。因此即使是这种自动化工作流，在面对要求非常严格的场景时，人工审查仍然是必要的。

还有一点是切片容易带来的上下文断裂。上文的节点中其实可以在某个节点内添加「概括段落」的内容，然后一起输出给翻译节点，这样翻译节点会获得前后的上下文，上下文一致性会更好。切片的目的是降低模型的处理压力，提升精度，但切片切得太碎的话依旧会降低稳定性，使用时需要自己找到其中的平衡。

这个工作流最核心的依旧是 LLM 自身的能力。如果你使用三个很差的模型，那产生的结果可能好不到哪里去。目前的顶尖模型在面对翻译的场景下通常表现是不错的，有效上下文也随着模型迭代不断增加。在我的实践中，我认为通常要保持 LLM 2、LLM 3 这两个使用了顶尖模型，这样这个工作流才会更稳定一些。

对于 LLM 来说，面对不同语言情况选择不同模型也是有必要的。比如 Claude、Gemini、ChatGPT 这几个国外模型，它们训练时使用的中文语料相比国内的模型少很多，在面对中文相关翻译时表现可能不会很好。因此也需要使用者充分了解各个模型的优势，才能够让输出的译文更加稳定。

7. 让 AI 翻译变为可控流程

对我来说，现在 LLM 的价值不只在于「翻译得更快」，更在于它可以参与到审校、改写、术语整理和质量检查等环节中。只要把任务拆分清楚，并在关键位置保留人工判断，AI 翻译就可以从一个临时工具，变成一个稳定的内容处理流程。都说未来 2026-2027 是 Agent 爆发增长的时期，相比于 OpenClaw 这类个人助手，我感觉类似的工作流可能会更好地帮助我们工作和生活。

这个工作流也可以迁移到其他的场景中，背后的核心就是把复杂的文本任务拆分为明确的步骤，再通过工具和人工复核共同提高最终交付质量。

写在折腾完 Hugo 和 Astro 之后

Fri, 05 Sep 2025 00:00:00 +0000

写博客这件事情，是很简单的。写一篇文章，找一个平台，发布上去，别人打开就能够阅读。搭建博客的话，一般来说路径是两条，一条是传统博客（新浪、WordPress、Medium等），另一条是近些年新兴的静态博客（Hugo、Hexo、Jekyll、Astro 等）。

传统博客

传统博客我们大家应该都非常熟悉了。就像早些年的新浪博客，哪怕现在的知乎，小红书其实都能算是博客。还有大量个人或公司网站都是依托 WordPress 搭建的。像新浪、知乎、小红书之类的就不提及了，它们是成套的方案，打开就能用。随便讲一下 WordPress。这个安装好之后，每天面对的其实是网站后台，写文章就打开内置的编辑器，要插入图片就有相应的功能勾选。还有大量的成熟的第三方插件可供选择，丰俭由人。这个很适合多人写作、商业网站、内容站。管理员也可以给用户分配权限，设置文章经过管理员审核之后才能发布。它的优势是非常成熟，你遇到的问题基本上都有对应的解决方案。如果你想换主题、加功能，也通常能够找到现成的方案。对很多人来说，这种就非常省心。不过，传统博客是非常「重」的。通常需要数据库、运行环境、后台登录系统，要的功能越多，整个博客也会越来越「重」。维护的成本也会越来越高。

静态博客

静态博客就如名字一样，静态的意思是写完文章后利用工具直接把网页生成好。部署完静态博客后，访问者打开的就是已经生成好的 HTML 页面。静态博客通常都是使用 Markdown 这样的纯文本来编辑、存储文章。这种一开始学习就会比较麻烦。要去看框架的目录结构，要知道对应的配置文件在哪里，还要学习构建和部署。很多问题都需要自己去一一排查。当然度过新手阶段，一切就豁然开朗了。文章就是核心，后续维护什么的也很方便，写完文章之后推送到云端就行了，工具会自动生成对应的 HTML 页面。静态博客的优势主要是速度、稳定性和安全性。对应的网站都是提前生成好的，少了很多步骤，访问就会更快。而且访问时对服务器的压力相比传统博客会小很多，像 Cloudflare Pages 对个人开发者提供的额度几乎是使用不完的。传统博客还需要关注的安全问题，像登录、插件漏洞、主题漏洞等等等等，对于个人开发者来说负担很大。像 WordPress 这种生态极其庞大的系统，插件和主题的选择会直接影响站点的安全性。而静态博客的攻击面相对较小。页面都是静态文件，没有提供后台（可以自己选择加入后台），没有运行中的数据库。对于个人开发者来说，维护成本很低。

静态博客适合哪些人呢？

拿我自己的感觉来看的话，静态博客最适合的其实还是喜欢折腾的人。刚开始学习起来还是很麻烦的，尤其如果没有编程的基础的话。但是搭建起来后的成就感是不一样的，哪怕你的博客其实没有什么人会看🤣。静态博客有很多框架，而且这些框架都提供了很多很多的主题供你选择。但是这些主题都不是完美的，如果想自定义的话都需要小修小改，这个对于没有编程基础的人来说有点不便。但现在已经是 AI 时代了，静态博客的小型代码，LLM 完全能够胜任。比如 Claude Code，配置好 API 后只需要提示词就能够让它自主修改。静态博客几乎都是前端代码，因此 LLM 修改起来很顺手。很多人的静态博客也有一个毛病：装修地十分热闹，但文章总共没几篇（甚至装修笔记占了总数😂）。其实我自己也差不多，很多笔记没有公开放到博客上。总结一下就是：

喜欢折腾新技术的
喜欢 Markdown 写作
原意使用 Git 管理内容
希望低成本部署个人网站的
希望安全性更高一些的

静态博客的框架

常见的静态博客的框架有 Hugo、Hexo、Jekyll、Astro、VitePress 等。这些框架的作用都是一样的：读取文章、主题和配置文件，然后生成可以直接部署的 HTML 网页。我随便写一下我了解的 Hugo 和 Astro。 Hugo 应该是非常普及的框架了，我看过的很多博客都采用的这个框架。它的优点是构建速度快。文章数量越多，这个优势就会越大。Hugo 的主题也比较成熟。很多主题都会内置归档、标签、分类、目录、暗色模式、搜索、适配评论系统等等。当然还有一个坑就是不同的主题的配置可能差别很大。 Astro 可以实现非常现代的前端效果，适合那些想要炫酷效果、组件化和自定义要求很高的人。它其实像一个完整的网站项目，类似于很多企业的官网。除了常规的 Markdown 文章之外，它还可以使用组件、布局、数据集合和各自前端集合。我个人感觉它更适合作为作品集、产品展示。它可以结合 React、Vue、Svelte 等组件框架，也可以使用它自己的组件写页面。

写在最后

我也按照惯例，祭出下面的这张梗图。

简单概括下就是：差生文具多，折腾博客系统代替了写博客🤣。既然是博客，终究还是要回归文字内容的。我收藏了不少人的博客，但很多博客的文章都寥寥无几，只是页面的效果很酷炫（拿来当作参考）。我也希望我建完博客之后能稳定写一些文章吧，就当一个互联网的树洞。

归档 | Archives

Sun, 06 Mar 2022 00:00:00 +0000

搜索 | Search

Mon, 01 Jan 0001 00:00:00 +0000