andrej-karpathy-skills 完整解读1 个 CLAUDE.md 纠正 LLM 编码的 3 个坏习惯【免费下载链接】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 助手修一个空邮箱导致校验崩溃的小 Bug它却顺手改了引号风格、加了类型标注、重写了注释还补了一段没人要的用户名校验。andrej-karpathy-skills 就是冲这类问题来的一个用 CLAUDE.md 行为准则改善 Claude Code及同类编码助手行为的开源项目核心是纠正 LLM 写代码时的 3 个坏习惯——乱猜需求、过度设计、顺手乱改。这种 diff 很难审查你要在一堆无关改动里找出真正修 Bug 的那两行。更糟的是模型做这些假设时不会告诉你——它悄悄选了一种解释然后闷头执行到底。 项目定位它到底是什么一句话它不是编程框架也不是新工具而是几份给编码助手看的工作守则文件。内容来自 Karpathy 对 LLM 编码缺陷的观察模型会替你做出错误假设还不检查、偏爱把代码搞复杂、甚至会改动自己并不理解的代码和注释。它解决的是生成的代码看着对但假设错、改动杂、难审查的问题服务对象是用 Claude Code、Cursor 这类助手的开发者。可以把它理解成一份通用的 Claude Code 行为准则、LLM 编码行为准则。中文读者可以直接读 README.zh.md。 机制拆解3 个机制分别管住输入、过程和终点这个项目的核心思想一句话不教模型怎么写代码而是管住它的工作习惯。四条原则被组织成三层防线管住输入不许闷头猜、管住过程少写、少改、管住终点必须有可验证的成功标准。机制一先想清楚再动手把假设摆到台面上改变了什么行为模型遇到模糊需求默认动作是悄悄选一种解释然后执行。CLAUDE.md 里的 Think Before Coding 一节把这个默认动作反了过来——假设必须明说、多种解释必须并列、想不清楚必须停下来问。❌ 传统做法你说导出用户数据它直接写函数把全部用户导出到本地文件字段、路径、格式全靠猜✅ 项目做法先问四个问题——导出全部还是子集什么交付形式文件/接口/后台任务要哪些字段数据量多大然后给出最简单的方案这个机制的价值不是多问几轮话而是把猜错的代价从整段代码重写降到多回答一条消息。机制二少写、少改两句话约束输出过度工程和顺手乱改是模型在写代码、改代码时的两种冲动Simplicity First 和 Surgical Changes 分别管住它们。写代码时不写要求之外的功能不为一次性代码建抽象不加没人要的灵活性和可配置性不为不可能发生的场景写错误处理检验标准资深工程师会说写复杂了吗会说就重写改代码时不改进相邻的代码、注释、格式没坏的东西不重构匹配现有风格哪怕你更想换一种写法无关的死代码提一句别删检验标准每一行改动都能直接追溯到你的请求❌ 传统做法修一个空邮箱校验的 Bugdiff 里多出邮箱规则增强、用户名校验、新注释✅ 项目做法diff 里只有处理空邮箱的那两行机制三给成功标准不给口头指令Karpathy 的观察是LLM 非常擅长朝着明确目标循环直到达成。Fix the bug这种指令没有可验证的终点模型只能边做边问换成可验证目标它就能自己循环。❌ 传统做法修复认证系统 → 模型列个模糊计划看看代码、找问题、改一改、测一测没有终点✅ 项目做法先定义成功标准——改密后旧会话失效 → 写测试复现验证测试失败→ 修复验证测试通过→ 查边界情况验证附加测试通过→ 确认无回归验证全部测试通过多步任务同理每一步后面挂一个 verify 检查点。标准越具体模型越少回头问你让它能跑这种弱标准则意味着全程需要你盯着。️ 效果实证EXAMPLES.md 里的真实前后对比上面讲的是机制下面用项目自带的 EXAMPLES.md 里的真实案例看效果。案例一一个折扣函数40 行 vs 3 行需求加一个计算折扣的函数。❌ 过度工程版抽象基类、两种折扣策略实现、配置数据类、计算器类光调用就要 30 行 setup✅ 简单版一个函数输入金额和百分比返回折扣EXAMPLES.md 点破了一个关键过度工程版并不错——策略模式本身是正确的设计。错在时机需求还没出现就把复杂度加上了结果更难读、更容易出 Bug、更难测试。等真正需要多种折扣类型时再重构成本更低。用项目自己的话说好代码是简单解决今天的问题而不是提前解决明天的问题。案例二修 Bug 的 diff 里不该出现的东西需求修掉空邮箱让校验器崩溃的 Bug。❌ 模型常做增强邮箱校验规则、加用户名校验、改注释、加 docstring✅ 应该做只改处理空邮箱的两行其余原样不动这个案例的检验标准值得直接抄走每一行修改都应能直接追溯到用户的请求。做不到就是改多了。案例三限流需求300 行一次提交 vs 4 步可验证计划需求给 API 加限流。❌ 一次提交Redis、多策略、配置系统、监控共 300 行没有任何验证点✅ 分 4 步内存限流验证第 11 次请求返回 429→ 抽成中间件验证现有端点测试仍通过→ 接 Redis验证重启后限流计数保留→ 按端点配置验证各端点速率各自生效每一步独立可验证、可部署第 1 步做完就能上线。怎么判断它在工作README 给了 4 个可观察信号不需要玄学判断diff 里不必要的改动变少只出现请求的改动因过度复杂导致的重写变少澄清问题出现在实现之前而不是犯错之后PR 干净没有顺带的重构和改进 适用与不适用什么时候值得用值得用的场景非平凡的编码任务尤其是改现有代码库——顺手乱改在这里代价最高diff 会被多人审查的团队协作需要一致的编码标准你已经被模型乱猜需求坑过想让它先问再做项目自己交代的权衡这套准则偏向谨慎而非速度。修个拼写错误、一眼能看出一行的改动用判断力即可不必走完整流程。目标是减少非平凡工作中的昂贵错误而不是拖慢小任务。另外两个事实层面的局限它约束的是行为不是能力——模型的编码水平不会因此变强只是更少用力过猛它依赖助手支持指令文件或插件Claude Code、Cursor不支持这类机制的工具用不了 andrej-karpathy-skills 快速上手步骤先读 EXAMPLES.md9 组真实前后对比是建立直觉最快的方式全局安装推荐在 Claude Code 里执行/plugin marketplace add forrestchang/andrej-karpathy-skills再执行/plugin install andrej-karpathy-skillskarpathy-skills所有项目生效按项目配置把 CLAUDE.md 放到项目根目录已有 CLAUDE.md 的项目直接追加合并可与项目特定规则共存Cursor 用户把.cursor/rules/karpathy-guidelines.mdc复制到目标项目的.cursor/rules/目录设置与注意事项见 CURSOR.md也可以本地克隆仓库git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills从一个小场景开始试挑现有代码里一个真实小 Bug 让它修对比 diff 里还有没有无关改动完整技能文本在 skills/karpathy-guidelines/SKILL.md想改某条原则时记得同步 CLAUDE.md 与 Cursor 规则。今晚就能做的一件事把 CLAUDE.md 复制到你手头项目的根目录选一个你正要修的小 Bug 开工。如果这次的 diff 里只有你请求的改动说明它在工作。【免费下载链接】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），仅供参考 andrej-karpathy-skills 完整解读：1 个 CLAUDE.md 纠正 LLM 编码的 3 个坏习惯
andrej-karpathy-skills 完整解读1 个 CLAUDE.md 纠正 LLM 编码的 3 个坏习惯【免费下载链接】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 助手修一个空邮箱导致校验崩溃的小 Bug它却顺手改了引号风格、加了类型标注、重写了注释还补了一段没人要的用户名校验。andrej-karpathy-skills 就是冲这类问题来的一个用 CLAUDE.md 行为准则改善 Claude Code及同类编码助手行为的开源项目核心是纠正 LLM 写代码时的 3 个坏习惯——乱猜需求、过度设计、顺手乱改。这种 diff 很难审查你要在一堆无关改动里找出真正修 Bug 的那两行。更糟的是模型做这些假设时不会告诉你——它悄悄选了一种解释然后闷头执行到底。 项目定位它到底是什么一句话它不是编程框架也不是新工具而是几份给编码助手看的工作守则文件。内容来自 Karpathy 对 LLM 编码缺陷的观察模型会替你做出错误假设还不检查、偏爱把代码搞复杂、甚至会改动自己并不理解的代码和注释。它解决的是生成的代码看着对但假设错、改动杂、难审查的问题服务对象是用 Claude Code、Cursor 这类助手的开发者。可以把它理解成一份通用的 Claude Code 行为准则、LLM 编码行为准则。中文读者可以直接读 README.zh.md。 机制拆解3 个机制分别管住输入、过程和终点这个项目的核心思想一句话不教模型怎么写代码而是管住它的工作习惯。四条原则被组织成三层防线管住输入不许闷头猜、管住过程少写、少改、管住终点必须有可验证的成功标准。机制一先想清楚再动手把假设摆到台面上改变了什么行为模型遇到模糊需求默认动作是悄悄选一种解释然后执行。CLAUDE.md 里的 Think Before Coding 一节把这个默认动作反了过来——假设必须明说、多种解释必须并列、想不清楚必须停下来问。❌ 传统做法你说导出用户数据它直接写函数把全部用户导出到本地文件字段、路径、格式全靠猜✅ 项目做法先问四个问题——导出全部还是子集什么交付形式文件/接口/后台任务要哪些字段数据量多大然后给出最简单的方案这个机制的价值不是多问几轮话而是把猜错的代价从整段代码重写降到多回答一条消息。机制二少写、少改两句话约束输出过度工程和顺手乱改是模型在写代码、改代码时的两种冲动Simplicity First 和 Surgical Changes 分别管住它们。写代码时不写要求之外的功能不为一次性代码建抽象不加没人要的灵活性和可配置性不为不可能发生的场景写错误处理检验标准资深工程师会说写复杂了吗会说就重写改代码时不改进相邻的代码、注释、格式没坏的东西不重构匹配现有风格哪怕你更想换一种写法无关的死代码提一句别删检验标准每一行改动都能直接追溯到你的请求❌ 传统做法修一个空邮箱校验的 Bugdiff 里多出邮箱规则增强、用户名校验、新注释✅ 项目做法diff 里只有处理空邮箱的那两行机制三给成功标准不给口头指令Karpathy 的观察是LLM 非常擅长朝着明确目标循环直到达成。Fix the bug这种指令没有可验证的终点模型只能边做边问换成可验证目标它就能自己循环。❌ 传统做法修复认证系统 → 模型列个模糊计划看看代码、找问题、改一改、测一测没有终点✅ 项目做法先定义成功标准——改密后旧会话失效 → 写测试复现验证测试失败→ 修复验证测试通过→ 查边界情况验证附加测试通过→ 确认无回归验证全部测试通过多步任务同理每一步后面挂一个 verify 检查点。标准越具体模型越少回头问你让它能跑这种弱标准则意味着全程需要你盯着。️ 效果实证EXAMPLES.md 里的真实前后对比上面讲的是机制下面用项目自带的 EXAMPLES.md 里的真实案例看效果。案例一一个折扣函数40 行 vs 3 行需求加一个计算折扣的函数。❌ 过度工程版抽象基类、两种折扣策略实现、配置数据类、计算器类光调用就要 30 行 setup✅ 简单版一个函数输入金额和百分比返回折扣EXAMPLES.md 点破了一个关键过度工程版并不错——策略模式本身是正确的设计。错在时机需求还没出现就把复杂度加上了结果更难读、更容易出 Bug、更难测试。等真正需要多种折扣类型时再重构成本更低。用项目自己的话说好代码是简单解决今天的问题而不是提前解决明天的问题。案例二修 Bug 的 diff 里不该出现的东西需求修掉空邮箱让校验器崩溃的 Bug。❌ 模型常做增强邮箱校验规则、加用户名校验、改注释、加 docstring✅ 应该做只改处理空邮箱的两行其余原样不动这个案例的检验标准值得直接抄走每一行修改都应能直接追溯到用户的请求。做不到就是改多了。案例三限流需求300 行一次提交 vs 4 步可验证计划需求给 API 加限流。❌ 一次提交Redis、多策略、配置系统、监控共 300 行没有任何验证点✅ 分 4 步内存限流验证第 11 次请求返回 429→ 抽成中间件验证现有端点测试仍通过→ 接 Redis验证重启后限流计数保留→ 按端点配置验证各端点速率各自生效每一步独立可验证、可部署第 1 步做完就能上线。怎么判断它在工作README 给了 4 个可观察信号不需要玄学判断diff 里不必要的改动变少只出现请求的改动因过度复杂导致的重写变少澄清问题出现在实现之前而不是犯错之后PR 干净没有顺带的重构和改进 适用与不适用什么时候值得用值得用的场景非平凡的编码任务尤其是改现有代码库——顺手乱改在这里代价最高diff 会被多人审查的团队协作需要一致的编码标准你已经被模型乱猜需求坑过想让它先问再做项目自己交代的权衡这套准则偏向谨慎而非速度。修个拼写错误、一眼能看出一行的改动用判断力即可不必走完整流程。目标是减少非平凡工作中的昂贵错误而不是拖慢小任务。另外两个事实层面的局限它约束的是行为不是能力——模型的编码水平不会因此变强只是更少用力过猛它依赖助手支持指令文件或插件Claude Code、Cursor不支持这类机制的工具用不了 andrej-karpathy-skills 快速上手步骤先读 EXAMPLES.md9 组真实前后对比是建立直觉最快的方式全局安装推荐在 Claude Code 里执行/plugin marketplace add forrestchang/andrej-karpathy-skills再执行/plugin install andrej-karpathy-skillskarpathy-skills所有项目生效按项目配置把 CLAUDE.md 放到项目根目录已有 CLAUDE.md 的项目直接追加合并可与项目特定规则共存Cursor 用户把.cursor/rules/karpathy-guidelines.mdc复制到目标项目的.cursor/rules/目录设置与注意事项见 CURSOR.md也可以本地克隆仓库git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills从一个小场景开始试挑现有代码里一个真实小 Bug 让它修对比 diff 里还有没有无关改动完整技能文本在 skills/karpathy-guidelines/SKILL.md想改某条原则时记得同步 CLAUDE.md 与 Cursor 规则。今晚就能做的一件事把 CLAUDE.md 复制到你手头项目的根目录选一个你正要修的小 Bug 开工。如果这次的 diff 里只有你请求的改动说明它在工作。【免费下载链接】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），仅供参考