技术债准入记录总在评审后补，通常源于评审议程里没有为准入决策留出记录动作：口头通过、会后凭记忆整理，季度盘点再集中补。改进方向是把记录从“评审后补文档”改为“评审中当场形成决策记录”，让债务项、准入理由、偿还时机与责任人随评审结论同步产出，事后只做核对与归档。本文围绕需求评审与架构评审场景，给出可落地的议程、字段、角色安排，以及适用条件与验证方法。
要点总览（TL;DR）
- 事后补录的根源是评审议程里没有为准入记录留出位置：口头通过、会后凭记忆整理、季度盘点集中补，导致准入理由、偿还时机和责任人失真。
- 改进的核心动作是在需求评审与架构评审中固定一个带时间盒的技术债准入环节，用统一的最小字段当场登记债务描述、准入理由、影响范围、偿还时机、责任人和决策结论。
- 记录由评审主持或指定记录人当场完成，评审结论与记录同步产出并直接交接跟踪，事后只核对归档，不再二次整理。
- 这套做法需要稳定议程、主持人、团队认可和字段统一作为前提，代价是单次评审时间略增与前期培训投入；临时性、非决策类讨论不必强制走准入记录。
- 效果验证看三项指标：事后补录条数占比、补录距评审的时间间隔、字段完整率，先小范围试点再推广，指标数字需有实际记录支撑。
当前做法与目标：事后补录是怎么形成的
事后补录并非某一次疏忽，而是一条相对固定的链路。常见触发方式有三种：评审会上口头同意“先这样实现，后面再还”，散会后没有留下文字；会后由参会者凭记忆整理，隔一两天补进文档或表格；到了季度技术债盘点，再集中把此前遗漏的准入项一次性补录。三种方式叠加，记录就与决策现场脱节。
信息损耗集中在三类内容上。准入理由最容易失真，当时是为了赶交付节点、规避接口改造风险，还是因为第三方依赖限制，会后往往只剩一句“临时方案”。偿还时机同样容易走样，会上说的是“下个迭代评估”，补录时可能写成“待定”。责任人则常被写成团队名或干脆空缺，后续跟踪时无人认领。这三项恰恰是技术债准入记录最有价值的部分。
本文的改进目标可以写成一句可检验的话：技术债准入记录在评审现场形成，评审结束时字段基本齐全，事后只做核对与归档，不再重写。对应的衡量方式也很直接——事后补录的条数占比下降，补录距评审的时间间隔缩短，记录字段完整率上升。目标不追求记录篇幅，而追求决策信息在记忆还新鲜时被固定下来。
瓶颈与误区：为什么记录总被推到评审之后
记录被推到评审之后，首先卡在议程缺位。需求评审和架构评审的议程通常排满了方案讲解、范围确认和排期讨论，没有为准入记录预留时间，也没有明确由谁在什么时刻填写。评审主持人的注意力在推动结论上，记录动作自然被挤到会后。
其次是字段缺失。团队没有约定最小记录字段，现场即使想记，也不知道该记哪几项，于是倾向于“先过会，回头再整理”。字段不统一还导致补录时各人写法不同，后续无法汇总和跟踪。
与之相伴的两个误区值得单独指出。第一个误区是把补录归因为执行力问题，认为只要强调纪律、加强检查就能解决，却忽视评审流程本身没有承载记录动作——流程里没有位置，纪律只能制造会后加班。第二个误区是追求记录完整度而把评审拖长，要求现场写长篇说明、逐项论证，结果评审时间失控，团队反而更愿意会后补，形成“越要求完整、越推迟记录”的循环。
区分真瓶颈与误区之后，改进的着力点就清楚了：补的是议程位置、最小字段和记录角色，而不是加码问责。记录动作要轻到能在评审节奏内完成，才可能稳定发生。
优先改进动作：把准入记录嵌入评审议程
核心动作是在需求评审与架构评审的议程中固定一个技术债准入环节，并给它一个时间盒。做法可以是在议程末尾设置十到十五分钟的准入确认段：主持人逐项确认本次评审中出现的临时方案、妥协设计和延后改造，逐条判定是否作为技术债准入，并当场记录。时间盒的作用是让记录有边界，避免滑向逐项深挖。
配套的是统一的最小记录字段。字段宜少而稳定，保证现场能填完、事后能跟踪。可参考下表：
| 字段 | 填写要求 | 常见错误 |
|---|---|---|
| 债务描述 | 一句话说明妥协了什么，涉及哪个模块或接口 | 写成笼统的“代码待优化” |
| 准入理由 | 说明为何本次接受该债务，如交付节点、依赖限制、风险规避 | 只写“临时方案” |
| 影响范围 | 受影响的系统、团队或后续需求 | 留空或写“暂无” |
| 偿还时机 | 给出可判断的时间点或触发条件，如某迭代、某版本上线前 | 写“以后再说” |
| 责任人 | 具体到个人，而非团队名 | 写团队或项目经理 |
| 决策结论 | 准入、拒绝或需补充论证 | 只记录准入项，遗漏被拒项 |
角色安排上，由评审主持或主持人指定的记录人当场填写，评审结束即视为记录完成。主持人负责在准入环节逐条点名确认，记录人负责按字段录入，二者分离可以避免主持人一边推动结论一边分心记录。评审结论与记录同步产出，会议结束时就地交接给后续跟踪人，不再安排二次整理。
记录需要有承载物，才能被检索、分配和跟踪。可以用工作项承载每一条准入债务，把上述字段作为工作项属性，状态从“已准入”流转到“偿还中”“已关闭”；评审纪要文档则保留当次评审的整体结论与准入清单。这样，准入记录与后续偿还动作在同一条链路上，季度盘点时直接查看状态，不必回头翻会议记忆。在需要把评审纪要与债务项关联起来的团队里，ONES 的工作项与文档可以承担这一承载和状态跟踪的角色，让准入记录从会议现场直接进入跟踪流程。
适用前提与代价
这套做法成立有几个前提。评审需要有稳定的议程和明确的主持人，否则准入环节无法固定下来；团队需要认可技术债准入属于评审的决策范围，而不是事后由个人判断的私事；最小字段需要在推行前统一，并对主持人和记录人做一次简短说明。缺少其中任何一项，记录动作都容易退回会后。
代价也要提前说清。单次评审时间会略有增加，准入环节的时间盒本身就是成本；前期统一字段、培训记录人需要投入；记录人角色会增加一个人的会议负担，需要在团队内轮换或明确分工。这些成本换来的是决策信息在当场被固定，后续跟踪有据可依。
并非所有讨论都适用。临时性、非决策类的技术讨论，例如方案可行性探讨、故障复盘中的技术分析，不必强制走准入记录，否则会把轻量讨论流程化。边界上还需注意：已确认的功能 Bug 走缺陷流程，不混入技术债准入记录，两类事项的跟踪口径和责任人都不同，混记会让技术债清单失去决策含义。
效果验证：如何判断补录真的减少了
验证要围绕“补录是否真的减少”设计指标，而不是只看记录数量变多。可观察的指标有三类：事后补录条数占全部准入记录的比例；补录时间距对应评审的时间间隔；记录字段完整率，即六个最小字段中填写齐全的比例。三项指标结合看，能区分“记录变多”与“补录变少”。
对照方法上，选取改进前后同一类评审做比较，例如连续若干次需求评审的补录比例，保持评审类型、参与团队和记录口径一致，避免把不同会议的差异当成改进效果。验证节奏建议先在一个评审小组试点，观察评审时长与记录质量的变化，再决定是否推广。评审时长明显上升而字段完整率没有改善，说明时间盒或字段设计需要调整。
需要提醒的是，指标数字要有实际记录支撑。若团队尚无历史数据，可以先按演示假设说明口径，例如“以试点前四次评审的补录条数为基线”，在试点后按同一口径统计对比，而不是直接给出结论性百分比。相关性也不等于因果：补录比例下降同时伴随评审议程调整，才能较有把握地归因于记录内嵌；若同期还更换了记录工具或人员，需要在结论中说明这些混杂因素。
常见问题
评审节奏很紧，准入环节的时间盒应该设多长，超时怎么办？
时间盒的用途是给记录划边界，具体长度按评审规模和临时方案数量调整，常见做法是放在议程末尾、控制在十到十五分钟。超时通常说明现场在逐项深挖方案，此时主持人应把争议项标为“需补充论证”，记录结论后转入后续专项讨论，避免准入环节挤占整场评审。若多次超时，可以检查最小字段是否过多，或把准入确认拆到单独的短会。
团队还没有历史补录数据，效果验证怎么起步？
可以先确定统计口径，再开始试点。例如明确“补录”指评审结束后才录入的准入记录，统计范围限定为同一类评审，以试点前若干次评审的补录条数作为基线，试点后按同一口径对比。字段完整率按六个最小字段的填写齐全比例计算。这样即使没有长期数据，也能得到可比较的前后对照，结论中注明样本范围和混杂因素即可。
准入记录和缺陷记录会不会混在一起，边界怎么划？
两者跟踪口径不同。已确认的功能 Bug 走缺陷流程，按缺陷的严重程度、修复排期和验证闭环管理；技术债准入记录针对的是评审中接受的妥协设计、延后改造等决策，关注准入理由与偿还时机。评审现场遇到功能 Bug 应转入缺陷流程，不写入技术债准入清单，否则技术债清单会失去决策含义，偿还跟踪也难以推进。
记录人由谁担任比较合适，需要长期固定吗？
常见做法是由评审主持人指定一名记录人，与主持人角色分离，避免主持人一边推动结论一边分心录入。是否长期固定取决于团队规模：评审频繁的团队可以轮换，让更多人熟悉字段口径；评审较少的团队固定一人更利于记录一致性。无论哪种方式，都应在推行前对记录人做一次字段说明，减少各人写法差异。
哪些评审必须走准入记录，哪些可以豁免？
判断标准是这次讨论是否产生了需要后续偿还的决策。需求评审和架构评审中出现的临时方案、妥协设计、延后改造，属于应记录的准入事项；方案可行性探讨、故障复盘中的技术分析等非决策类讨论，不必强制走准入记录。豁免情形宜在团队内提前约定，避免现场临时判断造成遗漏或争议。
