无法生成该检查表，因您未提供当前系统中真实存在的技术债实例（如“订单服务中PaymentService类有7层嵌套if-else”“用户中心数据库未建唯一索引导致并发写入重复记录”）。根据您的【关键前提】，缺少这2个真实实例，ChatGPT不得虚构条目，否则将违背可落地执行的核心要求。请补充具体实例后，我将严格按六阶段生命周期、五类债型标签、客观技术信号及纯文本表格格式生成可勾选、可拦截、可验证的检查表。

你需要让ChatGPT输出一份可直接落地执行的技术债改造检查表，而不是泛泛而谈的“建议”或“原则”。这份检查表必须包含具体动作、责任人归属提示、前置条件判断、风险拦截点，且每一项都能在研发日常流程中被勾选验证。

明确检查表的核心结构

先告诉ChatGPT：检查表不是清单罗列，而是按改造生命周期分阶段组织。必须包含【识别→评估→排期→实施→验证→归档】六个环节，缺一不可。每个环节下设3～5个可执行条目，条目格式统一为“动词开头+宾语+判定标准”，例如“确认该模块存在至少2个未覆盖的边界用例→覆盖率报告截图需附在PR描述中”。

这一步不能跳过。如果漏掉任一环节，生成的表格会缺失关键控制点，导致团队执行时漏检高危项。

注入技术债的具体分类锚点

方法一：用括号标注典型债型前缀
在每条检查项开头强制加入【代码债】【架构债】【测试债】【文档债】【部署债】五类标签之一。例如【测试债】编写回归测试用例→覆盖本次修改路径所有分支，且通过CI自动触发。

方法二：绑定具体技术信号
给出3个可检测的客观信号作为触发条件，如“函数圈复杂度＞15”“同一SQL在3个以上服务中重复出现”“API响应时间P95＞2s且无缓存头”。ChatGPT必须将这些信号嵌入检查项判定标准中，不能只写“性能较差”这类模糊描述。

【关键前提】必须提供至少2个你当前系统里真实存在的技术债实例（比如：“订单服务中PaymentService类有7层嵌套if-else”“用户中心数据库未建唯一索引导致并发写入重复记录”），否则ChatGPT会虚构通用条目，无法匹配你的实际场景。

限定输出格式与校验机制

第一步：要求用纯文本表格呈现，禁止Markdown、HTML或代码块。
第二步：每行严格遵循“阶段｜条目编号｜检查项｜责任人提示｜阻断条件”五列，用中文全角｜分隔。
第三步：在“阻断条件”列中，必须写出明确的拦截动作，例如“CI流水线失败”“TL审批不通过”“安全扫描告警未清除”。

第四步：最后追加一行校验指令：“请逐项核对：① 是否所有检查项都含可验证的动作动词；② 是否每个‘责任人提示’都指向具体角色（如‘后端主程’‘SRE值班人’）；③ 是否存在任意一条检查项依赖主观判断（如‘代码质量良好’）。若有，则重写。”

这一步决定输出是否可用。没有校验指令，ChatGPT大概率生成“建议增加单元测试”这类无效项，而非“提交PR前须运行jest --coverage --onlyChanged，覆盖率下降≥0.5%则拒绝合并”这种可卡点项。