一个 CLAUDE.md 治好 Claude Code 的过度热心andrej-karpathy-skills 完整上手指南【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skillsClaude Code 生成的代码总多想一步andrej-karpathy-skills 用一个 CLAUDE.md 行为准则文件约束 AI 编程助手的常见毛病不乱假设、不堆代码、不动无关行。本文讲清它的 4 条规则、安装命令以及装上前后 diff 的实际差异。先看一个有点尴尬的代码评审上周的评审会上同事的 PR 被问住了。这个任务只有一行改动修一个空值崩溃。但 diff 展开是 60 多行——整个文件的单引号被换成了双引号函数签名补上了类型标注还多出三段没人点名的校验逻辑。评审人只问了一句修复在哪一行他翻了半天才指出来。问题不在 AI 不够聪明。反常识的地方在这AI 越能干越需要你把不许做什么写在它面前。andrej-karpathy-skills 干的就是这件事——把 Andrej Karpathy 总结的大模型编程毛病浓缩成一个 CLAUDE.md 文件让 Claude Code 这类工具在动手前先读一遍。andrej-karpathy-skills 到底是什么一句话定位它不是一个工具而是一份给 AI 看的一页纸工作守则。打个比方。你招了个特别能干的实习生但热情过头每次干完活都顺手整理办公室——帮你重排书架、擦键盘、甚至挪你桌面快捷方式。你没法开除他只能贴一张守则在他显示器上开工前先看工单只修报修的那一处自己弄乱的自己收拾验收签字了再下班。这份项目就是那张守则。核心内容在 CLAUDE.md 里一共 4 条规则纯 Markdown没有任何代码。它会被 AI 助手在每次打开项目时读取等于给实习生定死了工作习惯。4 条规则各自改掉一个习惯它以前的习惯规则改成什么样一句话自检只让你修一处顺手把旁边的引号统一了、死代码删了、注释也重写了手术式修改每一行改动都要能追溯到你的请求发现无关死代码只报告、不删这个 diff 里每一行我都能说出来历吗你让它写个折扣计算它先搭好策略模式、配置类、缓存层简单优先不写没要求的功能、没要求的可配置性、不可能发生的场景的错误处理200 行能压到 50 行就重写这段代码资深工程师会不会觉得过设计任务没有完成标准它一口气干到底你事后才发现方向错了目标驱动把修一下翻译成先写能复现问题的测试 → 让它通过 → 确认无回归动手之前我知道怎么判定成功吗遇到模糊需求默默挑一个最可能的理解写完才暴露理解错了先想后写假设摆上台面多种解释并列给出不确定就停下来问澄清问题发生在写代码之前还是返工之后最后一行值得多说一句。修复登录系统这种说法没有终点规则会逼着 AI 把它改写成先写一个能复现的测试让它通过再确认没有回归。Karpathy 的原意是模型非常擅长朝着明确的成功标准循环干活你给它标准它自己就能跑。所以这条规则的本质是把你嘴里的一句模糊指令换成 AI 可以自查的验收条件。三步装好最短上手路径第 1 步选一种方式把文件放进去。用 Claude Code 的话插件方式一次配置、全局生效在项目里依次输入/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skillskarpathy-skills白话这两行装的是全局守则你所有项目都不用再配。想按项目控制就克隆仓库、把文件拷进项目根目录git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills cp andrej-karpathy-skills/CLAUDE.md 你的项目/白话CLAUDE.md 是 AI 每次打开项目都会先读的文件放进根目录即生效。项目里已有 CLAUDE.md 时追加而不是覆盖cat andrej-karpathy-skills/CLAUDE.md CLAUDE.md第 2 步用别的工具就换对应格式。你用 Cursor 的话把仓库里的.cursor/rules/karpathy-guidelines.mdc拷到目标项目的.cursor/rules/目录即可细节见 CURSOR.md。想以技能形式复用可以看 skills/karpathy-guidelines/SKILL.md。本质都是同一份守则的三种包装。第 3 步验证它真的生效了。给它一个故意模糊的任务比如让搜索变快。如果它第一反应不是上来加缓存、加索引而是先列出几种理解——要的是响应时间、并发能力还是页面感知速度——然后问你更在意哪个说明守则已经在工作。前后对比同一个 bug两份 diff拿仓库 EXAMPLES.md 里的真实例子修空邮箱让校验器崩溃这个 bug。❌ 没装守则时典型产出是这样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) username user_data.get(username, ).strip() if len(username) 3: raise ValueError(Username too short)崩溃确实修了但 docstring、邮箱校验逻辑的加强、外加整段没被要求的用户名校验全混在一起。✅ 装上守则后def validate_user(user_data): - if not user_data.get(email): email user_data.get(email, ) if not email or not email.strip(): raise ValueError(Email required)变化在哪diff 从读不出重点变成每一行都能解释空字符串和纯空格不再触发崩溃别的什么都没碰。这就是守则内置的验收标准——说不清来路的改动就不该出现在 diff 里。哪些地方它不划算说几句实话。小事不划算。改个错别字、一行明显的修改不需要走完整套流程。文件开头自己就写了这套规则偏向谨慎胜过速度琐碎任务用判断力即可。别让它给简单任务添堵。前期节奏会变慢。动手前它会多问几句第一个任务的体感确实慢一点。换回来的是后面的省——少说几次重写简单点少解释几次这行为啥改。它治的是习惯不是能力。这份文件不会让模型更聪明只让它在既有水平上守规矩。底层模型写错逻辑守则拦不住它约束的是假设、膨胀、乱碰这几类行为问题。和你习惯的协作方式可能冲突。如果你的工作流是先让 AI 一口气干完再打磨这套偏保守的规则会让你觉得被拖慢。它更适合需要 review diff、多人协作的场景。现在就做一个小动作只做一件事把 CLAUDE.md 放进你本周改动最多的那个项目插件用户跑上面那两行命令即可。明天第一个任务故意说得模糊一点——看它是直接开干还是先反问你一句。【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 一个 CLAUDE.md 治好 Claude Code 的“过度热心“：andrej-karpathy-skills 完整上手指南
一个 CLAUDE.md 治好 Claude Code 的过度热心andrej-karpathy-skills 完整上手指南【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skillsClaude Code 生成的代码总多想一步andrej-karpathy-skills 用一个 CLAUDE.md 行为准则文件约束 AI 编程助手的常见毛病不乱假设、不堆代码、不动无关行。本文讲清它的 4 条规则、安装命令以及装上前后 diff 的实际差异。先看一个有点尴尬的代码评审上周的评审会上同事的 PR 被问住了。这个任务只有一行改动修一个空值崩溃。但 diff 展开是 60 多行——整个文件的单引号被换成了双引号函数签名补上了类型标注还多出三段没人点名的校验逻辑。评审人只问了一句修复在哪一行他翻了半天才指出来。问题不在 AI 不够聪明。反常识的地方在这AI 越能干越需要你把不许做什么写在它面前。andrej-karpathy-skills 干的就是这件事——把 Andrej Karpathy 总结的大模型编程毛病浓缩成一个 CLAUDE.md 文件让 Claude Code 这类工具在动手前先读一遍。andrej-karpathy-skills 到底是什么一句话定位它不是一个工具而是一份给 AI 看的一页纸工作守则。打个比方。你招了个特别能干的实习生但热情过头每次干完活都顺手整理办公室——帮你重排书架、擦键盘、甚至挪你桌面快捷方式。你没法开除他只能贴一张守则在他显示器上开工前先看工单只修报修的那一处自己弄乱的自己收拾验收签字了再下班。这份项目就是那张守则。核心内容在 CLAUDE.md 里一共 4 条规则纯 Markdown没有任何代码。它会被 AI 助手在每次打开项目时读取等于给实习生定死了工作习惯。4 条规则各自改掉一个习惯它以前的习惯规则改成什么样一句话自检只让你修一处顺手把旁边的引号统一了、死代码删了、注释也重写了手术式修改每一行改动都要能追溯到你的请求发现无关死代码只报告、不删这个 diff 里每一行我都能说出来历吗你让它写个折扣计算它先搭好策略模式、配置类、缓存层简单优先不写没要求的功能、没要求的可配置性、不可能发生的场景的错误处理200 行能压到 50 行就重写这段代码资深工程师会不会觉得过设计任务没有完成标准它一口气干到底你事后才发现方向错了目标驱动把修一下翻译成先写能复现问题的测试 → 让它通过 → 确认无回归动手之前我知道怎么判定成功吗遇到模糊需求默默挑一个最可能的理解写完才暴露理解错了先想后写假设摆上台面多种解释并列给出不确定就停下来问澄清问题发生在写代码之前还是返工之后最后一行值得多说一句。修复登录系统这种说法没有终点规则会逼着 AI 把它改写成先写一个能复现的测试让它通过再确认没有回归。Karpathy 的原意是模型非常擅长朝着明确的成功标准循环干活你给它标准它自己就能跑。所以这条规则的本质是把你嘴里的一句模糊指令换成 AI 可以自查的验收条件。三步装好最短上手路径第 1 步选一种方式把文件放进去。用 Claude Code 的话插件方式一次配置、全局生效在项目里依次输入/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skillskarpathy-skills白话这两行装的是全局守则你所有项目都不用再配。想按项目控制就克隆仓库、把文件拷进项目根目录git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills cp andrej-karpathy-skills/CLAUDE.md 你的项目/白话CLAUDE.md 是 AI 每次打开项目都会先读的文件放进根目录即生效。项目里已有 CLAUDE.md 时追加而不是覆盖cat andrej-karpathy-skills/CLAUDE.md CLAUDE.md第 2 步用别的工具就换对应格式。你用 Cursor 的话把仓库里的.cursor/rules/karpathy-guidelines.mdc拷到目标项目的.cursor/rules/目录即可细节见 CURSOR.md。想以技能形式复用可以看 skills/karpathy-guidelines/SKILL.md。本质都是同一份守则的三种包装。第 3 步验证它真的生效了。给它一个故意模糊的任务比如让搜索变快。如果它第一反应不是上来加缓存、加索引而是先列出几种理解——要的是响应时间、并发能力还是页面感知速度——然后问你更在意哪个说明守则已经在工作。前后对比同一个 bug两份 diff拿仓库 EXAMPLES.md 里的真实例子修空邮箱让校验器崩溃这个 bug。❌ 没装守则时典型产出是这样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) username user_data.get(username, ).strip() if len(username) 3: raise ValueError(Username too short)崩溃确实修了但 docstring、邮箱校验逻辑的加强、外加整段没被要求的用户名校验全混在一起。✅ 装上守则后def validate_user(user_data): - if not user_data.get(email): email user_data.get(email, ) if not email or not email.strip(): raise ValueError(Email required)变化在哪diff 从读不出重点变成每一行都能解释空字符串和纯空格不再触发崩溃别的什么都没碰。这就是守则内置的验收标准——说不清来路的改动就不该出现在 diff 里。哪些地方它不划算说几句实话。小事不划算。改个错别字、一行明显的修改不需要走完整套流程。文件开头自己就写了这套规则偏向谨慎胜过速度琐碎任务用判断力即可。别让它给简单任务添堵。前期节奏会变慢。动手前它会多问几句第一个任务的体感确实慢一点。换回来的是后面的省——少说几次重写简单点少解释几次这行为啥改。它治的是习惯不是能力。这份文件不会让模型更聪明只让它在既有水平上守规矩。底层模型写错逻辑守则拦不住它约束的是假设、膨胀、乱碰这几类行为问题。和你习惯的协作方式可能冲突。如果你的工作流是先让 AI 一口气干完再打磨这套偏保守的规则会让你觉得被拖慢。它更适合需要 review diff、多人协作的场景。现在就做一个小动作只做一件事把 CLAUDE.md 放进你本周改动最多的那个项目插件用户跑上面那两行命令即可。明天第一个任务故意说得模糊一点——看它是直接开干还是先反问你一句。【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathys observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考