技术债准入记录要真正进入需求评审，关键是让它成为评审材料的一部分和评审结论的必填项：评审前由需求负责人与技术负责人共同填写，评审会上按固定议程讨论并当场写入结论，评审后随需求进入开发与债务台账。这样记录在决策现场产生，事后补录和形式化填写会明显减少。下文给出可执行的流程、字段表、角色分工、示例和检查清单；在需求与工作项流转环节，可借助ONES承接记录与后续跟踪。
要点总览（TL;DR）
- 把技术债准入记录嵌入需求评审，核心是让记录在评审前随材料提交、评审中作为固定议程项当场定稿、评审后随需求进入开发与债务台账，三个时点各有负责人和完成标志。
- 记录字段控制在支撑判断的最小集合：债务描述与来源、影响范围、风险等级、偿还时机与触发条件、责任人、验收方式、评审结论；暂缓项必须同时写明触发条件和责任人。
- 评审会上按风险等级分配讨论深度，高风险逐项讨论，低风险批量确认；结论当场写入，记录缺失或结论空白时评审不视为完成。
- 减少事后补录靠绑定机制而非自觉：记录是评审材料的组成部分和结论的必填项，评审后再整理的需求自然减少。
- 用记录产生时间、结论完整性、暂缓项条件、台账可追溯、偿还闭环等检查项定期抽查，把结果反馈到流程调整中。
核心做法：把准入记录变成评审的必填输入
准入记录嵌入需求评审，依靠三个时点的固定动作，而不是额外增加一份文档。记录在评审前产生、在评审中定稿、在评审后随需求流转，每个时点都有明确的负责人和完成标志。
评审前：随评审材料一起提交。需求负责人发起评审时，把技术债准入记录作为评审材料的附件或固定章节一并提交。技术负责人参与填写，重点确认本次需求会新增哪些债务、会触碰哪些已有债务。完成标志是记录中的债务描述、影响范围和初步风险等级已经填写，缺失时评审发起不完整，应退回补充。
评审中：作为固定议程项讨论并当场定稿。评审议程中安排技术债环节，位置放在需求方案讲解之后、评审结论形成之前。讨论结束后，评审组当场在记录中写入“准入/暂缓/拒绝”的判断及对应条件，由记录人同步更新。完成标志是结论字段已填写且无空白项。
评审后：随需求进入开发与台账。评审通过后，记录跟随需求进入开发流程，作为验收时核对债务偿还情况的依据，同时把新增债务登记到债务台账。完成标志是记录与需求建立关联，台账中出现对应条目。
减少事后补录的关键在于把记录绑定到评审议程：记录缺失时评审不能形成通过结论，记录结论未填写时评审视为未完成。记录在决策现场产生并当场定稿，评审后再整理的需求自然减少。需要说明的是，这套机制适用于有明确评审流程的需求；对于紧急修复类小需求，可以简化字段，但仍保留结论判断。
准入记录该写哪些字段
字段设计的目标是支撑评审判断，字段过多会让填写变成走形式。建议把字段分为必填和选填两类，必填项控制在能支撑“是否准入”判断的最小集合。
| 字段 | 填写要求 | 必填/选填 |
|---|---|---|
| 债务描述 | 用一两句话说明债务是什么，例如某模块缺少缓存层、接口耦合过紧 | 必填 |
| 债务来源 | 标明本次需求新增债务，还是触碰已有债务；触碰已有债务时注明原债务编号 | 必填 |
| 影响范围 | 受影响的模块、服务、接口或数据，以及可能波及的需求和团队 | 必填 |
| 风险等级 | 按团队约定分级，如高/中/低，并写明判断依据 | 必填 |
| 偿还时机 | 计划在哪个迭代、版本或触发条件下偿还 | 必填 |
| 触发条件 | 暂缓偿还时，写明什么条件出现必须启动偿还，如调用量超过阈值、下次改动该模块 | 暂缓时必填 |
| 责任人 | 债务偿还的负责人，与需求负责人区分 | 必填 |
| 验收方式 | 如何确认债务已偿还，如性能指标达标、代码评审通过、测试用例覆盖 | 必填 |
| 评审结论 | 准入/暂缓/拒绝，以及对应条件 | 必填 |
| 关联需求 | 需求编号或链接，便于追溯 | 选填 |
| 备注 | 评审中的补充讨论、替代方案等 | 选填 |
填写时注意两点：债务描述要具体到可判断，避免“代码质量较差”这类无法验证的表述；偿还时机与触发条件要和责任人对应，只写“后续偿还”而不落到人和时间点的记录，在评审中应被视为不完整。
评审会上怎么过这张记录
评审会上的操作顺序决定了记录是被认真讨论还是只走签字。建议把技术债环节固定在议程中，并按风险等级分配讨论深度。
- 议程定位。在评审议程中设置“技术债准入”环节，安排在需求方案讲解之后、结论形成之前，时长按需求规模预留，避免被压缩到会议末尾草草带过。
- 按风险分级讨论。高风险债务逐项讨论，明确影响范围、偿还窗口和责任人；中风险债务确认偿还时机与触发条件；低风险债务可批量确认，记录人统一填写结论。
- 判定暂缓与拒绝。暂缓适用于债务可以延后偿还、但必须写明触发条件和责任人的情况；拒绝适用于本次需求引入的债务超出团队可承受范围、且没有可行偿还安排的情况，拒绝时需给出替代方案或拆分需求的建议。
- 当场写入结论。讨论结束后，记录人当场填写评审结论及条件，评审组确认无误。结论为暂缓的，触发条件和责任人必须同时填写，否则视为未完成评审。
- 明确后续动作。结论为准入的，记录随需求进入开发，偿还安排进入迭代计划；结论为暂缓的，触发条件登记到债务台账并设置提醒；结论为拒绝的，需求退回修改。
判定规则需要提前在团队内达成一致，例如规定高风险债务必须在本迭代或下一迭代安排偿还，否则不予准入。规则一旦确定，评审会上按规则执行，减少每次临时争论。
角色分工与各环节交付物
责任悬空是准入记录流于形式的主要原因。下表把每个角色的输入、动作和交付物对应起来，便于在流程中核对。
| 角色 | 输入 | 主要动作 | 交付物 |
|---|---|---|---|
| 需求负责人 | 需求方案、涉及模块的技术现状 | 发起评审前填写记录中的需求相关信息，提交评审材料 | 填写了债务描述、来源和影响范围的准入记录 |
| 技术负责人 | 需求方案、已有债务台账、架构约束 | 补充风险等级、偿还时机与触发条件，确认责任人 | 字段完整的准入记录，含风险判断依据 |
| 评审组 | 准入记录、需求方案 | 按议程讨论，形成准入/暂缓/拒绝判断 | 写入结论及条件的评审记录 |
| 债务跟踪人 | 评审通过的准入记录 | 登记新增债务，跟踪暂缓项的触发条件，核对偿还验收 | 更新后的债务台账、偿还验收记录 |
评审结束后，记录流转到债务跟踪人手中，由其完成台账登记并持续跟踪。需求负责人保留记录与需求的关联，在验收阶段核对偿还情况。角色可以由同一人兼任，但职责要分开写明，避免填写和审核由同一人完成而失去把关作用。
在工具层面，ONES的需求与工作项管理可以把准入记录作为需求下的工作项或文档关联起来，评审结论和偿还安排随需求一起流转；ONES Wiki可用于沉淀记录模板和评审规则，ONES Assistant能够理解项目与Wiki上下文，并把结果保存为工作项或Wiki页面，减少页面切换和重复录入。具体配置需按实际部署与套餐确认。
示例：一次需求评审中的准入记录
以下为演示情景，用于说明记录如何填写和在评审中使用，不代表真实项目数据。
背景。某团队计划在订单服务中新增批量导出功能，该服务此前已知存在查询接口未做分页的债务，编号DEBT-012。
记录填写内容。
- 债务描述：批量导出复用现有查询接口，该接口未分页，大数据量下可能拖慢订单列表查询。
- 债务来源：触碰已有债务DEBT-012。
- 影响范围：订单查询接口、订单列表页，可能波及使用该接口的运营后台。
- 风险等级：高，依据是导出数据量预计达到十万级，且接口被多个页面共用。
- 偿还时机：本迭代内为查询接口补充分页参数。
- 触发条件：不适用，本次直接安排偿还。
- 责任人：订单服务后端负责人。
- 验收方式：分页接口上线后，订单列表页在大数据量下的响应时间达到约定指标，相关测试用例通过。
- 评审结论：准入，条件是分页改造与导出功能同迭代交付。
评审过程。评审会上，技术负责人说明该接口被多个页面共用，评审组据此将风险定为高，逐项讨论后同意准入，但要求分页改造不能晚于导出功能上线。记录人当场写入结论和条件，债务跟踪人随后更新台账，把DEBT-012的偿还状态标记为进行中，并在迭代计划中关联对应任务。验收阶段，测试用例与需求关联，偿还完成后由债务跟踪人核对指标并关闭台账条目。
完成检查：判断嵌入是否生效
机制建立后，需要定期核对它是否真正生效。以下检查项可按季度或按迭代抽查，每项给出通过标准。
| 检查项 | 通过标准 |
|---|---|
| 记录产生时间 | 抽查的需求中，准入记录的创建时间早于评审时间，不存在评审后补录 |
| 评审结论完整性 | 每条记录都有明确的准入/暂缓/拒绝判断，结论字段无空白 |
| 暂缓项条件 | 所有暂缓项都写明了触发条件和责任人，缺一即不通过 |
| 台账可追溯 | 新增债务和触碰的已有债务都能在台账中找到对应条目，并与需求关联 |
| 偿还闭环 | 到期或触发条件满足的债务有偿还记录和验收结果 |
| 评审跳过情况 | 抽查期内没有出现记录缺失仍通过评审的需求 |
检查结果可用于调整流程：如果补录比例偏高，说明记录与评审材料的绑定不够紧，需要把记录设为评审发起的必填项；如果暂缓项长期没有触发偿还，说明触发条件设置过宽，需要收紧判定规则。检查本身不必复杂，关键是持续执行并让结果回到流程改进中。
常见问题
需求很紧急、来不及完整填写准入记录时怎么处理？
可以简化字段，但保留判断所需的最小集合：债务描述、来源、影响范围、风险等级和评审结论。紧急需求同样需要在评审前提交这份简化记录，评审会上当场写入结论。如果连简化记录都无法在评审前产生，建议把该需求纳入下一次常规评审，或者由技术负责人书面确认风险后再走紧急通道，并在事后补登台账。简化不等于跳过，结论判断始终保留。
技术债准入记录和缺陷管理如何区分，避免同一问题两边都记？
已确认的功能 Bug 归缺陷管理，按缺陷流程跟踪修复；准入记录处理的是需求引入或触碰的债务决策，关注是否准入、何时偿还、由谁负责。判断标准可以放在问题性质上：影响现有功能正确性的走缺陷流程，属于设计取舍、耦合、缺少分层等结构性问题的走准入记录。如果一个问题同时涉及两者，在准入记录中注明关联的缺陷编号，避免重复登记和状态不一致。
暂缓偿还的债务长期没有触发，怎么防止被遗忘？
暂缓项在评审当场就要写明触发条件和责任人，评审后由债务跟踪人登记到台账并设置提醒。触发条件应尽量可观察，例如调用量超过阈值、下次改动该模块、某个版本上线前。定期检查时专门核对暂缓项：触发条件已满足但未启动偿还的，要求责任人说明原因并重新排期；触发条件长期无法满足的，说明条件设置过宽，需要收紧判定规则或改为按固定周期偿还。
团队规模较小、没有独立评审组时，这套机制还能用吗？
可以用，角色可以合并但职责要分开写明。需求负责人填写债务描述和影响范围，技术负责人补充风险等级、偿还时机和责任人，评审由技术负责人和相关开发共同完成，结论当场写入。关键是填写与审核不由同一人独自完成，保留基本的把关环节。记录同样随需求流转并登记台账，检查项可以按季度抽查几条需求，确认记录产生时间早于评审、结论完整。
准入记录在工具里怎么承接，才能随需求一起流转？
常见做法是把准入记录作为需求下的关联工作项或文档，评审结论和偿还安排随需求状态一起流转，台账条目与需求建立关联便于追溯。ONES 的需求与工作项管理可以把记录关联到需求下，ONES Wiki 可用于沉淀记录模板和评审规则，ONES Assistant 能理解项目与 Wiki 上下文并把结果保存为工作项或 Wiki 页面，减少页面切换和重复录入。具体配置需按实际部署与套餐确认。
