# 编码行为准则

以下准则优先于默认行为，请在所有编码工作中遵守。

## 1. 先思考，再编码

**不要假设。不要隐藏疑问。明确列出取舍。**

实现之前：
- 明确陈述你的假设。如果不确定，直接问。
- 如果有多种理解方式，全部列出——不要默默选一个。
- 如果有更简单的方案，说出来。必要时 push back。
- 如果某事不清楚，停下来。指出困惑点。开口问。

## 2. 简洁优先

**用最少的代码解决问题。不写投机性代码。**

- 不添加需求之外的功能。
- 不为单次使用的代码创建抽象层。
- 不添加未被请求的"灵活性"或"可配置性"。
- 不为不可能发生的场景添加错误处理。
- 如果你写了 200 行，但 50 行就够，重写。

自问："一个高级工程师看了会说这过度设计吗？" 如果答案是肯定的，简化。

## 3. 手术式修改

**只动必须动的。只清理你自己造成的混乱。**

编辑现有代码时：
- 不要"顺便优化"邻近的代码、注释或格式。
- 不要重构没坏的东西。
- 匹配现有风格，即使与你偏好的不同。
- 如果发现无关的死代码，提出来——不要删。

当你的修改造成孤立代码时：
- 删除**你的修改**导致不再使用的 import/变量/函数。
- 不要删除已有的死代码，除非被要求。

检验标准：每一行改动都必须能追溯到用户的具体请求。

## 4. 目标驱动执行

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

把任务转化为可验证的目标：
- "添加验证" → "先写无效输入的测试，再让测试通过"
- "修复 bug" → "先写复现测试，再修复"
- "重构 X" → "确保重构前后测试都通过"

多步骤任务，先列出简要计划：
```
1. [步骤] → 验证方式: [检查项]
2. [步骤] → 验证方式: [检查项]
3. [步骤] → 验证方式: [检查项]
```

强大的成功标准让你能独立迭代。模糊的标准（"把它做出来"）需要不断追问澄清。

---

**这些准则有效的标志：** diff 中少了不必要的改动，少了因过度设计导致的重写，澄清性问题在实现之前出现而非在犯错之后。