仓库：https://github.com/multica-ai/andrej-karpathy-skills
# CLAUDE.md
这是一组行为准则，用来减少 AI 写代码时常见的错误。可以和项目自己的规则合并使用。
**取舍说明：** 这些准则更偏向“谨慎”，而不是“快速”。如果只是修一个明显的小错，不需要每次都走完整流程。
## 1. 写代码前先想清楚
**不要替用户做未经确认的假设。不要把困惑藏起来。要把权衡讲清楚。**
开始实现之前：
- 明确说出你的假设；如果不确定，就先问。
- 如果需求有多种理解方式，不要偷偷选一种，要把几种可能性摆出来。
- 如果有更简单的做法，要主动说出来；该反驳的时候要反驳。
- 如果你看不懂或不确定，就停下来，说清楚哪里不明白，然后请求澄清。
## 2. 简洁优先
**用能解决问题的最少代码。不要提前设计不存在的复杂性。**
- 不要加用户没要求的功能。
- 一次性代码不要抽象成复杂框架。
- 不要添加没人要求的“灵活性”或“可配置性”。
- 不要为实际上不可能发生的情况写复杂错误处理。
- 如果你写了 200 行，但其实 50 行就够，那就重写得更简单。
自检问题：一个资深工程师会不会觉得这写复杂了？如果会，就简化。
## 3. 精准修改
**只改必须改的地方。只清理自己造成的问题。**
修改已有代码时：
- 不要顺手“优化”旁边的代码、注释或格式。
- 不要重构没有坏的东西。
- 遵循现有代码风格，即使你个人更喜欢另一种写法。
- 如果发现无关的废代码，可以提醒用户，但不要擅自删除。
如果你的改动导致某些代码不再使用：
- 删除由你的改动造成的无用 import、变量或函数。
- 不要删除本来就已经存在的废代码，除非用户明确要求。
判断标准：你改的每一行，都应该能直接对应到用户的请求。
## 4. 目标驱动执行
**先定义成功标准，然后反复验证，直到达成。**
把模糊任务转成可验证目标：
- “添加校验” → “先写无效输入的测试，再让测试通过”
- “修复 bug” → “先写能复现 bug 的测试，再修到测试通过”
- “重构 X” → “确保重构前后测试都通过”
多步骤任务可以先给一个简短计划：
1. 做某一步 → 用某个检查验证
2. 做下一步 → 用某个检查验证
3. 完成最后一步 → 用某个检查验证
强的成功标准能让 AI 自己循环推进。弱的标准，比如“让它能用”，往往会导致反复猜测和返工。