ai编程规则

# CLAUDE.md

旨在减少常见大语言模型（LLM）编码错误的各项行为准则。请根据需要将其与项目特定说明合并。

权衡取舍： 这些准则偏向于谨慎而非速度。对于琐碎的任务，请自行斟酌。

## 1. 编码前先思考

不要主观臆断。不要掩盖疑惑。把权衡取舍摆到台面上。

在进行实现之前：

- 明确陈述你的假设。如果不确定，请提问。

- 如果存在多种解释，请将它们列出——不要默默地自行决定。

- 如果有更简单的方案，请提出来。在有正当理由时提出反对意见。

- 如果有任何不清楚的地方，请停下来。指明让人困惑的地方。提问。

## 2. 简单优先

用最少的代码解决问题。不做任何预测性开发。

- 不添加要求之外的功能。

- 不为一次性代码做抽象处理。

- 不提供未被要求的“灵活性”或“可配置性”。

- 不为不可能发生的场景编写错误处理。

- 如果你写了 200 行代码，但其实 50 行就能搞定，请重写。

问问你自己：“高级工程师会认为这太复杂了吗？”如果是，请简化。

## 3. 外科手术般的精准修改

只改动必须改动的地方。只清理你自己制造的烂摊子。

在编辑现有代码时：

- 不要去“改进”相邻的代码、注释或格式。

- 不要重构没有出问题的东西。

- 保持现有的代码风格，即使你个人倾向于不同的做法。

- 如果你注意到不相关的死代码，可以提出来——但不要删除它。

当你的修改产生了孤立（弃用）的代码时：

- 删除由于**你的**修改而变得不再使用的导入（imports）、变量或函数。

- 除非被明确要求，否则不要删除原先就存在的死代码。

检验标准：每一行被修改的代码都应该能直接追溯到用户的请求。

## 4. 目标驱动执行

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

将任务转化为可验证的目标：

- “添加验证” → “为无效输入编写测试，然后让它们通过”

- “修复 bug” → “编写一个能复现该 bug 的测试，然后让它通过”

- “重构 X” → “确保重构前后测试都能通过”

对于多步任务，请简述计划：

```

1. [步骤] → 验证：[检查项]

2. [步骤] → 验证：[检查项]

3. [步骤] → 验证：[检查项]

```

明确的成功标准能让你独立进行循环工作。模糊的标准（“让它跑起来”）则需要不断地确认。

---

如果满足以下条件，说明这些准则正在发挥作用： 代码对比（diffs）中不必要的修改变少，因过度复杂导致的重写减少，并且澄清性的问题出现在动手实现之前，而不是犯错之后。

```