活文档（living documentation）指的是与它所描述的系统保持同步、而不是写完那天就冻住的文档。敌人是文档漂移：文档发布时是准的，产品往前走，几周内它就悄悄地、很自信地错了——而读者分不清哪份新、哪份旧。常见的补救——一张 review 清单、一个文档 sprint、更多自律——每次都输给「发版」。Draftlize 走另一条路：文档从 card graph 派生而来，每份都带着它由哪些卡片生成的快照，一旦上游某个决策变了，文档就自己标成 stale。
每份文档在上线那天都是准的。问题在第 90 天——它能不能告诉你它过时了，还是只会继续读着像真的。
| Draftlize | wiki / Confluence / markdown | |
|---|---|---|
| 文档从哪来 | 从来源卡片派生 | 手打，然后脱钩 |
| 某个来源决策变了 | 文档自动标 stale | 文档悄悄变错 |
| 一眼能不能信？ | stale 是标出来的，不用猜 | 你得对着代码重新核 |
| AI agent 能靠它吗？ | 经 MCP 读当前卡片 | 读到什么文本算什么 |
| 谁让它保持最新 | substrate 追踪漂移 | 一个永远不来的文档 sprint |
文档在写下那天最完美，之后更新它就是永远的苦差。维护跟发版抢时间，输了，于是文档冻在原地、系统继续往前——每次发布，缝就更宽一点。
漂移最糟的地方是它看不见。一份过时的文档和一份最新的长得一模一样，于是读者信了它——而一份很自信地错着的文档，比没有文档更贵。
问题从来不是把文档写出来，而是文档没法知道自己什么时候不再成立。让文档从决策派生。决策一动，文档就说话。
活文档是与它所描述的系统保持同步、而不是写完那刻就冻住的文档。这个词来自 BDD 圈，那里文档是从可执行的规格生成的。更广义的想法是：文档应该从一个活的来源派生出来，于是来源一变，它要么自动更新、要么把自己标出来。
文档漂移是指：系统在演进、文档没跟上，两者之间裂开的那道缝。它危险，是因为一份漂移的文档和一份最新的长得一模一样，读者会继续信它——一份很自信地错着的文档，比没有文档更贵。
持久的解法是别再手动维护文档，而是从单一来源派生它，再在来源变化时把它标出来。Draftlize 从 card graph 生成文档，并记下来源卡片的快照，于是一个后台检测器能在上游决策一动那一刻，就把文档标成 stale。
Docs-as-code 把文档放进版本控制、和代码一起走同一条流水线——这是真实的进步，但文档仍然是一段得靠人记着去更新的散文。放在 card graph 上的活文档补上了缺的那一环：文档知道自己依赖哪些决策，于是它能自己标 stale，而不是指望有人注意到。
把决策和 spec 存成卡片，从它们派生文档，让每份文档在来源决策一动时就标 stale。
用 $5 免费开始