给 AI 一个分寸感：andrej-karpathy-skills 实战

给 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

"给上传函数加两条日志。"AI 加上了，顺手把整个函数的单引号换成双引号、给签名补了类型标注、加了 docstring、重排了空白，连布尔返回逻辑都改了。真实改动就两行，diff 却是三十行。

你大概率也撞见过这种场景。问题不在模型不够聪明，而在它缺少"分寸感"。andrej-karpathy-skills 把一套源自 Andrej Karpathy 对 LLM 写代码观察的行为准则，装进了一个 CLAUDE.md 文件：动手前先问清楚，先写最短的版本，只碰该碰的行。整个项目的核心就是一份拿来即用的"行为说明书"，日常用 Claude Code、Cursor 或任何会读根目录指令文件的工具，都能直接套用。

这份文件写了什么：AI 要过的四道"自检题"

CLAUDE.md 里的规则对应四类高频翻车，每条都自带一道"交付前必须通过"的自检测试，这是它和一般提示词的差别所在。

不确定就先问，把假设摆上台面

对应 "Think Before Coding"。任务有多种理解时，并排列出来让你选，不许默默挑一条开干；有不清楚的地方，停下来、说清哪里不清楚、然后提问。目的只有一个：把澄清问题挪到实现之前，而不是返工之后。

200 行能压到 50 行，就重写

对应 "Simplicity First"。不写没人要的功能，不给一次性代码搭"可配置"的架子，不为不可能的场景写容错。自检题是一道很狠的话："一个资深工程师会说这写复杂了吗？"会，就重写。

每一行改动都要能追溯到请求

对应 "Surgical Changes"。修 bug 时不许"顺手改进"相邻代码，不许重构没坏的东西，代码风格要跟现有的一致；发现无关的死代码，只报告、不删除。唯一允许清理的，是你自己这次改动造成的孤儿代码。

把"修一下"改写成"让测试通过"

对应 "Goal-Driven Execution"。"修复认证系统"这种没尽头的说法，会被改写成"先写一个能复现问题的测试，让它通过，再确认没有回归"。多步任务则输出"步骤 → 验证方式"的计划，一步步循环。这背后是 Karpathy 的观察：模型非常擅长朝着明确目标循环干活，给它成功标准它会自己跑，给它模糊标准你就得反复追问。

两条安装路径：一条全局，一条按项目

路径 A：Claude Code 插件，一次装全项目通用

在 Claude Code 里执行两条命令即可，之后所有项目都能用：

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

路径 B：往项目里放一份 CLAUDE.md

想按项目控制、或用的是别的工具，把文件放进项目根目录就行：

git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills cp andrej-karpathy-skills/CLAUDE.md 你的项目根目录/CLAUDE.md

项目里已有 CLAUDE.md 时，用追加而不是覆盖，原有规则不受影响：

echo "" >> CLAUDE.md cat andrej-karpathy-skills/CLAUDE.md >> CLAUDE.md

这个文件本来就设计为和你自己的项目指令合并。文末加一节项目专属规则即可，比如 "Use TypeScript strict mode"、"All API endpoints must have tests"——这两个例子直接取自 README.md 的推荐写法。

用 Cursor 的，拷一个 .mdc 规则文件

仓库里已附带.cursor/rules/karpathy-guidelines.mdc，把它拷进目标项目的.cursor/rules/目录即生效，具体见 CURSOR.md。注意 Cursor 默认不读根目录的指令文件，别指望 CLAUDE.md 在那边直接起作用。

同一个任务，两种 diff

拿"修复空 email 导致校验崩溃"来对照，EXAMPLES.md 里两组结果的差距很直观。

❌ 装指南前

def validate_user(user_data): - # Check email format - if not user_data.get('email'): + """Validate user data.""" + email = user_data.get('email', '').strip() + if not email: raise ValueError("Email required") - if '@' not in user_data['email']: + if '@' not in email or '.' not in email.split('@')[1]: raise ValueError("Invalid email") + if len(username) < 3: + raise ValueError("Username too short") + if not username.isalnum(): + raise ValueError("Username must be alphanumeric")

docstring、注释改写、"顺手加强"的校验，外加没人要的 username 规则，全挤在同一次提交里。

✅ 装指南后

def validate_user(user_data): # Check email format - if not user_data.get('email'): + email = user_data.get('email', '') + if not email or not email.strip(): raise ValueError("Email required")

整个 diff 都能追溯到"处理空 email"这一个请求。规则里的验收标准写得很直白：每一行改动都说不清来路的，就不该出现在 diff 里。

它什么时候帮到你，什么时候添堵

• 明码标价的取舍：这套规则偏向"谨慎胜过速度"。改错别字、显而易见的单行修复不必走全流程——文件里写明了，目标是减少非琐碎工作上的昂贵失误，不是拖慢简单任务。
• 前期节奏会变慢：动手前它多想、多问，第一反应可能比你预期的慢半拍。换来的通常是更少的"重写一遍"和 Review 时更少的"这行为啥改"。
• 软约束，不是硬卡口：它是一份文字指令，不是 linter，不会机械拦截越界改动。大任务里模型若跑偏，仍需你自己提醒。
• 工具要求：任何支持根目录指令文件的工具都能放；Cursor 例外，走.mdc规则文件那条路。

一周之后，问自己四个问题

• 打开 diff，每一行改动你都能说清来路吗？
• 给它"让搜索变快"这种有多种理解的任务，它是先列出几种解释让你选，还是直接挑一条开干？
• 它的第一版代码就已经是最短版本，你还需要说"简单点"吗？
• 澄清问题发生在动手之前，还是做错之后？

四个问题里有三个答案是肯定的，说明这套准则真正在起作用，而不只是躺在根目录吃灰。

今晚就能试

要做的事只有一件：克隆仓库，把 CLAUDE.md 放进你改动最频繁的项目，然后盯着下一个 diff 看变化。整套准则浓缩在这一个 CLAUDE.md 文件里，想多看几组"错在哪、该怎么写"的对照，翻 EXAMPLES.md；需要中文版看 README.zh.md。若想把准则变成可复用的个人技能，仓库里还有现成的 SKILL.md 定义。

【免费下载链接】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