一份 CLAUDE.md 治住 AI 乱改代码：andrej-karpathy-skills 快速上手指南-开发者社区

一份 CLAUDE.md 治住 AI 乱改代码：andrej-karpathy-skills 快速上手指南

【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

andrej-karpathy-skills 是一个几乎只有一份 CLAUDE.md 的开源项目：它把 Andrej Karpathy 观察到的 AI 编码坏习惯写成行为准则，装进 Claude Code 之后，AI 少乱改、少过度设计，动手前会先问清需求。

🎬 先聊一个熟悉的翻车现场

你让 AI 修一个"空邮箱让校验函数崩溃"的小 bug。它修好了，但你打开 diff 一看：顺手加了 docstring、把注释措辞全改了、引号风格变了，还"优化"了一段你根本没提的用户名校验逻辑。你要的是两行修复，拿到的是半页变更。

再比如你说"把搜索做快点"，它不问你要哪种"快"，直接上了缓存、数据库索引、异步处理，两百行代码一把梭。

这不是某次发挥失常，而是模型的本能：遇到模糊需求时，它倾向于默默选一个解释就往下跑，不澄清、不报困惑、不给你选项。andrej-karpathy-skills 就是冲着这个毛病来的。

🧩 它是什么：一张贴在 AI 工位上的行为守则

这个项目不是框架，也不是插件合集——核心就是根目录下那个 CLAUDE.md 文本文件，Claude Code 每次启动都会读它。内容源自 Karpathy 对 LLM 编码缺陷的总结，可以理解为"问题 → 对策"的对照：

AI 闷头做假设 → 逼它先把假设说出口，拿不准就问
100 行能搞定非要写 1000 行 → 只写解决问题所需的最少代码
修一个 bug 顺手"改进"半个文件 → 只动必须动的地方
一句"修好它"就算交差 → 先定义"怎样算修好"，再动手

同一套规则还做了三件"马甲"：通用的 CLAUDE.md、可复用的 skills/karpathy-guidelines/SKILL.md，以及给 Cursor 用的项目规则.cursor/rules/karpathy-guidelines.mdc，见 CURSOR.md。

⚙️ 机制拆解：它管住了 AI 的三个动作

抛开文件里那四条编号原则，这套守则实际上是在模型的三个关键动作上做了干预。

动手之前：先开口，再动手

默认习惯是"沉默地选一个解释然后跑"。守则要求它开工前把假设逐条摆出来：需求有歧义就列出多种理解让你挑；觉得有更简单的路线，要当面说，允许"顶嘴"；真被绕晕了，必须停下手来说明哪里不清楚，而不是硬编下去。

动手之中：克制这只手

两个方向的克制。改动量上：不碰相邻代码、注释和格式，不重构没坏的东西，只清理你自己造成的孤儿代码（比如你删掉的函数留下的 import），风格跟着现有代码走。代码量上：没要的功能不加，单次使用的代码不抽抽象，不为不可能出现的场景写错误处理。它给模型留了两句自检的话："一个高级工程师会说这写复杂了吗？"以及"每一行改动，都能追溯到你的请求吗？"

交活的时候：拿标准说话，不拿感觉说话

把模糊指令翻译成可验证的目标。"修这个 bug"变成"先写一个能复现它的测试，再让测试变绿"；"加个校验"变成"写无效输入的测试，然后让它们通过"。多步任务则要求报一个带验证点的计划：每步后面跟一句"怎么算完成"。标准给得硬，模型就能自己循环推进，不用你全程盯着。

🚀 安装步骤：两条路，任选其一

方式一：单项目使用（最快）

先把仓库克隆下来：

git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills

新项目：把根目录的CLAUDE.md拷到你项目根目录即可
老项目：把内容追加合并进已有的CLAUDE.md，下面再补上你们自己的团队约定

方式二：全局生效（Claude Code 插件）

在 Claude Code 里先加插件市场，再安装插件，两步完成，之后所有项目都能用：

/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skills@karpathy-skills

用 Cursor？把.cursor/rules/karpathy-guidelines.mdc拷进目标项目的.cursor/rules/目录（建目录即可），设置里能看到这条规则就生效了。

⚖️ 用之前 vs 用之后

案例一："把用户偏好存到数据库"

之前：AI 递来一个PreferenceManager类，构造参数带缓存、校验器、合并开关、通知钩子，四十多行，全是你没要过的
之后：一个save_preferences(db, user_id, prefs)函数执行一条 UPDATE。等哪天真的遇到脏数据，再谈校验

案例二：修"空邮箱导致崩溃"

之前：diff 里混进了 docstring、注释改写、引号风格切换，外加一段升级版的用户名校验
之后：diff 只有处理空邮箱的那两三行，连引号都没动过

用 EXAMPLES.md 里的说法，这种"过度设计"并不是显眼的错——设计模式、最佳实践都用了。问题出在时机：复杂度加得太早，代码更难懂、更难测。

🧭 边界与权衡：什么时候该省

这套守则整体偏向"谨慎"而不是"速度"。它适合：改现有代码库、不太平凡的任务、需要统一交付标准的团队协作。但对于改个拼写错误、一眼能看出的单行修改，把它全套跑一遍纯属拖慢节奏——文档自己也说：这些规则的目的，是减少复杂工作里昂贵的大错，而不是让简单任务变慢。

💡 为什么一张纸能起效

模型的短板从来不在智力，而在习惯：不管理自己的困惑，也不主动寻求澄清。给一份明确的规则，等于减少它临场"自由发挥"的决策点；而一旦成功标准是具体可验证的，LLM 最强的能力——朝着明确目标循环直到达成——才真正被利用起来。工程上，它就是 YAGNI（别写用不上的）和 KISS（保持简单）这两条老原则，只不过执行者从"人肉 code review"换成了模型自己。