架构演进后，旧的技术决策不再适用，但团队仍需要回答“当时为什么这样定、后来为什么改”。处理这类更新的稳妥做法是保留原记录正文与日期不动，新增一条取代记录，写明被取代的决策编号、废弃原因、生效时间和替代方案，再把原记录状态改为“已废弃（被XXX取代）”，两条记录双向链接。本文按操作步骤、字段设计、角色分工、完整示例和完成检查展开，适用于已有决策记录、需要维护可追溯历史的团队。
要点总览（TL;DR）
- 废弃技术决策时保留原记录正文与日期不动，新增一条取代记录，写明被取代的决策编号、废弃原因、生效时间和替代方案，再把原记录状态改为“已废弃（被XXX取代）”，两条记录双向链接。
- 决策记录模板至少固定编号、标题、状态、取代关系、废弃原因、生效时间、决策日期和决策人；状态统一为提议、已采纳、已废弃、被取代四类，取代关系同时保留正向与反向值。
- 决策提出者起草取代记录，架构或技术负责人审批废弃，文档维护人更新状态与链接，评审环节沿取代关系检查历史链路是否完整。
- 完成标准是原记录未被改写、新记录含被取代对象与原因、双向链接可跳转、状态与实际一致、按时间线能还原变化；直接覆盖原记录、缺少关联、状态未更新属于阻断项。
- 决策记录放在协作平台中维护时，可借助文档版本记录与权限控制承载状态更新和历史保护，ONES Wiki 的版本查看与回滚、页面组关联项目等能力可作为承载手段，具体配置需结合团队实际使用方式确认。
核心做法：新增取代记录，原记录只改状态
废弃一条技术决策，本质是追加一段历史，而不是修改旧历史。原记录继续保留当时的背景、选项和结论，新记录说明它为何失效、由什么接替。这样，后来者按时间顺序阅读，就能看到决策从生效到废弃的完整过程。下面五步可以按顺序执行，每一步都给出输入、动作、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确认废弃触发条件 | 架构变化说明、原决策记录、相关需求或故障记录 | 由决策提出者或架构负责人判断原决策是否确实不再适用，明确废弃原因类别（技术约束变化、业务目标调整、成本或合规要求变化等） | 一段简短的废弃理由草稿 | 废弃原因能对应到具体变化事实，而非笼统的“不合适了” |
| 2. 新建取代记录 | 原决策编号、废弃理由、替代方案要点、生效时间 | 在决策记录目录中新建一条记录，标题体现新决策内容，正文写明“取代 DEC-XXX”，并说明新方案、适用范围和迁移安排 | 一条状态为“已采纳”或“提议”的新记录 | 新记录中能直接看到被取代对象和替代方案 |
| 3. 建立双向链接 | 原记录与新记录的页面地址或编号 | 在新记录中链接原记录，在原记录顶部或关联区添加指向新记录的链接，注明“已被 DEC-YYY 取代” | 两条记录互相可跳转 | 从任一条记录出发，一次点击即可到达另一条 |
| 4. 更新原记录状态字段 | 原记录、新记录编号、生效时间 | 只修改原记录的状态字段为“已废弃（被 DEC-YYY 取代）”，正文、决策日期、决策人保持不变 | 状态与实际一致的原记录 | 状态字段含被取代对象，正文无改写痕迹 |
| 5. 通知与归档 | 变更后的两条记录 | 在团队例会或文档评审中同步变更，通知依赖该决策的项目成员；必要时在相关需求或架构文档中更新引用 | 相关方知悉、引用位置已更新 | 依赖方确认收到，旧引用不再指向失效结论 |
这套步骤的关键约束是：原记录的正文、决策日期和决策人不做任何修改，状态字段是唯一允许变更的部分。如果原记录本身写错了，应另开一条勘误说明，而不是直接改写历史。新记录承担“当前有效结论”的角色，原记录承担“历史证据”的角色，两者分工明确，追溯时不会混淆。
决策记录需要哪些字段来承载废弃与追溯
字段设计决定了废弃与追溯能否顺畅执行。建议在决策记录模板中固定以下字段，其中编号、标题、状态、决策日期、决策人和取代关系为必填，其余按团队需要选填。状态取值统一为“提议、已采纳、已废弃、被取代”四类，避免各人自造说法。
| 字段 | 填写内容 | 必填/选填 | 在废弃场景中的作用 |
|---|---|---|---|
| 决策编号 | 如 DEC-012，全局唯一、按序递增 | 必填 | 作为被引用和被取代的稳定标识 |
| 标题 | 一句话概括决策内容 | 必填 | 便于在列表中识别新旧关系 |
| 状态 | 提议 / 已采纳 / 已废弃 / 被取代 | 必填 | 废弃时改为“已废弃（被 DEC-XXX 取代）” |
| 取代关系 | 取代谁、被谁取代，填决策编号 | 必填 | 构成追溯链路的核心字段 |
| 废弃原因 | 触发废弃的具体变化及判断依据 | 废弃时必填 | 解释“为什么改”，避免后人重复踩坑 |
| 生效时间 | 新决策开始执行的日期 | 废弃时必填 | 界定新旧方案的适用时间边界 |
| 决策日期 | 原决策作出日期，废弃时保持不变 | 必填 | 时间线的锚点，不可改写 |
| 决策人 | 作出决策的角色或姓名 | 必填 | 追溯责任与后续咨询对象 |
| 影响范围 | 涉及的系统、模块、团队或项目 | 选填 | 判断哪些依赖方需要同步通知 |
| 关联需求或架构文档 | 需求编号、架构文档链接 | 选填 | 把决策放回业务与技术上下文 |
字段落地时有两个细节值得注意。其一，“取代关系”建议同时保留正向和反向两个值，新记录写“取代 DEC-012”，原记录写“被 DEC-015 取代”，这样无论从哪条记录进入都能找到对方。其二，状态字段与取代关系字段要保持一致：状态为“已废弃”时，取代关系不能为空；状态为“已采纳”时，不应填写被取代对象。团队可以把这两条写成模板填写说明，减少遗漏。
角色分工与各环节交付物
废弃更新涉及判断、撰写、审批和维护四类动作，分散到不同角色可以互相校验。规模较小的团队可以由一人兼任多个角色，但审批与撰写最好分开，避免自己废弃自己刚写的决策而缺少复核。
| 角色 | 主要动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 决策提出者 / 记录撰写人 | 识别废弃触发条件，起草新记录，写明废弃原因与替代方案 | 取代记录草稿、废弃理由说明 | 草稿完成后提交审批 |
| 架构或技术负责人 | 审批废弃是否成立，确认替代方案的适用范围与生效时间 | 审批意见、生效时间确认 | 审批通过后交由文档维护人更新 |
| 文档维护人 | 更新原记录状态字段，补齐双向链接，检查编号与字段完整性 | 状态已更新、链接可跳转的两条记录 | 更新完成后进入评审 |
| 评审参与者（架构评审或文档评审） | 沿链路检查历史是否完整，确认依赖方已收到通知 | 评审记录、遗留问题清单 | 评审通过后关闭本次废弃事项 |
交接时点要写清楚，否则容易出现“新记录建了、原记录状态没改”的半完成状态。一个实用的做法是把“原记录状态已更新且双向链接可跳转”作为评审的前置条件，未满足则不进入评审。评审参与者的检查重点是链路而非文字润色：从最新记录能否一路回溯到最初决策，中间每次废弃是否都有原因和替代方案。
当决策记录放在协作平台中维护时，这些角色动作可以借助文档的版本记录与权限控制来承载。例如 ONES Wiki 记录所有页面版本并支持查看与回滚，原记录被误改时可以恢复；页面组可关联项目，使决策文档与需求、任务互相对应；读写权限可按角色配置，让文档维护人负责状态更新、其他成员以只读方式查阅历史。具体配置需结合团队实际使用方式确认。
示例：一次架构演进中的决策废弃与接续
以下为演示情景，用于说明写法，不代表真实项目数据。某团队早期决定采用单体应用加共享数据库支撑订单服务，记录为 DEC-012，状态“已采纳”，决策日期为两年前，决策人为当时的架构负责人。
原决策摘要（保持不动）：订单、库存、结算模块部署在同一应用内，共用一套数据库，理由是团队规模小、发布频率低、跨模块事务简单。正文中的背景、备选方案对比和结论均不修改。
触发废弃的架构变化：业务扩展到多区域后，结算模块需要独立扩容，共享数据库导致发布互相阻塞，跨模块事务也不再是主要诉求。架构负责人评估后认为原决策的前提已不成立。
新记录写法（DEC-015）：标题为“结算模块独立部署并拆分数据库”，正文开头写“本决策取代 DEC-012”，接着分三段说明：废弃原因（多区域扩容与发布解耦需求）、替代方案（结算模块独立服务、独立库、通过接口同步订单状态）、生效时间与迁移安排（分阶段迁移，旧共享库在迁移完成后下线）。状态填“已采纳”。
双向链接与状态变更：DEC-015 的“取代关系”填“取代 DEC-012”；DEC-012 的状态字段改为“已废弃（被 DEC-015 取代）”，并在记录顶部加一行链接指向 DEC-015。DEC-012 的正文、决策日期、决策人均未改动。
追溯过程：半年后新成员询问结算模块为何独立部署，从 DEC-015 出发点击链接到达 DEC-012，读到最初的单体方案及其适用前提，再回到 DEC-015 看到废弃原因和迁移安排，整条变化链路在两次跳转内还原。若后续 DEC-015 也被取代，同样新增一条记录并更新 DEC-015 的状态，链路继续延长而不覆盖任何一环。
完成检查：历史未被覆盖且链路可追溯
更新完成后，按下表逐项核对。全部通过才算本次废弃更新合格；任一阻断项未通过，应退回修改后再进入评审。
| 检查项 | 核对方法 | 判定 |
|---|---|---|
| 原记录正文与决策日期未被改写 | 对照版本记录或更新前快照，确认正文、日期、决策人一致 | 阻断项 |
| 新记录含被取代对象与废弃原因 | 在新记录中能找到被取代决策编号和具体废弃理由 | 阻断项 |
| 双向链接可跳转 | 从原记录到新记录、从新记录到原记录各点击一次 | 阻断项 |
| 状态字段与实际一致 | 原记录状态为“已废弃（被XXX取代）”，新记录状态为“已采纳”或“提议” | 阻断项 |
| 按时间线能还原决策变化 | 从最新记录出发，沿取代关系回溯到最初决策，每步都有原因与生效时间 | 通过项 |
| 依赖方已收到通知 | 核对影响范围内的项目成员确认记录 | 通过项 |
需要特别防范的三种情况：直接覆盖原记录正文，导致历史结论消失；只建新记录却不填取代关系，链路断开；状态字段未更新，读者仍以为旧决策有效。这三种情况都会让追溯失效，应作为评审的退回理由。把这份清单固定在决策记录模板的末尾，每次废弃更新时逐项勾选，团队就能在架构持续演进的过程中保持一份可信、可回溯的决策历史。
常见问题
原决策记录本身写错了，还能按“只改状态”的方式处理吗？
可以分开处理。原记录正文、决策日期和决策人保持不动，另开一条勘误说明，写清哪段表述有误、正确内容是什么、依据是什么，并链接回原记录。勘误说明与取代记录是两种不同性质的追加：前者修正记录质量，后者反映决策结论变化。若错误影响到决策结论本身，则按取代流程新增记录，并在新记录中同时说明废弃原因和勘误内容。
一条决策被多次取代时，链路怎么维护才不会断？
每次取代只新增一条记录并更新被取代那条记录的状态，形成 DEC-012 → DEC-015 → DEC-021 这样的单向链条。中间每条记录的状态都改为“已废弃（被后一条取代）”，取代关系字段同时保留“取代谁”和“被谁取代”。评审时从最新记录出发逐级回溯，确认每一环都有废弃原因和生效时间。链路变长后，可在最新记录顶部加一行“决策沿革”列出完整编号序列，方便快速定位。
废弃审批由谁拍板，和日常文档修改权限是什么关系？
废弃审批属于技术判断，通常由架构或技术负责人确认原决策的前提是否确实不成立；文档修改权限属于操作权限，由文档维护人执行状态更新和链接补齐。两者分开可以避免撰写人自行废弃自己刚写的决策而缺少复核。在协作平台中，可按角色配置读写权限，让维护人拥有编辑权、其他成员以只读方式查阅历史，具体配置需结合团队实际使用方式确认。
旧决策被取代后，引用过它的需求文档和架构文档要一起改吗？
需要检查引用位置，但处理方式取决于引用性质。如果文档引用的是“当前有效方案”，应更新为指向新决策；如果引用的是历史背景或当时的设计依据，保留原引用并补充说明“该决策已于某日被 DEC-YYY 取代”更合适。建议在取代记录的“影响范围”字段列出涉及的系统、模块和文档，通知依赖方逐项确认，避免旧引用继续指向失效结论。
团队规模小、决策记录不多，也需要这么完整的字段和角色吗？
可以精简，但三条底线建议保留：原记录正文不改写、新记录写明被取代对象与废弃原因、两条记录互相可跳转。字段上至少保留决策编号、状态、取代关系和决策日期；角色上撰写与审批可由不同人兼任，但不宜由同一人在无复核的情况下完成。决策记录数量少时，维护成本主要来自链路检查，把检查清单固定在模板末尾，每次废弃时逐项勾选即可。
