来自 Andrej 的推文：
四个原则，集中在一个文件中，直接解决这些问题：
1. 编码前思考
不要假设。不要隐藏困惑。呈现权衡。
LLM 经常默默选择一种解释然后执行。这个原则强制明确推理：
- 明确说明假设 — 如果不确定，询问而不是猜测
- 呈现多种解释 — 当存在歧义时，不要默默选择
- 适时提出异议 — 如果存在更简单的方法，说出来
- 困惑时停下来 — 指出不清楚的地方并要求澄清
2. 简洁优先
用最少的代码解决问题。不要过度推测。
对抗过度工程的倾向：
- 不要添加要求之外的功能
- 不要为一次性代码创建抽象
- 不要添加未要求的”灵活性”或”可配置性”
- 不要为不可能发生的场景做错误处理
- 如果 200 行代码可以写成 50 行，重写它
检验标准： 资深工程师会觉得这过于复杂吗？如果是，简化。
3. 精准修改
只碰必须碰的。只清理自己造成的混乱。
编辑现有代码时：
- 不要”改进”相邻的代码、注释或格式
- 不要重构没坏的东西
- 匹配现有风格，即使你更倾向于不同的写法
- 如果注意到无关的死代码，提一下 —— 不要删除它
当你的改动产生孤儿代码时：
- 删除因你的改动而变得无用的导入/变量/函数
- 不要删除预先存在的死代码，除非被要求
检验标准： 每一行修改都应该能直接追溯到用户的请求。
4. 目标驱动执行
定义成功标准。循环验证直到达成。
将指令式任务转化为可验证的目标：
对于多步骤任务，说明一个简短的计划：
1. [步骤] → 验证: [检查] 2. [步骤] → 验证: [检查] 3. [步骤] → 验证: [检查]
强有力的成功标准让 LLM 能够独立循环执行。弱标准（“让它工作”）需要不断澄清。
选项 A：Claude Code 插件（推荐）
在 Claude Code 中，首先添加插件市场：
/plugin marketplace add forrestchang/andrej-karpathy-skills 然后安装插件：
/plugin install andrej-karpathy-skills@karpathy-skills 这会将指南安装为 Claude Code 插件，使其在你所有项目中可用。
选项 B：CLAUDE.md（按项目）
新项目：
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md 已有项目（追加）：
echo ”” >> CLAUDE.md curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md 本仓库包含一个已提交的 Cursor 项目规则 ([.cursor/rules/karpathy-guidelines.mdc](https://link.zhihu.com/?target=https%3A//github.com/forrestchang/andrej-karpathy-skills/blob/main/.cursor/rules/karpathy-guidelines.mdc))，因此在 Cursor 中打开项目时同样适用这些指南。详情请参见 CURSOR.md，包括如何在其他项目中使用该规则，以及它与 Claude Code 的关系。
如果你看到以下情况，说明这些指南正在发挥作用：
- diff 中不必要的改动更少 —— 只有请求的改动出现
- 因过度复杂而导致的重写更少 —— 代码第一次就写得简洁
- 澄清问题在实现之前提出 —— 而不是在犯错之后
- 干净、精简的 PR —— 没有顺带的重构或”改进”
来自 Andrej：
“LLM 非常擅长循环执行直到达成特定目标……不要告诉它该做什么，给它成功标准，然后看着它完成。”
“目标驱动执行”原则正是捕捉了这一点：将指令式指令转化为带有验证循环的声明式目标。
以上安装命令仅供参考, 具体的安装教程见gitHub仓库:
github.com/forrestchang/andrej-karpathy-skills
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/282632.html