两种香草

罗勒要见光，薄荷更耐阴。浇法也不一样。

items:
  - title: 罗勒
    text: 土面发白再浇透，托盘里的水倒掉。
  - title: 薄荷
    text: 土保持微湿，避开正午的直射光。

这季记下的数

种子是三月中旬播的。盆不深，第一次剪叶等到第六周。

items:
  - label: 发芽
    value: 7
    unit: 天
  - label: 盆深
    value: 15
    unit: 厘米
  - label: 第一次剪叶
    value: 6
    unit: 周

从播种到剪叶

items:
  - date: 3月12日
    title: 播种
    text: 罗勒和薄荷各一盆，覆土不超过半厘米。
  - date: 3月19日
    title: 出苗
    text: 罗勒先露头，薄荷晚了两天。
  - date: 4月2日
    title: 间苗
    text: 每盆留下最壮的两株。
  - date: 5月1日
    title: 第一次剪叶
    text: 只剪顶端，留下至少四片叶。

[!NOTE] 北向窗冬天光照不够，罗勒会徒长。把盆移到能见到上午光的那一格。

每周的株高

从第二周起，每周一量一次最高的那片叶。

type: bar
title: 罗勒株高
x: ["第2周", "第3周", "第4周", "第5周", "第6周"]
series:
  - name: 株高
    data: [4, 8, 13, 18, 22]
unit: cm
caption: 第六周剪叶前，罗勒大约 22 厘米。

窗台怎么摆

靠左的那格上午有光，罗勒放那里。薄荷在中间。右边的空盆先不浇。

caption: 朝北的窗台，从左到右是罗勒、薄荷和一只空盆。
parts:
  - name: 全部
    text: 三只盆并排，靠左的光照最好。
  - name: 罗勒
    text: 靠左，每天都够到上午的光。
  - name: 薄荷
    text: 中间，土干得慢一些。
  - name: 空盆
    text: 右边空着，留给秋天的香菜。
---
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 640 220">
  <rect data-p="全部" x="20" y="16" width="600" height="150" rx="10" fill="#d5e3ea"/>
  <rect data-p="罗勒" x="70" y="96" width="90" height="58" rx="8" fill="#c4a574"/>
  <circle data-p="罗勒" cx="115" cy="78" r="30" fill="#3f7d4e"/>
  <rect data-p="薄荷" x="270" y="104" width="90" height="50" rx="8" fill="#c4a574"/>
  <circle data-p="薄荷" cx="315" cy="88" r="26" fill="#6aa87a"/>
  <rect data-p="空盆" x="470" y="118" width="90" height="36" rx="8" fill="#e4d3b8"/>
</svg>

今天浇不浇

土面还湿就先不动。干了再浇，浇到盆底出水，然后把托盘倒掉。

flowchart TD
  A[看土面] --> B{还湿吗}
  B -->|湿| C[今天不浇]
  B -->|干| D[浇到盆底出水]
  D --> E[倒掉托盘]

[!WARNING] 霜前把盆搬进屋。罗勒叶子一碰霜就发黑，回不来。

盆口和浇水量

盆口越大，一次浇得越多。12 厘米的盆大约是 70 毫升。

caption: 盆口越大，一次浇得越多。12 厘米大约是 70 毫升。
intent: |
  让读者拧盆口直径，看这一次该浇多少毫升。
---
<State diameter={12} />
<Slider bind="diameter" label="盆口直径" min={8} max={24} unit="cm" />
<Let water={round(diameter * diameter * 0.35 + 20)} />
<Stat label="这一次" value={water} unit="ml" />

水怎么往下走

浇下去的水不会停在表面。它慢慢渗过土层，最后从排水孔滴出来。

title: 水从土面渗到排水孔，大约要一分钟。
code: |
  <style>
    html, body { margin: 0; background: transparent; color: #3c342c; font: 15px/1.5 ui-sans-serif, sans-serif; }
    svg { display: block; width: 100%; height: auto; }
  </style>
  <svg viewBox="0 0 640 280" role="img" aria-label="水从土面渗到盆底">
    <rect x="180" y="36" width="280" height="200" rx="18" fill="#efe6d6" stroke="#cbbfa8"/>
    <rect id="water" x="196" y="48" width="248" height="16" fill="#7ea4c4" opacity="0.85"/>
    <rect x="196" y="150" width="248" height="70" fill="#8b6a45"/>
    <circle cx="320" cy="214" r="8" fill="#5c4632"/>
    <text x="320" y="268" text-anchor="middle" font-size="14" fill="#3c342c">排水孔</text>
  </svg>
  <script>
    var water = document.getElementById("water");
    var y = 48;
    var reduce = window.matchMedia("(prefers-reduced-motion: reduce)").matches;
    if (reduce) {
      water.setAttribute("y", "168");
      water.setAttribute("height", "36");
    } else {
      (function tick() {
        y += 0.45;
        if (y > 168) y = 48;
        water.setAttribute("y", String(y));
        water.setAttribute("height", String(Math.max(16, 204 - y)));
        requestAnimationFrame(tick);
      })();
    }
  </script>

浇水纸条

纸条上先记下这一周。周四那次少了，周日又给薄荷补了一次。

周一  罗勒  80 ml
周四  罗勒  80 ml

 周一  罗勒  80 ml
-周四  罗勒  80 ml
+周四  罗勒  120 ml
+周日  薄荷  60 ml

六周记录

想核对叶子是不是对生、花是不是穗状时，看这一页。

url: https://zh.wikipedia.org/wiki/%E7%BD%97%E5%8B%92
title: 罗勒
description: 叶子对生，花排成穗。窗台上的那盆对得上。

[!TIP] 剪叶之后把盆转半圈，让另一面也能见到上午的光。

• 窗台香草资料包（ZIP · 1.8 KB）：浇水记录表（CSV 和 Markdown）和排盆小工具，解压就能用

单独的文件

每份文件也可以单独看。Markdown、HTML 和 PDF 点「预览」，在页面右侧打开，不用离开这篇。

种植资料

• watering-log.md（MD · 846 B）：前四周的浇水量和土况
• 窗台排盆（HTML · 1.8 KB）：拖动滑块，看一条窗台放几只盆合适
• 播种指南（PDF · 204 KB）：从准备盆土到第一次采摘，一页纸

放在对象存储里的大文件

原图这类大文件不进仓库，放到对象存储，src 写完整地址。这样的文件只能下载或在新标签页打开。

• 罗勒原图（JPG · 4.3 MB）：Castielli 摄，来自 Wikimedia Commons，CC BY-SA 3.0

KV cache 到底占多少显存

每个 token 在每一层都要存一份 K 和一份 V。以 32 层、8 个 KV 头、每头 128 维、fp16 的模型为例：

所以长上下文推理的瓶颈往往不是算力，而是显存。

Prefill 和 Decode 有什么不同

Prefill 阶段一次处理整段 prompt；之后每生成一个 token，都只为这个新 token 算 K/V。

这就是 decode 阶段每步计算量和序列长度无关的原因。

读多写少时选哪把锁

假设每次读和写都要 10 ms，几个读者和一个写者同时到达。

代价是 RwLock 自身更重，写多的场景反而更慢。

为什么 ECB 会泄露图案

相同的明文块在 ECB 下总是得到相同的密文块，图案就这样漏了出来。

人数一变，采购量跟着变

写作格式的价值，不在于语法多，而在于文件离开编辑器之后仍能完整表达。

基础排版与 GFM

实现**掩码（Masking）操作，引入多头注意力（Multi-Head Attention）机制；前（中文括号）**后也能正常加粗。

新的向量知道前面有 Your journey，后面有 with one step，高亮应连续。

一段文字可以同时包含粗体、斜体、删除线、inline code 和 外部链接。

• 第一层列表
  • 第二层列表
    • 第三层列表
• 列表之后仍然保持稳定的段落节奏

1. 写作
2. 本地预览
3. 发布与验证

• 标题、引用、列表和代码
• 表格、删除线与任务列表
• 数学公式与 Mermaid
• 用新的真实文章继续回归测试

语义警告框

[!NOTE] 普通补充信息会显示为「提醒」。

[!TIP] 推荐做法会显示为「建议」。

[!IMPORTANT] 读者不能漏掉的要点会显示为「重要」。

[!WARNING] 需要关注的风险会显示为「警告」。

[!CAUTION] 可能造成严重后果的操作会显示为「注意」。

链接卡片

在链接后面紧跟 {card}，网页里会多出一张卡片，写着对方页面的标题、简介和配图。链接写在句子里时，文字照常可点，卡片跟在这一段后面：表格、任务列表和脚注都来自 remark-gfm，它让 GFM 语法在这里生效。

链接单独占一行时，卡片就放在这一行的位置：

KaTeX 支持的函数

写在代码里的 [文字](https://example.com){card} 不会变成卡片，原样显示。

标题里的 Typora 外链

标题本身点了会定位到这里，不带下划线；标题里的外链照常带虚线下划线。

数学公式

求和部分：$\sum_{j=1}^{N}$（上下限）。

$$ C_i = \sum_{j=1}^N w_{ij} \cdot V_j $$

行内公式会和文字一起流动，例如注意力的缩放项 $\frac{QK^\top}{\sqrt{d_k}}$。

块级公式支持多行对齐：

$$ \begin{aligned} \operatorname{Attention}(Q,K,V) &= \operatorname{softmax}\left(\frac{QK^\top}{\sqrt{d_k}}\right)V \ K_{\text{cache}}^{(t)} &= [K_{\text{cache}}^{(t-1)}; K_t] \ V_{\text{cache}}^{(t)} &= [V_{\text{cache}}^{(t-1)}; V_t] \end{aligned} $$

矩阵也能正常显示：

$$ X = \begin{bmatrix} 1 & 0 & 1 \ 0 & 1 & 0 \ 1 & 1 & 1 \end{bmatrix} $$

Mermaid 流程与时序

所有 Mermaid 图表固定使用「中性」主题。每张图都可以在「图表」与「Code」之间切换：前者用于阅读，后者用于检查或复制原始 Mermaid 语法。

下面的流程图描述本地写作到发布的闭环：

flowchart LR
  A[Typora 写作] --> B{本地验证}
  B -->|通过| C[生成内容索引]
  B -->|失败| A
  C --> D[构建网站]
  D --> E[浏览器验收]
  E --> F[发布]

同一篇文章里可以继续放更复杂的时序图：

sequenceDiagram
  autonumber
  participant W as Writer
  participant M as Markdown
  participant S as Site
  participant R as Reader
  W->>M: 保存 .md 与媒体
  M->>S: 构建内容与目录
  S-->>W: 返回预览
  W->>S: 发布已验证版本
  R->>S: 阅读文章
  S-->>R: HTML + KaTeX + Mermaid

多语言代码高亮

同一种内容结构，在不同语言里应该保留各自可辨识的关键字、类型、字符串、注释与数字层级。

TypeScript

type Post<TMeta extends Record<string, unknown>> = {
  slug: string;
  meta: TMeta;
};

async function publish<TMeta extends Record<string, unknown>>(
  post: Post<TMeta>,
): Promise<string> {
  const response = await fetch(`/api/posts/${post.slug}`, {
    method: "POST",
    body: JSON.stringify(post.meta),
  });
  return response.ok ? "published" : "failed";
}

Python

from dataclasses import dataclass
from pathlib import Path

@dataclass(frozen=True)
class Article:
    """选中这行文字时，深浅主题都应保持清晰。"""
    title: str
    source: Path

def published_titles(articles: list[Article]) -> list[str]:
    return [article.title for article in articles if article.source.exists()]

Rust

#[derive(Debug)]
struct Entry<'a> {
    title: &'a str,
    pinned: bool,
}

fn pinned_titles(entries: &[Entry<'_>]) -> Vec<&str> {
    entries.iter()
        .filter(|entry| entry.pinned)
        .map(|entry| entry.title)
        .collect()
}

Go

func renderAll(ctx context.Context, slugs []string) <-chan Result {
	results := make(chan Result)
	go func() {
		defer close(results)
		for _, slug := range slugs {
			results <- render(ctx, slug)
		}
	}()
	return results
}

SQL

WITH ranked_posts AS (
  SELECT
    title,
    topic,
    ROW_NUMBER() OVER (PARTITION BY topic ORDER BY published_at DESC) AS rank
  FROM posts
  WHERE status = 'published'
)
SELECT title, topic
FROM ranked_posts
WHERE rank <= 3;

Swift

actor ReadingProgress {
    private var offsets: [URL: Double] = [:]

    func save(_ offset: Double, for article: URL) {
        offsets[article] = max(0, offset)
    }

    func restore(for article: URL) -> Double {
        offsets[article, default: 0]
    }
}

C#

public record Article(string Title, DateOnly Published);

public static class Archive
{
    public static IEnumerable<string> Titles(IEnumerable<Article> articles) =>
        articles.OrderByDescending(a => a.Published).Select(a => a.Title);
}

C++

#include <string>
#include <vector>

struct Article {
    std::string title;
    int words;
};

int totalWords(const std::vector<Article>& articles) {
    int total = 0;
    for (const auto& article : articles) total += article.words;
    return total;
}

Shell

npx garden check && npm run build

for file in content/posts/*.md; do
  wc -m "$file"
done

Diff、图片与原生 HTML

- const publishing = "copy and paste";
+ const publishing = "content as source";

code: |
  <p class="garden-html-probe">静态 HTML 块</p>

items:
  - "**程序化**：结构化、强状态、可以穷举的场景。"
  - "大模型: 非结构化、需要理解语境的场景。"

最后用一个脚注说明这篇文章的角色：它既是示例，也是未来升级 Markdown 依赖时的回归测试。[^regression]

[^regression]: 页面构建测试会检查公式与示例内容，浏览器验收会检查 Mermaid 是否被转换为 SVG。

这一条随想故意把三张照片、一段声音、一段视频和一个链接放在一起，用来确认日常记录不需要被单一媒体类型限制。

好的界面不只是让事情更快发生，也应该帮助人知道什么值得发生。

界面在分配什么

每一个高亮、通知和默认选项，都在替用户分配注意力。它们看上去只是视觉决策，实际上却在参与判断。

摩擦不是敌人

有些摩擦应该被删掉，例如重复输入和无意义的确认；另一些摩擦则应该被保留，例如发布前的停顿、删除前的复核，以及阅读长文时清晰的段落边界。

type Friction = {
  cost: number;
  protectsIntent: boolean;
};

const shouldRemove = (friction: Friction) =>
  friction.cost > 0 && !friction.protectsIntent;

把节奏设计进去

我现在更愿意先问三个问题：

1. 用户来到这里时，最需要看见什么？
2. 哪些信息可以晚一点出现？
3. 这个流程应该在哪里自然结束？

这些问题没有让界面变得更复杂，反而让许多元素失去了存在的理由。

最后的判断

注意力不是取之不尽的资源。产品真正的克制，不是少用一种颜色，而是少向用户索取一次不必要的注意。

脚注也应该像在 Typora 中一样自然工作。^attention

验证真实路径

测试最小单元很重要，但用户真正经历的是一条完整路径。至少有一次验证应该从入口走到结果。

不隐藏边界

没有验证的部分要明确说出来。诚实的边界比虚假的完整更有价值。

留下下一步

一次发布应该让下一次开发更容易开始，而不是重新理解所有上下文。

文件就是作品

文章不应该只存在于某个编辑器的数据库里。标题、发布日期和主题放进 YAML front matter，正文保持标准 Markdown，图片则和文章一起归档。

发布只是一次编译

写作和发布可以分离。写作阶段只关心内容；网站读取文件，生成目录、搜索索引和 RSS。

• 在 Typora 中完成正文
• 提交 Markdown 与媒体资源
• 发布后继续修正

可迁移才有长期主义

真正的长期主义不是选中一个“永远不会倒闭”的平台，而是让迁移成本始终足够低。

唯一事实来源

先确定数据由谁拥有，再决定界面如何派生。临时交互状态可以留在视图，持久事实必须有明确边界。

乐观更新

乐观更新让操作显得即时，但失败时必须能够回滚，并且不能让选择状态丢失。

可恢复

真正可靠的状态不是永不失败，而是在失败以后仍然知道应该回到哪里。

什么是最小闭环

它必须包含触发、完成和反馈。只有按钮不算闭环，只有数据结构也不算。

把想法切成动作

以一个文件浏览器为例，第一步不是标签、搜索或批量操作，而是：

1. 创建文件夹；
2. 创建 Markdown 文件；
3. 刷新列表；
4. 自动选中新项目。

可观察的完成

闭环需要能被人看见，也能被测试验证。每次完成之后，都应该留下足够明确的证据。

下一步

当闭环成立，再进入命名、删除和上下文菜单。功能扩展不再是猜测，而是沿着已经成立的路径自然生长。

页码不等于位置

同一页里也有阅读进度。只记录页码，恢复后仍然可能让人失去上下文。

变化前先保存锚点

布局变化之前，保存视口中心所对应的文档坐标；布局完成以后，再把这个坐标映射回新的视口。

两条交互路径

侧栏开关是离散变化，分隔线拖拽是连续变化。它们应该共享“保持锚点”的原则，但不应该共享完全相同的更新频率。