基于实际项目经验,为Cursor编写技术债优先级提示词,核心在于让AI充分掌握项目背景信息——当前迭代进度、团队人员配置、线上环境是否曾发生严重故障。否则,生成的优先级排序可能出现偏差:将日志格式不规范这类低影响问题排在数据库连接泄漏等高风险缺陷之前。

明确项目当前阶段与关键约束条件
在Cursor左侧的「Project Context」面板中,或直接在项目根目录的.cursor/rules.md文件内,在提示词起始位置添加三行结构化背景信息:
• 当前迭代周期:Sprint 47(2024-06-10 至 2024-06-23)
• 团队人力配置:后端3人(含1人下周休假)、前端2人、无专职测试人员
• 线上稳定性要求:SLA 99.95%,近7天P0/P1故障共2起,均与订单服务超时相关
这一步至关重要,不可省略。缺少时间窗口和人力约束信息,AI会默认资源无限,生成的优先级排序虽然看起来合理,但实际执行时难以落地。
注入真实技术债实例与现状数据
提示词中至少应包含两个真实的技术债条目,每条需附带可验证的现状指标。例如:
• 技术债A:用户中心服务未接入OpenTelemetry → 当前仅依赖日志排查慢请求,平均定位耗时42分钟(基于上周3次P1故障统计)
• 技术债B:支付回调验签逻辑硬编码密钥 → 已在灰度环境触发1次密钥泄露告警(安全平台ID: SEC-ALERT-882),但未阻断发布流程
不要仅描述"代码质量差"、"耦合度高"等抽象表述,AI需要的是具体数字和事件ID——这才是建立严重性评估锚点的可靠依据。
声明决策依据的权重顺序
在提示词中使用冒号分隔的短语,将判断逻辑链清晰地呈现给AI:
第一步:是否已引发线上故障或安全告警(是→直接置顶处理)
第二步:是否阻碍当前Sprint核心目标(如:订单履约率提升至99.2%)
第三步:修复所需人日是否≤1.5(超过则降低优先级,除非满足前两条条件)
这个排序规则需根据团队的实际协作模式来定制。如果团队更关注长期可维护性,可将第三步替换为"是否影响新功能开发速度(使用最近3个PR的平均合并延迟作为衡量指标)"。权重顺序一旦设定错误,整个优先级排序结果将失去参考价值。
