sanity-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sanity Check

合理性检查

<purpose> Claude confidently builds on assumptions that turn out to be wrong. "The auth middleware probably checks X" becomes a 50-line solution for a problem that doesn't exist. This skill forces verification of key assumptions before building on them. </purpose>

<purpose> Claude常常会基于最终被证明是错误的假设展开工作。比如认为‘认证中间件可能会检查X’，进而针对一个根本不存在的问题写出50行代码的解决方案。这项技能要求你在基于假设开展工作前，先对关键假设进行验证。 </purpose>

When To Activate

何时启用

<triggers> - Using words like "probably", "likely", "I assume", "should be" - Explaining how code works without reading it - Diagnosing a bug without reproducing it - Making claims about what exists or doesn't exist - Building a solution based on inferred behavior - User asks "why is X happening?" and you're about to guess </triggers>

<triggers> - 使用了"probably"（可能）、"likely"（很可能）、"I assume"（我假设）、"should be"（应该是）这类词汇时 - 未阅读代码就解释其工作方式时 - 未复现Bug就进行诊断时 - 断言某个事物是否存在时 - 基于推断的行为构建解决方案时 - 用户询问“为什么会出现X问题？”而你准备猜测原因时 </triggers>

Instructions

操作步骤

Identify Your Assumptions

明确你的假设

Before proposing a solution, list what you're assuming:

markdown

undefined

在提出解决方案前，列出你所有的假设：

markdown

undefined

Assumptions

假设

[The function X exists and does Y]
[The error is caused by Z]
[This file is imported by W]
[The config value is set to V]

undefined

[函数X存在且实现Y功能]
[错误由Z导致]
[该文件被W导入]
[配置值被设置为V]

undefined

Verify Before Building

先验证再开展工作

<verify> For each assumption, verify it:

Assumption	Verification	Status
Function X does Y	Read the function	Verified / Wrong
Error caused by Z	Check error logs	Verified / Wrong
File imported by W	Grep for imports	Verified / Wrong

Stop if any key assumption is wrong. Don't patch - reassess. </verify>

<verify> 针对每一个假设进行验证：

假设	验证方式	状态
函数X实现Y功能	阅读函数代码	已验证 / 错误
错误由Z导致	查看错误日志	已验证 / 错误
该文件被W导入	使用Grep查找导入关系	已验证 / 错误

若任何关键假设被证明错误，请立即停止。 不要尝试修补，重新评估问题。 </verify>

Types of Assumptions

假设的类型

Existence assumptions:

"There's probably a config file for this"
"The API endpoint likely exists"
Verify:
```
find
```
,
```
grep
```
,
```
ls
```

Behavior assumptions:

"This function probably validates input"
"The middleware likely checks auth"
Verify: Read the actual code

Causation assumptions:

"The error is probably from X"
"This is likely failing because Y"
Verify: Reproduce, check logs, trace execution

State assumptions:

"The database probably has this column"
"The env var is likely set"
Verify: Check schema, check actual values

存在性假设：

"可能存在对应的配置文件"
"该API接口很可能存在"
验证方式：
```
find
```
,
```
grep
```
,
```
ls
```

行为假设：

"这个函数可能会验证输入"
"中间件很可能会检查认证信息"
验证方式：阅读实际代码

因果假设：

"错误可能来自X"
"失败很可能是因为Y"
验证方式：复现问题、查看日志、追踪执行流程

状态假设：

"数据库可能包含该字段"
"环境变量很可能已设置"
验证方式：检查数据库Schema、查看实际值

The Assumption Cascade

假设连锁反应

Wrong assumption: "Auth is handled by middleware"
    ↓
Build solution: "Just call the protected endpoint"
    ↓
Solution fails: "Auth not working"
    ↓
Wrong diagnosis: "Middleware must be misconfigured"
    ↓
Deeper hole: "Let me fix the middleware..."
    ↓
Reality: Auth was in the route handler all along

Break the cascade early. Verify before building.

错误假设："认证由中间件处理"
    ↓
构建解决方案："直接调用受保护的接口即可"
    ↓
解决方案失败："认证不生效"
    ↓
错误诊断："中间件肯定配置错误了"
    ↓
越陷越深："让我修复中间件……"
    ↓
实际情况：认证逻辑一直都在路由处理器中

尽早打破这种连锁反应，先验证再开展工作。

Output Format

输出格式

When working on non-trivial problems:

markdown

undefined

处理非简单问题时：

markdown

undefined

Sanity Check

合理性检查

Key assumptions:

[assumption] → Verified by [how]
[assumption] → Verified by [how]
[assumption] → ⚠️ NOT verified, checking...

Proceeding with: [list verified assumptions]

undefined

关键假设：

[假设内容] → 验证方式：[具体方法]
[假设内容] → 验证方式：[具体方法]
[假设内容] → ⚠️ 未验证，正在检查中……

基于以下已验证假设推进： [列出已验证的假设]

undefined

NEVER

绝对不要

Say "probably" or "likely" without then verifying
Diagnose bugs without reproducing or checking logs
Build multi-step solutions on unverified assumptions
Explain code behavior without reading the code
Assume error messages are accurate (verify root cause)

在使用"probably"（可能）或"likely"（很可能）这类词汇后不进行验证
未复现问题或查看日志就诊断Bug
基于未验证的假设构建多步骤解决方案
未阅读代码就解释其行为
假设错误信息完全准确（要验证根本原因）

ALWAYS

务必做到

List assumptions explicitly before building on them
Verify existence before assuming something exists
Read code before explaining what it does
Reproduce issues before diagnosing them
Stop and reassess when an assumption proves wrong

在基于假设开展工作前，明确列出所有假设
在假设某事物存在前先验证其真实性
在解释代码行为前先阅读代码
在诊断问题前先复现问题
当某个假设被证明错误时，停止当前工作并重新评估

Example

示例

User: "The user signup isn't sending confirmation emails"

Bad approach (assumption cascade):

"The email service probably isn't configured correctly. Let me check the SMTP settings... Actually, the email template might be wrong... Let me also check if the queue is processing..."

Good approach (sanity check):

markdown

undefined

用户： "用户注册后没有发送确认邮件"

错误做法（假设连锁反应）：

"邮件服务可能配置不正确。让我检查一下SMTP设置……其实，邮件模板可能有问题…… 我再看看队列是否在正常处理……"

正确做法（合理性检查）：

markdown

undefined

Sanity Check

合理性检查

Assumptions to verify:

Signup actually triggers email sending
Email sending code exists and is called
Email service is configured
No errors in logs

Verifying #1: Reading signup handler... Found:

sendConfirmationEmail(user)

on line 45. Verified: signup does call email function.

Verifying #2: Reading sendConfirmationEmail... Found: it calls

emailService.send()

. But wait - there's a

if (config.emailEnabled)

check on line 12.

Verifying #3: Checking config...

emailEnabled: false

in development.

Root cause found: Emails disabled in config, not a bug.


No assumption cascade. Verified each step. Found real cause.

需要验证的假设：

注册流程确实会触发邮件发送
邮件发送代码存在且被调用
邮件服务已配置
日志中无错误信息

验证假设1： 阅读注册处理器代码……发现：第45行有

sendConfirmationEmail(user)

调用。已验证：注册流程确实会调用邮件发送函数。

验证假设2： 阅读sendConfirmationEmail函数……发现：它调用了

emailService.send()

。但注意到——第12行有一个

if (config.emailEnabled)

的判断。

验证假设3： 查看配置……开发环境中

emailEnabled: false

。

找到根本原因： 配置中禁用了邮件发送，并非Bug。


没有出现假设连锁反应。每一步都进行了验证，找到了真正的问题原因。