Lunote结构不等于官僚主义
结构不是给每页笔记套厚重模板，而是让决策有固定落点，让症状能链到原因，让标题在未来依然好搜。一段链到 [[payment-module]] 的简短 ADR，胜过十页没人打开的文档。
工程笔记库里好用的几种模式
- 枢纽笔记 — 如
[[Platform overview]]这类索引页，链到各服务与运维手册。 - 决策记录 — 简短的「我们选 X，因为 Y」笔记，在 Frontmatter 里写上日期和状态。
- 事故关联 — 把复盘链到受影响的组件，而不只留在 Slack 线程里。
- 按问题组织代码片段 — 示例代码放在以问题命名的笔记里，而不只以文件名命名。
工具要减摩擦，而不是加流程
如果链两条笔记比复制一段文字还麻烦，结构就坚持不下去。Lunote 优化了快速写作与 [[双链]] 自动补全、知识侧栏里的反向链接，以及知识图谱——帮你看看「平台枢纽」是真的连出去了，还是成了孤立节点。
用「找答案要多久」来衡量成效
正确的指标不是笔记数量。不妨问：回答「为什么移动端 auth 行为是这样？」需要多久？如果路径是枢纽 → 服务笔记 → ADR → 事故记录，你的系统就在起作用。