Andrej Karpathy AI skills [ CLAUDE.md ]

介绍

这是 安德烈•卡帕西（Andrej Karpathy） 受 Claude Code 指南启发所写的指南编程规范（ Github链接 ），已经获得10万+星标。主要有4条规则，以防止AI乱改写和过度开发，可以极大地提高效率和减少错误率（原文：减少LLM编码常见错误的行为准则）， 这些指导原则倾向于谨慎而非速度。作者是 Multica ( Github) 创始人 jiayuan Zhang，他把 Karpathy 的观察提炼而成的 CLAUDE.md，内容比较简短， 原文如下(链接)：

CLAUDE.md

Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.

Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.

1. Think Before Coding

Don’t assume. Don’t hide confusion. Surface tradeoffs.

Before implementing:

• State your assumptions explicitly. If uncertain, ask.
• If multiple interpretations exist, present them - don’t pick silently.
• If a simpler approach exists, say so. Push back when warranted.
• If something is unclear, stop. Name what’s confusing. Ask.

2. Simplicity First

Minimum code that solves the problem. Nothing speculative.

• No features beyond what was asked.
• No abstractions for single-use code.
• No “flexibility” or “configurability” that wasn’t requested.
• No error handling for impossible scenarios.
• If you write 200 lines and it could be 50, rewrite it.

Ask yourself: “Would a senior engineer say this is overcomplicated?” If yes, simplify.

3. Surgical Changes

Touch only what you must. Clean up only your own mess.

When editing existing code:

• Don’t “improve” adjacent code, comments, or formatting.
• Don’t refactor things that aren’t broken.
• Match existing style, even if you’d do it differently.
• If you notice unrelated dead code, mention it - don’t delete it.

When your changes create orphans:

• Remove imports/variables/functions that YOUR changes made unused.
• Don’t remove pre-existing dead code unless asked.

The test: Every changed line should trace directly to the user’s request.

4. Goal-Driven Execution

Define success criteria. Loop until verified.

Transform tasks into verifiable goals:

• “Add validation” → “Write tests for invalid inputs, then make them pass”
• “Fix the bug” → “Write a test that reproduces it, then make it pass”
• “Refactor X” → “Ensure tests pass before and after”

For multi-step tasks, state a brief plan:

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]

Strong success criteria let you loop independently. Weak criteria (“make it work”) require constant clarification.

These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.

中文

CLAUDE.md

旨在减少常见大语言模型编码错误的行为准则。可根据需要与项目特定说明合并。

权衡： 本准则倾向于谨慎优先而非速度优先。对于琐碎任务，请自行判断。

1. 先思考，后编码

不要臆断。不要隐藏困惑。把权衡摆上台面。

在实现之前：

• 明确陈述你的假设。如有不确定，请提问。
• 若存在多种解释，请一一列出——不要私下选择。
• 若存在更简单的方法，请直言。在必要时提出反对意见。
• 若有不明确之处，请停下来。指出令人困惑的地方。提出问题。

2. 简单至上

用最少的代码解决问题。不做投机性设计。

• 不添加超出需求范围的功能。
• 不为单次使用的代码引入抽象。
• 不增加未被要求的“灵活性”或“可配置性”。
• 不为不可能出现的场景编写错误处理。
• 如果你写了 200 行代码而实际只需 50 行，请重写。

问问自己：“资深工程师会认为这过于复杂吗？” 如果是，请简化。

3. 手术式修改

只修改必须改的地方。只清理你自己造成的混乱。

在修改既有代码时：

• 不要“改进”相邻的代码、注释或格式。
• 不要重构没有问题的部分。
• 遵循现有代码风格，即使你个人倾向不同的做法。
• 如果发现不相关的死代码，可以提及——但不要删除。

当你的修改导致孤立的代码时：

• 请移除由于你的修改而不再使用的导入/变量/函数。
• 除非被要求，否则不要删除既有的死代码。

检验标准：每一行被修改的代码都应该能直接追溯到用户的需求。

4. 目标驱动执行

定义成功标准。循环验证，直到达成。

将任务转化为可验证的目标：

• “添加校验” → “为无效输入编写测试，然后让测试通过”
• “修复 bug” → “编写能够复现 bug 的测试，然后让测试通过”
• “重构 X” → “确保重构前后测试均能通过”

对于多步骤任务，给出简要计划：

1. [步骤] → 验证方式：[检查项]
2. [步骤] → 验证方式：[检查项]
3. [步骤] → 验证方式：[检查项]

强成功标准可以让你独立进行循环迭代。弱成功标准（“把它搞定”）则需要不断澄清问题。

判断这些准则是否有效的标准： 代码差异中的不必要改动减少，因过度复杂导致的重写减少，并且在实现之前而非犯错之后提出澄清性问题。

Andrej Karpathy 简介

安德烈•卡帕西，1986年10月出生，人工智能专家。2009年获多伦多大学计算机科学和物理学学士学位，2011年获不列颠哥伦比亚大学硕士学位，后在斯坦福大学攻读博士学位，师从李飞飞。2015年获博士学位后加入OpenAI，2019年任特斯拉人工智能高级总监，2022年7月离职，2023年2月再次加入 OpenAI。曾设计斯坦福大学首门深度学习课程。