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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
---
title: 稻草人周刊 Vol.62
subtitle:
tags:
- AI
- 编程
- 写作
date: 2026-01-05 10:13:50
categories: 稻草人周刊
draft: false
toc: true
toot: https://c7.io/@eltrac/115840087983869751
---
{{< music cover="https://r2.eltr.ac//uPic/2025/12/29161349-Mathis-Wonderful.jpg" title="Wonderful, Wonderful" artist="Johnny Mathis" apple="https://music.apple.com/cn/album/wonderful-wonderful-with-ray-conniff-single-version/201413403?i=201414524t" >}}
上周去看了《魔法坏女巫 2》之后，对巫师和 Glinda 合唱的那首《Wonderful》印象很深，看音乐剧《雨中曲》的时候也听到了 Wonderful 这个词，不知怎么地，竟然触发了有关另一首歌的回忆，歌名就叫作《Wonderful, Wonderful》——这是《绝望的主妇》最终季最后一季，Karen McClusky 请 Bree 帮她找了一张唱片，她在病床上离世时就听着这首歌。同时进行的还有另一条故事线，Susan 的女儿 Julie 在医院诞下了新生命。这个结局让我印象很深刻。
<!--more-->
## ⋈︎ · 连接
### 你的工作是交付可用的代码
> [!note] 📜
> [Your job is to deliver code you have proven to work](https://simonwillison.net/2025/Dec/18/code-proven-to-work/)
作者观察到一种现象：许多会使用 LLM 编程工具的新人，会在用 LLM 写出一大堆代码之后直接提交 Pull Request，指望同事或者开源项目的维护者在审查代码的时候解决问题。这很不负责，不仅在浪费其他人的时间，还完全没有尽到一个开发者的职责。
作者认为在提交 PR 时，应当附上「代码能跑」的证明，以下两个步骤都不能被跳过。
1. 手动测试，给出输入和输出，提供文字输出、截图或者录屏
2. 自动测试，提交的代码中应当集成相关的测试
其中，自动测试甚至也能用 LLM 写，尤其是在原先就已经有测试代码的情况下，Coding Agent 甚至会在没有被显式要求的情况下按照现有的模式编写测试。此外，不能因为有了自动测试就不进行手动测试，测试不总是能覆盖所有情况。测试应当包含最主要的操作路径（happy path）和边缘情况（edge cases）。
作者还提到了一个很有启发性的观点：==计算机不能被追责（held accountable），程序员作为人类的工作就是为交付的成果负责。== 我一直以来也有一个类似的观点：LLM 无法取代人类，因为一个软件系统无论如何都要有输入才能工作，换句话说，就是要有人写提示词、维护上下文，以及编写文档。
### 关于 AI 辅助写作
> [!note] 📜
> [我是如何使用 AI 辅助创作的 - 静かな森](https://innei.in/posts/tech/how-to-use-ai-for-assisted-creation)
作者分享了他使用 AI（准确来说是 LLM）辅助写作的方法，读完之后我对这种写作方式有了一些改观，我想这对一部分人来说大概是有帮助的，只是我自己仍然会坚持每个字都要自己敲出来。
作者在编写技术文章时，主要用 LLM 绘图和生成示例代码，因为自己画图和改代码很费时间——我觉得这是好的，能让作者把注意力放在写作上（理清思绪、组织语言、尽可能表达清楚自己的意思），不去关注那些细枝末节的事情。作者是让 LLM 用 Excalidraw 画图的（应该是 JSON 格式），我觉得完全可以换成 Mermaid 或者 PlantUML 等绘图语言，这样画出来的图风格更统一、自己写代码画图也不会像用 GUI 画图那样费事费力，就算用 LLM 生成，也能避免因 LLM 极其不稳定的空间想象力导致的错位问题。[^2]
作者也会用 LLM 编写生活类文章，他表示用 LLM 辅助这类写作反而让时间变长了，因为他会先用自己的话把故事讲一遍给 LLM 听，再让 LLM 写进文章里，然后还会对风格和细节提出进一步的要求。说实话，看到作者写出了「让小标题更加简短和文艺」这种提示词的时候，我还是很难对这种写作方式表示认同——如果自己本来就不是一个「文艺」的人，那为什么要让 LLM 帮你把文章写得文艺呢？你本来就**不会也不需要**写出那样「文艺」的文字啊？
这大概和社会文化脱不了干系，大家都想要写出「好」的文章，而不是完全真诚的表达自己——真诚自然也包括写作风格上的真诚，我认为写作风格就是作者人格中某一部分的自然流露。
> 形成个人风格的最佳手段是尽力自然而诚恳地写作。构成个人风格的不是刻意为之的文风，不是充满诗意的段落，也不是对文字结构的疯狂追求。写作者无需刻意为之，风格就会自然呈现。
{{< right "—— Lawrence Block《[小说的八百万种写法](https://www.geedea.pro/library/2025/%E5%B0%8F%E8%AF%B4%E7%9A%84%E5%85%AB%E7%99%BE%E4%B8%87%E7%A7%8D%E5%86%99%E6%B3%95/)》" >}}
即便不是个大文豪也能写作，每天都在博客写流水账也会有人看，甚至愿意读这种内容的人会更多。我得承认，尽管博客的中文文章没有一句话是 LLM 生成的，但[英文博客](/en)的前五篇文章都有大量的语句是用 ChatGPT 修改过的，因为当时的我觉得一些措辞太尴尬，而 ChatGPT 改过的句子明显好多了。
后来我想明白了，我本来就不是作家，不是英语母语者，写不出完全没有错误、行文流畅、语言自然的文章是理所应当的，我犯错是应该的。我很喜欢 [LessWrong](https://www.lesswrong.com/posts/bJ2haLkcGeLtTWaD5/welcome-to-lesswrong) 的欢迎页面的开头引用的一句话：
> _The road to wisdom? Well, it's plain and simple to express:_
>
> _Err_
>
> _and err_
>
> _and err again_
>
> _but **less**_
>
> _and **less**_
>
> _and **less**._
{{< right "– Piet Hein" >}}
我最近在读《The Design of Everyday Things》，其中有一章的标题就是：To Err is Human.（犯错是人）LLM 可以写出平均的「好」，但写不出真实的「坏」，更何况，LLM 生成的内容也逃离不了幻觉、错误，写出来的文章也绝非完美（写文章根本没有完美这一说！）。为什么要让自己给 LLM 当 Agent，修改和清理一个计算机程序生成出来的东西呢？
---
跑个题。读完这篇文章，我想起来我观察到有不少人虽然不用 AI 直接辅助创作，但会用 LLM 帮他们改文法问题。把文章草稿复制粘贴到聊天框，让 LLM 帮忙找错字和语法问题等。对此，我也发表一下我*不太友好的*观点。
我觉得用 ChatGPT 这样的大模型帮你的文章找错别字是一件很**蠢**的事情，因为 LLM 是生成式模型，不会像传统算法一样关注你的每一个输入，注意力机制很容易让 LLM 忽略用户输入文本中的某些内容，导致一部分错误没有被纠正。更致命的是，LLM 无法避免幻觉，纠出不存在的问题也是完全有可能的。甚者，LLM 完全有可能「不知道」正确答案，*自信地*帮你把正确的东西改错、把小错改成大错。
简单来说，真的要用软件辅助改错别字，用词典、语言概率和专门训练用于纠错的小模型效果会好得多得多，它们能做到稳定和准确地匹配。拼写检查在上个世纪就已经实现了（现在几乎每个编辑器都自带拼写检查），语法检查也在十几年前就有人做了（如 Grammarly），只是中文的语言处理工具相比英文没有那么成熟而已，LLM 不是必须的——==人们对 AI 的狂热已经让他们开始忽视早就存在的、更好的解决方案了。==
### 解析到本地 127.0.0.1 的域名
> [!note] 📜
> [解析到本地127的神奇域名 - 两双筷子](https://www.dbkuaizi.com/archives/479.html)
一般来说，程序员在本地进行开发的时候会使用 localhost（指向 127.0.0.1 的一个域名）加端口号进行测试，比如 Vite 的 dev server 就默认跑在 5173 端口，运行 `npm run dev`（或者 `pnpm dev`）之后就可以启动 dev server，通过 `localhost:5173` 访问正在运行的服务器，用于开发和调试。
这么做一般来说没问题，但有几个弊端：
1. `localhost` 和 `127.0.0.1` 都太长了
2. 如果有多个服务同时在跑，只能通过端口号区分，不如子域名直观
3. 没办法配置 SSL，只能使用 HTTP 连接
4. 很多 OAuth 提供商不允许使用 IP 或 `http://` 协议的网址作为重定向 URL
5. IP 和域名处理 Cookie 的逻辑不同，子域名之间可以共享 Cookie
简而言之，有一个解析到 `127.0.0.1` 的域名用作本地开发会很方便，但自己注册太贵，用现有的域名可能也太长，本文的作者收集了一些本身就解析到本地的域名，其中最短的一个是 `lvh.me`，顶级域名和子域名都解析到本地，可以在开发过程中使用。
顺带一提，我第一次知道 `*.localhost` 也是默认解析到本地的，不只可以用 `localhost`。
### AltBot 的关停
*本条由 [@doincyberspace](https://github.com/doincyberspace) 投稿*
这期周刊的 AI 含量有点高，还请读者见谅。AltBot 是 Fediverse 上的一个机器人账号，由 [@micr0@wetdry.world](https://wetdry.world/@micr0/) 创建，开放给所有 Fediverse 用户免费使用，用于给图片自动生成 Alt Text。
Alt 是 Alternative 的缩写，也是 HTML `<img>` 标签的一个属性，一开始是图片失效时代替（alternative）图片显示的文字。如今，Alt Text 也用于保证网站的可访问性（Accessibility），盲人可以通过 Alt Text 了解他们看不见的图片内容。为图片添加 Alt Text 是如今 Web 开发的共识，Mastodon 等联邦社交媒体也要求用户在发布图片时为图片添加 Alt Text。为了帮助用户更方便地为图片添加 Alt Text，@micr0 创建了 AltBot。关注 AltBot 之后，如果账号上有发布没有 Alt Text 的图片，AltBot 就会通过本地模型识别图片，帮你编写文字。
@micr0 的本意是让 Fediverse 变得更具包容性，毕竟觉得麻烦的话，大多数人可能选择不写 Alt Text，这完全是可以的。最近有盲人用户发声批评 AltBot，希望人们反对它，原因是他经常在时间线上读到那些用 AltBot 生成的糟糕描述，很多根本就不准确。他认为人类写的 Alt Text 永远是更好的，至少是下了心思想让盲人读者理解，而不是把写 Alt Text 当作负担，必须要用自动化的方式应付了事。
<blockquote class="mastodon-embed" data-embed-url="https://ieji.de/@anantagd/115804706509841365/embed" style="background: #FCF8FF; border-radius: 8px; border: 1px solid #C9C4DA; margin: 0; max-width: 540px; min-width: 270px; overflow: hidden; padding: 0;"> <a href="https://ieji.de/@anantagd/115804706509841365" target="_blank" style="align-items: center; color: #1C1A25; display: flex; flex-direction: column; font-family: system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Oxygen, Ubuntu, Cantarell, 'Fira Sans', 'Droid Sans', 'Helvetica Neue', Roboto, sans-serif; font-size: 14px; justify-content: center; letter-spacing: 0.25px; line-height: 20px; padding: 24px; text-decoration: none;"> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="32" height="32" viewBox="0 0 79 75"><path d="M63 45.3v-20c0-4.1-1-7.3-3.2-9.7-2.1-2.4-5-3.7-8.5-3.7-4.1 0-7.2 1.6-9.3 4.7l-2 3.3-2-3.3c-2-3.1-5.1-4.7-9.2-4.7-3.5 0-6.4 1.3-8.6 3.7-2.1 2.4-3.1 5.6-3.1 9.7v20h8V25.9c0-4.1 1.7-6.2 5.2-6.2 3.8 0 5.8 2.5 5.8 7.4V37.7H44V27.1c0-4.9 1.9-7.4 5.8-7.4 3.5 0 5.2 2.1 5.2 6.2V45.3h8ZM74.7 16.6c.6 6 .1 15.7.1 17.3 0 .5-.1 4.8-.1 5.3-.7 11.5-8 16-15.6 17.5-.1 0-.2 0-.3 0-4.9 1-10 1.2-14.9 1.4-1.2 0-2.4 0-3.6 0-4.8 0-9.7-.6-14.4-1.7-.1 0-.1 0-.1 0s-.1 0-.1 0 0 .1 0 .1 0 0 0 0c.1 1.6.4 3.1 1 4.5.6 1.7 2.9 5.7 11.4 5.7 5 0 9.9-.6 14.8-1.7 0 0 0 0 0 0 .1 0 .1 0 .1 0 0 .1 0 .1 0 .1.1 0 .1 0 .1.1v5.6s0 .1-.1.1c0 0 0 0 0 .1-1.6 1.1-3.7 1.7-5.6 2.3-.8.3-1.6.5-2.4.7-7.5 1.7-15.4 1.3-22.7-1.2-6.8-2.4-13.8-8.2-15.5-15.2-.9-3.8-1.6-7.6-1.9-11.5-.6-5.8-.6-11.7-.8-17.5C3.9 24.5 4 20 4.9 16 6.7 7.9 14.1 2.2 22.3 1c1.4-.2 4.1-1 16.5-1h.1C51.4 0 56.7.8 58.1 1c8.4 1.2 15.5 7.5 16.6 15.6Z" fill="currentColor"/></svg> <div style="color: #787588; margin-top: 16px;">Post by @anantagd@ieji.de</div> <div style="font-weight: 500;">View on Mastodon</div> </a> </blockquote> <script data-allowed-prefixes="https://ieji.de/" async src="https://ieji.de/embed.js"></script>
这件事情发生后，@micr0 很快关停了 AltBot，这之后每个使用 AltBot 的用户都能看到一开始发声的那位盲人用户发的帖子——他做了他能做的，尽可能让更多人听到盲人群体的声音。不过，这条讨论串后面的内容变得有些过于情绪化了，这位盲人用户甚至称「健全人对我而言也是一种负担」。
<blockquote class="mastodon-embed" data-embed-url="https://ieji.de/@anantagd/115808741963174456/embed" style="background: #FCF8FF; border-radius: 8px; border: 1px solid #C9C4DA; margin: 0; max-width: 540px; min-width: 270px; overflow: hidden; padding: 0;"> <a href="https://ieji.de/@anantagd/115808741963174456" target="_blank" style="align-items: center; color: #1C1A25; display: flex; flex-direction: column; font-family: system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Oxygen, Ubuntu, Cantarell, 'Fira Sans', 'Droid Sans', 'Helvetica Neue', Roboto, sans-serif; font-size: 14px; justify-content: center; letter-spacing: 0.25px; line-height: 20px; padding: 24px; text-decoration: none;"> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="32" height="32" viewBox="0 0 79 75"><path d="M63 45.3v-20c0-4.1-1-7.3-3.2-9.7-2.1-2.4-5-3.7-8.5-3.7-4.1 0-7.2 1.6-9.3 4.7l-2 3.3-2-3.3c-2-3.1-5.1-4.7-9.2-4.7-3.5 0-6.4 1.3-8.6 3.7-2.1 2.4-3.1 5.6-3.1 9.7v20h8V25.9c0-4.1 1.7-6.2 5.2-6.2 3.8 0 5.8 2.5 5.8 7.4V37.7H44V27.1c0-4.9 1.9-7.4 5.8-7.4 3.5 0 5.2 2.1 5.2 6.2V45.3h8ZM74.7 16.6c.6 6 .1 15.7.1 17.3 0 .5-.1 4.8-.1 5.3-.7 11.5-8 16-15.6 17.5-.1 0-.2 0-.3 0-4.9 1-10 1.2-14.9 1.4-1.2 0-2.4 0-3.6 0-4.8 0-9.7-.6-14.4-1.7-.1 0-.1 0-.1 0s-.1 0-.1 0 0 .1 0 .1 0 0 0 0c.1 1.6.4 3.1 1 4.5.6 1.7 2.9 5.7 11.4 5.7 5 0 9.9-.6 14.8-1.7 0 0 0 0 0 0 .1 0 .1 0 .1 0 0 .1 0 .1 0 .1.1 0 .1 0 .1.1v5.6s0 .1-.1.1c0 0 0 0 0 .1-1.6 1.1-3.7 1.7-5.6 2.3-.8.3-1.6.5-2.4.7-7.5 1.7-15.4 1.3-22.7-1.2-6.8-2.4-13.8-8.2-15.5-15.2-.9-3.8-1.6-7.6-1.9-11.5-.6-5.8-.6-11.7-.8-17.5C3.9 24.5 4 20 4.9 16 6.7 7.9 14.1 2.2 22.3 1c1.4-.2 4.1-1 16.5-1h.1C51.4 0 56.7.8 58.1 1c8.4 1.2 15.5 7.5 16.6 15.6Z" fill="currentColor"/></svg> <div style="color: #787588; margin-top: 16px;">Post by @anantagd@ieji.de</div> <div style="font-weight: 500;">View on Mastodon</div> </a> </blockquote> <script data-allowed-prefixes="https://ieji.de/" async src="https://ieji.de/embed.js"></script>
后来我看到了 @micr0 的嘟文，他表示自己在收到消息之后很快做出了行动，暂时关停了 AltBot，一直有在收集反馈；在先前那条讨论串的回复中，他也有在积极跟其他用户交流想法，提出了改进方案。从一开始，他就有追踪能源使用，因为他关注环保；为了保证用户隐私，他使用的是本地模型而非云服务。他为 AltBot 花了很多心思（成本就更不用说了），然而却有人进行人身攻击，表示他「太笨了以至于不能理解 AltBot 是有害的」。
<blockquote class="mastodon-embed" data-embed-url="https://wetdry.world/@micr0/115832168197246859/embed" style="background: #FCF8FF; border-radius: 8px; border: 1px solid #C9C4DA; margin: 0; max-width: 540px; min-width: 270px; overflow: hidden; padding: 0;"> <a href="https://wetdry.world/@micr0/115832168197246859" target="_blank" style="align-items: center; color: #1C1A25; display: flex; flex-direction: column; font-family: system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Oxygen, Ubuntu, Cantarell, 'Fira Sans', 'Droid Sans', 'Helvetica Neue', Roboto, sans-serif; font-size: 14px; justify-content: center; letter-spacing: 0.25px; line-height: 20px; padding: 24px; text-decoration: none;"> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="32" height="32" viewBox="0 0 79 75"><path d="M63 45.3v-20c0-4.1-1-7.3-3.2-9.7-2.1-2.4-5-3.7-8.5-3.7-4.1 0-7.2 1.6-9.3 4.7l-2 3.3-2-3.3c-2-3.1-5.1-4.7-9.2-4.7-3.5 0-6.4 1.3-8.6 3.7-2.1 2.4-3.1 5.6-3.1 9.7v20h8V25.9c0-4.1 1.7-6.2 5.2-6.2 3.8 0 5.8 2.5 5.8 7.4V37.7H44V27.1c0-4.9 1.9-7.4 5.8-7.4 3.5 0 5.2 2.1 5.2 6.2V45.3h8ZM74.7 16.6c.6 6 .1 15.7.1 17.3 0 .5-.1 4.8-.1 5.3-.7 11.5-8 16-15.6 17.5-.1 0-.2 0-.3 0-4.9 1-10 1.2-14.9 1.4-1.2 0-2.4 0-3.6 0-4.8 0-9.7-.6-14.4-1.7-.1 0-.1 0-.1 0s-.1 0-.1 0 0 .1 0 .1 0 0 0 0c.1 1.6.4 3.1 1 4.5.6 1.7 2.9 5.7 11.4 5.7 5 0 9.9-.6 14.8-1.7 0 0 0 0 0 0 .1 0 .1 0 .1 0 0 .1 0 .1 0 .1.1 0 .1 0 .1.1v5.6s0 .1-.1.1c0 0 0 0 0 .1-1.6 1.1-3.7 1.7-5.6 2.3-.8.3-1.6.5-2.4.7-7.5 1.7-15.4 1.3-22.7-1.2-6.8-2.4-13.8-8.2-15.5-15.2-.9-3.8-1.6-7.6-1.9-11.5-.6-5.8-.6-11.7-.8-17.5C3.9 24.5 4 20 4.9 16 6.7 7.9 14.1 2.2 22.3 1c1.4-.2 4.1-1 16.5-1h.1C51.4 0 56.7.8 58.1 1c8.4 1.2 15.5 7.5 16.6 15.6Z" fill="currentColor"/></svg> <div style="color: #787588; margin-top: 16px;">Post by @micr0@wetdry.world</div> <div style="font-weight: 500;">View on Mastodon</div> </a> </blockquote> <script data-allowed-prefixes="https://wetdry.world/" async src="https://wetdry.world/embed.js"></script>
这起事件倒没有引发我对无障碍设计的思考，但它让我反思：为什么人们不能一开始就友善地沟通，而是在情绪积压到一定程度过后直接「开战」呢？为什么要伤害那些真正想把事情做好的人？
## ⁂ · 星群
### Infographic
一个用于绘图的语言，之前在《[关于一切的纯文本解决方案指南](/essays/everything-in-plain-text/)》中提及了 Mermaid、Graphviz 和 PlantUML 等用于绘图的标记语言，这周我又发现了一个新的绘图语言。Infographic 和 Mermaid 很像，但解决的是不同的需求。在我看来，Infographic 更注重快速构建美观的图表，其风格更像是会插入在 PPT 里的图表。Infographic 是专门为 LLM 设计的，如果用大语言模型生成 Infographic 代码，会比直接用文生图模型高效、稳定得多。
访问：[GitHub - antvis/Infographic](https://github.com/antvis/infographic)
### witr
名字是 Why is this running? 的缩写，witr 是一个命令行工具，用来查询特定进程的 ID、用户、来源、锁等信息，最主要的是回答「这个进程为什么在跑？谁启动的？」这几个问题。如果进程有什么可疑的举动，拥有某些权限，这个工具也会将其作为警告列出来。
我还挺喜欢这种以疑问词或问句缩写明明的小工具的，常见的有类 Unix 系统的 `whereis` 和 `which`，用于查询某个命令的可执行文件和相关文件的路径。我之前也用相似的命名方式写过 [wthis](https://github.com/BigCoke233/wthis)，用于查询 Homebrew 软件包的信息。
访问：[GitHub - pranshuparmar/witr: Why is this running?](https://github.com/pranshuparmar/witr)
### NeoDB
我在去年年底加入了 Fediverse，拥有了一个 Mastodon 账号。最近在 Fedi 上冲浪的时候，发现了 [NeoDB](https://neodb.net/)，也是联邦宇宙的一部分——去中心化、可以自托管、支持 ActivityPub 协议。从需求上看，NeoDB 基本上是豆瓣的开源替代品。如果不想折腾，也可以使用[官方实例](https://neodb.social/)。
我以前就不怎么爱用豆瓣，从 2024 年开始，读过的书、详细的书评和评分都发布在博客上了，不过电影、演出和剧集倒是没有好去处。使用豆瓣等平台，我没办法真正拥有自己的数据，这导致我一直不愿意在上面认真记录。NeoDB 看起来是一个不错的选择，可以自由地导入导出数据，就算我不想继续用官方实例了，也可以自建然后把数据重新导入。
我不会补记自己以前看了什么，但如果你对我最近在看什么、我对各种文化产品的评价如何感到好奇，可以关注我的 NeoDB [主页](https://neodb.social/users/Eltrac/)，我也会把内容同步到[我的 Mastodon 账号](https://c7.io/@eltrac)上。
访问：[NeoDB](https://neodb.net/)
## ↯ · 当下
### RIME
之前一直对输入法没有太多感知，秉持着能用系统自带软件解决的需求就绝不额外安装的原则，我一直没有去尝试配置繁琐的开源输入法 RIME [^1]，毕竟 macOS 自带「小鹤双拼」，可以开箱即用。这周接触到 RIME 的契机，是我~~上课摸鱼的时候~~在 Fediverse 上吐槽自己在终端输入 `brew update` 时忘记切换输入法，意外用 `brew` 打出了「别惹我」这四个字，没想到引发了一连串有关输入法词库的讨论。
我之所以能用 `brew` 打出「别惹我」，是因为 `r` 在小鹤双拼里映射到 `uan` 这个韵母，而 `buan` 并不是中文里存在的读音，所以 `br` 没有被识别为一个字，输入法把我的输入拆成了 `b-re-w`，于是就打出了「别惹我」。
后来有人提到，在电脑上用雾凇拼音就不会打出这三个字，而是会直接打出 brew 这个英文单词。这时我才意识到，原来中文输入法也能对英文输入进行优化。于是我很快安装了[鼠鬚管](https://github.com/rime/squirrel)（适用于 macOS 的 RIME）和[雾凇拼音](https://github.com/iDvel/rime-ice)（一个广受好评的 RIME 词库配置），还找到了一个模仿 macOS 原生输入法风格的[配置](https://gist.github.com/lewangdev/f8ebbba24f464e915fb7d36857fcbbe5)。
大概是经常折腾开源软件习惯了，配置 RIME 我只用了不到半个小时，之后就用得很顺手了。
可能需要用新输入法写过长文之后才能明白有好词库的爽感，目前比较令我惊喜的点是 macOS 的各种版本名居然也在词库里。
### 泡温泉
跨年夜的时候一个朋友问我想不想元旦去泡温泉，我正好有空，便答应了。顺带一提，这个朋友是去年夏天一不小心喜欢上的那个直男…… 对，我也不知道他为什么找我，我也不知道为什么我答应了。总之…… 元旦那天晚上和直男泡温泉去了，嗯。不过我确实对他没感觉了，而且经过了半年的训练，我觉得我的身材比他好。
本来以为这种需要我付钱进去的场所会有单独的更衣间，结果没有，但还好淋浴间有隔板，只是隔板比公共卫生间的门还矮。有些男人似乎完全不介意，直接在储物柜旁边换衣服，什么都不遮，看到了很多不该看到的东西（而且并不好看）。我去年夏天就是因为相同的原因逃掉了所有的游泳课。
更衣大概是体验最差的环节，泡温泉的过程还是很不错的。人类似乎会因为生物本能而靠近热源，人几乎都聚集在温度最高的几个小池子里，从第三方的视角观察那个场景还挺奇妙的。泡在泉水里很舒服，一方面整个身体会温暖起来，另一方面身体会被浮力拖举起来，感到很放松。我还把头放在岸边，让身体的剩余部分扶起来，就这样闭着眼睛放空了好一会。不过旁边有小孩子玩水，还是得注意周边的环境。
第一次泡温泉还让我发现了关于自己的有趣的一点：我更耐寒，但不耐热。朋友裹着毛巾在岸上走一直发抖，我倒觉得还好，但在汗蒸房是真的待不下去。总的来说，体验中规中矩，如果有下次，我会选择私汤。
另外，在水里做卷腹会有用吗？
### 开源、自由、本地优先和去中心化
去年全面从 Windows 转向 macOS 和苹果生态，许多服务都开始使用苹果的原生应用，也花钱购买和订阅了不少 SaaS，原因是我想要获得更高质量的软件体验。不过，最近 Apple 的软件质量越来越不尽人意，再加上随着自己作为程序员的认知提升，我对数据和隐私的敏感度也逐渐提升，所以 2026 年我在数字生活方面的目标就是：全面拥抱开源软件和自由软件，逐渐转向本地优先和去中心化的解决方案。
开源软件即开放源代码，而自由软件则是允许使用者自由使用、分发、执行、研究、改动甚至售卖的软件。这两个概念有所重合，比如使用 MIT、GPL 和 Apache 开源许可证授权的开源软件都是自由软件，但并非完全一样。所谓本地优先，就是我的数据主要储存在本地，而不是上传到云端，同时，我的数据应该是以纯文本、Markdown 和 JSON 等开放的数据格式存储的，我可以对数据做任何事情，也可以随时拍屁股走人，带着数据换个软件用。至于去中心化，就是说软件服务不由某个经销商运营，而是由数个独立的服务器组成的分布式网络，用户可以自己搭建服务器或者选择自己信任的服务器使用，而不是把数据交给某一个邪恶的大公司。
我还在做的一件事情是去 Chromium/Electron 化，目前已经能用 NeoVim 代替 Obsidian 了，用上 Claude Code 之后我也不需要用某个基于 VS Code 的 AI IDE 了（再加上我本身对 LLM 的需求也没有很高），所以我可以很荣幸地宣布：从此我的 MacBook 上没有一个多余的 Chromium 内核。[^3]
这种选择软件的原则会带来以下好处：
1. 你真正拥有自己的数据，不会因为某天腾讯或者 Google（Apple 也会）因为某些莫名其妙的原因把你的账号封禁而失去所有的数据；
2. 只有你能决定你的数据被用来做什么，你的数据不会被用作算法推荐或者其他肮脏的交易；
3. 如果你不喜欢某个软件或服务，你可以带着你的数据随时退出（你知道吗？如果你尝试在最新版本的 Edge 浏览器上搜索 Chrome 并尝试安装，Edge 会不厌其烦地告诉你它和 Chrome 使用的是相同的技术，而且更值得信赖[^4]。我不知道你怎么想的，总之我没空陪他们玩。）
目前我的各种软件选择如下：
1. 浏览器：[Helium](https://helium.computer/)
- 我不用 Google Chrome；事实上，几乎任何基于 Chromium 内核的浏览器都能达到和 Google Chrome 差不多甚至更好的浏览体验和最新的 Web 特性
- 需要登录才能使用的 Arc 我是绝对不会用的
- 我不会用任何没有丝毫数据安全保障也无法带来真正体验提升的 AI 浏览器
2. 编辑器：[NeoVim](https://neovim.io/)
- Obsidian 很好，尽管不开源，但本地优先，除非需要 Sync 否则不用联网，是个有原则的商业软件。不过，唉，你为什么要往软件里套一个 Chromium 内核呢？
- VS Code 由邪恶的 Microsoft 开发，不好；VSCodium 是 VS Code 的自由软件版本，很好，但仍然是用 Electron 写的，而且自定义空间远远不如 NeoVim。
- JetBrains 的产品还行，也有免费使用的教育版，但 GUI 界面太臃肿，我不喜欢，而且最近还加上了好多烦人的 AI 功能——不要吃我的 MacBook 存储了！
- Zed 很好，大概是我最不舍得放弃的代码编辑器了，是用 Rust 编写的 VS Code 替代品，启动速度很快，界面简洁，只是 NeoVim 太诱人了…… 如果你需要一款基于 GUI 的代码编辑器，我很推荐 Zed。
3. 社交媒体：Mastodon（实例：[c7.io](https://c7.io)）
4. 书影音：NeoDB（实例：[neodb.social](https://neodb.social/)）
5. 输入法：[RIME](https://rime.im/)
- 我不用大家都很爱用的微信输入法，原因就是我绝对不会把输入这种每天都会用到的操作交给腾讯这种东西的
- RIME 不仅开源，词库等配置也是通过开放的数据格式储存在本地的，可以随时迁移，而且可自定义性极强
6. 邮件：[Migadu](https://www.migadu.com/)
- Migadu 是一家瑞士的小公司，提供邮件服务，最低方案一年 $19.9
- 我很喜欢 Migadu 的「观点鲜明」，它们甚至写了[一页长长的清单](https://www.migadu.com/procon/)，罗列你可能不需要或者不想使用它们家服务的理由
- 邮件系统本身就是去中心化的，只要你拥有自己的域名，就可以随时更改 DNS 记录换到另一家邮件服务，或者自己搭建邮件基础设施，也不难
诚然，微信这种软件我是没有办法不用的，我能做的只是减少使用频率，同时在这样的平台上产生尽可能少的数据，把我主要的数字生活建立在我信任的互联网上。此外，我也不排斥 SaaS，像是运动健康相关的需求，我依然会选择与系统集成更好的手机 App，但我仍然更偏好尊重用户数据和隐私的开发者，比如 Gentler Streak 团队[^5]。
[^1]: 还在用 Windows 的时候其实有尝试过，但当时还是个麻瓜，没折腾多久就放弃了。
[^2]: 详见：《[关于一切的纯文本解决方案指南](/essays/everything-in-plain-text/)》
[^3]: 如果你不清楚我在说什么：现在很多跨平台的桌面端软件，都是使用 Electron 开发的，这个框架允许开发者使用 Web 前端技术开发桌面端软件的用户界面，可以极大节省开发成本，提高效率。然而，Electron 会把一个完整的 Chromium 浏览器内核打包在软件里，这使得软件包变得很大，而且完全没有必要。我不反对网页套壳，相反，我很喜欢 Tauri 和 Wails，这两个框架与 Electron 类似，但它们使用操作系统默认的 WebView，不会把一整个浏览器打包在软件里。
[^4]: 来源：[IT 之家](https://www.ithome.com/0/909/729.htm)
[^5]: Gentler Streak 每次启动都会从苹果健康里读取数据并进行分析，数据永远不会离开用户的设备。
|
