Cursor rule

1---
2description: 回答前必须先查证，禁止未经搜索就声称"不存在"或"没有"
3alwaysApply: true
4---
5 
6# 先查证，再回答
7 
8对项目事实的任何断言，必须有工具调用作为依据。禁止凭记忆或猜测回答。
9 
10## 规则
11 
121. **涉及"有没有"、"在哪里"、"是什么"类问题时**，必须先用 Grep / Glob / SemanticSearch / Read 等工具实际搜索，再给出结论。
132. **禁止未搜索就说"没有"、"不存在"、"未见"、"代码里没找到"**——这些结论只有在工具返回空结果后才能说。
143. **不确定时**，搜多个关键词、多个目录、多种拼写。一次没找到不代表没有，换词再搜。
154. 如果工具搜索后确实没有，如实说明搜了什么、搜索范围是什么，让用户能判断是否需要扩大范围。
16 
17## 外部库的具体值必须查源码
18 
19引用第三方库的 **key 名、默认值、API 签名、存储格式** 时，禁止凭记忆写。必须到 `node_modules/` 或库源码中实际确认。
20 
21典型场景：localStorage key、配置项默认值、事件名、CSS 类名前缀、环境变量名。
22 
23```
24❌ 凭印象写 localStorage.getItem('vueuse-color-appearance')，实际 key 是 'vueuse-color-scheme'
25❌ 在错误的 key 上反复修条件逻辑和 CSS，三轮都没质疑前提
26✅ 先 grep node_modules/@vueuse/core 确认 storageKey 默认值，再写代码
27```
28 
29**如果一个修复没有生效，第一步是质疑前提假设，不是在同一假设上换方向打补丁。**
30 
31## 排查问题必须追到可执行方案
32 
33找到"为什么不行"只是排查的一半。必须继续追到"怎么才能行"。
34 
35### 规则
36 
371. **禁止停在解释层**——"ARM 上 Debian sid 只有最新版 Chromium"是原因分析，不是排查结论。排查结论必须是：用户该做什么才能成功。
382. **禁止把平台限制当终点**——当原路径不通时，主动寻找替代路径（换基础镜像、换架构、换工具链）。"这个平台做不到"只有在穷尽所有替代方案后才能说。
393. **每次排查必须回答三个问题**：(1) 直接原因是什么 (2) 根因是什么 (3) 用户现在该怎么做。缺任何一个都不算排查完成。
404. **构建/部署类失败优先看完整日志**——不要只看前 200 字符就下结论。日志被截断时，去源头（终端、容器、文件）拿完整版本。
41 
42### 反例
43 
44```
45❌ "ARM 上无法安装旧版 Chromium，这是平台限制"（停在解释层，没给方案）
46❌ "Docker Hub 网络超时，重试即可"（没排查为什么超时，没加预防措施）
47❌ 日志显示 #2 [internal] load metadata for 就截断了，直接猜"网络问题"（没拿完整日志）
48```
49 
50### 正例
51 
52```
53✅ "ARM 没有原生 Chrome 135 → 但可以用 amd64 官方镜像 + --platform=linux/amd64 构建 → 代价是运行慢一些"
54✅ "Docker metadata 拉取超时 → 根因是 buildkit 每次都校验远程 → 修法：构建前先 docker pull 刷新本地缓存"
55✅ 日志截断 → 去终端/DB 拿完整 build_log → 定位到真正的错误行
56```
57 
58## 反例
59 
60```
61❌ "当前代码里没有看到睡眠唤醒的实现"（没有任何搜索动作）
62❌ "项目中未见分辨率调整的相关配置"（没有 grep 过）
63❌ "这个功能还没有实现"（没有查证就下结论）
64```
65 
66## 正例
67 
68```
69✅ 先 grep "sleep"、"wake"、"suspend"、"hibernate" → 找到/没找到 → 再下结论
70✅ 先 glob "**/*resolution*" + grep "resolution" → 确认无结果 → 说明搜索范围后给出结论
71✅ 不确定功能名 → 用 SemanticSearch 按语义搜 → 根据结果回答
72```
73