删掉它的时候我没有太多犹豫。真正让我决定重写的，不是内容不够多，而是写的过程太累——每次想记点什么，先要打开编辑器、等依赖装完、处理插件冲突，等这一切结束，想说的话已经凉了。

三个具体的理由#

一是我发现自己只在写下来的时候才真正想清楚。读过的书、写过的代码、下过的棋，如果没有落成文字，过两个月就只剩一个模糊的印象：「好像读过」。

二是对「输出」这件事的重新理解。以前我以为写博客是为了被人看到，所以总在纠结选题够不够硬、观点够不够新。现在觉得，它更像是一个公开的笔记本：有人看很好，没人看也不亏。

三是技术上的洁癖。我想要一个十年后还能正常打开的站点：

• 没有构建工具链，index.html 用浏览器直接打开就能看

• 没有 CDN 依赖，断网也能读

• 文章是纯文本的 Markdown，即使这个站点全丢了，文件还在

关于最后一点，我几乎是被迫学会的：2019 年用某个 CMS 写的四十多篇东西，因为数据库导出格式没人维护，现在全部躺在硬盘里打不开。

这个站点的实现#

整个站点只有四类文件：

构建脚本只用 Node 内置模块，做三件事：读取 Markdown 与 front matter、生成 posts.generated.js、顺带产出 feed.xml 与 sitemap.xml。

npm run build     # 生成数据与 RSS
npm run serve     # 本地预览 http://localhost:4173

接下来#

我不打算给自己定更新频率——定过的计划，大多死在了计划本身。只留一个最低要求：每月至少写一篇，写不动长文就写短的。

如果非要说有什么目标，大概是这句：

写得慢一点，但每篇都值得三个月后的自己再读一遍。

四隅与四声#

棋盘四角各有一个名字，对应四个声调：

• 平 —— 左手方向（棋盘以左手为尊）

• 上、去、入 —— 依序轮转

每个角管辖 90 路，四角合计 360 路，再加上棋心一路「太极」，正好 361。宋代《忘忧清乐集》里写得很清楚：

夫棋盘有三百六十一路，以分平上去入四字，各管一角，计九十路……若言「六·三」，先顺数六而后逆数三；或言「三·六」，先顺数三而后逆数六是也。

也就是说，数字的先后顺序是有意义的——它决定了你沿哪条边走。

顺数与逆数#

把这一点翻译成今天的语言，大约是：

1. 先确定这个点属于哪个角（平 / 上 / 去 / 入）；

2. 从角上的「一一」出发，沿一条边顺数到第一个数字；

3. 再沿另一条边逆数到第二个数字。

清代的《弈理指归》把这件事编成了口诀，方便记：

局分四隅，谱寓四声。落子数数，先纵后横。

「线」其实是圈#

这是另一个容易误解的地方。我们平常说「第三线」，听起来像是一条直线，但古人说的「第\*线」是一个方形圈。

从四隅的「一一」互相连起来，得到「第一线」；四隅的「二二」互相连起来，得到「第二线」——以此类推，共九条线。所以「一一」的两边都在第一线上，「三三」的两边都在第三线上。

势子为什么要摆在对角#

传统开局前，要在四隅的「四四」位对角各摆两黑两白，称为势子（也叫座子）。《棋经十三篇》说：

权舆者，弈棋布置，务守纲格。先于四隅分定势子。

对角而非同边的摆法，让开局天然带着均衡与张力。这一点和现代围棋取消座子、追求自由布局的方向，恰好是两种不同的审美。

一点提醒#

需要说明的是，十九路棋盘并非自古如此。考古发现的棋盘里，还有十七路、十五路等形制；棋子也有双面凸、单面凸、双面平（表面带文字或花纹）的区别。本文的讨论，只以流传千年的十九路形制为基准。

读谱这件事，术语弄清之后，剩下的就是耐心了。

范数：给向量量个长度#

一个范数 \|\cdot\| 要满足三条性质：非负性、齐次性、三角不等式。翻译成人话：

• 长度不能是负的，只有零向量长度为 0；

• 把向量拉长 $k$ 倍，长度也正好是 $k$ 倍；

• 走三角形两边不会比走第三边更近。

最常见的三个：

那个「几何形状」看起来很抽象，其实是理解它们差异的钥匙：单位球的形状，决定了大梯度方向偏向哪里。

为什么 L1 会产生稀疏解#

一句话版本：L1 的单位球在坐标轴上有尖角，而损失函数的等高线通常是光滑的椭圆。两者相切时，切点大概率落在尖角上——而尖角就在坐标轴上，那里意味着「某些分量为零」。

反观 L2，单位球是圆的，没有尖角，切点落在哪儿都正常，于是权重只会被压小、不会归零。

从范数到距离#

有了范数，距离只是把差向量塞进去：

但注意：距离函数不一定要来自范数。只要满足非负、对称、三角不等式，任何函数都能当距离用。这带来了很多有意思的选择：

• 余弦距离 1 - \frac{x \cdot y}{\|x\|\|y\|}：只关心方向，不关心长度，适合文本向量

• 编辑距离：两次字符串变换的最少操作数

• Jaccard 距离：集合的交并比，适合标签与推荐

一段容易踩坑的代码#

下面的写法看起来很自然，但在高维下会失效：

import numpy as np

def euclidean(a, b):
    return np.sqrt(np.sum((a - b) ** 2))

# 高维下所有点对的 L2 距离会趋同，
# 「最近邻」逐渐失去区分度 —— 这就是维度灾难的一种表现。
x = np.random.rand(1000, 5000)
d = np.linalg.norm(x[:, None, :] - x[None, :, :], axis=-1)
print(d.std() / d.mean())   # 数值越小，说明区分度越差

所以做向量检索时，通常不是「选个距离然后开算」，而是：

• 先看数据的尺度，做标准化
• 判断该关心方向还是绝对位置
• 盲目套用欧氏距离
• 忘了高维下距离会失效

一点体会#

范数这个概念，我在课本上见过很多次，真正弄懂却是在写检索功能的时候：当「相似」要被写进代码，你必须先回答「相似是什么意思」。数学只是把这个回答变得更精确，它并不能替你回答。

结论先行：块级解析比行内解析难，行内解析比想象中危险。

架构：两遍扫描#

解析器分成两层，互不干扰：

1. 块级解析：按行扫描，识别标题、列表、代码块、引用、表格、段落；

2. 行内解析：对段落与标题的文本内容，处理粗体、链接、行内代码等。

function render(src) {
  var lines = src.replace(/\r\n?/g, '\n').split('\n');
  var html = renderBlocks(lines);       // 块级
  return { html: html, toc: toc };      // 顺便收集目录
}

块级函数返回 { html, next }——next 是下一个待处理行号。这个约定让「消费掉若干行」的块（代码块、列表、表格）能干净地交还控制权。

坑一：列表的续行与嵌套#

这是最麻烦的部分。列表项可能跨多行：

- 第一行
  缩进两格的续行
  - 嵌套的子项

我的策略是先切成项、再递归：

1. 找出这个列表的基础缩进量 baseIndent；

2. 缩进等于 baseIndent 的行，开启新项；

3. 缩进更深的行，剥离缩进后并入当前项；

4. 对每一项的内容数组，再次调用 renderBlocks——嵌套就自然发生了。

var m = line.match(/^(\s*)([-*+]|\d{1,9}[.)])\s+(.*)$/);
if (m && m[1].length >= baseIndent && m[1].length <= baseIndent + 3) {
  items.push([m[3]]);          // 新列表项
}

坑二：先转义，再解析#

如果不转义就解析，用户写一句 <img src=x onerror=alert(1)> 就直接注入了。我的做法是先转义再匹配：

var text = escapeHtml(raw);   // & < > 先变实体
text = text.replace(/\*\*(?=\S)([\s\S]*?\S)\*\*/g, '<strong>$1</strong>');

但这里有个细节：引号不能一起转义，否则链接的标题语法 [文字](url "标题") 里的引号会变成 "，正则再也匹配不上。所以属性值单独用 escapeAttr 处理。

另外，javascript: 这类协议不会包含 &<>，所以必须显式拦截：

function safeUrl(url) {
  if (/^\s*(javascript|vbscript|data)\s*:/i.test(url)) return '#';
  return url;
}

坑三：行内代码要最先处理#

行内代码里的内容不应该被二次解析。比如 `**不要加粗**` 必须原样输出。解决办法是用「占位符暂存」：

function stash(html) {
  store.push(html);
  return '\u0000' + (store.length - 1) + '\u0000';   // 用 NUL 字符占位
}

\u0000 在正常文本里几乎不可能出现，所以不会被后续规则误伤；等所有行内规则跑完，再把占位符还原成真正的 HTML。

坑四：兼容性#

写的时候顺手用了一个后行断言：

// 危险：旧版 Safari 会在「解析阶段」直接抛 SyntaxError，整个 JS 文件都不执行
code.replace(/(?<=\S) $/g, '');

这类问题不会给出友好的运行时报错，而是整个脚本静默失效、页面白屏。改成普通写法就好：

code.replace(/^ +| +$/g, '');

成果#

最终支持的范围：

不支持的项是有意为之：功能范围越小，行为越可预测。对一个博客来说，这比支持所有冷门语法重要得多。

问题不在于读得快，而在于读的时候没有停下来。

三遍读法#

现在我读一本非虚构的书，会分三遍：

第一遍：当小说读#

不划重点，不做笔记，不求甚解。遇到看不懂的地方直接跳过，目标是知道这本书在讲什么、作者想说服我什么。

这一遍通常能在一两个晚上完成。它的作用不是记住，而是建立一个「地图」——后面再碰到细节时，知道该把它挂在哪儿。

第二遍：当工具书读#

隔几天再回来。这一遍只读目录和标题，挑出真正与我的问题相关的两三章精读，其余略过。

配合的动作是：

• 每读完一节，用一句话在空白处写下这节在说什么
• 遇到反直觉的论断，标记出来并写下「为什么我不同意」
• 抄写金句（这件事几乎没有用）

第三遍：当材料读#

这一遍只在需要输出的时候做——写文章、做分享、解决具体问题时，回到书里找那几段，把它变成自己的素材。

为什么第三遍最重要#

因为输入的价值只有在被调用时才兑现。

前两遍建立的是「我知道这本书里有这个东西」的索引；第三遍才是真正的取用。很多人读了很多书却写不出东西，原因往往不是读得不够，而是从来没有走到第三遍。

一个反面清单#

下面这些事，我做过并且确认没用：

1. 抄金句——抄的时候很爽，抄完永远不会再看；

2. 追求读完——读到 60% 发现没用还硬读完，是最贵的一种节俭；

3. 同时开五本——同时开五本的结果通常是一本也没读完；

4. 把划线当理解——划线只说明「这句话写得好看」，不说明「我懂了」。

一点退让#

这套方法不适合小说。小说就该一口气读完，被打断的阅读体验会毁掉整本书。所以我的实际做法是：

• 非虚构 → 三遍读法

• 小说 → 一遍读完，中间不插别的书

读得慢下来之后，年阅读量掉到了十几本。但这两年我写出来的东西，比之前五年加起来还多。

这笔账，我觉得划算。