初始化项目

## 编码守则

**取舍：** 这些守则偏向谨慎而不是速度。琐碎的任务自己判断。

### 1. 动手前先想清楚

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

动手实现之前：

- 明确说出你的假设。拿不准就问。
- 存在多种理解时，把它们都摆出来 —— 不要默默挑一个。
- 有更简单的做法就说出来。该反驳的时候反驳。
- 有不清楚的地方就停下，指出是哪里让你困惑，然后问。

### 2. 简洁优先

**用能解决问题的最少代码。不做任何投机性的设计。**

- 不加要求之外的功能。
- 只用一次的代码不做抽象。
- 不加没人要求的「灵活性」或「可配置性」。
- 不为不可能发生的场景写错误处理。
- 写了 200 行、其实 50 行就够，那就重写。

问问自己：「资深工程师会不会说这写得太复杂了？」会，就简化。

### 3. 手术式修改

**只碰必须碰的。只收拾自己弄出的烂摊子。**

改现有代码时：

- 不要顺手「改进」旁边的代码、注释或格式。
- 没坏的东西不要重构。
- 沿用现有风格，哪怕你自己会换种写法。
- 注意到无关的死代码，提一句 —— 不要删。

你的改动留下孤儿时：

- 删掉因为**你的**改动而不再被用到的 import、变量、函数。
- 原本就存在的死代码，没被要求就不要删。

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

### 4. 目标驱动执行

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

把任务转成可验证的目标：

- 「加个校验」→「为非法输入写测试，再让它们通过」
- 「修这个 bug」→「写一个能复现它的测试，再让它通过」
- 「重构 X」→「确保重构前后测试都通过」

多步任务先说一个简短的计划：

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

成功标准够强，你就能自己循环推进；标准弱（「让它能跑」），就得不停地找人澄清。