用一个文件治好 Claude Code 的"坏习惯"：andrej-karpathy-skills 完全指南
如果你用过 Claude Code 写项目，大概率遇到过这些情况：
- 明明只让改一个函数，结果 AI 顺手把旁边的注释也改了
- 一个本来 50 行能解决的逻辑，AI 写出了带接口、工厂类、配置注入的 200 行"企业级"方案
- AI 碰到歧义不问你，自己猜一个方向写下去，等你发现已经跑偏了几百行
这些问题 Andrej Karpathy 在一条广为流传的推文里说得很直接：
"模型会替你做假设然后一路跑下去，不管理自身的困惑，不寻求澄清，不暴露不一致性，不在该反驳时反驳。" "它们真的很喜欢把代码和 API 过度复杂化，膨胀抽象层……明明 100 行能搞定的，非要写超过 1000 行。"
andrej-karpathy-skills 这个项目的回答很简单：用一个 CLAUDE.md 文件，把这些坏习惯直接约束掉。
这个项目是什么
GitHub 地址：multica-ai/andrej-karpathy-skills
协议：MIT，完全免费
核心内容：单一 CLAUDE.md 配置文件
支持中文：官方提供简体中文版 README
项目由 multica-ai 团队维护，同时也是 Multica（开源编程 Agent 管理平台）的开发团队。它不修改底层模型，不需要额外服务器，仅靠一个配置文件为 Claude Code 添加一层行为约束。
四大核心原则详解
原则一：Think Before Coding（编码前先思考）
针对问题：模型静默猜测方向、假装理解需求
规则要求 Claude Code：
- 存在歧义时，必须提问而不是猜
- 有多种解读时，列出来让你选，不自己挑
- 发现更简单的方案时，主动说出来
- 遇到困惑时，停下来，说清楚哪里不懂
实际效果：改需求前会先收到"我理解你要做的是 X，这样对吗？"而不是直接开干。
原则二：Simplicity First（极简优先）
针对问题：过度设计、抽象膨胀
明确禁止：
- 添加没有被要求的功能
- 为只用一次的代码创建抽象层
- 没人要求的"灵活性"或"可配置性"
- 处理不可能发生的异常情况
判断标准：如果资深工程师看了会说"这是不是太复杂了"，就简化。200 行能压到 50 行的，重写。
原则三：Surgical Changes（外科手术式修改）
针对问题：改 A 动 B，顺手"优化"不相关的代码
修改已有代码时：
- 只动任务要求的部分
- 不改相邻代码、注释、格式，哪怕你觉得风格不好
- 不重构没有问题的代码
- 发现不相关的死代码：提出来，但不自己删
你自己引入的孤儿代码（比如改完后不再用的 import、变量）：要清理。
判断标准：每一行改动都应该能追溯到用户的请求。
原则四：Goal-Driven Execution（目标驱动执行）
针对问题：指令模糊导致反复返工
把命令式的指令转化为可验证的目标：
| 原始指令 | 转化后的目标 |
|---|---|
| "加验证逻辑" | "写出无效输入的测试用例，然后让它们通过" |
| "修复这个 Bug" | "写一个能复现该 Bug 的测试，然后修复" |
| "重构 X" | "确保重构前后测试全部通过" |
多步骤任务时，先给出计划：
1. [步骤] → 验证：[检查点]
2. [步骤] → 验证：[检查点]
3. [步骤] → 验证：[检查点]
Karpathy 的原话是："LLM 非常擅长循环直到满足特定目标……不要告诉它做什么，给它成功标准然后看它自己跑。"
安装方法（两种）
方案 A：Claude Code 插件（推荐，全局生效）
在 Claude Code 内执行：
# 第一步：添加插件市场
/plugin marketplace add forrestchang/andrej-karpathy-skills
# 第二步：安装插件
/plugin install andrej-karpathy-skills@karpathy-skills
安装后对所有项目生效，不需要每个项目单独配置。
方案 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，打开项目即自动生效，无需额外配置。
如何判断它在生效
配置后观察 Claude Code 的行为变化：
- ✅ Diff 更干净：只有你要求的改动，没有多余的"顺手优化"
- ✅ 代码更简洁：第一次输出就不过度设计
- ✅ 先问再做：实现前收到澄清问题，而不是做完才发现跑偏
- ✅ PR 更小：没有无关的重构或格式调整混进来
如何与项目规则结合使用
这份配置设计为可叠加的，在文件末尾追加你的项目规则即可：
## 项目专属规则
- 使用 TypeScript strict 模式
- 所有 API 端点必须有测试
- 错误处理遵循 `src/utils/errors.ts` 的现有模式
适合谁用
推荐使用的场景：
- 多人协作项目，需要统一 AI 辅助编码的行为
- 维护中的存量代码库，AI 乱改一通代价高
- 代码质量要求高、每次 PR 都要认真 Review 的团队
- 已经被 Claude Code "越权修改"坑过的开发者
可以不用的场景：
- 纯原型/demo 阶段，追求速度而非代码质量
- 简单的单次脚本，不需要严格约束
- 已经有成熟的代码审查流程，AI 只是辅助
与其他方案的对比
| 维度 | andrej-karpathy-skills | 手写 Prompt | 不配置直接用 |
|---|---|---|---|
| 配置成本 | 一次，5 分钟 | 每次手动 | 零 |
| 覆盖范围 | 全局 / 按项目 | 单次对话 | — |
| 版本管理 | 可提交到 Git | 难以管理 | — |
| Cursor 支持 | ✅ 内置规则文件 | 需单独配置 | 需单独配置 |
| 对代码质量的影响 | 显著减少无关改动 | 不稳定 | 无约束 |
总结
andrej-karpathy-skills 本质上是把 Karpathy 对 LLM 编码问题的观察，转化成了可执行的约束规则。它不是银弹，不能让 Claude Code 变聪明，但能让它不做蠢事。
如果你每周有一次以上被 AI "顺手改了不该改的东西"而头疼，5 分钟配置这个文件是值得的。
官方 GitHub：multica-ai/andrej-karpathy-skills
Multica 平台（作者新项目）：multica-ai/multica
评论(0)