架构选型和临时技术例外都不需要对所有情况单独写技术决策记录。更可行的做法是按影响范围、存续时间、可回退性和后续被引用频率分档：架构选型中形成长期约束、跨团队协作的部分通常值得单独成文；临时技术例外则要看它偏离了什么规范、会持续多久、到期后由谁回收。影响小、可快速回退的日常取舍，在评审纪要中留痕即可。
要点总览（TL;DR）
- 架构选型与临时技术例外都不需要一刀切地单独成文，判断依据是影响范围、存续时间、可回退性和后续被引用频率。
- 跨团队、形成长期约束的架构选型，以及偏离规范、持续超过一个迭代、需要到期回收的临时例外，值得单独写技术决策记录。
- 影响限于单个模块、可快速回退的日常取舍，在评审纪要中写明原因、到期时间和责任人即可。
- 建立机制前先约定模板、存放位置和谁写谁审谁归档，单条记录控制在半页到一页，避免写成完整方案文档。
- 先在一个项目或一个发布周期内试点，用记录耗时、被引用次数和例外回收情况决定推广还是收缩。
先给结论：哪些决策值得单独成文
技术决策记录的价值在于把“为什么这样定”从会议现场剥离出来，变成可检索、可追溯的独立条目。是否单独成文，取决于这个决策未来会不会被反复问起、会不会约束其他人的工作、会不会在某个时间点需要复核或撤销。
架构选型通常值得单独记录。它往往涉及多个系统或团队的边界划分、技术栈约束和长期维护成本，一旦定下来，后续需求设计、接口约定、部署方案都会引用它。把选型背景、备选方案和被否原因写清楚，能减少后来者重复论证，也能在出现问题时快速定位当时的约束条件。
临时技术例外需要分档处理。偏离既有规范、但影响范围限于单个模块、预计几周内回收的例外，可以在评审纪要中写明原因、到期时间和责任人；如果例外涉及多个团队、持续时间超过一个迭代周期，或者会改变对外接口、数据口径、安全边界，就值得单独成文，并在记录中标注回收条件。
只在评审纪要中留痕适用于影响范围小、可快速回退、无需跨团队追溯的日常取舍。例如某个内部工具的参数调整、一次性的脚本处理方式、局部代码结构的临时改动。这类决策的受众主要是当次评审参与者，事后被引用的概率低，单独成文反而增加维护成本。
判断时可以用四个条件对照：影响范围是否跨团队或跨系统；存续时间是否超过一个迭代或一个发布周期；回退是否需要协调多方；后续是否会被反复引用或引发争议。四个条件中命中两个以上，单独成文的收益通常大于成本。
| 决策类型 | 典型特征 | 建议记录方式 |
|---|---|---|
| 架构选型（跨系统、长期约束） | 影响多个团队，形成技术栈或接口约定，后续频繁被引用 | 单独写技术决策记录 |
| 架构选型（局部、可替换） | 限于单个服务或模块，替换成本低，无对外约束 | 评审纪要留痕，必要时补记 |
| 临时技术例外（跨团队、长周期） | 偏离规范且影响面广，持续超过一个迭代，需到期回收 | 单独写技术决策记录，注明到期与回收责任人 |
| 临时技术例外（局部、短周期） | 影响单个模块，可快速回退，几周内恢复 | 评审纪要留痕，写明原因与到期时间 |
| 日常技术取舍 | 影响小、可逆、已有规范覆盖 | 评审纪要或任务评论留痕 |
技术决策记录解决的是什么问题
评审纪要按会议组织，记录的是“这次会上讨论了什么”；技术决策记录按决策组织，记录的是“这个决定为什么成立、约束了谁、什么时候需要重新看”。两者的组织维度不同，导致检索和追溯的效率差异明显。
当新成员加入或跨团队协作时，常见的问题是“这个接口为什么这样设计”“为什么这里没有采用统一规范”。如果答案散落在某次评审纪要里，需要先知道是哪次会议、哪份文档，才能找到上下文。决策记录以决策为标题和索引，背景、备选方案、被否原因和最终结论放在同一页面，检索路径更短。
人员变动会放大这个问题。架构选型的约束条件往往由当时的评审参与者口头传递，人员离开后，约束变成“一直就是这样”。单独成文可以把约束条件、适用边界和例外情况固定下来，减少因人员更替导致的重复讨论或误改。
临时技术例外还需要一个独立的回收载体。例外本身带有时间属性，到期后需要复核是否延续、是否整改、是否转为正式方案。如果只写在会议纪要里，到期提醒和回收责任容易丢失；单独记录可以明确到期时间、回收责任人和复核结论，让例外有始有终。
需要说明的是，决策记录不替代评审纪要。评审纪要保留讨论过程和参与意见，决策记录提炼结论与约束，两者配合使用。团队规模较小、决策频率低时，可以先在纪要中增加“决策结论”字段作为过渡，再逐步把高价值决策拆成独立记录。
适用条件：什么情况下值得单独写
以下条件可以逐条对照，命中越多，单独成文的必要性越高。这些条件描述的是决策的外部影响和追溯需求，与团队规模没有直接关系。
- 影响多个团队或系统。决策会改变接口约定、数据口径、部署方式或安全边界，其他团队需要据此调整工作。
- 形成长期约束的技术方案取舍。选定的框架、中间件、存储方案或集成方式预计会沿用多个版本周期，替换成本较高。
- 偏离既有规范的临时技术例外。例外有明确的规范对照对象，需要说明偏离理由、影响范围和补偿措施。
- 需要后续评审、延期或回收的决策。决策带有时间条件，到期后必须有人复核，不能自然沉没在文档里。
- 被反复引用或争议较大的决策。同一问题在不同场合被多次提起，或者评审中存在明显分歧，需要把结论和理由固定下来。
这些条件可以组合使用。例如一个临时例外同时影响两个团队、持续两个迭代、到期需要回收，就同时命中前三项和第四项，适合单独成文。反过来，一个局部参数调整只命中“有规范对照”一项，放在评审纪要中说明即可。
投入与前提：建立记录机制要准备什么
单独记录的成本主要来自三部分：写一条记录的时间、维护模板和存放位置的一致性、以及评审与归档的衔接。控制成本的关键是限定必要字段和篇幅，避免把决策记录写成完整方案文档。
单条记录建议控制在必要字段以内：决策标题、背景与问题、备选方案、最终结论、影响范围、回退或回收条件、责任人与日期。架构选型可以适当展开备选方案对比；临时例外重点写清偏离对象、到期时间和回收责任人。篇幅以半页到一页为宜，复杂方案可以附链接指向详细设计文档。
前置约定包括模板和存放位置。模板统一字段，减少每次从零组织内容；存放位置按项目或系统分组，便于按主题检索。团队需要约定命名规则，例如“决策主题+日期”或“系统名+决策类型”，让标题本身具备检索价值。
角色安排上，建议明确谁写、谁审、何时归档。通常由决策提出人或方案负责人起草，评审参与者确认结论，技术负责人或架构评审角色审核影响范围与回退条件。归档时间可以定在评审通过后一个工作日内，避免记录滞后导致上下文丢失。
与评审流程的衔接方式有两种：一是在评审议程中固定“是否需要单独记录”的判断环节，二是评审结论产出时同步指定记录责任人和归档时间。前者适合决策频率较高的团队，后者适合评审节奏稳定的团队。两种方式都要求评审主持人在会前明确本次评审的决策清单。
控制负担的简化做法包括：只对命中触发条件的决策单独成文；使用统一模板减少组织成本；把记录放在团队日常协作的文档空间中，与项目、任务关联，避免另建一套系统；定期清理已失效或已回收的记录，保持索引有效。以 ONES Wiki 为例，团队可以用模板库创建决策记录页面，通过页面组关联项目，让需求文档与决策记录互相对应；文档支持版本记录与回滚，便于追溯结论变化；权限配置可以区分读写角色，全局搜索能触达附件内容，降低查找成本。具体模板内容和权限粒度以所购版本为准。
暂缓条件：哪些情况先不单独成文
以下情形可以先在评审纪要或任务评论中留痕，暂不单独成文。暂缓不等于放弃记录，而是把记录成本留给影响更大的决策。
- 影响范围小且可快速回退的取舍。改动限于单个模块或单次任务，回退不需要跨团队协调，事后被引用的概率低。
- 尚未定型、仍在探索的方案。方案还在验证阶段，结论可能反复变化，过早成文会产生大量修订记录。可以先用任务评论或实验记录跟踪，结论稳定后再补记。
- 重复性高、已有规范覆盖的决策。团队已有明确规范或标准模板，本次决策只是按规范执行，不需要重复论证。
- 团队尚未形成评审习惯时的过渡做法。评审流程本身还不稳定，先固定评审节奏和结论输出，再逐步引入独立记录，避免机制叠加造成负担。
暂缓后需要补记的触发信号包括：同一问题第二次被提出；决策影响范围扩大到其他团队；例外到期需要延期；方案从探索转为正式采用；新成员需要依据该决策开展工作。出现这些信号时，把原有留痕内容整理成独立记录，比重新组织讨论更省力。
试点判断：小范围验证记录负担与收益
在全面推广前，可以选一个项目或一个系统范围试点，用实际数据判断记录机制是否值得扩展。试点范围建议覆盖一个完整的决策周期，例如一个迭代或一个发布周期，确保能观察到架构选型和临时例外两类场景。
试点期间可以观察三类指标：单条记录从起草到归档的耗时；记录在后续评审、需求设计或问题排查中被引用的次数；临时例外的到期回收情况，包括是否按时复核、是否延期、是否转为正式方案。这些指标不需要精确统计，按周记录大致情况即可。
试点后的取舍判断可以分三种情况。记录耗时稳定在可接受范围、引用次数明显、例外回收有明确结论，说明机制有效，可以推广到更多项目；记录耗时偏高但引用次数少，说明模板或触发条件需要收紧，先简化字段再观察；例外回收仍然依赖口头提醒，说明记录中的到期与责任人字段没有发挥作用，需要调整评审衔接方式。
推广或收缩的决策依据应来自试点数据，而不是一次性全员推行。推广时可以按决策类型分批扩展，先覆盖跨团队架构选型和长周期例外，再逐步纳入局部取舍。收缩时保留已建立的模板和存放约定，把单独成文的范围收回到高价值决策，避免机制反复重建。
常见问题
临时技术例外在评审纪要里写清楚原因和到期时间，还需要单独成文吗？
看例外的影响面和持续时间。如果例外只影响单个模块、几周内可以恢复，评审纪要中写明偏离对象、原因、到期时间和责任人通常够用。如果例外涉及多个团队、会改变对外接口或数据口径、持续时间超过一个迭代，或者到期后需要正式复核是否延续，就值得单独成文，并在记录中标注回收条件和复核责任人。判断标准与架构选型一致，区别在于临时例外多了一个到期回收的动作，需要有人负责触发。
团队还没有稳定的评审流程，直接上技术决策记录会不会负担太重？
评审流程本身不稳定时，先固定评审节奏和结论输出更实际。可以在评审纪要中增加“决策结论”和“是否需要单独记录”两个字段作为过渡，等评审习惯形成后，再把命中触发条件的决策拆成独立记录。这样做的原因是，决策记录依赖评审产出结论；评审结论本身不清晰时，单独成文只会把模糊内容固定下来，后续修订成本更高。
技术决策记录和评审纪要可以合并成一份文档吗？
两者组织维度不同，合并后容易两头不讨好。评审纪要按会议组织，保留讨论过程和参与意见；决策记录按决策组织，提炼背景、备选方案、结论和约束条件。团队规模小、决策频率低时，可以先在一份文档里分节承载，但建议给决策结论单独设置可检索的标题或标签，方便后续按决策主题查找。等决策数量增加，再拆成独立页面。
试点多久、看哪些指标，才能判断记录机制是否值得推广？
试点范围建议覆盖一个完整的决策周期，例如一个迭代或一个发布周期，确保能同时观察到架构选型和临时例外两类场景。观察三类情况：单条记录从起草到归档的耗时；记录在后续评审、需求设计或问题排查中被引用的次数；临时例外是否按时复核、是否延期、是否转为正式方案。耗时可控、引用有实际发生、例外回收有明确结论，可以推广；耗时偏高而引用很少，先收紧模板字段和触发条件再观察。
决策记录建在文档工具里，和放在项目管理工具里有什么区别？
关键看团队日常在哪里工作、决策需要和什么对象关联。决策记录需要长期沉淀、按主题检索、保留版本变化，文档空间更适合承载；同时它又需要和项目、需求、任务对应，方便执行时回查。以 ONES Wiki 为例，页面组可以关联项目，让需求文档与决策记录互相对应，文档支持版本记录与回滚，权限配置可以区分读写角色，全局搜索能触达附件内容。具体模板内容和权限粒度以所购版本为准。选型时优先考虑团队已有的协作入口，减少另建一套系统带来的维护成本。
