docs: update weekly

1 files changed, 5 insertions, 8 deletions

diff --git a/content/weekly/72.md b/content/weekly/72.md
index fb708487..91709c2f 100644
--- a/content/weekly/72.md
+++ b/content/weekly/72.md
@@ -2,7 +2,7 @@
 title = "稻草人周刊 Vol.72"
 subtitle = ""
 tags = []
-date = 2026-03-11 19:02:39
+date = 2026-03-15 21:30:33
 draft = true
 toc = true
 +++
@@ -57,7 +57,7 @@ toc = true
 
 作者在这篇文章中对比了 Org Mode 和其他标记语言（Markdown、AsciiDoc、Wikitext 和 reStructuredText）的区别，以及为什么他认为 Org Mode 比这些标记语言更具优势、更合理。
 
-文章前半部分的观点我很认同。首先，Org Mode 是规范化的，而 Markdown 却有很多不同的 Flavor，在不同的平台上输入 Markdown 得到的结果不总是一样的，比如 Markdown 很常见的表格就是拓展语法而非最初的标准。我自己也依赖一些并不常见的 Markdown 拓展语法，比如 Obsidan 里常用的 `==高亮标记==` 和 GitHub 上常用的 [Alert](https://github.blog/changelog/2023-12-14-new-markdown-extension-alerts-provide-distinctive-styling-for-significant-content/)，这两个语法都被 Hugo 支持，所以我在博客里也经常用，但是在其他地方就不一定了。这的确是 Markdown 的缺陷之一，不够标准化。
+文章前半部分的观点我很认同。首先，Org Mode 是规范化的，而 Markdown 却有很多不同的 Flavor，在不同的平台上输入 Markdown 得到的结果不总是一样的，比如 Markdown 很常见的表格就是拓展语法而非最初的标准。我自己也依赖一些并不常见的 Markdown 拓展语法，比如 Obsidan 里常用的 `==高亮标记==` 和 GitHub 上常用的 [Alert](https://github.blog/changelog/2023-12-14-new-markdown-extension-alerts-provide-distinctive-styling-for-significant-content/)，这两个语法都被 Hugo 支持，所以我在博客里也经常用，但是在其他地方就不一定了。这的确是 Markdown 的缺陷之一。
 
 其次，Org Mode 的行内标记是符合直觉的，`*加粗*` `/斜体/` `_下划线_` `~代码~` 和 `=等宽字=` 都很容易记住，是唯一的语法，而且都是一前一后的单个字符，不像 Markdown 有 `_斜体_` 和 `*斜体*` 两种写法，而 `**加粗**` 和 `~~删除线~~` 居然需要一前一后的双字符进行标记，和其他行内标记不统一。说实话，我之前尝试 Org Mode 时，就挺搀它的行内标记语法的。
 
@@ -67,13 +67,13 @@ toc = true
 
 我认为「我容易忘记语法的顺序」并不是很有说服力的论据，因为我认为 Org Mode 用户能记住 `[[链接][文字]]`，和 Markdown 用户能记住 `[文字](链接)` 的方式一样：见多了就记住了，不是因为哪个语法更符合直觉。两边都有各自的优势和缺陷，仅仅是个人偏好和习惯问题。
 
-我尝试过 Org Mode，其中一部分我很喜欢，另一部分则很不习惯。我最不能接受的是 Org Mode 对中日韩文字的支持，它不能解析 `这样的*加粗*文字`，因为 Org Mode 的行内标记前后必须有空格，这显然是欧洲语言的使用逻辑，中文里就是很少用空格。其次，它不支持我很爱用的 `~~删除线~~`。再次，标准化是好事，但拓展性差也是问题，我没办法用 `==高亮标记==` 这种拓展语法。
+我尝试过 Org Mode，其中一部分我很喜欢，另一部分则很不习惯。我最不能接受的是 Org Mode 对中日韩文字的支持，它不能解析 `这样的*加粗*文字`，因为 Org Mode 的行内标记前后必须有空格，这显然是欧洲语言的使用逻辑，中文里就是很少用空格。其次，标准化是好事，但拓展性差也是问题，我没办法用 `==高亮标记==` 这种拓展语法。再次，你们是怎么忍受 `#+BEGIN_SRC` `#+END_SRC` 这种写法的？这跟 Markdown 的 \`\`\` 比难道不是长得多吗？和 `~行内代码~` 也没有连贯性（反而 Markdown 可以写 `~~~` 标记代码块）。
 
 不过，读完这篇文章过后，我的确产生了很多思考，其中之一是：标记语言本身真的有好坏之分吗？我认为，就和代码风格一样，有的风格固然是不好的，比如可读性很差的风格，但有的风格很难分个高下，比如 `{}` 应不应该换行写、缩进应该用空格还是制表符、文件末尾应该不应有空行，标记语言也有很难说是好是坏的语法。用于写配置的标记语言 YAML 和 TOML 也是一样，有人认为 [YAML 有诸多缺陷](https://www.arp242.net/yaml-config.html)，而 [TOML 的缺陷](https://hitchdev.com/strictyaml/why-not/toml/)也有人能列出来不少。
 
 你猜怎么着？没有一门标记语言是完美的，包括 Org Mode 和 Markdown。
 
-如何选择标记语言，应该由使用者自己尝试、权衡和决定，不存在「最合理且对所有人都同样合理」的语言。或许，可以开发一种与 Vim 和 Emacs 类似的标记语言，人们可以自己写配置，调整各种语法，自己创造最适合自己的语言。
+如何选择标记语言，应该由使用者自己尝试、权衡和决定，不存在「最合理且对所有人都同样合理」的语言。或许，可以开发一种自定义程度极高的标记语言，人们可以自己写配置调整语法，自己创造最适合自己的语言，就像配置编辑器一样。
 
 ### 「结果啊……」
 
@@ -101,7 +101,7 @@ toc = true
 > please ignore and sorry for that <br/>
 > 请忽略，抱歉。
 
-作者意识到「互联网已死」已经成现实了：Hacker News 开始限制新用户发表 ShowHN，因为最近出现了太多 Vibe Coded 且低质量的投稿； Reddit 上有很多机器人在评论区发帖宣传 SaaS 产品；LinkdIn 上的更新也是 AI 废料占大多数（作者贴的一条 LinkdIn 帖子的截图，帖子上全是些让人抓不住重点的车轱辘话，居然有两百多条评论和五千多个点赞；GitHub 也逃不过，AI 生成的 Pull Request 下的代码审查和回复竟然也是 AI 生成的。
+作者意识到「互联网已死」已经成现实了：Hacker News 开始限制新用户发表 ShowHN，因为最近出现了太多 Vibe Coded 且低质量的投稿； Reddit 上有很多机器人在评论区发帖宣传 SaaS 产品；LinkdIn 上的更新也是 AI 废料占大多数（作者贴的一条 LinkdIn 帖子的截图，帖子上全是些让人抓不住重点的车轱辘话，居然有两百多条评论和五千多个点赞）；GitHub 也逃不过，AI 生成的 Pull Request 下的代码审查和回复竟然也是 AI 生成的。
 
 对此我的态度是，我就待在小互联网上好了，与大平台保持距离，和自己选择的真实的人社交。说实话，我一旦在 RSS 更新中看到了 AI 生成的内容，我就会直接把这个订阅源删掉。
 
@@ -171,7 +171,4 @@ Twitter 和 Mastodon 自带的嵌入卡片可能和网页的风格不统一，�
 
 访问：[LibreSprite](https://libresprite.github.io/)
 
-## 切片
-
-
 [^1]: aseprite 是开源的商业软件，买断价格是 $19.99。如果不想花钱，也可以自己从源代码编译，可以合法地免费使用。不过，尽管开源，aseprite 并不是自由软件。