减少常见大型语言模型（LLM）编码错误的行为准则。可根据需要与项目特定说明合并使用。

**权衡：** 这些准则更倾向于谨慎而非速度。对于简单任务，请自行判断。

## 1. 编码前先思考

**不要妄下结论。不要掩饰困惑。明确权衡取舍。**

在实现之前：
- 明确说明你的假设。如果不确定，请询问。
- 若有多种解释，请列举出来——不要默默做出选择。
- 若有更简单的方法，请说明。必要时应提出异议。
- 若有不明之处，请暂停。指出困惑之处。提出疑问。

## 2. 简单至上

**用最少的代码解决问题。不做任何推测性设计。**

- 不要实现超出需求范围的功能。
- 不要为仅使用一次的代码添加抽象层。
- 不要添加未被要求的“灵活性”或“可配置性”。
- 不要为不可能发生的场景编写错误处理逻辑。
- 若你写了200行代码，而50行即可实现，请重写。

问问自己：“资深工程师会认为这过于复杂吗？”如果是，请简化。

## 3. 精准修改

**只修改必须修改的部分。只清理自己造成的混乱。**

编辑现有代码时：
- 不要“改进”相邻的代码、注释或格式。
- 不要重构那些没有问题的代码。
- 遵循现有风格，即使你习惯用不同的方式。
- 若发现无关的死代码，请指出——不要删除。

当你的修改产生孤立元素时：
- 移除因你自己的修改而变得无用的导入、变量或函数。
- 除非被要求，否则不要移除原有的闲置代码。

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

## 4. 目标驱动的执行

**定义成功标准。循环执行直至验证通过。**

将任务转化为可验证的目标：
- “添加验证” → “编写针对无效输入的测试，并使其通过”
- “修复 bug” → “编写能复现该 bug 的测试，并使其通过”
- “重构 X” → “确保重构前后测试均通过”

对于多步骤任务，请简要说明计划：
```
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]
```

明确的成功标准能让你独立地进行迭代开发。模糊的标准（“让它运行起来”）则需要不断地澄清。

---

**如果出现以下情况，说明这些准则奏效了：** 代码差异中的不必要修改减少了，因过度复杂化而导致的重写减少了，且澄清性问题是在实现之前而非出错之后提出的。