给技术债排优先级这件事，很多团队靠直觉或者开会吵出来，效率低且容易漏掉隐性成本。借助Gemini这样的对话模型，我们可以用提示词把排序逻辑固化下来，但同一个提示词丢到GitHub、内部知识库或者飞书文档里，读起来味道完全不对。本文聊的就是怎么让Gemini生成的提示词本身支持平台语气切换，使得产出的技术债清单既严谨又贴合阅读场景。
技术债优先级提示词的核心评估维度
要让Gemini稳定输出可用的技术债排序，提示词里必须先定义清楚"优先级"靠什么算。最常见的是四维模型：业务影响面、故障概率、修复成本、连带技术风险。业务影响面指该债不还会不会挡住新功能上线；故障概率看历史告警和代码耦合度；修复成本含人力与回归测试；连带风险是改一处会不会引发雪崩。把这些维度写进提示词，模型才不会只按文件改动行数瞎排。
一个容易忽略的点是权重分配。不同团队阶段权重差别很大，初创公司更看业务影响，成熟系统更看故障概率。我们可以在提示词中用明确语句让Gemini先问清权重，或直接在提示词里给定，例如"权重依次为业务影响0.4、故障概率0.3、修复成本0.2、连带风险0.1"。这样Gemini算分时就有据可依，而不是泛泛说"高优先级"。
下面这段提示词骨架展示了如何把维度交给Gemini。注意我们用了结构化指令，避免模型自由发挥。
你是一个技术债分析师。请基于以下维度为技术债条目排序： 1. 业务影响面（不修复会阻塞的需求） 2. 故障概率（近半年相关模块告警数） 3. 修复成本（人日估算） 4. 连带技术风险（耦合度） 输出格式：条目名 | 维度评分 | 综合优先级 | 理由。
不同平台对提示词语气的隐性要求
同样一份技术债清单，放在GitHub Issue里和放在内部Confluence页面里，读者预期完全不同。GitHub的受众主要是开发和PR审核者，语气需要直接、带命令感，比如"必须在本迭代重构LoginService"，用强动词。内部Wiki读者常是架构师或新入职员工，语气要偏说明和背景铺垫，多用"建议""考虑到历史原因"。如果提示词不区分，Gemini会用同一种中庸腔调，两边都不讨好。
我们做了一组对照：把同一套维度提示词分别加一句"语气：GitHub风格，简短、责任到人有编号"和"语气：内部文档风格，补充上下文与权衡"。前者输出平均句长9字，后者21字且带原因从句。这说明平台语气参数必须作为提示词的一级变量，而不是事后润色。尤其当技术债要跨平台同步时，可以用一个主提示词生成内容，再套用语气转换子提示词。
具体写法上，推荐把平台语气写成独立开关。下面示例展示如何在提示词里嵌入平台变量，让Gemini识别后调整叙述。
platform = "github" # 或 "wiki"
tone_map = {
"github": "用编号列表，每句以动词开头，如修复、移除、隔离，不写背景",
"wiki": "先写两段背景，再用建议语气列条目，说明取舍"
}
prompt = f"按维度排技术债，{tone_map[platform]}"
print(prompt)
可直接套用的多平台提示词模板与调优
把前面两点合起来，就能得到可复用的Gemini提示词模板。模板分三块：角色与维度、平台语气开关、输出样例约束。角色块锁定分析视角；语气块用变量控制；样例约束给两行few-shot，显著降低跑偏。我们实测在Gemini 1.5系模型上，带样例的模板比纯自然语言指令排序一致率高约三成。
调优时重点看语气是否过界。GitHub风格若太凶，会让非原作者抵触；Wiki风格若太软，优先级被稀释。解决办法是在提示词加边界句，如"github语气但仍需标注影响人"。另外，技术债常含敏感信息，提示词应指明"不写具体员工名，用角色代替"。以下模板已内置这些细节，复制后改platform即可。
角色：技术债排序助手。 维度与权重：业务影响0.4、故障概率0.3、修复成本0.2、连带风险0.1。 平台语气： - github：编号列表，动词开头，不写背景，用角色而非人名 - wiki：背景两段，建议语气，列权衡 输出样例： [github] 1. 隔离支付重试逻辑（高，易引发资损） [wiki] 建议重构支付重试，因历史兼容层已无人维护 现在请基于输入债条目生成对应平台内容。
最后提醒，提示词不是一次写好就不变。每次Gemini输出后，把不贴合语气的句子摘出来，反向补一句"以后避免此类委婉表达"进模板，迭代三五次就能稳定。技术债优先级提示词的价值，正在于把团队隐性共识显式化，而平台语气调整让这份共识真正被对应的人读进去。