BaseHalf
全部文章

核对过的结论写进自己的笔记，模型草稿就留在草稿里

我们在 BaseHalf 文件夹里核对 RFC 9562 的 UUID 版本规则，从官方 PDF 里长出一则笔记，让 Claude Code 写出草稿，再把亲自核对过的结论单独写进一页定稿。

我需要一页明天还能打开的笔记，讲清楚 UUID 的版本该怎么读。我不希望模型写出的第一份草稿，自动变成那一页。

问题本身很平常。在带连字符的 UUID 字符串里，版本到底是哪一个字符？我以前总是先看第一个十六进制数字。RFC 9562 废止了 RFC 4122：这是不是意味着 UUIDv4 已经不再被规定？人们推荐 UUIDv7 的时候，里面的 Unix 时间是按秒来计的吗？附录里的测试向量 017F22E2-79B0-7CC3-98C4-DC0C0C07398F，我也想自己读一遍，而不是只记得某篇博文里的说法。

我把官方文本放进一个文件夹，用 BaseHalf 0.6.1 打开。这份文件是 RFC 9562，标题是 Universally Unique IDentifiers (UUIDs)，作者是 K. Davis、B. Peabody 和 P. Leach，2024 年 5 月由 IETF 以 Standards Track 发布，并废止 RFC 4122。我在 2026-11-13、Asia/Shanghai 从 RFC Editor 取回了官方 PDF 和官方文本，把它们留在文件夹里阅读。我不会重新发布这份文件。一份简短的 SOURCE.md 记下了这些事实。我还在核对正文之前，先写了 question.md，里面是四个问题和我的第一轮猜测。

在 Card Detail 里，我打开这份 PDF，翻到第 10 页的 4.2 节 Version Field，选中标题和说明版本比特位置的那一句，然后用了 Grow branch。于是出现了 rfc9562-note.md，它的 upstream 里已经列着 rfc9562.pdf，还有一段引用，以及指向第 10 页的来源链接。引用在 bits 48 throug 这里就断了。我没有把它修整齐。我也读了第 11 页的 Figure 5、第 14 页的 5.4 节、第 18 和 19 页的 5.7 节，以及第 43 页的附录 A.6，并在 rfc9562.txt 里对过相同的措辞。

我把官方文本和长出的笔记写进 question.md 的 upstream 列表，把它们连了上去。画布上，这些文件之间出现了连线。SOURCE.md 就在旁边，但我没有连它。挨着放，是给眼睛看的。连线记下的，是应该留下来的上下文。

uuid-versions 文件夹在 BaseHalf 画布上：左边是问题，中间是 rfc9562.pdf，右边是 rfc9562.txt 和 SOURCE.md，文本文件下方是长出的笔记；官方文本和笔记有连线指向问题，SOURCE.md 没有。

Card Detail 打开 rfc9562.pdf，停在第 10 页的 4.2 节，标题和版本字段那句话被选中，选区下方的小工具栏里有 Grow branch 按钮。

我选中了问题这张卡片。状态栏显示，agents 能看到的是 question。我在 Agent Area 里启动了 Claude Code，请它阅读这个问题，并且只读其 upstream 里列出的文件，然后在同一个文件夹里写出 draft-answers.md，引用 RFC 9562 里的规则，不要改已有的笔记。我告诉它，长出的笔记可能是截断的，完整措辞要以官方文本为准。

同一张画布上选中了问题卡片，Agent Area 里的 Claude Code 已输入请求：根据官方文本和长出的笔记写 draft-answers.md，并且不要改已有文件。

1 分 29 秒后，也就是 Asia/Shanghai 时间 18:12，草稿出现了。它出现在侧边栏里，也作为一张新卡片出现在画布上。它的 upstream 列了问题和官方文本。它没有改 question.md、SOURCE.md、长出的笔记，也没有改 RFC 文件。我读了这份草稿，仍然没有把它当成明天要打开的那一页。

我核对了官方句子，也核对了一处算术。

  1. 版本并不是字符串的第一个十六进制数字。4.2 节写的是："The version number is in the most significant 4 bits of octet 6 (bits 48 through 51 of the UUID)." 第 11 页的 Figure 5 把这个位置写成 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx 里的 M，也就是第三组的第一个字符。
  2. 4.2 节的 Table 2 把版本 7 写成 "Unix Epoch time-based UUID specified in this document." 5.7 节把单位说得更准确："the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded." 它不是按秒计数。
  3. RFC 9562 废止了 RFC 4122，但仍然规定了 UUIDv4。摘要里写："This document obsoletes RFC 4122." Table 2 仍然把版本 4 列为 "The randomly or pseudorandomly generated version specified in this document." 5.4 节开头是："UUIDv4 is meant for generating UUIDs from truly random or pseudorandom numbers."
  4. 附录 A.6 的测试向量 017F22E2-79B0-7CC3-98C4-DC0C0C07398F 里，M 这个字符是 7，RFC 把 ver 写成 0x7。同一节给出的时间戳是 "Tuesday, February 22, 2022 2:22:22.00 PM GMT-05:00, represented as 0x017F22E279B0 or 1645557742000." 前面 12 个十六进制数字，就是 5.7 节里 48 比特的 unix_ts_ms 字段。我把 1645557742000 毫秒换算成 2022-02-22 19:22:22 UTC，也就是 GMT-05:00 的 14:22:22，这只是在核对我的算术，并不是另一份权威。

我把这些核对过的结论写进一个新文件 settled.md，第一轮猜测仍留在 question.md 里。我把官方文本、长出的笔记和问题连到了这页定稿上，没有把草稿连上去。草稿就留在文件夹里，仍然是草稿。

同一文件夹在 draft-answers.md 和 settled.md 出现在画布之后：定稿在问题下方，草稿在长出的笔记右侧，Agent Area 里的 Claude Code 还在回顾这四个答案。

Card Detail 以 Preview 打开 settled.md，可见标题 What I checked in RFC 9562 和四条核对过的结论，右侧 Agent Area 里仍能看到 Claude Code 的回顾。

这并不是把模型的每一句回复都变成定稿的笔记本，也不是内置的摘要。状态栏里的选择只在窗口开着时有效。官方文本、长出的笔记、问题、草稿和定稿，都是这个文件夹里的普通文件。即使关掉对话，我仍然有那页写进了核对结论的笔记，也仍然看得出，那份草稿只是草稿。