决策日志的作用，是在半年后回答一个问题：「我们当时为什么这么定？」可大多数日志做不到——写一次，埋进文档，然后在产品往前走的时候悄悄过时。这不是自律问题，而是一份静态文档根本无法知道：它记下的某个决策，什么时候已经不成立了。Draftlize 让决策日志成为 AI agent 能读也能写的东西——一个上游决策一变，每个依赖它的决策都会自动把自己标记成 stale。
写在 Notion、Confluence 或 markdown ADR 里的决策日志，是一张快照。决策一变，日志就错了，而且没人知道。解法不是更强的自律，而是一个替你追踪依赖的 substrate。
| Draftlize | 文档 / Confluence / markdown ADR | |
|---|---|---|
| 记录一个决策 | 结构化卡片：决策、理由、备选、依赖 | 一段文字 |
| 半年后还找得到 | 可按 URL / ID 寻址 | 埋着，得在 wiki 里翻 |
| 决策变了，下游知道吗 | 自动标记 stale | 没有连接，悄悄腐烂 |
| AI 用得上吗 | 经 MCP 原生读 + 写 | 顶多读个纯文本 |
| 谁来保持一致 | substrate 自动追踪 | 全靠你的意志力 |
| 和早先的决策冲突 | 自动浮现 | 下次复盘才发现 |
决策日志写给「未来的我们」。但未来的我们很忙，日志躺在没人重开的文档里。架构决策记录（ADR）从 2011 年就有，一直在腐烂，正是这个原因——读者是人，而人不会回头读。
你第 3 周定了定价，第 7 周改了。三个假设了旧定价的 spec 现在全错了——但没有东西把它们连到那个决策上，于是没人更新，直到演示时出事。
每一份决策日志都死于同一种死法：第一天完美，第九十天 40% 是错的。保持它最新，是个跟「发版」抢时间的杂活，而发版永远赢。
当日志的首要读者是 agent——一个在起草下一份 spec 前会读完每张相关卡片的 agent——决策日志就不再是坟场，而成了随手可得的上下文。它在每一轮都被读，而不是等到下次复盘。
每个决策都是一张带显式依赖的卡片。改掉定价决策，每张依赖它的卡片自动变 stale——就像构建系统让一个改动文件的所有下游失效一样。
决策是一张有稳定 ID 的卡片，能从 spec、thread、或经 MCP 从 Claude Code 引用。「依据决策 c-04」成了一个真实的链接，而不是模糊的记忆——而一份决策日志模板或架构决策记录（ADR）也成了你克隆的起手包，而不是让你发怵的空白页。
决策日志只有在「有东西回头读它」时才有用。让那个东西，成为一个永不跳过任何一张卡片的 agent。你靠手动维持不下去的自律，substrate 替你维持。
决策日志是团队重要决策的流水记录——定了什么、为什么、考虑过哪些备选、什么时候定的。它的作用是在几个月后回答「我们当时为什么这么定？」，让推理不至于丢失，旧的选择也不必每个 sprint 重新吵一遍。
每条应记下决策本身、背后的背景与问题、你权衡过的备选、理由、日期，以及依赖它的人或 spec。最后这一项是大多数日志漏掉的——而正是它，让你日后能知道：这个决策一变，什么会跟着坏。
因为一份静态文档无法知道：它记下的某个决策，什么时候已经不成立了。它写一次、埋进文档，然后在产品往前走时悄悄过时——又因为没有任何东西把决策连到依赖它的东西上，没人会去更新下游，直到出事。
Draftlize 把每个决策做成 AI agent 能读也能写的可寻址卡片。每张依赖卡都声明它靠什么，于是一个决策一变，所有下游自动标成 stale——你靠手动撑不住的那份自律，交给 substrate 替你撑。
建一个项目，用你已有的文档把它喂起来，让 agent 替你把决策——以及一切依赖它们的东西——保持最新。
用 $5 免费开始一键创建项目：这些章节会预置成结构化、互相链接的卡片。和 agent 一起回答它们——之后任何决策变了，依赖它的章节会自动标记过时，而不是悄悄失真。注册送 $5 额度，无需绑卡。