让 Claude Code 少犯错的 4 条规则：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
你让 Claude Code 加一个导出用户数据的功能，它没问一句，默默假设了导出范围、文件格式和字段，一口气写完，结果全对不上。andrej-karpathy-skills 把 Andrej Karpathy 观察到的 LLM 编码陷阱浓缩成一个 CLAUDE.md，用 4 条行为规则管住 Claude Code，是提升 AI 编码效率的轻量做法。
LLM 写代码时会踩的坑
先看两个常见的翻车场景。
场景一：你说"加个折扣计算函数"，它给你搭出抽象类、折扣策略枚举、可配置参数，100 行的活写成 500 行的架构。
场景二：你只让它修一个空指针，它顺手把相邻代码的风格"统一"了，删掉一段注释，还在没完全理解的情况下改了无关逻辑。PR 一打开，diff 里一半是你想要的，一半是它"顺手"做的。
Andrej Karpathy 对此的总结很直接：模型会把错误假设当结论直接执行，遇到歧义时不澄清，有更简单的方案时也不提醒。这类毛病靠模型自觉改不了，得靠行为约束。
💡 两分钟装好：Claude Code 插件安装步骤与 CLAUDE.md 快速配置
推荐方案：装成 Claude Code 插件，所有项目通用。在 Claude Code 里依次执行两条命令：
/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skills@karpathy-skills装完即全局生效，之后每个项目都自动带上这套行为指南。
备选方案：写进项目的 CLAUDE.md，按项目生效。先克隆仓库：
git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills新项目直接把 CLAUDE.md 拷到项目根目录；已有项目把内容追加到现有 CLAUDE.md 末尾即可。
🎯 照着做的 4 条规则
4 条规则分别针对 LLM 过度工程化、越界改动、目标含糊这些典型毛病，都按"遇到这种情况 → 该怎么做"来讲。
1. Think Before Coding（编码前思考）
坏场景：需求有歧义，模型默默选一种解释就开写，写完才发现方向错了。
正确动作：动手前先摆出自己的假设；拿不准就问；存在多种理解时，把几种都摆出来让你选；如果有个更简单的方案，主动说出来；遇到不清楚的地方，停下来明确指出。
判断标准：它开始写代码之前，是否已经把"我理解你要做什么"交代清楚了。
2. Simplicity First（简洁优先）
坏场景：加个小功能，它顺手引入策略模式、配置项和扩展点。
正确动作：只写能解决当前问题的最少代码；没要求的功能不加，一次性代码不建抽象，没人要的"灵活性"也不预留。200 行能压到 50 行，就重写。
判断标准：拿给资深工程师看，他会不会说"这也太复杂了"。会，就简化。
3. Surgical Changes（精准修改）
坏场景：修一个小 bug，周围代码的风格被"顺手统一"，无关的死代码被删了。
正确动作：只改必须改的行；跟随文件现有风格，哪怕你有更喜欢的写法；发现无关死代码，口头提一句就够了；只清理你这次改动自己产生的孤儿导入和变量。
判断标准：diff 里每一行改动，能否直接对应到你提出的请求。
4. Goal-Driven Execution（目标驱动执行）
坏场景：你说"让它能跑就行"，它做到一半就宣布完成，质量全凭运气。
正确动作：把指令式任务翻译成可验证目标——"加验证"变成"先给非法输入写测试，再让它通过"；"修 bug"变成"先写一个能复现的测试，再让它通过"；"重构"则要求重构前后测试都通过。多步骤任务，把每一步拆成"步骤 → 验证方式"的短清单。
判断标准：成功标准越强，模型越能自己循环到验证通过；标准越含糊，它越频繁回头找你确认。
真实例子怎么看：错误示范 vs 正确示范
例子一：需求本身含糊的任务。你提"添加导出用户数据功能"。错误示范：假设导出全部用户、输出 CSV、包含所有字段，然后直接实现。正确示范：先问三件事——导出全部用户还是筛选后的子集？形式是浏览器下载、后台任务还是 API 返回？包含哪些字段、数据量大概多大？问清楚再动手，返工基本为零。
例子二：小功能被过度设计。你提"加个计算折扣的函数"。错误示范：抽象类加折扣类型枚举再加配置层。正确示范就是三行：
def calculate_discount(amount: float, percent: float) -> float: """返回折扣金额，percent 取 0-100。""" return amount * (percent / 100)等将来真出现多种折扣类型，再抽象也不迟。
✅ 怎么知道它在起作用，以及如何融入你的项目
看四个信号：diff 里跟任务无关的改动变少了；因过度复杂而推倒重来的次数变少了；澄清性问题出现在写代码之前，而不是出错之后；PR 干净、最小，没有夹带的"顺手改进"。
它设计来和你的项目专属指令合并：在 CLAUDE.md 里加一节项目规则，比如"使用 TypeScript 严格模式""所有 API 端点必须有测试"，和这 4 条规则并存，互不冲突。
边界要心里有数：这套指南偏向谨慎而不是速度。拼写错误、单行修改这类琐碎任务，走一遍完整流程纯属浪费时间，凭判断力直接改就好。它要减少的是非琐碎工作中的昂贵错误，不是拖慢简单任务。
这 4 条规则的本质，是把"模型自己猜"换成"先对齐、再动手、可验证"。下一步，直接在你手头的项目里装上试试，下一个 diff 就能感受到差别。
【免费下载链接】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辅助生成（AIGC），仅供参考
