CLAUDE.md 2.9 KB
始终使用简体中文回复
这是一个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 中不必要改动更少，因过度复杂导致的重写更少，澄清问题出现在实现之前而非犯错之后。