提到通义千问分析技术债，很多人的第一反应往往是先丢一个提示词，让模型直接输出一堆优化建议。但真正的问题在于，如果提示词本身缺少关键上下文和业务锚点，最后得到的内容通常只会停留在套话层面——比如“建议优先处理高风险、低修复成本项”。并不是模型能力不够，而是它根本不了解你的项目现状、资源限制和线上压力，只能重复通用型表达。

因此，想让模型真正输出可执行、可落地的技术债优先级清单，核心就在于把几个关键锚点准确塞进提示词里。

明确技术债的三类真实约束

先看第一个硬约束。在提示词开头，直接写明当前项目面临的三项硬性限制。例如：【必须包含：团队当前仅有1名后端熟悉Elasticsearch；下个迭代只剩8人日可用；线上P0故障必须48小时内闭环】。没有这些限制条件，模型始终无法区分“理论上应该修复”和“当前阶段能够修复”之间的差别。

第二个重点，是把你目前掌握的数据源类型写清楚。比如“已有：近30天慢查询日志（含trace_id）、Git提交频率热力图、SRE告警分级记录”。如果模型不知道你有trace_id，就很难主动提出按调用链路深度排序；而一旦它知道这些数据存在，给出的技术债定位思路和排查路径通常会更准确。

第三步，是删掉所有过于柔和的动词。把“请”“建议”“可以考虑”之类的表述全部去掉，直接改成“输出格式：每条技术债必须标注【不可跳过】或【可延期】，仅二选一”。指令越明确、约束越强，模型输出的结果往往越聚焦，也越少空话。

用角色+动作替代抽象要求

更具体地说，可以采用两种常见写法。方法一：为模型指定明确角色。例如：“你是一名刚接手该系统的Tech Lead，上周因缓存击穿导致订单丢失，现在要向CTO汇报未来两周技术债攻坚清单。”当角色、压力和后果同时出现时，模型通常会自动过滤掉“长期演进”“架构优化”这类泛泛而谈的内容。

方法二：直接绑定具体交付物。可以写成：“生成一份可直接粘贴进Jira Epic描述的文本，含：①每条债的触发现象（例：支付回调超时率从0.3%升至5.7%）；②定位路径（例：查payment-service→trace_id→发现Redis连接池耗尽）；③修复后可验证的指标（例：回调超时率回落至0.5%以下且持续24小时）”。注意：不要直接写“现象/路径/指标”这三个词，而是只保留冒号后的真实内容样例，这样模型更容易模仿输出结构，而不是机械罗列术语。

注入时间感知与衰减逻辑

在技术实现上，还可以在提示词中加入动态权重因子。例如：“对6个月内未被修改的模块，其技术债优先级×1.8；对最近一次发布含hotfix的模块，其技术债优先级×2.3”。模型看到这种乘数规则后，通常会放弃平均分配优先级的做法，开始进行更接近真实场景的权重判断。

再看一个贴近业务节奏的例子：“当前大促备战期（10.20-11.11），期间禁止任何数据库schema变更”。这句话看起来很简单，但实际效果非常直接——模型会主动降低“新增索引”这类技术债的优先级，同时把“避免大促期间OOM”这类高风险稳定性问题排到更靠前的位置。