77 lines
3.2 KiB
Markdown
77 lines
3.2 KiB
Markdown
- [一个CLAUDE.md霸榜GitHub第一！蒸馏自Karpathy，6万码农抄作业](https://mp.weixin.qq.com/s/iHFAIbedBdVvWuxR3ENsIg)
|
||
- https://github.com/forrestchang/andrej-karpathy-skills/blob/main/CLAUDE.md
|
||
|
||
**权衡：** 这些准则更偏向谨慎而不是速度。对于琐碎任务，请自行判断。
|
||
|
||
## 1. 编码前先思考
|
||
|
||
[](https://github.com/vtroisWhite/andrej-karpathy-skills/blob/main/CLAUDE.zh.md#1-%E7%BC%96%E7%A0%81%E5%89%8D%E5%85%88%E6%80%9D%E8%80%83)
|
||
|
||
**不要假设。不要掩饰困惑。明确呈现权衡。**
|
||
|
||
在实现之前：
|
||
|
||
- 明确写出你的假设。如果不确定，就提问。
|
||
- 如果存在多种解释，先把它们列出来，不要默默自行选择。
|
||
- 如果有更简单的方法，就直接指出来。在有必要时提出异议。
|
||
- 如果有不清楚的地方，就停下来。说清楚困惑点，并提问。
|
||
|
||
## 2. 简单优先
|
||
|
||
[](https://github.com/vtroisWhite/andrej-karpathy-skills/blob/main/CLAUDE.zh.md#2-%E7%AE%80%E5%8D%95%E4%BC%98%E5%85%88)
|
||
|
||
**只写解决问题所需的最少代码。不做任何预设性扩展。**
|
||
|
||
- 不要加入超出需求范围的功能。
|
||
- 不要为一次性代码做抽象。
|
||
- 不要加入未被要求的“灵活性”或“可配置性”。
|
||
- 不要为不可能发生的场景写错误处理。
|
||
- 如果你写了 200 行，但 50 行就够，就重写。
|
||
|
||
问问自己：“一个资深工程师会认为这太复杂了吗？” 如果答案是会，那就继续简化。
|
||
|
||
## 3. 外科手术式修改
|
||
|
||
[](https://github.com/vtroisWhite/andrej-karpathy-skills/blob/main/CLAUDE.zh.md#3-%E5%A4%96%E7%A7%91%E6%89%8B%E6%9C%AF%E5%BC%8F%E4%BF%AE%E6%94%B9)
|
||
|
||
**只改必须改的内容。只清理你自己造成的问题。**
|
||
|
||
编辑现有代码时：
|
||
|
||
- 不要“顺手优化”相邻代码、注释或格式。
|
||
- 不要重构没有坏掉的部分。
|
||
- 保持现有风格，即使你个人会写成别的样子。
|
||
- 如果发现无关的死代码，可以指出，但不要删除。
|
||
|
||
当你的改动产生遗留项时：
|
||
|
||
- 删除那些因你的修改而变成未使用的 import、变量或函数。
|
||
- 不要删除原本就存在的死代码，除非被明确要求。
|
||
|
||
检验标准：每一行改动都应当能直接追溯到用户请求。
|
||
|
||
## 4. 目标驱动执行
|
||
|
||
[](https://github.com/vtroisWhite/andrej-karpathy-skills/blob/main/CLAUDE.zh.md#4-%E7%9B%AE%E6%A0%87%E9%A9%B1%E5%8A%A8%E6%89%A7%E8%A1%8C)
|
||
|
||
**先定义成功标准，再循环推进，直到验证通过。**
|
||
|
||
把任务转换成可验证的目标：
|
||
|
||
- “添加校验” → “先为非法输入写测试，再让测试通过”
|
||
- “修复这个 bug” → “先写能复现它的测试，再让测试通过”
|
||
- “重构 X” → “确保改动前后测试都通过”
|
||
|
||
对于多步骤任务，先给出简短计划：
|
||
|
||
```
|
||
1. [步骤] → 验证：[检查项]
|
||
2. [步骤] → 验证：[检查项]
|
||
3. [步骤] → 验证：[检查项]
|
||
```
|
||
|
||
强有力的成功标准能让你独立闭环推进。弱成功标准（“把它弄好”）则会不断需要额外澄清。
|
||
|
||
---
|
||
|
||
**如果这些准则正在发挥作用，你会看到：** diff 中不必要的改动更少，因为过度复杂而返工的次数更少，而且澄清性问题会出现在实现之前，而不是出错之后。 |