渴望建立个人网站的作者们总是长久地纠结于该使用哪种博客引擎、选择哪种静态网站生成器、挑选哪种模板语言等等。我认为，在你的网站上发表至少五篇文章之前，这些都不重要。先写纯 HTML，以后再操心工具的事。

确实，很多作者花很多时间捣鼓博客的样式、构建等，但博客文章却寥寥无几。除非本身就是为了学习技术捣鼓博客构建，否则更重要的还是多写些内容，当写得足够多，能够保持一定频率输出的时候，再慢慢考虑构建、优化样式。很多时候，直接写 HTML 就够了。如果不想写 HTML，也可以用 Markdown 或任何喜欢的纯文本格式编写，用类似 Pandoc 的工具转换成 HTML。

总之，如果创建博客的的初衷是写文章，那就先写上几篇，再考虑其他事情吧。 (发现作者也用 Emacs，他的 Emacs for You (Emfy) 可以作为一份 Emacs 入门参考配置，解释也很详细。)

文章建议用纯文本发送邮件（为什么纯文本比 HTML 更好），列出了一些推荐的邮件客户端，以及指导设置这些客户端使用纯文本发送。

此外，文章还分享了一些邮件礼仪：

• 在适当的行宽换行，例如 72 个字左右，不要让一行的内容太长（一些邮件客户端会自动换行）

• 引用回复的时候，引用应该在上面，而不是下面。

  答：因为它颠倒了对话的逻辑顺序。
  问：为什么不建议在邮件顶部回复？
  

如今很多人都不愿意看长文，而读者愿意花时间把自己写的文章看完，确实可以和读者说一声「谢谢」。谢谢你来看我的博客，谢谢你阅读我的内容 :) 常来呀！

undernet.uy 是一个自托管、自管理的社区服务器，文章采访了其管理者 Santiago Roland，关于 undernet.uy 的创建缘由、运行情况。

文章是发布在 421 上的，这是一个刊物，涉及文化、技术、哲学、现实生活等方面，他们有三个主张：

1. 独立思考
2. 低科技，高生活（在采用每项技术前对其进行评估；当复杂性毫无益处时，宁可选择简单；并理解更好的生活并不需要任何事物的最新型号）
3. 数字自主

蛮有趣的刊物，里面也有大量有趣的信息。例如我从 You Already Pay for Internet, Don't Pay for the Rest 知道了 Soulseek，一个点对点 (peer-to-peer) 模式的音乐下载客户端。

这篇文章主要是关于 API 文档的，API 文档主要面向两类读者，一类是 API 的使用者，一类是 API 的维护者。对于使用者来说，他只需要知道怎么用，他不太关心背后的细节；对于维护者，他会关心更多为什么，希望尽可能多地了解 API 的设计细节，从而避免出错。两者对于文档的需求是不同的，使用者期望的是清晰简洁的文档，快速知道 API 的作用、需要什么参数、用例；维护者则期望更多技术细节，API 是怎么设计的、如何变迁的、为什么需要某个参数。一个糟糕的文档是企图平等地服务于这两类读者，结果就是，对于使用者来说不够简洁，不能快速浏览；对于维护者来说又不够深入和严谨。

作者认为，对于使用者，最好的文档首先是 API 本身，保持 API 的一致性，遵循清晰且可重复的模式，让用户可以推断 API 的使用。例如如果存在一个这样的 API /users/orders/1234/cancel ，如果设计的好的话，用户可以推断，可能也存在一个 /users/orders/1234/update API。其次，在写文档的时候要保持克制，不要阐述过多的细节，用户不需要知道你为了兼容旧版本的 API 做了什么，你只要告诉他「兼容旧版本」就足够了。作者的这句话我觉得讲得很精辟：「就像你不会为了解释每一行代码而写注释一样，文档也不会从过多的信息中获益。(Source)」

作者的建议是将额外信息折叠起来 (例如利用 <details>)，这样文档可以保持简洁，让使用者得以快速浏览获取信息；对于维护者，他们可以展开折叠部分，了解更多细节。而在文章组织上，也采取由浅入深的结构，先解释是什么，接着是怎么用，最后才是为什么，而「为什么」这个部分还可以折叠起来。作者又来了一个精辟的比喻：

把这想象成一个设计良好的错误信息。一条好的错误信息会用通俗易懂的语言告诉你出了什么问题。一条极佳的错误信息还会包含可展开的堆栈跟踪，但它不会先向你展示堆栈跟踪。

你的文档也承担着同样的工作。先给人们他们正在寻找的答案，然后为那些愿意深挖的人提供深度内容。

Source

另外考虑将给维护者看的内容拆分到别的文档里，通过拆分，可以保持使用者文档的简洁，而在编写维护者文档时也可以写得很深入，不用去考虑初学者。

文档的目标不是完整性。完整性是你写给自己的，为了让自己觉得完成了工作。文档的目标是在正确的时刻，将正确的信息传递到正确的人的脑海中。

Source

以我自己为例，我之前写过一篇关于 Emoji 正则匹配的文章，你可以对比一下前后两个版本：

• 2024 年 10 月 13 日归档版本：Emoji 正则匹配
• 当前版本：Emoji 正则匹配

在归档版本，关于「Unicode character class escpae」、一些 String 的相关方法是直接呈现在正文的，看起来内容很多，但会显得比较杂乱。这些属于补充信息，在当前版本里我放到了 <details> 里，读者感兴趣的话可以自己点开看，减少一些干扰。另外如果有人点进这篇文章，大概率是希望直接得到一个答案，而不是看我一顿分析，所以我在文章开头就给出了答案，如果读者只需要一个答案就可以关闭页面走人了，如果愿意了解背后的细节就可以继续往下看。

工作中可能会出现你「搞砸」了某些事情的时候，此时可能会有很大的情绪波动，比较常见的是给自己找借口掩盖事实，或者坦白错误、自贬身价并乞求原谅。不管是那种情绪，都不要在情绪冲动的时候做什么，先花一些时间让情绪平复下来，再理性地行动。

至于行动，则是客观地、实事求是地描述问题，及早告知相关人员，及早处理问题，总之不要掩藏问题。

根据我的经验，科技公司的经理会原谅错误，但他们不会原谅被当成傻瓜。特别是，他们不会原谅被剥夺了关键信息。

Source

文章分享了很多奠定了现代计算基础的人的故事，包括 Tony Hoare、Ada Lovelace、Edsger W. Dijkstra、Alan Turing、Grace Hopper、Dennis Ritchie、Brian Kernighan、Richard Stallman。这些都人都极具人文素养和人文精神，而不局限在计算机领域。

文章建议技术人员多涉猎人文方面的内容，除了关心「是否有效」，还应该关心「是否美好」。

Land Of Lisp 是 Conrad Barski 写的一本 Lisp 教程，这个网站是用来推销这本书的，蛮有趣的。

网站一开始是个视频，里面的歌词蛮有趣的：

Now I eat parentheses for breakfast.
And if my program isn't done,
I eat parentheses for lunch.

如果视频不足以打动你，作者还制作了漫画，讲述人类被 Bugs 征服，无论用 Java、C# 还是 ruby 等语言都无法击败 bugs，但在「Land Of Lisp」有强大武器可以击败任何 bugs，于是主角去「Land Of Lisp」寻求帮助。漫画里穿插了很多 lisp 的语法介绍，蛮有趣的。

除了 Land Of Lisp，还看到一本关于 Lisp 的书： The Genius Of Lisp。

马年快乐，来欣赏一下各种神奇的马。

错误交互的艺术 (The Art of Interacting Incorrectly) 是一个通过颠覆技术使用方式，挑战我们与技术之间无缝交互的项目。该项目借鉴了 Eadweard Muybridge 的 运动中的马 (A Horse In Motion)，通过非常规方法创作出各种赛马奔跑的动画，探讨了干扰技术如何能促进更具思考性和参与性的互动。通过将使用笔记本电脑的熟悉场景以陌生感呈现，其旨在为我们与日常数字化工具的体验重新注入一种新奇感。每一段动画都融合了所使用介质的局限性、独特性和质感。

你也可以来 画马 :P

MadCSS 是一场比赛，这次参加的有 16 位开发者，举办方会给出基础的 HTML 和目标 UI，选手只能使用 CSS 和 HTML，2 分钟构思、15 分钟实现，最后谁的实现和目标 UI 最接近谁就获胜。

决赛视频： One Last Battle (16:59) by Syntax

在你隔壁同事起身去洗手间的空隙，在他电脑上装上一个可执行文件 Git Shitstorm，然后修改 git 指令，变成 alias git='git-shitstorm && git' 。 Git Shitstorm 在 90% 的时间里都是正常的 git 操作，但有 10% 的概率会从仓库里提取内容然后提交少量改动，这会让你的同事摸不着头脑，他肯定很难发现你改了 git 命令，每次他尝试修复，也有概率触发 git-shitstorm，可以让你的同事非常抓狂，哈哈哈。

以上只是玩笑，真这么干了，被同事爆揍一顿，或者被辞退了可不怪我。为了避免被同事这么搞，离开工位的时候记得锁屏 :)

作者经常被问到，应该学习 C++ 还是 Java？

答案是应该都去学，都去尝试和接触一下，编程是需要终身持续学习的，不是选择了一门语言就一劳永逸。

作者观察了几个成熟的项目，发现它们慢慢放弃了 Tailwind，转而拥抱原生 CSS 的实现。原生 CSS 已经足够强大，它不需要额外构建，也可以让类名可读性更好（不过命名是个难题）。

文章里的 <mark> 样式很不错，抄了，你可以在 搜索页 玩玩看。如果你也用 pagefind，并且也打算使用这个样式，可以参考 我的步骤。

当在公司里看到一个「烂项目」要不要去给这个项目的人提出建议？

是否提建议，要评估「烂项目」对自己和公司的影响程度；也取决于自己是否能够介入（无法介入也可以做一些防御措施）；以及自己是否真的具备做出判断的专业知识。

文章中关于影响力的说法蛮有趣的，作者说把影响力当作一张储蓄卡，当你帮助别人的时候就会获得一定的影响力额度，而有些事情会消耗影响力，不同的事情需要的额度不同，只有当你的储蓄额度足以支持你的花费时，你才能影响别人。相反，如果储蓄额度为零，甚至负债，你可能还会受到很多阻碍。

作者分享了 5 个他在阅读代码前会执行的 Git 命令，挺实用的。

作者分享了她是如何记忆 Markdown 的链接和图片链接语法的：

利用谐音：「Put the path in parentheses.」既然链接在括号里，那描述文字自然就只能在方括号里了。而拍照的时候，往往会大喊一声「茄子！ (Cheese!)」，所以图片就在前面补一个 ! 就好了。

我也想了一个：

Markdown 链接是先写方括号还是括号呢？我想到「方括号」里「括号」两个字是在「方」的后面，所以应该先写方括号，再写括号。链接中必不可少的是 URL，URL 放哪里呢？ 放「括号」里呀，所以是放到后面的括号里。

原来标题的字号大小有排版比例，学习了。

作者通过 CSS 动画，不依赖任何 JS，使得元素能够记住 focus 和 hover 的状态。

.remember-focus {
  animation-name: remember-focus;
  animation-duration: .00001s;
  animation-timing-function: linear;
  animation-fill-mode: forwards;
  animation-play-state: paused;
}


.remember-focus {
  animation: remember-focus .00001s linear forwards paused;
}

.remember-focus:focus {
  animation-play-state: running; (running)
}

@keyframes remember-focus {
  from {
    background: red;
  }
  to {
    background: blue;
  }
}

很佩服作者能够想到这样的思路！

一篇解释 JPEG 压缩原理的交互式文章。

JPEG 是一种巧妙的图像压缩算法，它利用了人类的感知偏差和自然图像的结构。它在编码前进行基变换，使得重写后的图像表示集中了人类最敏感的信号 (亮度)，从而可以丢弃剩余的细节，而不会严重降低视觉保真度。

Source

文章分享了几个很不错的组织 z-index 的方法。

1. 使用 CSS 变量命名 z-index。这样当需要给 toast 设置 z-index，就直接用 var(--z-toast) ，而不用纠结具体数值。
2. 对于同一个 z-index 层级內的元素，考虑用 --z-top 、 --z-bottom 去进一步做区分。
3. 使用相对值： calc(var(--z-overlay) - 1) 。

另见： Unstacking CSS Stacking Contexts by Gabriel

LLM 可以快速地产出代码，如果一味追求速度，可能也在快速地积累代码负债。作者建议慢下来，参与架构、API 的代码实现，而不是全部委托给 LLM，从而保持对代码库的理解和掌控感。

既然我们已经有了能够编写可用代码的软件，那么我们人类还剩下什么可做的呢？

答案是：还有太多事情要做。

编写代码从来不是软件工程师的唯一活动。这门手艺的核心一直是弄清楚该写什么代码。任何给定的软件问题都有数十种潜在的解决方案，每种方案都有其权衡。我们的工作是权衡这些选项，并找到最适合我们特定环境和要求的方案。

Source

编程其实是一种思维方式，也是一种沟通方式。你是用汇编，还是用 C 语言，还是用自然语言去指挥计算机，关系都没有那么大。关键在于，你有没有真正的编程思维。你能不能把问题拆开，能不能描述边界，能不能发现错误，能不能一步一步把系统构建出来。如果这些能力没有，那就算你手写汇编，也未必是一个真正会编程的人。如果这些能力有了，那你不管是写 C，写 Python，还是和 AI 对话，本质上都是在编程。所以我越来越觉得，未来真正重要的，不是你会不会某一种语言，而是你有没有计算机的编程思维。

Source

向 AI 模型输入提示词并不等同于阐述观点。你虽然能得到生成的结果，但就构思而言，这些结果是可有可无的。真正重要的是思考的过程。

Source

如果是和 LLM 对话，探讨某个问题，从而加深或拓宽自己对问题认识，我想 LLM 还是有帮助的。

我从事这一行已经很多年了，工作中最困难的部分从来都不是敲击键盘写代码。我最头疼的始终是理解系统、调试那些莫名其妙的错误、设计在高负载下不会崩溃的架构，以及做出能避免日后数月痛苦的决策。

这些问题都不是大语言模型所能解决的。它们可以提供代码建议、帮助编写样板代码，有时还能充当探讨想法的参谋。但它们并不理解系统，它们的「脑子」里没有上下文，更不知道为什么某个决策是对还是错。

最重要的是，它们不会做选择。这部分工作仍然属于你。软件开发的真正核心，也是体现个人价值的地方，在于从一开始就知道应该构建什么，以及为什么要构建它。

Source

真正的危险在于人们停止思考。真正的陷阱是工程师让工具去承担本该由他们自己构建的认知负荷 ⸺ 这是理性的自我放弃。

Source

AGENTS.md 是项目根目录的一个文件，提供持久的上下文信息。 Skills 是一系列的 markdown 文件，封装了相关领域知识，提供给模型在需要时查阅。

但是 Skill 没法保证可靠的触发，有时模型并不会查阅 Skills，相比而言 AGENTS.md 是模型始终会去加载的，会更稳定。有的事情 Skills 做不好的话，可以试试放到 AGENTS.md 中，比较一下效果。

人工智能代理已经太像人类了。这并不是在浪漫的意义上，不是因为它们会爱、会恐惧或会做梦，而是在更平庸、更令人沮丧的层面上。目前的实现方式一次又一次地展示了它们的人类起源：缺乏严谨性、缺乏耐心、缺乏专注力。面对棘手的任务，它们会向熟悉的领域漂移。面对硬性约束，它们开始与现实讨价还价。

Source

• Claude HUD 一个 Claude Code 插件，用于展示 Claude Code 的使用信息，如上下文用量、启用的工具、进度等。
• Awesome DESIGN.md 这个仓库收集了很多 DESIGN.md，可以丢给 Agent 指导它设计页面。
• Hermes Agent 一个会自我学习、改进的 Agent。
• thedotmack/claude-mem 一个 Claude Code 插件，自动压缩上下文作为后续的上下文，保持项目上下文的连续性。
• Vibe Kanban Agent 编排工具，另见 工程师如何把多个 Coding Agent 真正带起来：一套比“开更多聊天窗口”更像工程流程的方法 by 白宦成
• manaflow-ai/cmux 一款基于 Ghostty 的 macOS 终端，具备垂直标签页以及面向 AI 编程智能体的通知功能。

Just below the surface of these inchoate intuitions, I believe, is a tacit awareness that the writer’s goal is to encode a web of ideas into a string of words using a tree of phrases. Aspiring wordsmiths would do well to cultivate this awareness.

我认为，在这些模糊直觉的表象之下，隐藏着一种心照不宣的领悟：作者的目标，在于借助层级分明的短语结构，将纷繁交织的思绪编织成线性的文字。有抱负的文字工作者应当刻意培养这种意识。

另一个更常见的表达：

写作之难，在于把网状的思维，通过树状的结构，用线性的文字展开。

来自豆瓣 2026 周历第十三周

人们总在讨论驱动 Bluesky 和 ActivityPub 的协议，因为我们都是技术宅，内心深处坚信更优越的协议终将胜出。这想法挺天真的。它完全违背了人类历史 ⸺ 无论技术水平如何，更方便的东西总是会赢。

Source

我从未想过会从一个半数网民都没听说过的联邦式社交网络上(federated social network)的陌生人那里获取新闻。我从未预料到很多事情。但在这样一个地方，人们只是……分享他们所知道的东西，这其中有一种宁静的美感。没有品牌合作，没有互动指标，没有算法诱导你走向愤怒。只有一位研究了二十年北极政策的人，在凌晨两点发帖，仅仅是因为他们觉得你应该了解正在发生的事情。这就是我在 1996 年得到承诺的那个互联网。为了到达这里，竟然花了三十年的时间，并经历了美国新闻业的彻底崩塌。

Source

在雨中做事并不舒服，至少在需要鼓起意志力开始工作时是这样。不过，过去的经验很有帮助，因为你知道最初的不适感很快就会消失。难点在于，不要在最初的几秒钟内丧失决心。有一个充分的行动理由也很有帮助，甚至是必不可少的：它迫使你走出舒适区，让你更投入地追求积极的结果。如果你不相信这项事业，你就很难应对挑战。信念赋予了一个人战胜一切困难的力量。

支撑我努力的是对自身处境的长期理解。我不认为安逸是理所当然的。生活从来都不容易，除非是在婴儿时期受父母照顾的时候。我接受所有中间过程中的问题，将它们视为我生命这一宏大进程的一部分。我有自己的土地，并随之不断改进。它最终会成为一个体面且安全的地方。就像一颗橡子发育成脆弱的幼苗，然后长成纤细的小树，直到最终成为一棵雄伟的橡树。

[…]

当你处于「行动」模式时，耐心是自然而然的。[…]

相反，当你仅停留在抱负和痴心妄想的层面时，你没有参考标准，对有限资源的经济性缺乏感知，因此也就没有耐心的空间。 […]

Source

我不谈论我的生活选择。我没兴趣让任何人改变观点或接受我的生活方式。我为什么戒酒是我自己的事：简而言之，比起在餐桌上赢得那些毫无意义的关注，我更看重长期健康。

Source

我的生活方式可以概括为「多做少说」，或者更确切地说是「先精通，后传授」。如果我认同某种理念，我会将其融入到我的行动中。如果它是行之有效的，那么我本身就是其功效的化身。我不需要宣扬显而易见的事。他人自然会注意到效果并尝试效仿。如果他们看不出其中的门道，那说明他们还没准备好。我觉得脱离行动的空谈会削弱人的力量，它不可避免地会演变成过度思考和随之而来的焦虑不安，陷入恶性循环。

Source

当客户找上你的聊天机器人时，并不是因为他们觉得聊天机器人很酷，而是因为你让他们失望了。

在整个过程中，由于某些原因，他们找不到物流信息。他们在迷宫般的常见问题解答（FAQ）中迷失了方向。他们在尝试解决一个简单问题时遇到了阻碍。当他们打开聊天窗口时，已经感到沮丧或困惑。他们不想要另一层复杂性，他们想要一个快速、简单的解决方案。

你的聊天机器人只是覆盖在你造成的伤口上的一块止血贴。去修复你的用户界面吧。让信息易于查找。停止将基础功能隐藏在菜单和迷宫之后，到头来你可能根本不需要那个昂贵的聊天机器人。

Source

Good artists borrow, great artists steal.

我访问《纽约时报》想扫一眼四条新闻标题，结果迎面而来的是 422 个网络请求和 49 MB 的数据。页面足足花了三分钟才稳定下来。这也难怪每个神智正常的科技从业者都会在亲友的系统上安装广告拦截器。

为了真正理解 49 MB 网页是什么概念，让我们快速回到几十年前。加载这个页面所消耗的数据量已经超过了 Windows 95（28 张软盘）的大小。那个曾经运行全球的操作系统，竟然能完美塞进如今的一个网页加载量中。 2006 年，iPod 占据统治地位，数字音乐弥足珍贵。一首 192 kbps 比特率的标准高质量 MP3 歌曲大约占用 4 到 5 MB。这一个页面大约相当于 10 到 12 首完整长度的歌曲。我为了读几段文字，实际上下载了相当于一整张专辑的数据。根据 国际电信联盟 的数据，当时的全球平均宽带网速约为 1.5 Mbps。你的浏览器会持续加载这个「庞然大物」好几分钟，这段时间足够你走开去冲杯咖啡了。

Source

前阵子我把字体移除了，使用系统默认字体，目前一个页面一般也就几百 KB (有的页面有图片就会大一些)，相比之前应该是会快一些。

幽灵塔

挽救计划 Project Hail Mary (2026)

超时空辉夜姬！ 超かぐや姫！ (2026)

作画精美的一部动画，喜欢里面的人物形象和声优的声音。音乐也不错，看了一下演唱是 ryo，难怪觉得好听，因为 supercell 的声音和歌我就很喜欢。剧情一般，没啥触动。什么时候也能像动画一样进入虚拟世界玩耍就好了。

接近终点 Sirât (2025)

春天情书 （ハル） (1996)

制片人 The Producers (1967)

迈克尔·杰克逊：巨星之路 Michael (2026)

异国日记 違国日記 (2026)

一部治愈系动画，节奏比较慢，讲述了双亲意外身亡的「朝」寄居在她的阿姨「槙生」家中，慢慢从悲伤和困惑中走出来的故事。里面的角色都挺喜欢的，尤其是「槙生」这个角色。

• 133. 对谢赛宁的7小时马拉松访谈：世界模型、逃出硅谷、AMI Labs、两次拒绝Ilya、杨立昆、李飞飞和42 (405 mins) by 张小珺Jùn｜商业访谈录

  文字版： 独家对话谢赛宁：逃出硅谷！ by 语言即世界 language is world

• 喜欢什么一定要说出来 2.0 (114 mins) by Nice Try
• E104 2030 年的世界：起初，人们以为只是失业 (73 mins) by 虚实之间 True Imagination

Balatro

宇宙機器人