[!info] related notes

• 所属 MOC: Obsidian MOC
• 模板: Templater 插件指南
• 格式整理: Linter 插件指南
• 周期记录: Periodic Notes 插件指南
• 版本控制: Obsidian Git 插件指南
• 发布: Obsidian Digital Garden 插件指南
• 文件命名: Obsidian 笔记标题与文件名

Obsidian 写作工作流

目标与成功状态

这套流程解决的是：

一篇内容怎样从模糊想法稳定走到可发布成品，并且过程可恢复、可复用、可复盘。

完成一篇文章时，至少应留下：

• 一个明确题目与目标读者；
• 一份可解释文章结构的提纲；
• 一个经过事实/逻辑/文字三轮检查的正文；
• 规范 metadata 与内部链接；
• 明确发布版本；
• 发布后的反馈或复盘记录。

插件只是支撑流程，不是流程本身。

总体模型

Capture
→ Select
→ Outline
→ Draft
→ Edit
→ Verify
→ Package
→ Publish
→ Reflect

不要把：

安装很多插件
= 建立了写作系统

两者混为一谈。

1. Capture：先捕获，不急着写成文章

灵感出现时只记录最低成本信息：

题目 / 问题
为什么值得写
触发来源
可能的读者
相关链接

例如：

---
type: idea
status: seed
---

# 为什么 Event Loop 不能只背宏任务/微任务

- 触发：Node.js setImmediate / setTimeout 顺序问题
- 目标读者：前端转全栈开发者
- 核心冲突：浏览器模型被错误套到 Node
- 相关：[[js-event-loop]]

捕获阶段不要为了“格式完整”阻塞思考。

2. Select：把灵感变成一个可交付问题

正式开始前回答四个问题：

1. 这篇文章最终回答什么问题？
2. 谁会因为它受益？
3. 读者读完应该能解释、判断还是完成什么？
4. 哪些内容明确不属于本篇？

如果一句话无法表达核心问题，说明题目可能还太大。

例如：

差：
“JavaScript 异步详解”

较清楚：
“为什么浏览器与 Node.js 不能用同一张 Event Loop 图解释”

3. Outline：先设计论证结构

推荐先写标题骨架，而不是直接从第一段一路写到底。

常见结构：

问题
→ 核心结论
→ 心智模型
→ 证据 / 机制
→ 示例
→ 边界 / 反例
→ 实际决策
→ 总结

技术文章尤其要提前确认：

• 哪些结论需要引用官方文档；
• 哪些示例必须实际运行；
• 哪些图片/代码是必要证据；
• 哪些知识已经存在于知识库，只需要链接。

4. Draft：先完成一版，不边写边完美化

初稿优先保证：

• 论点完整；
• 关键例子到位；
• 暂缺资料处显式标记；
• 不因为格式、错别字或图片位置反复中断。

可以使用：

TODO: verify
TODO: source
TODO: example
TODO: diagram

初稿的目标是形成完整思路，而不是直接达到发布质量。

5. Edit：分轮次编辑

不要一遍同时改逻辑、措辞、格式。

第一轮：结构编辑

检查：

• 题目是否真的被回答；
• 章节顺序是否存在因果；
• 是否重复解释同一个点；
• 有没有明显跑题；
• 是否应拆成独立文章/知识笔记。

第二轮：事实与技术编辑

检查：

• 结论有无证据；
• API / 版本 / 命令是否过时；
• 示例能否运行；
• 边界条件是否遗漏；
• “最佳实践”是否被错误写成绝对规则。

第三轮：文字编辑

检查：

• 长句；
• 模糊指代；
• 重复形容；
• 无意义铺垫；
• 术语是否前后一致。

第四轮：格式编辑

再处理：

• frontmatter；
• 标题层级；
• Markdown；
• 代码块；
• 图片；
• 链接。

格式自动化统一交给 Linter 等工具，不在本页复制插件配置。

6. Verify：把可验证内容真的验证

技术写作应尽量满足：

代码 → 跑过
命令 → 执行过
UI → 看过真实效果
版本事实 → 查官方来源
性能结论 → 有测量

特别避免：

“看起来应该是这样，所以直接写进正文。”

如果文章包含当前软件行为、价格、版本、政策或 API，应在发布前重新验证。

7. Package：整理成可发布资产

发布前固定：

• title；
• slug / filename；
• description；
• tags；
• cover / diagram（如果需要）；
• 外部引用；
• 内部 WikiLink；
• code block language；
• 发布状态。

模板自动生成可由 Templater 负责。

8. Publish：发布渠道和写作内容分离

文章本体是内容资产，发布只是 distribution。

可能的渠道：

Obsidian Vault
→ Git
→ Quartz / Digital Garden
→ PDF
→ 社交平台摘要

具体 Digital Garden 配置见 Obsidian Digital Garden 插件指南。

不要让某个平台私有格式成为正文唯一来源。

9. Reflect：发布后收集反馈

发布后至少记录：

• 哪个段落最容易被误解；
• 哪个结论被质疑；
• 哪些搜索词带来访问；
• 哪些问题值得拆出下一篇；
• 是否出现事实过期。

对于周期复盘，可以用 Periodic Notes。

灵感、知识笔记与文章的边界

三者不应互相替代：

Idea
= 还没验证的写作机会

Knowledge Note
= 稳定、可复用的知识节点

Article
= 为特定读者组织的连续叙事

一篇文章可以引用多个知识节点，但不必把整个知识库复制进去。

反过来，一篇文章中形成新的稳定知识，也应该拆回知识库。

推荐目录状态模型

不需要复杂文件夹也可以工作，关键是状态清楚：

seed
→ outlining
→ drafting
→ editing
→ ready
→ published
→ updating

状态属于文章生命周期，不要通过“文件移动到十几个目录”隐式表达所有信息。

最小模板

---
title:
description:
status: drafting
created:
updated:
---

# 标题

> 核心问题：

## 为什么值得写

## 核心结论

## 心智模型

## 机制 / 证据

## 示例

## 边界 / 反例

## 实际应用

## 总结

## Sources

具体模板自动化不要继续扩写在本页，放到 Templater 插件指南。

常见失败模式

插件驱动流程

先装十个插件，再试图决定怎么写。

修正：

先定义工作流
→ 再找自动化痛点
→ 最后选插件

Capture 阶段过度整理

一个灵感为了补 metadata 花五分钟，导致记录成本太高。

初稿与编辑同时进行

每写一句就反复改，难以形成整体结构。

文章和知识节点完全重复

文章为了连续叙事可以重复必要定义，但长期维护的稳定事实应回链知识节点。

发布后永不更新

技术文章应允许进入 updating，而不是把 published 理解为永久冻结。

一个 60–120 分钟短文循环

10 min   定题 + 读者 + 边界
15 min   提纲
30–60 min 初稿
15 min   结构/事实编辑
10 min   文字/格式
5 min    发布检查

长文仍可使用同一阶段，只是每阶段跨多次 session。

无提示执行检查

不看正文，从一个新灵感开始：

1. 用一句话定义核心问题和读者；
2. 写 5–8 个标题组成论证结构；
3. 标出需要验证的事实与代码；
4. 完成不追求格式完美的初稿；
5. 分别做结构、事实、文字、格式四轮编辑；
6. 把插件专属配置链接到独立专页，而不是写进文章流程；
7. 发布后记录至少一个反馈并决定是否更新知识节点。