用Cursor生成技术债说明，第一步就必须锁定问题根源、影响范围和修复路径。很多开发者在写技术债说明时容易踩的坑是——描述泛泛而谈，开发人员拿到之后无法据此排期或评估风险。要避免这种问题，提示词的结构需要严格遵循一个三步框架。

明确锁定技术债的三个核心要素

第一步：提示词开头用「【技术债类型】+【模块名】+【当前表现」」固定结构起句。举个例子：“【架构耦合】用户鉴权模块中Token校验逻辑与JWT解析硬编码耦合，导致无法切换认证协议”。这个格式的好处是强制剥离模糊描述，关键原则是：避免使用“性能差”“不易维护”这类主观判断，只描述可验证的行为现象。

第二步：紧接着插入「→ 触发条件：」加上具体操作路径，比如“→ 触发条件：调用/api/v2/login接口且传入refresh_token字段”。说穿了，没有触发条件的技术债说明等于无效文档，因为开发人员根本无法复现问题。

第三步：用「→ 风险后果：」列出两条客观结果，其中必须包含一项运行时影响（例如“每次刷新token失败率上升12%”）和一项维护成本（例如“新增OAuth2支持需重写3个Service类”）。这里要注意，尽量避免“可能影响”“潜在风险”这类弱约束表述，结果要可衡量。

过滤冗余信息的两种方法

方法一：用「保留」指令显式声明关键字段。在提示词末尾加一句：“保留：错误码（401/403）、涉及类名（AuthFilter.ja va、TokenService.ja va）、最近一次报错时间（2024-05-12 14:22）”。Cursor会忽略其余日志堆栈和调试变量，输出内容会更聚焦。

方法二：用「剔除」指令屏蔽干扰项。“剔除：前端报错截图、个人排查过程、历史讨论记录、非Ja va文件路径”。这个技巧很实用，能防止Cursor把会议纪要片段混进技术债说明里，避免文档冗长而无重点。

生成后必须校验的硬性检查点

生成结果出来后，立刻逐行核对三项内容是否全部存在：① 精确到行号的代码位置（如“src/main/ja va/com/app/auth/TokenService.ja va:87”）；② 可复现的输入参数组合；③ 明确标注「临时方案」和「根治方案」的段落。这三项缺任何一项，都必须重写提示词。

需要警惕的一种情况是：如果Cursor输出中间出现“建议后续优化”“可考虑重构”这类软性表述，说明提示词里漏掉了「→ 根治方案：」前缀。这是最常踩的坑，必须用「→ 根治方案：」开头，后面跟具体的代码修改动作，比如“将TokenParser抽离为独立Bean并注入AuthFilter”。这才是能直接落到代码层面、可执行的方案。