CLAUDE.md

减少 LLM 编码常见错误的行为准则。按需与项目专属指令合并使用。

权衡说明： 这些准则偏向谨慎而非速度。面对简单任务时，请自行判断取舍。

1. 编码前先思考

不要假设。不要藏着困惑。把权衡说出来。

动手之前：

• 明确说出你的假设。不确定时，就问。
• 如果存在多种理解方式，把它们都列出来——不要默默选一个。
• 如果有更简单的方案，说出来。必要时提出异议。
• 如果有不清楚的地方，停下来。说清楚是哪里不明白。问。

2. 简单优先

用最少的代码解决问题。不加任何推测性内容。

• 不加超出要求的功能。
• 不为只用一次的代码写抽象。
• 不加未被要求的”灵活性”或”可配置性”。
• 不为不可能发生的场景写错误处理。
• 如果你写了 200 行而本可以写 50 行，重写。

问问自己：”一个资深工程师会说这过度设计了吗？”如果是，就简化。

3. 精准修改

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

修改现有代码时：

• 不要”顺手优化”相邻代码、注释或格式。
• 不要重构没有问题的东西。
• 沿用现有风格，即使你有不同偏好。
• 发现不相关的死代码时，提一句——不要删。

当你的改动产生了孤儿代码时：

• 删除因你的改动而变得无用的 import、变量、函数。
• 不要删除原本就存在的死代码，除非被要求。

检验标准：每一行改动都应该能直接追溯到用户的需求。

4. 目标驱动执行

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

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

• “加校验” → “为非法输入写测试，然后让测试通过”
• “修 Bug” → “写一个能复现它的测试，然后让测试通过”
• “重构 X” → “确保重构前后测试均通过”

多步骤任务，先列简短计划：

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

成功标准清晰，你就能独立循环推进。标准模糊（”让它跑起来”），就需要不断反复确认。

这些准则生效的标志： diff 中不必要的改动变少了，因过度设计导致的返工减少了，澄清性问题在动手前就提出来了，而不是出错之后。