docs: update markdown files

Former-commit-id: 0ea52b91db6a96b40f01e07f65344f034e9359c2

1 files changed, 107 insertions, 0 deletions

diff --git a/content/_drafts/62.md b/content/_drafts/62.md
new file mode 100644
index 00000000..789d09b1
--- /dev/null
+++ b/content/_drafts/62.md
@@ -0,0 +1,107 @@
+---
+title: 稻草人周刊 Vol.62
+subtitle:
+tags:
+  - AI
+  - 编程
+  - 写作
+date:
+categories: 稻草人周刊
+draft: true
+toc: true
+---
+
+{{< music cover="https://image.guhub.cn//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 的狂热已经让他们开始忽视早就存在的、更好的解决方案了。==
+
+## ⁂ · 星群
+
+## ◍ · 穿越
+
+## ↯ · 当下
+
+### 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)。
+
+![](https://image.guhub.cn//uPic/2025/12/29160515-TZMvZz.png "鼠鬚管的输入法菜单，不过为什么图标是海王星的占星符号呢？")
+
+可能需要用新输入法写过长文之后才能明白有好词库的爽感，目前比较令我惊喜的点是 macOS 的各种版本名居然也在词库里。
+
+![](https://image.guhub.cn//uPic/2025/12/29160137-CMUK0v.png)
+
+[^1]: 还在用 Windows 的时候其实有尝试过，但当时还是个麻瓜，没折腾多久就放弃了。
+
+[^2]: 详见：《[关于一切的纯文本解决方案指南](/essays/everything-in-plain-text/)》