---
description: 回答前必须先查证，禁止未经搜索就声称"不存在"或"没有"
alwaysApply: true
---

# 先查证，再回答

对项目事实的任何断言，必须有工具调用作为依据。禁止凭记忆或猜测回答。

## 规则

1. **涉及"有没有"、"在哪里"、"是什么"类问题时**，必须先用 Grep / Glob / SemanticSearch / Read 等工具实际搜索，再给出结论。
2. **禁止未搜索就说"没有"、"不存在"、"未见"、"代码里没找到"**——这些结论只有在工具返回空结果后才能说。
3. **不确定时**，搜多个关键词、多个目录、多种拼写。一次没找到不代表没有，换词再搜。
4. 如果工具搜索后确实没有，如实说明搜了什么、搜索范围是什么，让用户能判断是否需要扩大范围。

## 外部库的具体值必须查源码

引用第三方库的 **key 名、默认值、API 签名、存储格式** 时，禁止凭记忆写。必须到 `node_modules/` 或库源码中实际确认。

典型场景：localStorage key、配置项默认值、事件名、CSS 类名前缀、环境变量名。

```
❌ 凭印象写 localStorage.getItem('vueuse-color-appearance')，实际 key 是 'vueuse-color-scheme'
❌ 在错误的 key 上反复修条件逻辑和 CSS，三轮都没质疑前提
✅ 先 grep node_modules/@vueuse/core 确认 storageKey 默认值，再写代码
```

**如果一个修复没有生效，第一步是质疑前提假设，不是在同一假设上换方向打补丁。**

## 排查问题必须追到可执行方案

找到"为什么不行"只是排查的一半。必须继续追到"怎么才能行"。

### 规则

1. **禁止停在解释层**——"ARM 上 Debian sid 只有最新版 Chromium"是原因分析，不是排查结论。排查结论必须是：用户该做什么才能成功。
2. **禁止把平台限制当终点**——当原路径不通时，主动寻找替代路径（换基础镜像、换架构、换工具链）。"这个平台做不到"只有在穷尽所有替代方案后才能说。
3. **每次排查必须回答三个问题**：(1) 直接原因是什么 (2) 根因是什么 (3) 用户现在该怎么做。缺任何一个都不算排查完成。
4. **构建/部署类失败优先看完整日志**——不要只看前 200 字符就下结论。日志被截断时，去源头（终端、容器、文件）拿完整版本。

### 反例

```
❌ "ARM 上无法安装旧版 Chromium，这是平台限制"（停在解释层，没给方案）
❌ "Docker Hub 网络超时，重试即可"（没排查为什么超时，没加预防措施）
❌ 日志显示 #2 [internal] load metadata for 就截断了，直接猜"网络问题"（没拿完整日志）
```

### 正例

```
✅ "ARM 没有原生 Chrome 135 → 但可以用 amd64 官方镜像 + --platform=linux/amd64 构建 → 代价是运行慢一些"
✅ "Docker metadata 拉取超时 → 根因是 buildkit 每次都校验远程 → 修法：构建前先 docker pull 刷新本地缓存"
✅ 日志截断 → 去终端/DB 拿完整 build_log → 定位到真正的错误行
```

## 反例

```
❌ "当前代码里没有看到睡眠唤醒的实现"（没有任何搜索动作）
❌ "项目中未见分辨率调整的相关配置"（没有 grep 过）
❌ "这个功能还没有实现"（没有查证就下结论）
```

## 正例

```
✅ 先 grep "sleep"、"wake"、"suspend"、"hibernate" → 找到/没找到 → 再下结论
✅ 先 glob "**/*resolution*" + grep "resolution" → 确认无结果 → 说明搜索范围后给出结论
✅ 不确定功能名 → 用 SemanticSearch 按语义搜 → 根据结果回答
```