在使用Cursor编写技术债改造方案时，若提示词过于随意，往往容易遗漏业务上下文、影响范围及回滚路径等关键细节，导致生成内容空泛或难以落地。如何写出结构清晰且精准的提示词？以下几条来自实践的经验值得参考。

明确提示词的三要素框架

第一步，用「角色+任务+约束」三段式开头把调子定下来。举个例子：“你是一位有5年Java微服务经验的后端架构师，需要为订单服务中的库存扣减逻辑撰写技术债改造方案，方案里必须包含当前问题定位、改造后的接口契约变化、数据库迁移脚本片段、以及灰度验证步骤。”如果缺少角色或约束，Cursor默认会按通用工程师视角输出，完全忽略你的团队技术栈和发布流程。

第二步，在任务描述中嵌入必须保留的细节锚点。例如明确要求：“请显式输出：① 该逻辑当前被哪些上游服务调用；② 改造后新增的幂等字段名及其生成规则；③ 回滚时需要执行的SQL语句（必须带WHERE条件）。” 这样做，Cursor就不会仅给出一个笼统的“加锁”建议。

第三步，在结尾追加一句强制指令：“所有输出必须严格对应上述三点，缺失任一即视为无效。” 简单直接，效果立竿见影。

用分隔符锁定关键信息区块

方法一：在提示词中使用「---」将不同类型的信息物理隔离。例如：

当前问题：
库存扣减未校验超卖，日志无traceId，异常堆栈不透出。
---
影响范围：
订单创建、秒杀下单、退单补偿三个场景均调用此逻辑。
---
交付约束：
必须兼容旧版OpenAPI v2.1，不可修改request body结构。

方法二：使用符号标记重点字段。例如将“幂等键”写成【idempotency_key】，“回滚SQL”写成【rollback_sql】。Cursor会识别这类带【】的标识，并在输出中优先保留它们。

注入真实代码片段锚定上下文

直接粘贴一段真实的、带注释的问题代码，比纯文字描述有效得多。例如：

```java
// 当前库存扣减入口，问题：未使用分布式锁，高并发下存在超卖风险
public void deductStock(Long skuId, Integer quantity) {
    Stock stock = stockMapper.selectById(skuId);
    if (stock.getAvailable() < quantity) {
        throw new BizException("库存不足");
    }
    stock.setAvailable(stock.getAvailable() - quantity);
    stockMapper.updateById(stock); // ⚠️ 这里存在ABA问题
}
```

操作很简单——直接将文件中的这段代码复制到提示词中即可。Cursor会基于真实代码结构生成改造建议，而非泛泛而谈“加锁”或“用CAS”。

禁用模糊动词，替换为可验证动作

将“优化性能”改为“将原同步RPC调用改为本地缓存+异步MQ更新，缓存key格式为sku:{id}:stock，TTL=30s”。模糊动词会让Cursor自由发挥，而具体动作能触发它对Spring Cache和RocketMQ语法的准确调用。

将“增强可观测性”改为“在deductStock方法入口打点，埋点字段包含traceId、skuId、quantity、before_stock、after_stock”。

将“支持回滚”改为“提供两条SQL：一条UPDATE恢复available字段值，一条DELETE清理新引入的idempotent_record表中对应记录”。

将这些技巧组合使用，写出的提示词能让Cursor的输出既精准又落地。最后提醒一点：别忘了将生成的方案拿到真实代码中验证一遍，毕竟工具再聪明，也替代不了人的判断。