|
|
@@ -0,0 +1,79 @@
|
|
|
+始终使用简体中文回复
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+**这是一个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
|
