必须在cursor提示词中结构化注入项目上下文、真实技术债指标和权重决策链：当前sprint 47（2024-06-10至2024-06-23）、后端3人（1人下周休假）、sla 99.95%且近7天2起订单超时故障；嵌入含可验证指标的债例（如日志定位耗时42分钟、sec-alert-882告警）；严格按“是否引发故障/告警→是否阻碍sprint目标→修复人日≤1.5”三步加权排序。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在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会默认“无限资源”，给出理想化但不可执行的排序。
注入真实技术债实例及现状数据
在提示词中嵌入至少2个真实待评估的技术债条目，每条必须包含：【可验证的现状指标】，例如：
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
• 技术债A：用户中心服务未接入OpenTelemetry → 当前仅靠日志排查慢请求，平均定位耗时42分钟（上周3次P1故障统计）
• 技术债B：支付回调验签逻辑硬编码密钥 → 已在灰度环境触发1次密钥泄露告警（安全平台ID: SEC-ALERT-882），但未阻断发布
不要写“代码质量差”“耦合度高”这类模糊描述。Cursor依赖具体数字和事件ID才能建立严重性锚点。
声明决策依据权重顺序
用冒号分隔的短语明确告诉AI判断主次的逻辑链：
第一步：是否已引发线上故障或安全告警（是→直接置顶）
第二步：是否阻碍当前Sprint核心目标（如：订单履约率提升至99.2%）
第三步：修复所需人日是否≤1.5（超过则降权，除非满足前两条）
这个排序必须严格按团队实际协作规则来写。如果你们其实更看重长期可维护性，就把第三步换成“是否影响新功能开发速度（由最近3个PR平均合并延迟衡量）”。【权重顺序一旦写错，整个优先级结果就失效】
