让 AI 少点“自作主张“：andrej-karpathy-skills 把 LLM 编程行为指南装进一个文件-编程实验室

让 AI 少点"自作主张"：andrej-karpathy-skills 把 LLM 编程行为指南装进一个文件

【免费下载链接】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 帮你修了个 bug，顺手把隔壁三个函数全重写了，注释改了，验证逻辑也换了。这是 andrej-karpathy-skills 要解决的痛点：一套源自 Andrej Karpathy 观察的 LLM 编程行为指南，把 4 条行为约束装进一个 CLAUDE.md 文件。放进来之后，它该写 1000 行的代码现在 100 行就够，30 行的抽象类变成 3 行函数。

📌 一句话定位

它是一组写进 AI 记忆文件里的行为约束，不是框架，也不是提示词工具。用 Claude、ChatGPT、Cursor 等写非平凡代码，又被"替你做了假设"坑过的人，这篇值得看；只拿 AI 改错别字的，可以划走。

🚨 AI 编程翻车现场

你输入"修个空邮箱导致验证器崩溃的 bug" → AI 顺手重写整个验证函数，加强邮箱校验、加 username 规则、改注释 → 修 bug 的 diff 加的行比删的多，review 得逐行找哪些是真改动。
你输入"加个算折扣的函数" → AI 产出 DiscountStrategy 抽象类、两个策略实现、Config 和 Calculator，30 多行 setup → 你实际要的只有 3 行：amount * (percent / 100)。
你输入"加个导出用户数据的功能" → AI 默认"导出全部用户到本地文件"，字段随便挑 → 做完才发现格式和范围全不对，推倒重来。
你输入"让搜索变快" → AI 直接堆上缓存、索引、异步处理 200 行 → 你要的是体感速度，方向一开始就错，200 行全白写。

🔧 它到底怎么约束 AI

这套 LLM 编程行为指南不管代码风格，管的是 AI 的行为方式。核心是 3 条行为规则，每条都是"以前 vs 现在"：

编码前思考：传统 AI 默默选一种解释往下冲；有约束后，先摆出假设和多种解释，拿不准就停下来说"我没懂哪里"。
简单优先：传统 AI 加你没要的抽象层和"灵活性"；有约束后，它自检"200 行能写成 50 行吗"，能就重写。
外科手术式改动：传统 AI 顺手"改进"相邻代码和注释；有约束后，每行改动都能追溯到你的请求，发现不相关的死代码，只提一句，不删。

第四条叫目标驱动：不让它"修 bug"，而让它"先写一个复现 bug 的测试，再让测试通过"。EXAMPLES.md 里的折扣函数对比最直观：

# ❌ 以前：抽象类 + 两个实现 + Config，30+ 行 setup class DiscountStrategy(ABC): @abstractmethod def calculate(self, amount: float) -> float: ... # ✅ 现在：只要被要的函数，3 行 def calculate_discount(amount: float, percent: float) -> float: return amount * (percent / 100)

🚀 5 分钟跑起来

整条流程就是三件事：拿到文件 → 放进项目根目录 → 确认生效。拿文件有两条路。

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

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

在 Claude Code 里依次执行这两条，约束对你所有项目生效，不用每个项目单独放文件。

方式二：手动放文件（每个项目一份）

第 1 步，clone 仓库（只做一次）：

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

第 2 步，把核心文件放进你的项目根目录：

cp andrej-karpathy-skills/CLAUDE.md your-project/CLAUDE.md

如果你的项目已经有 CLAUDE.md，把内容合并追加到末尾即可。

第 3 步，验证：打开 Claude Code，第一句话问它"这个项目 CLAUDE.md 里有什么约束"，它答得上四条原则，就算生效了。

⚖️ 一个完整任务的改前 vs 改后

用户原话："修个 bug：空邮箱会导致验证器崩溃。"

改前（无约束时的典型输出）：重写整个 validate_user 函数，加 docstring，注释全换掉，邮箱加 strip，校验加强成"域名必须含点"，顺手补上 username 的长度和字符校验 → 10 行左右新增、6 行左右删除，其中跟空邮箱 bug 相关的只有 2 行。

改后（有约束时的输出）：只在邮箱检查里加空值判断，为空直接抛 ValueError，其他代码、注释、格式一概不动，没有产生新的孤儿引用，也不删任何既有死代码 → diff 是 2 行新增，0 行删除，每行都能用你的原话解释。

区别一句话：改前你得从十几行 diff 里挑出哪两处才是真修复，改后你确认 2 行就完事。这就是"外科手术式改动"和"路过顺手重构"的差距。

📊 数据怎么说

1000 行 vs 100 行：Karpathy 原话，模型"该写 100 行时给你 1000 行的臃肿结构"，整个项目就是为拉回这条写的（README 引文）。
200 行 vs 50 行：CLAUDE.md 里写死的自检阈值："如果你写了 200 行而 50 行就够，重写它。"
30+ 行 vs 3 行：EXAMPLES.md 的折扣示例，抽象 setup 直接收敛成一个函数。
16 行 vs 2 行：上面 bug 修复场景里 diff 的体积对比，来自仓库示例代码的逐行统计。
返工率约降 50%：宣传材料里的说法，项目自述，无第三方实测，当参考就好。