一、标题的层级

正文的层级从二级标题开始。二级标题负责大节，三级标题负责小节，再往下就不应该出现标题了——如果一件事需要四级标题才能讲清楚，说明它应该拆成两篇文章。

1.1 小节标题的样子

这是一个三级标题下面的段落。注意标题本身不使用编号以外的装饰，层级关系由字号与留白表达。

二、列表

无序列表用于并列：

• 浅灰白作为底色，拒绝刺眼的纯白
• 近黑作为正文，拒绝低对比度灰
• 圆角卡片加柔和阴影，层次不靠喊叫

有序列表用于步骤：

1. 先想清楚要写什么
2. 再想清楚不写什么
3. 最后才动笔

嵌套列表用于细分：

• 视觉系统
  • 色彩：灰白底、白卡、暗红强调
  • 排印：无衬线正文，图标化元信息
• 工程系统
  • 静态生成
  • 零后端

三、引用

把想清楚的事写下来，是唯一能让它继续想下去的方式。

——这句话放在页脚题词的位置，也放在这里测试引用块。

引用块应该是浅底圆角的旁注：凹面色打底、左侧一道强调色细线、不抢正文的戏。

四、表格

表格用浅发丝线分隔行，表头文字重一档，数字右对齐留给实现阶段。

五、代码

行内代码像 --ground 这样出现在句子里。代码块则独占一行：

/* 柔光体系的根基：底色、正文色、暗红强调 */
:root {
  --ground: #F6F8FB;
  --ink: #2B313A;
  --accent: #A31F34;
}

另一种语言（TypeScript）：

export const site = {
  name: '[站点名]',
  since: 2026,
} as const;

以及一段 Shell：

npm run build && npm run preview

代码块应该有语言标签和复制按钮，配色跟随亮暗主题。

六、图片与图注

图注跟随图片，使用小号字与次级色。演示配图来自 Lorem Picsum，仅用于验证版面。

七、脚注与分隔线

这里有一个脚注¹，还有一个链接到外部的引用。链接是暗红色的，悬停时有明确的回应，下划线不贴着字身。

分隔线之上是上半场，之下是总结。

八、中英文混排

中文写作离不开西文与数字：比如 2026 年、17 寸屏幕、TypeScript 3.9、或 CSS 的 line-height。好的混排不需要手动加空格——盘古之白应由渲染层处理，写作时保持自然。标点也值得检查：中文全角逗号、句号、顿号，与西文半角括号不要混用，列一个对照：

• 全角：，。、；：？！“”‘’（用于中文句子）
• 半角：,.;:?!””’()（用于代码与西文句内）

另一个容易忽略的细节是省略号：中文用“……”而不是三个句号，破折号用“——”而不是两个连字符。

九、长段落与短段落

长段落是对排版的真正考验。设想这样一段：从浅灰白的底色开始，经过近黑文字的密度，穿过发丝线的分隔，抵达暗红的强调——一路上每一个元素都在争夺注意力，而排版的任务是让它们排队：底色退到最后，文字站到最前，线条只做引导，强调色一年只准出场几次。如果读者读完这一段没有意识到任何“设计”的存在，只记得内容本身，那这套系统就赢了。反之，如果读者先看到的是“这个博客好特别”，那它就输了——被看见的设计是失败的装饰，看不见的设计才是成功的秩序。

短段落则是另一种测试。

一句话成段时，留白是否还成立？

答案取决于段落间距是否恒定：无论一段五十字还是五百字，段与段之间的呼吸必须一致。恃强凌弱的间距体系会在短段落面前穿帮。

十、强调与内联元素

正文中会出现的所有内联元素集中在此：加粗用来标记真正重要的判断，斜体用于西文书名与术语，删除线几乎不该出现（出现时必然是修辞），以及行内代码 --hairline。它们在同一段里混排时最容易出问题：加粗会撑破字距，斜体在无衬线下只剩倾斜角度，行内代码的背景色如果太重会切断行内的灰度节奏。本段的测试点是：读完之后你只记得哪个词被强调了，而不记得它们各自长什么样。

十一、对齐、断行与标点

中文排版的深水区在细节。两端对齐在长行中文里几乎必然产生拉伸的高原与低谷，本站选择左对齐、右端参差——阅读视线回行时参差反而更稳定。标点悬挂是另一件事：行首不该出现句号逗号，行尾不该出现开引号，浏览器对此的支持仍然零碎，需要接受“绝大多数时候正确”的妥协。西文断词在中文正文里只影响夹杂的英文术语，word-break 与 overflow-wrap 的取舍留一组对照：

• 默认：长 URL 可能溢出栏宽
• overflow-wrap: break-word：只在必要时断开
• word-break: break-all：随处可断，西文惨不忍睹

本站采用第二种：必要时的丑是可以接受的，常态的丑不可以。

数字与单位的排法也有讲究：纯数字用正体，变量用斜体，单位与数字之间留半个字宽——“720px 栏宽”而不是“720 px栏宽”。表格里的数字右对齐便于比大小：

十二、引用的变奏

单段引用之外，还有连续引用：

第一段引用。它足够长，长到能观察左侧细线与内缩在多行下的表现。

第二段引用与第一段之间用空引用行分隔，两段的视觉权重应当一致。

以及引用内嵌套列表：

引用里的列表：

• 灰白不是白
• 近黑不是黑

十三、更多的代码

长代码块测试滚动与行高：

from dataclasses import dataclass

@dataclass
class Post:
    title: str
    pub_date: str
    tags: list[str]

    @property
    def year(self) -> int:
        return int(self.pub_date[:4])

posts = [
    Post("新年，重新开始写", "2026-01-01", ["写作", "习惯"]),
    Post("在 WSL2 里搭一套顺手的开发环境", "2026-08-14", ["WSL", "工具链"]),
]

for post in sorted(posts, key=lambda p: p.year, reverse=True):
    print(f"{post.year}  {post.title}")

package main

import "fmt"

type Site struct {
    Name  string
    Since int
}

func main() {
    s := Site{Name: "[站点名]", Since: 2026}
    fmt.Printf("%s · since %d\n", s.Name, s.Since)
}

两种语言、两种风格，同一套亮暗配色——语法高亮是“配色”而非“彩色”，任何语言在任何主题下都不该喊叫。

十四、图片的更多形态

单图之外，正文中的图片还有几种出场方式。紧随段落的配图承接上文意象；两组图的对比需要统一高度与图注句式；横贯栏宽的大图则应该有自己的呼吸空间——上下各留一个段落间距，而不是贴着文字。图注的写法也有讲究：它不是重复图片内容的字幕，而是补充正文没说的信息——拍摄时间、数据来源、或看图的方法。无障碍语境下图注与 alt 文本各司其职：alt 面向读屏用户描述图像信息，图注面向所有人补充上下文。本站的图片一律 12px 圆角、不浮动环绕——环绕排版在中文长文里几乎必然造成右侧参差，而参差的代价由读者承担。

图片之外还有一个特殊形态：无图。设计目标之一是“没有一张配图时站点依然成立”，所以每个依赖图片的位置都必须有无图降级：封面可选、首页有无图时的浅色占位、正文没有图片时就是纯粹的文字。图片是锦上添花，不是结构支柱——这句话是整个视觉系统的地基。

十五、排版的节奏

把前面所有元素放进同一段视野里观察：标题、正文、列表、代码、引用、表格，它们的灰度、密度与留白构成一篇长文的节奏。节奏的离下在于重音不能连着重音：加粗的段落后面该跟一段平叙，表格之后该有一段过渡，连续三个列表几乎总是结构错误。编辑的工作一半是改字，一半是调度这些元素的出场顺序。这篇长文刻意在密集元素之间插入成段的议论，正是为了验证这种调度在真实阅读里的手感——你此刻读到的是一篇经过调度而非堆砌的测试文。

十六、总结

如果以上所有元素都在各自的岗位上——标题有层级、列表有呼吸、引用像旁注、表格不喊叫、代码有圆角和标签、图片有图注、脚注可跳转、链接有回应——那么这套排版系统就可以交付了。剩下的，是把想清楚的事，一篇一篇写下来。

解法是把博客当成项目来维护：开头有固定的引子句式，收尾回扣标题；每周固定时间写，发布门槛降到「讲清一件事」；版式、代码、部署全部模板化，让写作环节之外的一切都变成肌肉记忆。

长期项目的关键指标只有一个：还活着。写作频率、文章质量、访问量都是派生指标。只要这个月还在写，项目就没有失败——这就是我能给出的全部方法论。

基础层：Ubuntu 24.04 + zsh。包管理交给 apt，语言版本交给各自的版本管理器（nvm、sdkman、官方 tarball），不混用。

字体：终端字体决定长时间阅读的疲劳度。选一款带连字（ligatures）的等宽字体，Windows Terminal 里设置完成后，连 => 和 != 都会变成单个字形。

Docker：Docker Desktop 开启 WSL 集成后，发行版里直接可用 docker 命令。记住两个前提：桌面版要先启动；代码放 WSL 文件系统而不是 /mnt/c，卷挂载性能差一个数量级。

编辑器：VS Code 的 Remote-WSL 模式，编辑器 UI 在 Windows，语言服务在 Linux，两边都不妥协。

验证：git、node -v、docker ps 三条命令都通，环境就算立住了。之后每装一样东西，都用一条命令验证一次——环境搭建的本质是验证，不是安装。

默认零 JS。博客 95% 的面积是静态内容，任何默认带运行时的方案都是在为 5% 的交互付出 100% 的成本。Astro 的「群岛架构」让交互只出现在真正需要的小岛上——主题切换、搜索、目录高亮，其余全是纯 HTML。

内容集合与校验。十篇 Markdown 可随意，一百篇之后 frontmatter 的混乱会反噬。Astro 的 content collections 用 schema 校验 frontmatter，字段缺失在构建期报错，而不是渲染出一页残缺的文章。

TypeScript 一等公民。站点配置、组件 props、内容类型都在一个类型系统里，改字段名时编辑器直接告诉你哪里断了。

Hexo 陪了我很多年，但它解决的问题（2014 年的构建速度）已经不是今天的问题。工具没有忠诚度，只有适配度。

这个博客用的是一套克制的「柔光」词汇：

• 圆角有节制——卡片 16px、图片 12px，再大就是玩具
• 阴影低透明度、大模糊——托起层次，而不是炫耀光源
• 强调留给暗红色——小面积、有预算，一年只出场几次

层次不一定要靠投影，这点没错。一本书里没有投影：标题靠字号，段落靠缩进，层次靠细线。印刷词汇安静、克制，这个博客曾经整套用过它。但它要求读者自己完成全部的空间想象——而屏幕上的读者往往在滚动、在分心、在 390px 宽的手机上读一篇三千字的长文。印出来的层次是「读」出来的，浮起的层次是「看」见的：后者便宜，但对分心的人更诚实。

用回圆角和阴影之后有一个意外的收获：层次变直觉了。卡片是一张卡片，浮层是一次浮起，读者不需要学习词汇——注意力仍然回到文字本身，因为所有装饰都压在低透明度、大模糊的柔和阴影里，谁也不炫耀光源。对一个以长文为主的站点，这正是想要的。

我做过一组实验，结论是宋体正文成立，前提是三个参数同时到位：

1. 字号 18px。宋体笔画细，14px 以下发虚；到 18px，横细竖粗的骨架才立得住。
2. 行高 1.9。汉字方块密度高，1.5 的行高读两行就开始串行；1.9 给每行留出呼吸。
3. 栏宽 720px。约三十八到四十字一行。超过五十字，眼睛回行时会丢行。

三者缺一，可读性就崩回「宋体糊」的印象。参数对了，宋体的书卷气是黑体给不了的——黑体有黑体的清楚，宋体有宋体的书卷气；选哪个，取决于你要一册工具书还是一卷文集。

• Shell：zsh + 最小化配置，不装花哨主题，只留语法高亮与自动建议
• 编辑器：终端里用 neovim 看小文件，大改动交给编辑器
• 提示符：右侧显示 git 分支与退出码，其他一概不要
• 别名：只为高频命令设别名，比如 gco、dcu，其余交给历史搜索 Ctrl-R
• 字体：等宽字体是终端体验的底盘，值得认真挑一款

配置的全部原则只有一条：每次觉得「这里不顺手」就立刻修，不顺手的债务会复利。

内存：默认配置下 vmmem 会吃掉宿主机大半内存。解法是 %USERPROFILE%\.wslconfig 里限制 memory=8GB，改完 wsl --shutdown 重启生效。

启动顺序：WSL 里的 docker 命令依赖 Windows 侧的 Docker Desktop 先启动。桌面版没起来时 docker ps 会报 cannot connect to the Docker daemon。可以在 shell 配置里加一个检查，或者干脆从 WSL 侧拉起桌面版再等就绪。

卷挂载权限：/mnt/c 下的路径挂载进容器性能差且权限混乱。项目代码尽量放在 WSL 文件系统（如 ~/workspace）里，需要访问 Windows 文件时再走 /mnt/c。

三条都不复杂，但每条都足以浪费一个下午。记录在此，希望帮你省下这三个下午。

第一，笔记的价值不在收集而在连接。摘抄一百条不如用自己的话重写一条——重写逼你理解，理解才可能与其他想法发生关系。

第二，写作不是从零开始的过程，而是从已有笔记里「长」出来的。平时把想法存成一张张卡片，动笔时做的只是排列与缝合。

所以这个博客的定位也清楚了：它不是发表成果的展柜，而是卡片之间连接的公开记录。

今年把规则改小：一篇只讲一件事，两百字也算数，写完就发。先让「写」这个动作活下来，质量让位给频率。

这是新规则下的第一篇。两百字，讲完一件事：把门槛降到能跨过去的高度。