先聊一个很多团队都会踩的坑：你让ChatGPT输出一份技术债改造检查表，结果它给你一堆泛泛而谈的“建议”或“原则”，根本没法落地执行。为什么？因为你没有给它具体的实例来锚定。没有真实的代码债、架构债作为上下文，AI只能编造通用条目，离你的系统场景相去甚远。

所以，要让输出真正可用，必须给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%则拒绝合并”这种可卡点项。