技术债务从来不是虚无缥缈的概念，它可能是张三在某个周二下午为赶上线拍板做的临时方案，也可能是李四离职前没来得及填补的隐患。要让AI输出的技术债说明摆脱泛泛空谈，就必须将具体的人名、时间节点、决策细节嵌入到提示词中。

先锚定真实场景再写提示词

告诉模型项目当前所处的阶段：是刚上线的ToB SaaS系统，还是维护了五年的政企老旧Java单体？不同背景会导致技术债的成因与表述方式截然不同。真实案例表明：政企项目中那句“当时为赶验收节点跳过单元测试”，其真实度远超“缺乏测试意识”这类空话。

把真实角色带入提示词。例如张伟。2023年9月。Vue 2硬套Ant Design Vue 4组件库——正是这位同事亲手埋下的隐患，表单校验逻辑重复了三份。这种带有姓名、时间、技术栈的细节一旦给出，模型就不会编造“存在兼容性问题”这种万能话术。没有具体人物、事件、时间、技术细节的提示词，模型只能生成通用废话。

用缺陷反推技术债描述

方法一：从线上报错日志切入。
直接将最近一次500错误的堆栈信息、发生时间、影响范围交给模型，让它逆向还原背后的技术债成因。比如抛出这段信息：“2024-06-12 14:22 用户提交订单时触发NPE，堆栈指向OrderService.java第87行，该类无Spring事务注解，但调用了需事务保障的库存扣减接口”。模型自然会生成：“订单服务未声明事务边界，根源在于2022年V1.3版本为快速接入支付网关而临时移除@Transactional，此后未回归修复”。

方法二：从重构卡点倒逼描述。
团队计划把用户中心模块拆分为微服务，却卡在数据库强耦合上。此时可提示：“用户表与订单表共用同一MySQL实例且存在外键约束，拆分时需停机3小时。请说明该设计决策发生时间、原始需求背景、当时替代方案评估结论。”这种提问方式远比“数据库耦合有什么风险”更能榨出有血有肉的细节。

强制嵌入不可伪造的上下文字段

第一步：在提示词开头固定插入三行元数据模板：

【项目代号】：XX-CRM-V2
【最后修改人】：李工（后端）
【最近一次相关变更】：2024-05-18 合并请求#2217，移除了Redis缓存层降级开关

第二步：要求所有技术债描述必须引用其中至少一项。不能写“缓存策略不合理”，而要写“【最近一次相关变更】中移除降级开关后，Redis集群故障时订单创建接口直接雪崩，暴露了2021年V1.0版未设计熔断器的根本缺陷”。缺少元数据锚点的描述，九成概率是模型虚构。

第三步：追加验证指令：“列出该技术债在Jira中对应的原始需求编号（如无则写‘缺失’），以及当前是否被标记为P0级技术任务（是/否/未知）”。模型无法编造真实Jira编号，会主动暴露信息缺口——反而让输出结果更可信。