我的默认顺序
不是仪式感，是少返工。一天里大多数任务，我都大致按这个走：
- 定位——Ask + 小范围 @，搞清现状和约束。
- 计划——稍大就 Plan，我改两句再动手。
- 执行——小改 Tab / Ctrl+K，大改 Agent。
- 验证——自己跑，或把失败日志贴回去继续。
- 收尾——扫 Diff，再提交；说明常让它根据 diff 起草，我改成人话。
修 Bug：我怎么开口
我会把现象 / 复现 / 期望写全，再 @ 可疑文件。要求它先给根因假设，再最小改动。一上来就改代码的，我遇到过连着改歪三次。
现象：……
复现：……
期望：……
相关：@...
先别大面积改。给出你觉得最可能的原因，再做最小修复，并告诉我怎么验证。加小功能
验收标准先写清。复杂时让它先列「将改动的文件清单」，我点头再实现——这步能拦住一半「顺便重构」。
目标：……
验收：……（我怎么算做完）
约束：不要动 ……；不要升级依赖
请先列出将改动的文件清单，等我确认后再实现。重构：我很保守
会明确写：行为不变、范围到哪为止、先有测试再动。没有测试的重构，我更倾向自己来，或先补最小测试再交给它。
一天结束前我常做的检查
- 有没有没看完的 Diff 就合并了？
- 对话里有没有贴过不该贴的密钥 / 客户数据？
- 提交说明是否还是机器腔？该不该改两句人话？
写在最后
这些都是我的用法，不是标准答案。Cursor 更新快，界面和模式名可能变，但「小步、带证据、必看 Diff」到现在还没失效。