技术决策被推翻后，处理记录的核心原则是保留原记录、另建新记录并建立双向关联。原决策记录承载的是当时的背景、约束和判断依据，直接改写会让后来者失去理解决策演变的线索。本文按判断变更类型、编写新记录、建立双向关联、明确角色分工、参照示例、发布前检查的顺序展开，帮助团队把一次决策替换做成可追溯的完整记录。
要点总览（TL;DR）
- 原决策记录保持正文原样，只追加状态标注和指向新记录的链接；另建一条新记录写明推翻原因、新方案、生效时间与影响范围。
- 先判断变化类型：换方案按推翻处理，新建记录；局部调整按修订处理，在原记录追加说明；不再需要该决策按废弃处理，标注失效。
- 双向关联是新记录引用原决策编号、原记录标注“已被替代”并链接新记录，只在新记录里提一句会造成追溯断链。
- 角色分工要落到交付物：提出人交初稿与依据，架构师评审影响范围，文档维护人当日回写状态与索引，受影响团队确认下游文档。
- 发布前核对原记录未被覆盖、要素齐全、双向链接可点击、索引与下游文档已同步；无推翻原因、无关联、原记录被改写属于阻断项。
先判断：这次变化属于推翻、修订还是废弃
动手写记录之前，先给这次变化定性。定性决定了后续动作是新建一条记录、在原记录上追加说明，还是新建一条失效记录。判断时看三个信号：触发原因是什么、影响范围有多大、是否产生了新的技术选择。
如果原来的技术方案整体不再适用，团队选择了另一套方案，属于推翻。典型情形是架构演进、业务规模变化、关键技术依赖停止维护。如果方案主体保留，只是参数、边界或局部实现需要调整，属于修订。如果这项决策对应的需求或场景已经不存在，团队不再需要它，属于废弃。
| 变更类型 | 判断标准 | 处理动作 |
|---|---|---|
| 推翻 | 原方案整体不再适用，已产生新的技术选择，影响范围涉及多个模块或团队 | 新建一条决策记录，写明推翻原因与新方案，与原记录建立双向关联，原记录标注“已被替代” |
| 修订 | 方案主体保留，仅局部调整参数、范围或实现方式，未产生新的方案选型 | 在原记录上追加修订说明，注明修订日期、内容与原因，保留原有正文 |
| 废弃 | 决策对应的需求或场景已不存在，无需替代方案 | 新建一条废弃记录或状态变更说明，标注失效原因与失效时间，原记录标注“已废弃” |
三种类型中，推翻的处理成本最高，也最容易出现记录缺失。判断时如果拿不准，可以问一句：这次变化是否让团队做出了一个原来没有的技术选择？答案是肯定的，就按推翻处理，新建记录。
补充新记录的操作步骤与字段
新记录是一条独立的决策记录，不是原记录的补丁。它需要能单独读懂：读者只看这一条，也能明白问题是什么、为什么改、改成了什么、影响哪些地方。
操作按六步走，每步都有明确的输入、动作和输出：
- 确认原决策编号。输入是原决策记录的编号与标题；动作是在决策索引或文档目录中定位原记录，核对编号与当前状态；输出是确认后的原决策编号；完成标志是编号准确、原记录状态仍为“已采纳”。
- 收集推翻依据。输入是触发变化的事实材料，如容量数据、故障复盘、业务需求变更、技术依赖公告；动作是整理成可引用的依据清单；输出是推翻原因的事实支撑；完成标志是每条原因都能指向具体材料，而非“感觉不合适”。
- 起草新记录。输入是原决策编号、推翻依据和候选方案；动作是按字段清单逐项填写；输出是新记录初稿；完成标志是必填字段无空缺。
- 评审。输入是新记录初稿；动作是由架构师或技术负责人评审新方案与影响范围，受影响团队确认下游影响；输出是评审意见与修订后的定稿；完成标志是评审结论明确、影响范围无遗漏。
- 发布。输入是定稿；动作是将新记录放入决策记录目录，状态设为“已采纳”，并登记到决策索引；输出是可访问的新记录；完成标志是链接可打开、索引已更新。
- 回写原记录状态。输入是新记录链接；动作是在原记录上追加状态标注与指向新记录的链接，正文不改写；输出是完成双向关联的两条记录；完成标志是原记录状态变为“已被替代”，链接可点击。
新记录的必填字段建议如下：
| 字段 | 填写要求 |
|---|---|
| 决策编号 | 按统一规则生成，能体现时间顺序，便于与原决策编号区分 |
| 标题 | 一句话说明决策对象与结论，如“订单服务由单体拆分为独立服务” |
| 状态 | 从“提议 / 已采纳 / 已替代 / 已废弃”中取值，发布时为“已采纳” |
| 日期 | 决策日期与生效日期分开写，二者可能不同 |
| 背景与问题 | 说明当前面临的问题和约束，交代为什么需要重新决策 |
| 原决策引用 | 写明原决策编号与标题，说明本记录替代它 |
| 推翻原因 | 逐条列出原方案不再适用的原因，附事实依据 |
| 新方案与备选 | 写明采纳的方案，以及评估过但未采纳的备选方案和放弃理由 |
| 影响范围 | 列出受影响的系统、模块、接口、团队和下游文档 |
| 决策人 | 写明最终拍板人和参与评审的角色 |
| 关联文档 | 链接到架构文档、接口文档、需求文档等相关材料 |
状态字段的取值建议保持四个：提议表示记录在讨论中，已采纳表示当前有效，已替代表示被更新记录取代，已废弃表示不再需要。原记录只改状态，不改正文，这样历史内容与当前结论各归其位。
新旧记录如何建立双向关联
双向关联的目标是：从新记录能找到原决策，从原记录也能找到新记录。只在新记录里提一句原决策编号，原记录毫无标记，追溯时从旧记录出发就会断链。
新记录一侧的写法是在“原决策引用”字段中写明编号、标题和替代关系，例如：“本记录替代 DR-2023-014《订单系统采用单体架构》，原方案因扩展性不足不再适用。”同时在正文背景部分简述原决策当时的判断依据，让读者理解变化从何而来。
原记录一侧的写法是在记录顶部或状态字段处追加标注，正文内容保持原样。示例：“状态：已被替代。替代记录：DR-2025-006《订单服务拆分为独立服务》。”标注只增加指向信息，不删除、不改写原有背景、方案和评审意见。
关联粒度以决策级为主，一条新记录对应一条原记录。如果一次变更同时影响多份架构文档或接口文档，在新记录的“关联文档”字段中补充这些文档的链接，原记录不必逐一挂接。编号规则建议采用“DR-年份-序号”的形式，新记录序号递增，保证按编号即可排出时间线；标题中保留决策对象关键词，便于检索。
如果团队使用文档协作工具承载决策记录，可以把状态标注放在页面显眼位置，把新记录链接写在原记录的状态行，利用页面版本记录保留每次修改的历史。ONES Wiki 支持记录所有页面版本并随时查看与回滚，页面树方式组织页面也能让新旧记录之间的层级关系一目了然，适合用来维护这类需要长期留存的决策链。
角色分工与各环节交付物
决策替换记录常见的失败情形是：新记录写完了，原记录没人改状态，索引没人更新，下游文档还停留在旧方案。把角色和交付物定清楚，可以避免记录写完无人认领。
| 角色 | 主要动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 决策提出人 / 方案负责人 | 起草新记录，整理推翻依据，提出候选方案 | 新记录初稿、推翻依据清单 | 评审前提交给架构师 |
| 架构师或技术负责人 | 评审新方案与影响范围，确认推翻理由成立 | 评审意见、影响范围确认结论 | 评审会上给出结论 |
| 文档维护人 | 更新原记录状态，维护双向链接与决策索引 | 完成关联的两条记录、更新后的索引 | 新记录发布后当日完成 |
| 受影响团队 | 确认本团队受影响范围，同步下游文档 | 影响确认回复、下游文档更新记录 | 评审后、发布前完成确认 |
交接的关键节点有两个：评审前，提出人要把初稿和依据交齐，避免评审会上现找材料；发布后，文档维护人要在一个工作日内完成原记录状态回写和索引更新，否则新记录处于“孤岛”状态。受影响团队的确认不能省略，影响范围字段的准确性依赖他们的反馈。
示例：一次架构演进后的决策替换记录
以下示例为演示情景，展示一对新旧记录的实际写法。
原记录（DR-2023-014）追加标注后的开头部分：
- 决策编号：DR-2023-014
- 标题：订单系统采用单体架构
- 状态：已被替代
- 替代记录：DR-2025-006《订单服务拆分为独立服务》
- 原决策日期：2023-03-10
- 背景与问题：订单量处于起步阶段，团队规模小，单体架构部署简单、迭代快……（以下正文保持原样，未作改写）
新记录（DR-2025-006）的字段填写：
- 决策编号：DR-2025-006
- 标题：订单服务拆分为独立服务
- 状态：已采纳
- 决策日期：2025-02-18；生效日期：2025-04-01
- 背景与问题：订单量增长后，单体应用在大促期间出现部署耦合和扩容瓶颈，订单模块的发布需要整站停机，无法满足业务对独立迭代的要求。
- 原决策引用：本记录替代 DR-2023-014《订单系统采用单体架构》。原决策在团队规模小、订单量低的阶段成立，当前约束已变化。
- 推翻原因：一是订单模块与商品、用户模块共用部署单元，单模块故障影响全站；二是扩容只能整站扩容，资源成本高；三是订单迭代频率显著高于其他模块，发布节奏被拖慢。
- 新方案与备选：采纳按领域拆分订单服务、独立部署与扩容的方案；评估过模块化单体方案，因无法解决独立发布问题未采纳。
- 影响范围：订单、支付、库存三个模块的接口调用方式；运维部署流程；监控告警配置；下游的接口文档与联调计划。
- 决策人：技术负责人张某；参与评审：架构组、订单团队、运维团队。
- 关联文档：订单服务接口文档、部署架构说明、大促容量评估报告。
追溯路径是这样的：从新记录 DR-2025-006 的“原决策引用”字段点开 DR-2023-014，看到原记录状态为“已被替代”，正文保留了 2023 年的背景与方案；从原记录的状态行点回 DR-2025-006，看到推翻原因与新方案。两条记录合起来，完整呈现了“当时为什么这么定、后来为什么改”。
完成检查：记录是否可追溯
发布前逐项核对以下清单，全部通过才算完成这次决策替换记录：
- 原记录正文未被覆盖，背景、方案、评审意见等历史内容完整保留。
- 原记录状态已改为“已被替代”，并带有指向新记录的链接。
- 新记录包含推翻原因、新方案与备选、生效时间、影响范围四项关键内容。
- 新记录的“原决策引用”字段写明原决策编号与标题，替代关系表述清楚。
- 双向链接均可点击打开，两处引用的编号一致，无错号、漏号。
- 决策索引或目录已同步新增记录，原记录在索引中的状态同步更新。
- 受影响的下游文档已标注变更或完成更新，接口文档与部署说明无遗漏。
以下三项属于阻断项，出现任一项即判定不合格：新记录没有写明推翻原因；新旧记录之间没有建立关联；原记录被直接改写或删除。前两项会让追溯断链，第三项会直接丢失决策历史。检查通过后，把这次替换记录纳入决策索引的常规维护，后续再发生变更时按同样流程处理，决策链就能持续保持连续。
常见问题
原决策只是部分参数需要调整，也要新建一条记录吗？
不需要。方案主体保留、只调整参数、边界或局部实现时，按修订处理更合适：在原记录上追加修订说明，注明修订日期、内容和原因，原有正文保留。判断的分界是这次变化有没有产生新的技术选择。如果团队重新选了一套方案、原方案整体不再适用，就按推翻处理，新建记录并建立双向关联。
原决策记录已经被同事直接改写了，还能补救吗？
先利用文档的版本记录找回改写前的内容，恢复原记录的背景、方案和评审意见，再按规范追加状态标注。如果所用工具支持查看页面历史版本并回滚，可以定位到改写前的版本比对差异。恢复后在新记录中照常写明推翻原因和替代关系，并在检查清单中把“原记录被直接改写”作为阻断项复核一次，避免同类问题再次发生。
一次变更同时影响多个模块和多份下游文档，关联要挂到哪一层？
关联以决策级为主，一条新记录对应一条原决策记录。受影响的架构文档、接口文档、部署说明统一写进新记录的“关联文档”字段，原记录不必逐一挂接。影响范围字段要列出受影响的系统、模块、接口和团队，并由受影响团队在发布前确认，避免下游文档停留在旧方案。
决策记录的状态字段怎么设置，原记录的状态由谁改？
状态取值建议保持四个：提议、已采纳、已替代、已废弃。新记录发布时设为“已采纳”，原记录改为“已被替代”。回写原记录状态通常由文档维护人负责，在新记录发布后一个工作日内完成，同时更新决策索引。如果承载决策记录的工具支持自定义状态或页面模板，可以按团队习惯固化这套取值。
决策记录分散在多个页面，怎么保证后来者能按时间线找到完整链条？
编号规则统一采用“DR-年份-序号”，新记录序号递增，按编号即可排出先后顺序；标题保留决策对象关键词，便于检索。页面组织上可以用页面树把同一决策链的新旧记录放在相邻层级，让替代关系一目了然。团队使用 ONES Wiki 时，页面树组织与页面版本记录可以帮助维护这类需要长期留存的决策链，具体配置以实际产品为准。
