架构决策记录（ADR）要回答一个代码库里最贵的问题：「为什么是这么搭的？」这套实践本身是对的——一份小小的、带日期的记录，写下当时的背景、做了什么决定、以及后果。问题出在 substrate。一份 ADR 是 check 进 repo 的 markdown 文件，在做决定那天写下，之后再没人打开。代码在演进，决策悄悄不再匹配现实，ADR 就成了考古文物。Draftlize 保留这份记录本身——但让它成为 AI coding agent 在动代码之前会先读的东西，并在它所记录的决策不再成立的那一刻，自动翻成 drift_detected。
放在 docs/adr/0007-use-event-sourcing.md 里的 ADR，提交那天是对的，之后就慢慢和运行中的系统分叉。解法不是更严的 review checklist，而是一个知道哪些记录还匹配代码、并在某条不匹配时告诉你的 substrate。
| Draftlize | repo 里的 markdown ADR | |
|---|---|---|
| 记录本身 | 结构化卡片：背景、决策、后果、依赖 | 一份手填的 markdown 模板 |
| 状态字段 | 活的——自己翻成 drift_detected | 手动改；通常还写着「Accepted」 |
| 决策变了，代码知道吗 | 依赖它的记录自动标记 drift | 没有连接，文件一直骗人直到有人发现 |
| coding agent 用得上吗 | 经 MCP 原生读 + 写 | 你指给它，它顶多读个纯文本 |
| 动代码前会被读 | agent 先拉出相关 ADR | 没人打开 docs/adr/ |
| 谁来保持它诚实 | substrate 自动追踪 | 一份没人执行的 review checklist |
Michael Nygard 在 2011 年提出架构决策记录，是为了捕捉「为什么」——一个结构性决定背后的背景和取舍。格式没错。但 ADR 归档在 docs/adr/，它的读者是一个永远不会打开这个目录的未来工程师。一份没人回头读的记录，做不到它唯一的那件事。
ADR-0007 写着「账本用 event sourcing」。十八个月后，半个账本又变回了 CRUD——在三个 PR 和一条 Slack 里定下来的。状态那栏还写着 Accepted。这份记录现在会主动误导下一个相信它的人——这比没有记录更糟。
更新 ADR 是个跟「合 PR」抢时间的手动杂活，而 PR 永远赢。于是记录冻结在写下的那一刻，系统却一直在动，docs/adr/ 和 main 之间的鸿沟每个 sprint 都在变宽。
一份标准 ADR 有五个字段。Draftlize 五个全保留——并把那个总是骗人的字段，Status，从「你忘了改的东西」变成「substrate 替你维护的东西」。
一个简短、可寻址的名字。在 Draftlize 里它是一张有稳定 ID 的卡片，能从 spec、thread 或 agent 引用为「依据 ADR-0007」——一个真实的链接，而不是一个你得 grep 的文件名。
在 markdown 里，Status 靠手动改，永远停在 Accepted。在 Draftlize 里它是活的：上游决策一动，实现就把自己翻成 drift_detected，于是不用任何人更新，记录也讲真话。
做这个决定时在起作用的各种力量。它连着它所依赖的那些决策——所以当那些变了，这份记录会知道：自己的前提已经动了。
你选了什么、排除了什么。备选方案是卡片的一部分——所以半年后没人会重新争论一个你早已关掉的选项。
这个决定带来的后果，好的坏的都算。继承这些后果的依赖卡片都连着——当这份记录在它们脚下变动时，它们会标记 drift。
经 MCP 接入的 Claude Code 或 Cursor，会在动一个模块之前先拉出相关记录——于是「这里为什么用 event sourcing」背后的决策，正好在最关键的那一刻进入上下文，而不是埋在没人打开的目录里。那个永不回来的读者，现在成了那个永不跳过任何一张卡片的读者。
当 agent 在任务中途做了一个结构性决定，它可以把一条新 ADR 记成一张卡片——title、context、decision、consequences——不用离开手头的活去打开一个 markdown 文件。记录之所以会被写下，是因为写它只是一次 tool call，而不是一次上下文切换。
每条记录都带显式依赖。改一个上游决策，每条建立在它之上的记录都翻成 drift_detected——就像构建系统让一个改动文件的所有下游失效一样。决策和代码之间的鸿沟，不再是你在复盘时才发现的东西。
ADR 这套实践从来不是问题。问题是一份记录没法知道：自己其实已经错了。五个字段都留下。把它们搬到一个会替你维护那个「会骗人字段」的 substrate 上。
ADR 是对一个重要架构决策的简短带日期的记录——背景、拍板、后果。这个做法由 Michael Nygard 在 2011 年提出，用来记下系统为什么这样搭，让后来的工程师不必从代码里反推当初的理由。
五个字段：标题、状态、背景、决策、后果。标题命名这次拍板，状态记它是提议、已接受还是被取代，背景记当时在起作用的各种力，决策讲清选了什么、否了什么，后果记它让你承担了什么。
因为它是签进 repo 的静态 markdown，写一次、很少再打开。代码在演进，决策悄悄和现实对不上了，但状态字段还写着「已接受」——于是这份记录反而会误导下一个信它的人，比没有记录更糟。
Draftlize 保留同样五个字段，但把记录做成 AI 编码 agent 在动代码前会先读、拍板后会写回的卡片。上游决策一动，实现状态就自己翻成 drift_detected——那个总在撒谎的字段「状态」，不用任何人去改就保持诚实。
建一个项目，把你已有的 ADR 作为卡片导进来，再经 MCP 接上你的 coding agent——让记录在动代码之前就被读到，并在决策一动时标记 drift。
用 $5 免费开始一键创建项目：这些章节会预置成结构化、互相链接的卡片。和 agent 一起回答它们——之后任何决策变了，依赖它的章节会自动标记过时，而不是悄悄失真。注册送 $5 额度，无需绑卡。