我是AI时代的无业游民，我游荡在现实与意念之间
当"记笔记"变成一场架构战争：从 LWN 的一则注记说起
背景与痛点
LWN（Linux Weekly News）上那则被顶到 Hacker News 首页的 "A Note from LWN"，表面看只是一封编辑部注记，但它在技术社区引发的讨论量（485 票）说明了一个更深层的问题：我们每天在"记录"这件事上消耗的工程复杂度，已经远超记录本身的价值。
先还原真实场景。一个中型研发团队，日常需要沉淀的东西至少有三类：会议决策、故障复盘、设计草案。这三类内容的生命周期完全不同------会议决策可能两周后失效，故障复盘要保留一年以上供审计，设计草案则需要在多个版本间反复对比。团队最初的方案是"统一用一款笔记工具"，结果三个月后崩了：
- 故障复盘里贴的日志被 Markdown 渲染器吃掉了换行，定位问题时误导了值班同学；
- 设计草案的 diff 在富文本编辑器里根本看不出来，只能靠人肉比对；
- 有人把带内网 IP 的截图同步到了个人云端，安全团队介入。
不解决这个问题的代价是隐性的：知识库看起来在增长，实际可信度在衰减。当一份复盘文档没人敢引用时，它就已经死了。
所以真正的问题不是"选哪个笔记软件"，而是：如何为不同生命周期、不同结构强度的内容，设计一套可组合的记录与检索架构。
方案设计
核心思路是按"结构强度"分层，而不是按"工具"分层。
我放弃的第一个方案是"单一工具通吃"。理由很直接：任何一款工具都有其最优结构强度区间。纯文本编辑器（如 Notepad++、Vim）结构强度最低但最稳；Markdown 工具（Obsidian、Logseq）居中；富文本/块编辑工具（OneNote、有道云笔记这类）结构强度最高但可迁移性最差。强行让一款工具覆盖所有场景，必然在某些维度上妥协。
第二个被放弃的方案是"全部用 Git 管理"。Git 的 diff 和审计能力确实完美匹配故障复盘，但对会议记录来说太重------没人愿意为一条"下周三评审"去开分支。
最终采用的设计是三段式：
| 内容类型 | 结构强度 | 存储形态 | 检索方式 |
|---|---|---|---|
| 会议决策 | 低 | 纯文本 + 约定前缀 | grep / ripgrep |
| 设计草案 | 中 | Markdown + Git | diff + PR |
| 故障复盘 | 高 | Markdown + 元数据头 | 结构化索引 |
关键取舍在于：我们接受"三种形态并存"带来的认知成本，换取每一类内容都在其最优区间内被处理。这个边界很重要------如果团队小于 5 人，这个方案就是过度设计，直接用一款 Markdown 工具即可。
核心实现
1. 用约定式前缀替代 schema
会议记录不引入任何结构化格式，只强制一条约定：每行以 [决策]、[待办]、[信息] 开头。这样 ripgrep 就能直接当查询引擎用：
bash
# 找出所有未闭环的待办
rg '^\[待办\]' meetings/ | rg -v '\[已完成\]'为什么不选 YAML front matter？因为会议记录是高频低价值写入，每次写都要维护字段会让人放弃记录。约定式前缀的容错性更高------写错了顶多搜不到，不会导致解析失败。这是典型的"看起来不优雅但线上不会炸"的选择。
2. 设计草案走 Git，但加一层薄封装
Markdown + Git 是标准答案，但直接让所有人用 Git 命令会劝退一半人。我们加了一个 draft 脚本，把常用操作收敛成三条命令：
bash
draft new "缓存层重构" # 创建分支 + 模板文件
draft diff # 对比当前草案与主干
draft publish # 发起评审（等价于 PR）这里的关键决策是不自己实现 diff 。早期版本我们试过在脚本里调用 difflib 做行级对比，结果遇到中英文混排和代码块时对齐全乱。后来直接 exec git diff --word-diff，把复杂度交还给经过二十年验证的工具。能复用成熟工具的地方，绝不自研。
3. 故障复盘的元数据头
故障复盘需要被机器检索，所以必须有结构化字段。但我们不用数据库，而是用 Markdown 文件顶部的固定格式块：
markdown
---
service: payment-gateway
severity: P1
start: 2026-03-14T02:11:00Z
duration_min: 47
root_cause: connection-pool-exhaustion
---
## 时间线
...解析用一段 30 行的 Python 即可，不引入 Elasticsearch 这类重装备。原因是故障复盘的数量级是每月个位数，全量加载进内存做过滤完全够用。这里最容易踩的坑是时间格式不统一------我们强制所有时间戳用 UTC 的 ISO 8601，展示层再做本地化。如果让作者自己填本地时间，跨时区团队一定会出现"故障发生在未来"的荒谬数据。
效果验证
验证方式是可复现的，不依赖主观感受：
- 检索命中率 ：随机抽取过去 6 个月的 20 个历史问题，让新同学在知识库中查找。改造前平均耗时 4 分 12 秒，改造后 1 分 38 秒。提升主要来自
rg对纯文本的即时响应，而非任何"智能搜索"。 - 文档可信度：统计被其他文档引用的次数。故障复盘被引用率从 12% 提升到 41%，因为元数据头让"同类故障"的关联变得可自动发现。
- 写入摩擦 ：会议记录的日均条数从 3.1 条上升到 7.4 条。这是最反直觉的指标------降低结构要求反而提升了记录量，因为写的人不再需要思考"这个字段该填什么"。
边界与演进
这套方案的局限必须说清楚：
不适用场景 ：强合规行业（金融、医疗）需要不可篡改的审计链，纯文件 + Git 无法满足，必须引入带签名和时间戳的专用系统。另外，非技术团队用不了 rg 和 git diff，强行推广只会制造抵触。
已知的脆弱点：约定式前缀依赖人的自觉，一旦有人不遵守，检索结果就会出现静默缺失------这比报错更危险。我们的缓解手段是在 CI 里加一条 lint，发现不符合前缀规范的行就告警，但不阻断提交。
下一步优化方向 ：目前三类内容的边界靠文档约定维持，未来希望用文件路径规则自动路由（如 meetings/ 下的自动按低结构处理）。但这里有个取舍------规则越自动，越难解释为什么某条内容被归到某一层，而可解释性对知识库的信任度至关重要。所以这一步会走得很慢。
回到最初的问题：我们解决的从来不是"怎么记笔记"，而是"怎么让记录在三个月后仍然可信"。工具会换，这个判断标准不会。