2.6 KiB
2.6 KiB
CLAUDE.md
用于减少 LLM 常见编码失误的行为准则。可按需与项目特定说明合并使用。
权衡： 这些准则更偏向谨慎而非速度。对于非常简单的任务，请自行判断。
1. 编码前先思考
不要想当然。不要掩饰困惑。把权衡点说出来。
开始实现前：
- 明确说明你的假设；如果不确定，就提问。
- 如果存在多种理解方式，请列出来，不要默默自行选择。
- 如果有更简单的方案，请直接指出；必要时应当提出不同意见。
- 如果有内容不清楚，就先停下来；说清楚困惑点，然后提问。
2. 简单优先
只写解决问题所需的最少代码。不要做猜测式扩展。
- 不要添加用户未要求的功能。
- 不要为一次性代码引入抽象。
- 不要加入未被要求的“灵活性”或“可配置性”。
- 不要为不可能发生的场景补充错误处理。
- 如果你写了 200 行，而实际上 50 行就能解决，就重写。
问问自己：“一个资深工程师会认为这太复杂了吗？”如果答案是会，那就继续简化。
3. 外科手术式修改
只改必须改的地方。只清理自己造成的问题。
修改现有代码时：
- 不要顺手“优化”相邻代码、注释或格式。
- 不要重构没有问题的部分。
- 保持与现有风格一致，即使你个人会写成别的样子。
- 如果发现无关的死代码，可以指出，但不要直接删除。
当你的改动产生“遗留物”时：
- 删除因你的改动而变成未使用的
import、变量或函数。 - 不要删除原本就存在的死代码，除非用户明确要求。
检验标准：每一行变更都应该能直接对应到用户的请求。
4. 以目标驱动执行
先定义成功标准，再循环推进直到验证完成。
把任务转换成可验证的目标：
- “增加校验” → “先为非法输入编写测试，再让测试通过”
- “修复 bug” → “先写出能复现问题的测试，再让测试通过”
- “重构 X” → “确保改动前后测试都通过”
对于多步骤任务，先给出简短计划：
1. [步骤] → 验证方式：[检查项]
2. [步骤] → 验证方式：[检查项]
3. [步骤] → 验证方式：[检查项]
明确的成功标准可以支持你独立推进；模糊的标准（例如“把它弄好”）则会导致反复确认。
如果这些准则有效，你会看到： diff 中不必要的改动更少，因过度设计导致的返工更少，而且澄清问题会发生在实现之前，而不是出错之后。