From f5c26400d8bca00df7020f209fce839536813010 Mon Sep 17 00:00:00 2001 From: eltrac Date: Thu, 30 Apr 2026 00:58:46 +0800 Subject: [draft] update --- content/article/no-ai-for-my-joy.md | 62 +++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/content/article/no-ai-for-my-joy.md b/content/article/no-ai-for-my-joy.md index e836b7b4..48b48231 100644 --- a/content/article/no-ai-for-my-joy.md +++ b/content/article/no-ai-for-my-joy.md @@ -23,6 +23,58 @@ toc = true ## 叛徒 +如果你是一名讨厌 AI 的画师，一名对 AI 编程感到焦虑或者厌恶的程序员，一名对 LLM 颇有微词的文字工作者，很不幸，我可能是个叛徒。 + +过去的一两个月里我一直在用 [OpenCode](https://opencode.ai/) 和 DeepSeek 的便宜 API 做项目，尽管每天最多只会花四个小时在 AI 编程上（再多我觉得我的大脑真的要承受不了了），但我的确给 AI 公司付了不少钱，一定程度上促进了市场需求的增长。 + +不过还请放心，我发布在 [Codeberg](https://codeberg.org/eltrac) 上的项目大部分都是我手写的。我从未想过 Vibe Code 一个爆款产品或开源项目，我仅仅是用它来*应付学校的项目*。我想如果我去实习或正式谋得一个职位，就算上司不要求（尽管现在不少岗位都希望求职者有 AI 编程经验），我也会用它来写工作上的代码，审查后对交付的结果负责。 + +这是好事吗？我把不想写的代码外包给 LLM，想写的代码留给自己写，听起来两全其美不是吗？ + +事实并非如此。 + +在我开始高强度使用 AI 编程之后，我手写代码的时间明显变少了，我的 [Wakapi](https://wakapi.dev/) 统计数据可以证明——过去七天，我只有不到七个小时在写代码，除了有三个小时在写 Clojure，有一个小时在写 YAML 调试 Woodpecker CI 工作流，剩下的时间基本上都是在写配置文件， + +此外，更明显的副作用是，我在写 Clojure 代码的那三个小时，脑子变得迟钝，常常面对简单的需求感到无从下手。我目前正在进行的学校项目，我选择了 Go 语言作为后端，这门[初识时让我感到相见恨晚](/essays/go-philosophy/)的语言，在我某天想要自己动手开发时，也让我觉得*令人恐怖地陌生*。本来我非常乐意解决新问题，可现在面对越来越多的我不知道怎么写的代码，比起思考和寻找他人的解决方案，我的下意识反应竟然变成了…… + +_*按下 ⌘D_[^1] + +_*`opencode`_ + +_*“请你帮我……”_ + +## 脑腐 + +LLM 在很多层面都和短视频十分相似。首先，它们都有类似老虎机的交互逻辑，再往下一刷就能看到更有趣、更新鲜、更吸引人的内容，再写一条提示词、再听一句「You're absolutely right!」，问题就会引人而解。尽管总是事与愿违，但我们似乎不愿意停下，*就像无法进行更高级的反思的动物一样*。如果给老鼠一个按钮，按下之后它就会经历性高潮，那么它就会一直按这个按钮，直到死亡。 + +除了[成瘾性](https://jkap.io/token-anxiety-or-a-slot-machine-by-any-other-name/)，LLM 对大脑的影响还有很多。短视频的恶性影响在诞生十年后才得到广泛关注，而即便是这样它的热度也只增不减，谁知道 LLM 会对大众造成什么样的影响？ + +我有实感的另一个 LLM 对认知的影响是，它加剧了确认偏误（confirmation bias）的发生。某个醉汉在路灯下找东西，路过的警察问他是不是有东西丢在灯下了，他说不是，他在这找仅仅是因为这里有光。 + +就在写文章的今天，我经历了让我感到非常羞耻的事件。我在联邦宇宙上用英文和别人讨论 Git 新特性 `git history reword`，其中我们谈到了给 commit 签名的问题，对方好奇 `reword` 会不会影响签名。我记得我能够给 SSH Key 签名的 commit 执行 `reword`，但 GPG Key 签名的却不行。 + +这是完全错误的，我被 LazyGit 的快捷键误导了。LG 有 `reword` 快捷键，但这在 `git history reword` 发布之前就有了，它实际上使用的是 `git rebase -i`。由于 LG 的限制，它不能和 GPG 一起使用 `git rebase -i`，所以就有了 GPG 签名的 commit 不能 `reword`（实际上是 `rebase`）但 SSH Key 签名的 commit 可以的情况。当时的我没有搞清楚，于是认定这是事实，所以开始思考：为什么 GPG 签名的 commit 可以 `reword`，但 SSH Key 不行呢？两者是不是在原理上有所差异，比如 SSH Key 仅仅对 commit 内容签名，而 GPG 还签名 commit 的 parent hash，所以历史的变更不会影响 SSH 签名？ + +你发现了吗？这个问题的前提就是有错的。 + +为了快速得到答案，继续对话，我向 Kimi 讨教。我不熟悉密码学，相信了 Kimi 的幻觉。它说：SSH Key 是对 git commit 的内容进行签名的，只要内容没变就不影响；而 GPG Key 签名对 Git 历史更加严格，所以 `rebase` 等操作会破坏 GPG 签名，而不会破坏 SSH 签名。 + +听起来很有道理，逻辑是自洽的，但这完全是胡扯。 + +当我意识到自己犯的错误时，对话已经进行了几个来回了，那时还有一位对密码学颇有研究的用户参与了讨论，我好担心被他发现我在胡说八道！我飞快地跑步找到一个地方坐下，掏出电脑查阅资料求证。我翻了各种相关的文章和文章，都没有证据表明 Git 会以不同的方式处理 commit 签名。根据 [Git man 页面](https://manpages.debian.org/experimental/git-man/gitformat-signature.5.en.html#COMMIT_SIGNATURES)里有关 Git 签名格式的描述。 + +> In every case, the command which is about to create an object or transaction determines a payload from that, calls an external program to obtain a detached signature for the payload (gpg -bsa in the case of PGP signatures), and embeds the signature into the object or transaction. + +简单来说，在需要签名的时候，要创建 Git 对象的命令会决定一个载荷（payload），调用外部程序来获取载荷的签名，如果是 GPG 签名，就会调用 `gpg -bsa`；如果是 SSH Key 签名，就会调用 SSH 密钥相关的外部程序。这里没有说载荷（payload）会因为调用的程序不同而发生改变。也就是说 Kimi 所说的、我相信的、另一个比我有经验的工程师听过之后还觉得很有趣的「SSH 密钥只签名 commit 内容而不包含 parent hash」的说法，根本不存在。 + +接下来就是狼狈地道歉、编辑、撤回和澄清…… + +让我来反思一下这段经历：首先，我提出了一个前提就有错的问题，这个问题一开始就不存在；然后，我想出了一个理论来解释这个不存在的问题；再然后，我试图「确认」这个理论，只不过我选错了工具，LLM 通过幻觉「确认」了我的理论，并附加了许多令人信服的解释；最后，我作为*卑贱的* LLM 人肉代理，传递了这个彻头彻尾的错误理论。 + +如果我「确认」的途径是相关的技术文档，或者一位对 Git 了如指掌的专家，就不会出现这个问题。我的「确认」会失效，我会被事实一锤子敲醒。 + +LLM 是个冰冷的确认偏误制造机。 + ## 反思 前文的所有论述都建立在一个尚未被证实的假设上：AI 真的能代替人。 @@ -35,3 +87,13 @@ toc = true 这样可怕的软件，甚至没有办法编写测试用例来保证稳定性。幻觉已经是陈词滥调了。既然传统的软件系统都没能消除人工，凭什么相信更加**不稳定**的技术可以？ +## 幕后的受害者 + +https://notabug.org/ + +https://www.debian.org/distrib/packages + +## Footnotes + +[^1]: Ghostty 的分屏快捷键，分屏后打开新的终端窗口 + -- cgit v1.2.3