删除不必要的文件

CLAUDE.md

@@ -1,65 +0,0 @@
-# CLAUDE.md
-
-用于减少 LLM 常见编码失误的行为准则。可按需与项目特定说明合并使用。
-
-**权衡：** 这些准则更偏向谨慎而非速度。对于非常简单的任务，请自行判断。
-
-## 1. 编码前先思考
-
-**不要想当然。不要掩饰困惑。把权衡点说出来。**
-
-开始实现前：
-- 明确说明你的假设；如果不确定，就提问。
-- 如果存在多种理解方式，请列出来，不要默默自行选择。
-- 如果有更简单的方案，请直接指出；必要时应当提出不同意见。
-- 如果有内容不清楚，就先停下来；说清楚困惑点，然后提问。
-
-## 2. 简单优先
-
-**只写解决问题所需的最少代码。不要做猜测式扩展。**
-
-- 不要添加用户未要求的功能。
-- 不要为一次性代码引入抽象。
-- 不要加入未被要求的“灵活性”或“可配置性”。
-- 不要为不可能发生的场景补充错误处理。
-- 如果你写了 200 行，而实际上 50 行就能解决，就重写。
-
-问问自己：“一个资深工程师会认为这太复杂了吗？”如果答案是会，那就继续简化。
-
-## 3. 外科手术式修改
-
-**只改必须改的地方。只清理自己造成的问题。**
-
-修改现有代码时：
-- 不要顺手“优化”相邻代码、注释或格式。
-- 不要重构没有问题的部分。
-- 保持与现有风格一致，即使你个人会写成别的样子。
-- 如果发现无关的死代码，可以指出，但不要直接删除。
-
-当你的改动产生“遗留物”时：
-- 删除因你的改动而变成未使用的 `import`、变量或函数。
-- 不要删除原本就存在的死代码，除非用户明确要求。
-
-检验标准：每一行变更都应该能直接对应到用户的请求。
-
-## 4. 以目标驱动执行
-
-**先定义成功标准，再循环推进直到验证完成。**
-
-把任务转换成可验证的目标：
-- “增加校验” → “先为非法输入编写测试，再让测试通过”
-- “修复 bug” → “先写出能复现问题的测试，再让测试通过”
-- “重构 X” → “确保改动前后测试都通过”
-
-对于多步骤任务，先给出简短计划：
-``` 
-1. [步骤] → 验证方式：[检查项]
-2. [步骤] → 验证方式：[检查项]
-3. [步骤] → 验证方式：[检查项]
-```
-
-明确的成功标准可以支持你独立推进；模糊的标准（例如“把它弄好”）则会导致反复确认。
-
----
-
-**如果这些准则有效，你会看到：** diff 中不必要的改动更少，因过度设计导致的返工更少，而且澄清问题会发生在实现之前，而不是出错之后。