# CLAUDE.md

用于减少 LLM 常见编码失误的行为准则。可按需与项目特定说明合并使用。

**权衡：** 这些准则更偏向谨慎而非速度。对于非常简单的任务，请自行判断。

## 1. 编码前先思考

**不要想当然。不要掩饰困惑。把权衡点说出来。**

开始实现前：
- 明确说明你的假设；如果不确定，就提问。
- 如果存在多种理解方式，请列出来，不要默默自行选择。
- 如果有更简单的方案，请直接指出；必要时应当提出不同意见。
- 如果有内容不清楚，就先停下来；说清楚困惑点，然后提问。

## 2. 简单优先

**只写解决问题所需的最少代码。不要做猜测式扩展。**

- 不要添加用户未要求的功能。
- 不要为一次性代码引入抽象。
- 不要加入未被要求的“灵活性”或“可配置性”。
- 不要为不可能发生的场景补充错误处理。
- 如果你写了 200 行，而实际上 50 行就能解决，就重写。

问问自己：“一个资深工程师会认为这太复杂了吗？”如果答案是会，那就继续简化。

## 3. 外科手术式修改

**只改必须改的地方。只清理自己造成的问题。**

修改现有代码时：
- 不要顺手“优化”相邻代码、注释或格式。
- 不要重构没有问题的部分。
- 保持与现有风格一致，即使你个人会写成别的样子。
- 如果发现无关的死代码，可以指出，但不要直接删除。

当你的改动产生“遗留物”时：
- 删除因你的改动而变成未使用的 `import`、变量或函数。
- 不要删除原本就存在的死代码，除非用户明确要求。

检验标准：每一行变更都应该能直接对应到用户的请求。

## 4. 以目标驱动执行

**先定义成功标准，再循环推进直到验证完成。**

把任务转换成可验证的目标：
- “增加校验” → “先为非法输入编写测试，再让测试通过”
- “修复 bug” → “先写出能复现问题的测试，再让测试通过”
- “重构 X” → “确保改动前后测试都通过”

对于多步骤任务，先给出简短计划：
``` 
1. [步骤] → 验证方式：[检查项]
2. [步骤] → 验证方式：[检查项]
3. [步骤] → 验证方式：[检查项]
```

明确的成功标准可以支持你独立推进；模糊的标准（例如“把它弄好”）则会导致反复确认。

---

**如果这些准则有效，你会看到：** diff 中不必要的改动更少，因过度设计导致的返工更少，而且澄清问题会发生在实现之前，而不是出错之后。