用Cursor写后端接口总翻车，是我姿势不对还是工具真不适合？

说实话我也遇到过这情况，Cursor写前端确实像开了挂，但一到Spring Boot这种带状态和边界条件的后端逻辑，它就容易给你整出个“看起来很美”的代码。我觉得核心问题不是工具不行，而是它压根没把事务边界、锁和异常补偿这些隐式约束当成硬需求，你得把并发控制的具体方案写进prompt里，比如直接说用悲观锁还是版本号。另外别让它一次性生成整个接口，拆成service、mapper、controller分步喂，每步让它先解释思路再写码，翻车率能降不少。你还可以试试用单元测试反向约束它，把关键断言的测试代码先丢给它，让它补实现，比单纯描述需求稳多了。

说实话我也遇到过类似情况，前端它确实能给你写出能跑的代码，但后端一旦涉及事务边界和并发控制，它就像个刚毕业的实习生，看着对，实际一压测就崩。我现在的套路是让它先画个流程草图，把关键的业务规则用伪代码写出来，再让它填充实现，最后自己重点review锁和事务那块。另外Spring的注解它经常用错，比如@Transactional的传播行为，建议直接把你们项目的规范文档喂给它当few-shot。

其实这玩意儿更像是个高级补全工具，别指望它真理解业务，你把它当个能快速生成模板和基础CRUD的助手，复杂逻辑还是得自己兜底，尤其是权限校验这种跟具体框架深度绑定的，我都是手写然后让AI给我补单元测试。对了，你可以试试用测试驱动的方式，先让它写测试用例，再用测试去逼它改实现，这样至少能保证逻辑自洽。