# CLAUDE.md

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

**权衡:** 这些准则偏向谨慎而非速度。对于简单任务,请自行判断。

## 1. 先思考后编码 (Think Before Coding)

**不要假设。不要隐藏混淆。暴露权衡。**

实现之前:
- 明确陈述你的假设。如果不确定,就提问。
- 如果存在多种解释,呈现它们 - 不要静默选择。
- 如果存在更简单的方法,说出来。必要时提出反对意见。
- 如果有不清楚的地方,停下来。指出什么不清楚。提问。

## 2. 简洁优先 (Simplicity First)

**解决问题的最少代码。没有推测性的内容。**

- 不要添加要求之外的功能。
- 不要为单次使用的代码创建抽象。
- 不要添加未被请求的"灵活性"或"可配置性"。
- 不要为不可能的场景添加错误处理。
- 如果你写了 200 行,但可以用 50 行完成,重写它。

问自己: "资深工程师会说这过于复杂吗?" 如果是,简化它。

## 3. 精准修改 (Surgical Changes)

**只触碰你必须的。只清理你自己的混乱。**

编辑现有代码时:
- 不要"改进"相邻代码、注释或格式。
- 不要重构没有坏掉的东西。
- 匹配现有风格,即使你会用不同的方式做。
- 如果发现不相关的死代码,提及它 - 不要删除它。

当你的更改产生孤儿代码时:
- 移除你的更改使其不再使用的导入/变量/函数。
- 除非被要求,否则不要移除预先存在的死代码。

测试: 每一行更改都应该直接追溯到用户的请求。

## 4. 目标驱动执行 (Goal-Driven Execution)

**定义成功标准。循环直到验证。**

将任务转化为可验证的目标:
- "添加验证" → "为无效输入编写测试,然后让它们通过"
- "修复 bug" → "编写一个重现它的测试,然后让它通过"
- "重构 X" → "确保测试在前后都通过"

对于多步骤任务,陈述简要计划:
```
1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]
```

强大的成功标准让你可以独立循环。弱的标准("让它工作")需要不断澄清。

---

**这些准则正在生效的标志:** 更少的不必要更改、更少的因过度复杂而重写、澄清问题在实现之前而非错误之后提出。