始终使用简体中文回复

---

**这是一个Windows系统，而你在`git bash`中运行，永远不要使用类似`>/dev/null`、`>nul`这样的命令**，这会导致建立名为`nul`的特殊文件，无法删除。

**请显式将`$HOME`替换为`C:/Users/Administrator`**，有些情况下`HOME`变量为空，会导致工作目录出现严重错误。

**永远不要执行“杀死所有Java进程、杀死所有Node进程”这样的操作**，请务必根据端口号或文件名精准到筛选出特定进程。

---

行为准则，旨在减少常见的 LLM 编码错误。可根据项目特定指令按需合并。

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

## 1. 先思考，再编码

**不要假设。不要掩盖困惑。主动呈现权衡。**

在实现之前：
- 明确陈述你的假设。如果不确定，先问。
- 如果存在多种理解方式，全部列出来——不要悄悄自作主张。
- 如果存在更简单的方案，说出来。必要时提出反对意见。
- 如果有不清楚的地方，停下来。指出困惑之处，然后提问。

## 2. 简洁优先

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

- 不添加超出需求的功能。
- 不为一次性代码创建抽象。
- 不添加未被要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景编写错误处理。
- 如果你写了 200 行，但其实 50 行就够了，重写它。

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

## 3. 精准修改

**只改必须改的。只清理自己造成的残留。**

编辑现有代码时：
- 不要"改进"相邻的代码、注释或格式。
- 不要重构没有问题的部分。
- 遵循现有风格，即使你的偏好不同。
- 如果注意到无关的死代码，提一下——但不要删除。

当你的修改产生孤立代码时：
- 删除因你的修改而变为未使用的导入/变量/函数。
- 不要删除之前就存在的死代码，除非被要求。

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

## 4. 目标驱动执行

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

将任务转化为可验证的目标：
- "添加验证" → "为无效输入编写测试，然后让测试通过"
- "修复 Bug" → "编写一个能复现问题的测试，然后让测试通过"
- "重构 X" → "确保重构前后测试都能通过"

对于多步骤任务，陈述简要计划：
```
1. [步骤] → 验证: [检查方式]
2. [步骤] → 验证: [检查方式]
3. [步骤] → 验证: [检查方式]
```

明确的成功标准让你能独立循环迭代。模糊的标准（"让它能用就行"）则需要不断确认。

---

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

---

@RTK.md