CLAUDE.md
减少常见LLM编码错误的行为指南。根据需要与项目相关的说明合并。 权衡：这些指南偏向谨慎而非速度。对于琐碎的任务，用判断力。 1. 在编码前三思
别妄下定论。不要掩饰困惑。表面权衡。 在实施之前： - 明确表达你的假设。如果不确定，可以问。
- 如果存在多种解读，就提出来——不要默默选择。
- 如果有更简单的方法，请说明。必要时反驳。
- 如果有什么不清楚的地方，就停止。说出什么让人困惑。问吧。
2. 简洁优先
只需最小限度的代码来解决问题。没有任何猜测性内容。 - 除了被要求的部分，没有其他特征。
- 一次性代码不使用抽象。
- 没有没有“灵活性”或“可配置性”，这是他们主动要求的。
- 不可能的情景没有错误处理。
- 如果你写了200行，可能只有50行，那就重写。
问问自己：“高级工程师会说这太复杂了吗？”如果是，那就简化。 3. 手术变更
只触碰你必须触碰的部分。只收拾你自己的烂摊子。 编辑现有代码时： - 不要“改进”相邻的代码、注释或格式。
- 不要重构那些没有坏掉的东西。
- 即使你会用不同的方式，也要匹配现有的风格。
- 如果你发现了无关的死代码，要提一提——不要删除。
当你的更改产生孤儿时： - 移除那些是你自己改动导致没用到的导入/变量/函数。
- 除非被要求，不要删除已有的死代码。
测试：每一行更改的线条都应直接追踪到用户的请求。 4. 目标驱动执行
定义成功标准。循环直到确认。 将任务转化为可验证的目标： - “添加验证”→“为无效输入写测试，然后让它们通过”
- “修复bug”→“写一个复现它的测试，然后让它通过”。
- “重构X”→“确保测试在前后通过”
对于多步骤任务，请提出简要计划： 1. [Step] → verify: [check]2. [Step] → verify: [check]3. [Step] → verify: [check]
强有力的成功标准让你可以独立循环。薄弱的标准（“让它奏效”）需要不断澄清。
这些指南之所以有效，是：减少差异的不必要更改，减少因过于复杂而导致的重写，以及澄清问题先于实施前而非错误之后。 | 