木

木鸟杂记

https://www.qtmuniao.com

https://www.qtmuniao.com/atom.xml (RSS订阅地址)

工程中的经典“意象”（一）：滑动窗口

<blockquote> 在古诗文中，我们以月喻离合、以水比时光、以柳寄别恨。在软件工程中，我们以管道贯通有无、以缓存平峰谷、以协议定不变。前者我们称为意象，《文心雕龙·神思》篇中写道：“独照之匠，窥意象而运斤”；后者我们叫做隐喻，《代码大全》（Code Complete）中将隐喻视为一种启发式方法（heuristic），用以在抽象与具象之间架设桥梁。 我们如此习惯于意象和隐喻，是因为“人类思维本质上是隐喻性的”（出自莱考夫和约翰逊在《我们赖以生存的隐喻》）。其特点是，将一类场景相关的上下文传神地压缩进一个词语中。比之于精确的算法，它模糊但强大，所谓 “运用之妙，存乎一心”。 我想通过一系列小文来收集我在实践中反复看到的一些有趣意象，本篇来聊聊滑动窗口。 </blockquote> <h1>引子</h1> 前几天听罗振宇的历史播客《文明之旅》时，讲到故宫博物院的传世名画——北宋末年宫廷画家王希孟的《千里江山图》。它除了有名外，另外一个特点就是——特别长，几近十二米（1191.5 厘米）！在中国古代书画中，这种"横长纵短、边展边看"的形式叫手卷（还有竖挂的立轴和分页的册页）。 手卷适合三两好友慢慢撵卷细品。这种前手展、后手收、只关注窗口内的“景色”的经典场景便正是软件工程中最经典的意象之一——滑动窗口。下面依时间线来聊聊我在接触编程后遇到的相关场景。 <img src="https://files.seeusercontent.com/2026/07/12/z1sW/c348508.png" alt="展卷窗口">

2026/7/12

一个大模型从业者的 Vibe Coding 一些一线经验

从第一个我体感“有点不一样”的 Code Agent —— Claude Opus 4.5 发布（2025年11月24日）以来，竟然才过去半年。但在这半年里，基本所有能被程序化、自动化的工作，都受到了前所未有的冲击。我们这个以代码为生的群体更是被当头棒喝，周围即使最保守的程序员，也在“卧槽”声中做了调整和转向。 现在深处漩涡中，去预测 AI 带来的社会层面变化，是我万万力所不及的。本篇只想稍稍记录下最近将 Agent 嵌入工作流的一些体验，以待将来回忆起有所凭借，零零碎碎，林林总总。主要从工作模式变迁，如何管理 Agent 和上下文，如何创建和管理 Skill 等方向聊一些一个大模型人的一线体感和经验。 <img src="https://files.seeusercontent.com/2026/06/16/k2kJ/sync-async.png" alt="同步到异步">

2026/6/16

大模型的损失函数为什么是交叉熵

<h1>引子</h1> 刚入门大模型的时候，由于线性代数、概率论和信息论等数学知识的短板，很容易迷失在诸多术语中：logprob（对数概率）、likelihood（似然）、NLL（Negative Log Likelihood，负对数似然）、cross entropy（交叉熵）、perplexity（困惑度）。它们常常出现在论文和文档的各种角落里，但都像点赞之交的朋友，频见其名，不解其意。 后来某天，在慢慢的补过一些最基础的数学知识后，在公司相关的上下文浸淫足够久后，终于在某次和 ChatGPT 的聊天中发现：上面一组概念本质上是同一件事的不同面向的侧写。从概率论的门摸进去叫 NLL，从信息论的门踏进去叫交叉熵，从 PyTorch 的门看进去叫 <code>F.cross_entropy</code>——殊途同归，本质上都是在试图刻画"模型当前输出离预期还有多远"。 “横看成岭侧成峰”，在大模型这种高维上下文的领域中，这种盲人摸象的感觉所在多有。不过我们这种三维生物，也只能靠长久的浸淫，才能靠着不同领域知识的交叉验证，才会突然有一天顿悟——嗷，原来这是同一座山。 本文想做的，就是想聊聊大模型领域中最基础概念——交叉熵这个损失函数的“一花各表”。 <img src="https://files.seeusercontent.com/2026/04/19/a7Py/NLL-entropy.png" alt="NLL-entropy.png">

2026/3/29

Why Is the Loss Function of Large Models Cross-Entropy

<h1>Prologue</h1> When first entering the world of large models, due to gaps in foundational math knowledge such as linear algebra, probability theory, and information theory, it’s easy to get lost among numerous terms: logprob (log probability), likelihood, NLL (Negative Log Likelihood), cross entropy, perplexity. They frequently appear in various corners of papers and documentation, yet they all feel like acquaintances you only know by name — you see them often, but don’t truly understand them. Then one day, after slowly catching up on some basic math knowledge and immersing myself in the company context for long enough, I finally realized during a chat with ChatGPT: the above set of concepts are essentially different perspectives of the same thing. Enter through the door of probability theory and it’s called NLL; step through the door of information theory and it’s called cross entropy; look through the door of PyTorch and it’s <code>F.cross_entropy</code> — different paths leading to the same destination, all essentially trying to characterize “how far the model’s current output is from the expected result.” “Viewed from the side, a mountain looks like a ridge; viewed from the end, a single peak” — in a high-dimensional field like large models, this feeling of blind men touching an elephant is everywhere. But we three-dimensional creatures can only rely on long-term immersion, cross-verifying knowledge from different domains, until one day we suddenly have an epiphany — ah, so this is the same mountain. What this article aims to do is talk about the most fundamental concept in the large model domain — the “many faces” of cross entropy as a loss function. <img src="https://files.seeusercontent.com/2026/04/19/a7Py/NLL-entropy.png" alt="NLL-entropy.png">

2026/3/29

20260120 B 站直播 —— 转行大模型文字精要

<blockquote> 我是 2024 年初到一家大模型公司工作，之前一直在数据库、存储等 infra 行业工作，因此有些很粗浅的转行认知。很久没有在 b 站做分享了，这次靠直播强制开机，回答了大家一些问题，稍稍弥合一点信息差。本文对直播中提到的一些点的稍微规整一点的总结，并将一些我觉得不错的资料附在最后。 b 站直播：<a href="https://www.bilibili.com/video/BV1uckJBkEto">https://www.bilibili.com/video/BV1uckJBkEto</a> </blockquote> <img src="https://s2.loli.net/2026/01/25/p5hVJcA4ytHolCf.png" alt="题图">

2026/1/25

20260120 Bilibili Live — Key Takeaways on Switching to LLMs

<blockquote> I joined an LLM company in early 2024, having previously worked in the infra industry (databases, storage, etc.), so I have some very basic insights on switching careers. I haven’t shared on Bilibili for a long time; this live stream forced me to get back in gear. I answered some of your questions and bridged a bit of the information gap. This post is a slightly more organized summary of some points mentioned during the stream, with some materials I find valuable attached at the end. Bilibili live stream: <a href="https://www.bilibili.com/video/BV1uckJBkEto">https://www.bilibili.com/video/BV1uckJBkEto</a> </blockquote> <img src="https://s2.loli.net/2026/01/25/p5hVJcA4ytHolCf.png" alt="Cover image">

2026/1/25

2025 年终总结——向内生长

有明显的自我意识以来，从没有像今年这样和世界、和自己发生如此激烈的冲撞，但结果很神奇——反倒更加平和了。很多下意识的反应、很多习以为常的做法，向内挖时，竟然都能摸出如此久远的强化链路。正如史铁生说的——那颗年少时射出的子弹，在长到这个年纪的时候，正中眉心。 于是，不管是被迫地还是自发地，今年都开始难以避免地向内生长——如格物致知一般去观察和追溯自己细微的情绪变化源头，见天地、见众生，终是为了见自己。虽然以前惯性还会持续一段时间，但觉察的开始，便是塑造另外轨迹的种子。 <img src="https://photo.tuchong.com/15470921/wp/672288214.jpg" alt="佛光寺经幢和东大殿">

2025/12/28

2025 Year-End Summary — Inward Growth

Since becoming distinctly self-aware, never have I clashed so intensely with the world and with myself as I have this year—yet the result is strangely magical: I have become even more peaceful. Many subconscious reactions, many habitual practices, when excavated inward, can be traced back to such ancient reinforcement chains. Just as Shi Tiesheng said—the bullet fired in youth strikes squarely between the brows at this age. Thus, whether forced or spontaneous, this year has become an inevitable journey of inward growth—observing and tracing the subtle origins of my emotional shifts, as in the investigation of things to extend knowledge. Seeing heaven and earth, seeing all beings, ultimately serves to see oneself. Although old inertia will persist for some time, the beginning of awareness is the seed that shapes a different trajectory. <img src="https://photo.tuchong.com/15470921/wp/672288214.jpg" alt="Foguang Temple's Sutra Pillar and East Main Hall">

2025/12/28

深入理解大模型 1：Transformer，大模型的基石

<blockquote> <a href="https://princeton-cos597r.github.io/">Princeton COS 597R “Deep Dive into Large Language Models”</a> 是普林斯顿大学的一门研究生课程，系统探讨了大语言模型原理、准备和训练、架构演进及其在多模态、对齐、工具使用等前沿方向中的应用与一些问题。注意，该课程侧重概念的理解上，而非工程的实现上。 我之前是在分布式系统和数据库内核方向，但这两年转到一家大模型公司做数据。本笔记主要是我对课程论文的梳理和精要。不同的是，我会结合在工作中解决实际问题的一些体感，给出一点转行人不同视角的思考，希望能对同样想从工程入门算法的同学一点帮助。 本文来自我的付费专栏《<a href="https://xiaobot.net/p/system-thinking">系统日知录</a>》，欢迎订阅查看更多大模型解析文章，文末有优惠券信息。 </blockquote> 本篇主要关注大模型的奠基之作——Transformer。 首先要明确问题域，Transformer 试图解决的是序列建问题，最主要的代表就是语言建模和机器翻译。其次，需要知道前驱方法—— RNN（循环神经网络）和 CNN（卷积神经网络）存在的一些问题，才能知道 Transformer 的创新之处。最后，Transformer 的解决要点的在于“多头注意力机制”和“位置编码”。

2025/9/10

Deep Dive Into Large Models 1: Transformer, the Foundation of Large Models

<blockquote> <a href="https://princeton-cos597r.github.io/">Princeton COS 597R “Deep Dive into Large Language Models”</a> is a graduate course at Princeton University that systematically explores the principles of large language models, their preparation and training, architectural evolution, and applications in cutting-edge directions such as multimodality, alignment, tool use, and related issues. Note that this course focuses on conceptual understanding rather than engineering implementation. I previously worked in distributed systems and database kernels, but in the past two years I moved to a large model company to work on data. These notes mainly consist of my organization and distillation of the course papers. What’s different is that I will combine some hands-on experience from solving practical problems at work, offering a bit of thinking from a career switcher’s perspective, hoping to help those who also want to enter algorithms from an engineering background. This article comes from my paid column “<a href="https://xiaobot.net/p/system-thinking">System Thinking Daily</a>”. Welcome to subscribe for more large model analysis articles; coupon information is at the end of the article. </blockquote> This article mainly focuses on the foundational work of large models — Transformer. First, we need to clarify the problem domain: what Transformer tries to solve is the sequence modeling problem, with the main representatives being language modeling and machine translation. Second, we need to know the problems existing in predecessor methods — RNN (Recurrent Neural Network) and CNN (Convolutional Neural Network) — in order to understand the innovation of Transformer. Finally, the key points of Transformer’s solution lie in the “multi-head attention mechanism” and “positional encoding”.

2025/9/10

在云上进行大规模数据处理的一些实践

随着云基础设施的不断成熟，新兴的公司为了快速实现业务目标，一般都会让基础设施上云。而在云上进行开发与传统上直接使用物理机开发其实有很大不同。云上更强调共享和弹性，此外，规模变大又会带来隔离性。这些改变也倒逼我们在进行开发时做出一些改变。在云上进行大规模数据处理，我主要有一些 spark 和 ray 的经验，使用的语言主要是 python；从这些技术栈出发，谈谈一些还算行之有效开发实践。 使用 ray 在云上进行大规模数据处理，一个基本的思路是：构建最小可并行单元，进行功能测试和性能测试，然后再利用 <a href="http://ray.data">ray.data</a> （比如 <a href="https://docs.ray.io/en/latest/data/api/doc/ray.data.Dataset.map.html">map</a>，<a href="https://docs.ray.io/en/latest/data/api/doc/ray.data.Dataset.map_batches.html">map_batches</a> ）进行 scale。使用 spark 时，会稍有不同；相比 ray，spark 虽然灵活性稍差一些，但抽象封装更好，可以从数据集整体的角度来考虑数据处理，spark 会通过你设置的分区数和并行度，自动地扩展和容错。

2025/6/4

Some Practices for Large-Scale Data Processing on the Cloud

As cloud infrastructure continues to mature, emerging companies typically move their infrastructure to the cloud in order to achieve business goals quickly. Developing on the cloud is actually quite different from traditional development using physical machines directly. The cloud emphasizes sharing and elasticity more, and as scale grows, isolation becomes important as well. These changes also force us to make some adjustments when developing. For large-scale data processing on the cloud, I mainly have experience with Spark and Ray, using Python as the primary language. Starting from these technology stacks, I’d like to share some development practices that have proven to be fairly effective. When using Ray for large-scale data processing on the cloud, the basic idea is: build the minimum parallelizable unit, perform functional and performance testing, and then scale using <a href="http://ray.data">ray.data</a> (e.g., <a href="https://docs.ray.io/en/latest/data/api/doc/ray.data.Dataset.map.html">map</a>, <a href="https://docs.ray.io/en/latest/data/api/doc/ray.data.Dataset.map_batches.html">map_batches</a>). When using Spark, it’s slightly different; compared to Ray, Spark is somewhat less flexible but has better abstraction and encapsulation. You can think about data processing from the perspective of the dataset as a whole, and Spark will automatically scale and handle fault tolerance based on the number of partitions and parallelism you set.

2025/6/4

数据可视化利器—— Streamlit 的有趣哲学

<a href="https://github.com/streamlit/streamlit">streamlit</a> 是一款可以快速进行简单网页开发的 Python 库，其 slogan 是： <blockquote> A faster way to build and share data apps </blockquote> 即“一种快速构建、分享数据应用的方法”。其在机器学习、数据科学，甚至当今大模型领域非常流行。其优点非常突出： <ol> <li>使用上述领域开发者最喜欢的语言：Python。不用写前端，pip 安装就能用。</li> <li>简单几行代码就能快速攒出一个数据可视化、打标等小工具的网页。</li> <li>还支持丰富的第三方组件扩展，比如社区开发的 <a href="https://github.com/bouzidanas/streamlit-code-editor">code_editor</a> 。</li> </ol> 当然，如果你还想要低延迟、高并发、深度定制等需求，那对不起，这是 streamlit 被 tradeoff 出去的那一部分。但对于面向内部少数人使用的小工具来说，streamlit 简直是利器。可以说这个小生态位被它卡的太好了，所以能在 2022 年以 8 亿美金卖给 Snowflake。 本文我们就一块来看看其基本设计哲学和一些简单实践。 <h1>设计哲学</h1> 其基本设计哲学可以概括为： <ol> <li>用后端语言写前端</li> <li>收到新事件会重新构建</li> <li>支持会话级别的缓存</li> </ol>

2025/3/18

A Data Visualization Powerhouse — the Interesting Philosophy of Streamlit

<a href="https://github.com/streamlit/streamlit">streamlit</a> is a Python library for quickly developing simple web apps. Its slogan is: <blockquote> A faster way to build and share data apps </blockquote> In other words, “a faster way to build and share data applications.” It is very popular in machine learning, data science, and even today’s large language model space. Its advantages are quite prominent: <ol> <li>Uses the favorite language of developers in the above fields: Python. No need to write frontend code; just <code>pip install</code> and you’re ready to go.</li> <li>With just a few lines of code, you can quickly whip up a web page for data visualization, labeling, and other small tools.</li> <li>It also supports rich third-party component extensions, such as the community-developed <a href="https://github.com/bouzidanas/streamlit-code-editor">code_editor</a>.</li> </ol> Of course, if you also need low latency, high concurrency, or deep customization, then sorry — that’s the part streamlit has traded off. But for small tools intended for internal use by a handful of people, streamlit is simply a godsend. You could say it occupies this small ecological niche so perfectly that it was acquired by Snowflake for $800 million in 2022. In this article, let’s take a look at its basic design philosophy and some simple practices. <h1>Design Philosophy</h1> Its basic design philosophy can be summarized as: <ol> <li>Write frontend in a backend language</li> <li>Rebuild upon receiving new events</li> <li>Support session-level caching</li> </ol>

2025/3/18

从“丰巢”快递柜看 Jemalloc 的内存管理

<h1>引子</h1> 在某些工作负载中，随着时间的推移，内存的使用会逐渐增长，直到 OOM。后面发现是内存碎片问题，而将系统默认的内存分配器（<a href="https://github.com/lattera/glibc/blob/master/malloc/malloc.c">glibc malloc</a>）换成 <a href="https://jemalloc.net/">jemalloc</a> ，能有效控制内存的增长上界。 为了解其背后原理，便找来 jemalloc 最初的论文：<a href="https://www.bsdcan.org/2006/papers/jemalloc.pdf">A Scalable Concurrent malloc(3) Implementation for FreeBSD</a> 来一探究竟。当然，相比 2006 年论文发表时，当前的 jemalloc 可能已经发生了很大改变，因此本文只对当时论文内容负责。更多 jemalloc 机制，大家可以去其 <a href="https://github.com/jemalloc/jemalloc">github 仓库</a>查看文档和源码。 <h1>背景</h1> 在探讨论文的主要思路之前，我们先简单回顾下内存分配器（memory allocator）的作用和边界。简言之： <ol> <li>对下，向操作系统申请大块内存（使用 <code>sbrk</code>、<code>mmap</code> 等系统调用）</li> <li>对上，处理应用层的各种尺寸的内存申请请求（<code>malloc(size)</code>），并在应用层“表示”不用（<code>free</code>）后进行释放</li> </ol> 往小了说，分配器的功能非常简单：分配和释放（malloc 和 free）。想象中，实现也应该很简单，只需利用一个表来记录所有已使用内存和未分配内存（ a bit of bookkeeping），然后： <ol> <li>malloc 请求来了，先去空闲表中找，不够的话就问操作系统要</li> <li>free 请求来了，还回空闲表中，如果空的多了，就还给操作系统</li> </ol>

2024/10/27

Understanding Jemalloc's Memory Management Through "Hive Box" Parcel Lockers

<h1>Introduction</h1> In certain workloads, memory usage gradually grows over time until an OOM occurs. Later, it was found to be a memory fragmentation issue. Replacing the system’s default memory allocator (<a href="https://github.com/lattera/glibc/blob/master/malloc/malloc.c">glibc malloc</a>) with <a href="https://jemalloc.net/">jemalloc</a> can effectively control the upper bound of memory growth. To understand the principles behind it, I sought out jemalloc’s original paper: <a href="https://www.bsdcan.org/2006/papers/jemalloc.pdf">A Scalable Concurrent malloc(3) Implementation for FreeBSD</a>. Of course, compared to when the paper was published in 2006, the current jemalloc may have changed significantly. Therefore, this article is only responsible for the content of the paper at that time. For more jemalloc mechanisms, you can check the documentation and source code in its <a href="https://github.com/jemalloc/jemalloc">GitHub repository</a>. <h1>Background</h1> Before discussing the main ideas of the paper, let’s briefly review the role and boundaries of a memory allocator. In short: <ol> <li>Downward, it requests large chunks of memory from the operating system (using system calls like <code>sbrk</code>, <code>mmap</code>)</li> <li>Upward, it handles memory allocation requests of various sizes from the application layer (<code>malloc(size)</code>), and releases them after the application layer indicates it is no longer needed (<code>free</code>)</li> </ol> In the simplest terms, the allocator’s functions are very simple: allocation and deallocation (malloc and free). One might imagine the implementation is also very straightforward—just use a table to keep track of all used and unallocated memory (a bit of bookkeeping), and then: <ol> <li>When a malloc request comes in, first look in the free list; if there’s not enough, ask the OS for more</li> <li>When a free request comes in, return it to the free list; if there’s too much free memory, return it to the OS</li> </ol>

2024/10/27

Snowflake：云原生数仓的开创者

<blockquote> Snowflake 由甲骨文的两位员工在 2012 年出来创办，一开始就瞄准云原生数仓，因此架构设计（在当时看来）非常“激进”。超前的视野带来超额的回报，Snowflake 在 2020 年正式上市，市值一度高达 700 亿美金，创造了史上规模最大的软件 IPO 记录。 本文我们综合两篇论文：<a href="https://dl.acm.org/doi/pdf/10.1145/2882903.2903741">The Snowflake Elastic Data Warehouse</a> 和 <a href="https://www.usenix.org/system/files/nsdi20-paper-vuppalapati.pdf">Building An Elastic Query Engine on Disaggregated Storage</a> 来大致聊聊其架构设计。 本文来自我的专栏《<a href="https://xiaobot.net/p/system-thinking">系统日知录</a>》，如果你觉得文章还不错，欢迎订阅支持我。 </blockquote> 这篇文章我早就想写了，但上次在看论文时卡住了——论文信息太多，地毯式的阅读，很快就淹没在细节中，当时也只看了三分之二，就搁置了。上周（20240707）在文章 <a href="https://xiaobot.net/post/93d3e9ad-90f2-47ec-a942-ff95c351cba1">Spark：如何在云上做缩容</a>时提到了存算分离的 snowflake ，有读者要求写下，于是便重新捡起来。 相比上次 push 的方式，本次采用 pull 的方式：即不是被动的读论文，而是先思考，如果让我设计这么一个云原生数仓，我要怎么设计，会有哪些问题等等。带着这些问题，我再去从论文中找答案，发现效率一下高了很多，也便让这篇文章没有再次难产。

2024/8/25

'Snowflake: The Pioneer of Cloud-Native Data Warehouses'

<blockquote> Snowflake was founded in 2012 by two former Oracle employees, targeting cloud-native data warehouses from the very beginning. Therefore, its architectural design was (at the time) considered very “radical.” This forward-looking vision brought extraordinary returns — Snowflake went public in 2020 with a market capitalization reaching as high as $70 billion, setting the record for the largest software IPO in history. In this article, we combine two papers — <a href="https://dl.acm.org/doi/pdf/10.1145/2882903.2903741">The Snowflake Elastic Data Warehouse</a> and <a href="https://www.usenix.org/system/files/nsdi20-paper-vuppalapati.pdf">Building An Elastic Query Engine on Disaggregated Storage</a> — to roughly discuss its architectural design. This article comes from my column “<a href="https://xiaobot.net/p/system-thinking">System Thinking Daily</a>.” If you find it helpful, feel free to subscribe to support me. </blockquote> I have wanted to write this article for a long time, but I got stuck while reading the papers last time — there was too much information, and carpet-bombing reading soon drowned me in details. At that time, I only read two-thirds of it and then put it aside. Last week (2024-07-07), when mentioning the disaggregated-storage Snowflake in the article <a href="https://xiaobot.net/post/93d3e9ad-90f2-47ec-a942-ff95c351cba1">Spark: How to Scale Down in the Cloud</a>, a reader asked me to write about it, so I picked it up again. Compared with the push approach last time, this time I adopted a pull approach: that is, instead of passively reading papers, I first thought about how I would design such a cloud-native data warehouse and what problems I might encounter. With these questions in mind, I went back to the papers for answers, and found that the efficiency improved dramatically, which also prevented this article from being abandoned again.

2024/8/25

人生是旷野 —— 罗素《幸福之路》

<blockquote> 缘于某个播客提了一嘴，便找来书在通勤时听了。这版是傅雷翻在 1939 年译的版本，有一股淡淡的老式白话风。小书不长，几天便听完。我喜欢在走路的时候听东西，所听入耳、所观入眼，哲人的凝言练语、街头的风物百态，总能在心里发生奇妙的化学反应，偶在三伏天都一激灵。 最近心绪颇为起伏，在上下班踱步听这本书时，数次给我宽慰平和，书中指出的快乐和不快乐之因，都命中了我的某些缺点和特点，因此听完觉得还是要写点东西。 </blockquote> <h1>罗素《幸福之路》</h1> 人类从狩猎时代进入农耕时代后，虽获得了生活的相对安稳，却也失掉了向外的探索和冒险。到工业时代，城市化加剧，进一步脱离了自然的“蓝领白领”亦是如此。只有少数的企业家才仍然保持着丛林式的生活方式。 选择安稳意味着有大量的“烦闷”（Boredom）需要排遣。但多数人过度的将注意力集中在自己的身上，比如畏罪狂（纠结于行为不符合少时的成见或社会的规训）、自溺狂（过度期待外界称许的虚荣）、自大狂（过度的权力欲望），则使得这种烦闷愈加在幻想中野蛮式的生长，直至占满人们的内心。

2024/7/28

Life Is a Wilderness —— Bertrand Russell's "The Conquest of Happiness"

<blockquote> I first heard about it from a passing mention on a podcast, so I sought out the audiobook for my commute. This is the 1939 translation by Fu Lei, with a faint, old-fashioned vernacular style. It’s a short book; I finished it in a few days. I like listening to things while walking—what enters my ears and what meets my eyes, the philosopher’s concise aphorisms and the myriad scenes of the street, always produce a curious chemical reaction in my mind, occasionally sending a jolt through me even in the height of summer. Lately my emotions have been rather turbulent, and listening to this book during my daily commute has brought me comfort and calm on several occasions. The causes of happiness and unhappiness the book points out all hit upon certain flaws and traits of mine, so after finishing it I felt I should write something down. </blockquote> <h1>Bertrand Russell’s “The Conquest of Happiness”</h1> After humanity transitioned from the hunting era to the agricultural era, although we gained relative stability in life, we lost the outward exploration and adventure. In the industrial era, with accelerated urbanization, the “blue-collar and white-collar” workers further detached from nature are no different. Only a small number of entrepreneurs still maintain a jungle-like way of life. Choosing stability means having a great deal of “boredom” to dispel. But most people excessively concentrate their attention on themselves—for example, the persecution maniac (obsessing over behavior that doesn’t conform to childhood prejudices or social conditioning), the narcissist (excessive vanity seeking external praise), and the megalomaniac (excessive desire for power)—which causes this boredom to grow wildly in fantasy until it fills people’s hearts.

2024/7/28