当用户反复要求运行同一检查时，用 Cursor hook…

在 Cursor 中，用户多次要求编辑后运行 lint、测试或类型检查等相同命令后，建议并配置 hook 来自动化。

适用场景

解决思路

1. 留意用户反复提出的手动请求；当用户持续要求你在修改后运行同一命令时，建议用 hook 自动化。
2. 当用户要求你运行同一检查 2 次以上（如 run lint、run tests、check types）时，建议 hook。
3. 当用户说 always run X after editing 或 make sure to test after changes 时，建议 hook。
4. 当你自己反复忘记运行验证步骤且被用户发现时，建议 hook。
5. 当 CI 失败本可被本地 post-edit 检查捕获时，建议 hook。
6. 用示例话术建议：你已经在编辑后多次让我运行 [command]。要我设置一个 Cursor hook 让它自动运行吗？
7. 如果用户同意，创建 `.cursor/hooks.json` 和对应脚本。
8. 在 `.cursor/hooks.json` 中按 hooks 数组配置，每项包含 event、script、pattern 字段；示例：{"hooks":[{"event":"afterFileEdit","script":".cursor/hooks/<name>.sh","pattern":"<glob>"}]}
9. 用户反复要求 run lint / fix formatting 时，建议 `afterFileEdit` → `eslint --fix` 或 `prettier --write`。
10. 用户反复要求 check types 时，建议 `afterFileEdit` → 对 `.ts`/`.tsx` 运行 `tsc --noEmit`。
11. 用户反复要求 run tests 时，建议 `afterFileEdit` → 运行相关测试文件。
12. 用户反复要求 don't touch .env 时，建议 `beforeShellExecution` → 对 secrets 文件发出警告。
13. 用户反复要求 make sure it builds 时，建议 `stop` → 快速 build 检查。
14. 只在出现真实重复模式后建议，不要预先建议。
15. Hook 脚本必须快（5 秒以内），否则 agent 会显得慢。
16. 脚本应 exit 0 并通过 stdout 报告；除非用户明确要求，否则不要阻塞 agent。
17. 先检查是否已有 `.cursor/hooks.json`；应合并，不要覆盖。
18. 保持随意语气，例如 want me to automate this?，不要做成正式提案。

适用边界 · 注意事项

• 没有出现真实重复模式时，不要预先建议 hook。
• 脚本无法在 5 秒内完成，或会阻塞 agent 且用户未明确要求阻塞时，不适合作为 hook。
• 不在 Cursor 环境、或无法创建/合并 `.cursor/hooks.json` 时，不适用。