80% 的数据科学家都用错了 Claude Code。

他们打开一个仓库，要求写代码，接受第一个看似合理的答案，然后纳闷为什么项目变成了一团无法维护的乱麻。

这不是 AI 工程。

这是自动化的技术债务。

Karpathy 刚刚分享了他的 CLAUDE.md 笔记。

它不是一条“提示词”。 也不是一个花哨的效率技巧。

它是阻止你的 AI 编程助手在你的代码库里乱喷垃圾的规则手册。

没有它，Claude 就会像大多数初级开发者那样：

• 先写代码，再读代码
• 靠猜测而不是调研
• 过早引入抽象
• 随便拉入依赖
• 能小改却大改
• 发布的代码看起来对，但静悄悄地出错

这就是危险所在。

AI 加速了糟糕的工程实践。

一份好的 CLAUDE.md 强制纪律：

• 先通读代码库
• 编码前先思考
• 保持改动精准
• 在实际构建前定义成功标准
• 测试行为
• 调试根本原因
• 解释改了什么以及为什么改

这是数据科学家需要理解的转变。

未来不是：“你会用 ChatGPT 吗？”

谁都会。

未来是：“你能在真实软件项目中引导 AI 工具，而不制造一团糟吗？”

GitHub: https://github.com/multica-ai/andrej-karpathy-skills…

想学习如何构建并交付 AI 和数据科学项目（2026 年企业真正需要的）？

7月14日，我将举办一场免费研讨会，帮助你入门 Python 的 AI + DS 项目。

在此注册（500 个席位）：https://learn.business-science.io/ai-register

multica-ai/andrej-karpathy-skills

来源：https://github.com/multica-ai/andrej-karpathy-skills

Karpathy 启发的 Claude Code 指南

看看我的新项目 Multica (https://github.com/multica-ai/multica) —— 一个用于运行和管理带有可复用技能的编码智能体的开源平台。

在 X 上关注我：https://x.com/jiayuan_jy

一个单一的 CLAUDE.md 文件，用于改善 Claude Code 的行为，源自 Andrej Karpathy（https://x.com/karpathy/status/2015883857489522876）关于 LLM 编码陷阱的观察。

English | 简体中文

存在的问题

引用 Andrej 的帖子：

“模型会替你做出错误的假设，并沿着假设执行而不加验证。它们不管理自己的困惑，不寻求澄清，不暴露不一致，不呈现权衡，在应该反对时也不反对。”

“它们非常喜欢把代码和 API 搞复杂，膨胀抽象，不清理死代码……用 1000 行实现一个臃肿的结构，而 100 行就够了。”

“它们有时仍然会更改/删除它们理解不够充分的注释和代码（作为副作用），即使这些与任务无关。”

解决方案

一个文件中的四项原则，直接解决这些问题：

四项原则详解

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（每个项目）

新项目： bash curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

已有项目（追加）： bash echo "" >> CLAUDE.md curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

与 Cursor 一起使用

本仓库包含一个已提交的 Cursor 项目规则（.cursor/rules/karpathy-guidelines.mdc），因此当你在 Cursor 中打开项目时，同样的指南也适用。请参阅 CURSOR.md 了解设置、如何在其他项目中使用该规则，以及这与 Claude Code 的关系。

核心要点

引用 Andrej：

“LLM 极其擅长循环直到达成特定目标……不要告诉它要做什么，给它成功标准，然后看着它执行。”

“目标驱动执行”原则抓住了这一点：将命令式指令转化为带有验证循环的声明式目标。

如何知道它在起作用

如果你看到以下情况，说明这些指南正在生效：

• 差异中不必要的变更更少 —— 只出现请求的变更
• 因过度复杂而导致的重新编写更少 —— 代码第一次就简洁
• 澄清性问题出现在实现之前 —— 而不是在犯错之后
• 干净、最小的 PR —— 没有顺手重构或“改进”

定制化

这些指南设计为与项目特定的指令合并。将它们添加到现有的 CLAUDE.md 中，或者新建一个。

对于项目特定的规则，可以添加如下部分：

``markdown

项目特定指南

• 使用 TypeScript 严格模式
• 所有 API 端点必须有测试
• 遵循 src/utils/errors.ts 中现有的错误处理模式 ``

权衡说明

这些指南偏向于谨慎而非速度。对于琐碎任务（简单的拼写修复、显而易见的单行代码），请自行判断——并非每次改动都需要如此严格。

目标是减少在非平凡工作上的高成本错误，而不是拖慢简单任务的速度。

许可证

MIT