引言“LLMs excel at looping until they meet specific goals — so provide success criteria rather than imperative instructions.”这是一天一个开源项目系列的第108篇文章。今天带你了解的项目是andrej-karpathy-skills。这个项目非常特别它的核心不是一个工具、框架或库——就是一个 CLAUDE.md 文件。故事起点是 Andrej Karpathy 在大量使用 Claude Code 之后发的一个 X 帖子记录了他发现 LLM 在编码任务中反复出现的失效模式不问清楚就动手、把简单问题工程化成复杂方案、顺手改了不该改的代码……multica-ai 团队把这些观察提炼成了四条可操作的行为准则打包进一个 CLAUDE.md 文件——你把它放进项目Claude Code 就会改变行为方式。同时提供 Claude Code 插件和 Cursor 规则两种格式覆盖主流 AI 编码工具。这个项目很好地回答了一个常被忽视的问题与其教 LLM 具体做什么不如告诉它怎么思考。你将学到什么Karpathy 观察到的 LLM 编码四大失效模式是什么四条行为准则的具体内容与实际案例三种安装方式独立 CLAUDE.md / Claude Code 插件 / Cursor 规则为什么给出成功标准比给出操作步骤更有效如何验证这套准则是否真的在起作用前置知识使用过 Claude Code 或 Cursor 等 AI 编码工具有一定的日常开发经验能感受到 LLM 编码的痛点项目背景项目简介andrej-karpathy-skills 的核心是一份行为配置文件。它的设计哲学来自一个关键洞察LLM 编码的问题往往不是能力不够而是行为没有约束。模型有能力写简单的代码但没人告诉它不要写复杂的。模型有能力先问清楚需求但没有压力让它问。模型知道不该动无关的代码但顺便改一下的习惯很难克制。这份 CLAUDE.md 文件把这些约束显式化让每次对话都带着这些行为准则进入上下文。项目同时提供了三种分发格式适配不同的使用场景和工具链。作者/团队介绍维护方multica-aiMultica AI 团队灵感来源Andrej Karpathy 在 X 上分享的 LLM 编码使用笔记原始作者该 CLAUDE.md 内容最初由 forrestchang 整理multica-ai 将其扩展为插件生态关于 Andrej KarpathyOpenAI 联合创始人之一前特斯拉 AI 负责人现独立研究者以 nanoGPT、Neural Networks: Zero to Hero 等教学项目在 AI 社区广为人知。他对 AI 工具的实际使用反馈在业内有很强的参考价值。项目数据 核心文件:CLAUDE.md行为准则 Claude Code 插件 Cursor 规则 附带:EXAMPLES.md四原则的对比示例 License: MIT 仓库: multica-ai/andrej-karpathy-skills主要功能核心作用这份 CLAUDE.md 直接对抗 LLM 编码中最常见的四个失效模式LLM 编码常见失效 ├── 静默假设不问清楚直接动手 ├── 过度工程化把简单问题变复杂 ├── 扩大改动范围顺手改了不相关代码 └── 模糊执行缺乏可验证的完成标准 ↓ CLAUDE.md 注入四条行为准则 行为改变 ├── 编码前先思考Think Before Coding ├── 简单优先Simplicity First ├── 外科手术式修改Surgical Changes └── 目标驱动执行Goal-Driven Execution快速开始方式一Claude Code 插件推荐全局生效/plugin marketplaceaddforrestchang/andrej-karpathy-skills /plugininstallandrej-karpathy-skillskarpathy-skills安装后对所有项目生效无需在每个项目中单独配置。方式二项目级 CLAUDE.md只对当前项目生效cdyour-projectcurl-oCLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md如果项目中已有 CLAUDE.md可手动将内容合并进去。方式三Cursor 规则仓库中已包含.cursor/rules/karpathy-guidelines.mdc设置了alwaysApply: true。将该文件复制到你的项目中即可mkdir-p.cursor/rulescppath/to/karpathy-guidelines.mdc .cursor/rules/验证是否生效打开 Cursor → Settings → Rules查看规则是否出现在列表中。验证准则是否在起作用的信号实现前 Claude 会主动提问而不是直接开始写PR diff 里的改动更干净只涉及被请求的部分不再出现顺便优化了一下的代码变动四条准则详解准则一编码前先思考Think Before Coding针对的问题LLM 在遇到模糊需求时倾向于做出隐性假设并直接执行而不是把不确定性暴露出来。错误行为示例用户: 给我导出用户数据的功能 LLM: [直接开始写代码] → 假设导出 CSV假设所有字段假设同步下载 → 但用户实际需要的是后台任务 特定字段 JSON 格式正确行为准则要求先把不确定性表面化用户: 给我导出用户数据的功能 LLM: 在开始之前有几个问题需要确认 1. 范围导出所有用户还是按条件过滤 2. 格式CSV / JSON / Excel 3. 交付方式浏览器直接下载、后台任务发邮件还是 API 接口 4. 字段需要哪些字段是否包含敏感数据另一个典型案例——让搜索更快有三种完全不同的含义解释实际需求解决方案响应时间API 返回慢加索引、缓存、优化查询吞吐量并发量高水平扩展、队列体感速度用户觉得慢预加载、骨架屏、即时反馈三种解释需要完全不同的方案任何一个都不能默认。准则要求当存在多种合理解释时呈现所有解释让用户选择而不是悄悄选一个。在真正困惑时停下来说我不确定这里应该如何处理而不是硬撑下去。准则二简单优先Simplicity First针对的问题LLM 有强烈的过度工程化倾向在复杂性真正需要之前就引入抽象、框架和灵活性。错误行为示例——折扣计算# 用户要求实现一个简单的折扣计算# ❌ LLM 给出的方案10 倍代码量classDiscountStrategy(ABC):abstractmethoddefcalculate(self,price:float)-float:...classPercentageDiscount(DiscountStrategy):def__init__(self,config:DiscountConfig):...defcalculate(self,price:float)-float:...classDiscountCalculator:def__init__(self,strategy:DiscountStrategy):...defapply(self,cart:Cart)-float:...# 工厂类、配置类、注册器……# ✅ 实际需要的1 个函数defapply_discount(price:float,discount_pct:float)-float:returnprice*(1-discount_pct/100)另一个示例——“保存用户偏好设置”❌ LLM 实现了 - 带失效时间的缓存层 - 输入验证用户没要求 - 冲突合并逻辑用户没遇到这个问题 - 变更通知系统用户没提到 ✅ 实际需要的 - 把偏好写入数据库的一个函数准则给出的判断标准“一个 senior 工程师看到这段代码会说它过于复杂吗”如果 200 行代码可以写成 50 行就重写成 50 行。核心格言“Good code is code that solves today’s problem simply, not tomorrow’s problem prematurely.”过早引入的复杂性不只是浪费还会让代码更难理解、引入更多 bug哪怕它遵循了正确的设计模式。准则三外科手术式修改Surgical Changes针对的问题LLM 做顺路重构——修复一个 bug 时顺便改了引号风格、加了类型注释、重命名了变量、整理了导入顺序。这个行为看起来是好意但实际上有两个严重问题让 diff 变得难以审查reviewer 无法区分哪些改动是 bug 修复、哪些是顺便引入意外 regression每一行未经要求的改动都是潜在的风险点正确的做法# 原始代码有 bug同时有一些不完美之处defcalculate_total(items):total0foriteminitems:totalitem[price]# 单引号returntotal# 缺少类型注释# ❌ LLM 的全面改善defcalculate_total(items:list[dict])-float:# 加了类型注释Calculate total price of items.# 加了文档字符串total:float0.0# 改了变量类型foriteminitems:totalitem[price]# 改成双引号风格统一returntotal# ✅ 只修复 bug假设 bug 是 items 为空时的问题defcalculate_total(items):ifnotitems:# 只加了这一行return0total0foriteminitems:totalitem[price]# 保持原有风格不变returntotal准则的具体要求每一行改动都要能追溯到用户的请求匹配现有代码风格即使你更喜欢另一种不要改进路过的代码除非被明确要求只清理你的改动产生的无用导入/变量不要动原有的准则四目标驱动执行Goal-Driven Execution针对的问题LLM 在接到模糊任务时会给出看起来很全面但缺乏可验证性的计划。模糊计划的示例任务: 重构 auth 模块 ❌ 模糊计划: 1. 审查现有代码 2. 识别问题 3. 改进结构 4. 运行测试 → 没有任何一步有明确的完成标准准则要求把任务转化为可验证的目标任务: 修复登录 bug ✅ 目标驱动计划: 步骤 1: 写一个复现 bug 的失败测试 验证点: 测试确实在当前代码上失败 步骤 2: 实现修复 验证点: 刚才写的测试现在通过 步骤 3: 运行完整测试套件 验证点: 没有新的回归 → 每步都有明确的完成定义另一个示例任务: 重构 auth 模块 ✅ 具体化后: 1. 所有现有测试通过记录基线 2. 抽取 TokenService验证独立单元测试通过 3. 重构 AuthController 使用 TokenService验证集成测试通过 4. 所有原有测试仍然通过无回归Karpathy 的核心洞察LLM 最擅长的事是循环直到满足特定目标——因此提供成功标准比提供操作步骤更有效。命令式指令“先做 A然后做 B然后做 C”在出错时会让 LLM 不知道该怎么处理。声明式目标“这个测试要通过”、“这个接口要可调用”让 LLM 可以自主决定路径同时有清晰的完成标准。为什么是一个文件而不是一个工具这个项目的设计选择本身就值得深思。面对 LLM 编码的行为问题可以有很多种解决方案构建一个代理框架来约束行为开发后处理工具来检测和修正训练一个更好的模型andrej-karpathy-skills 选择的是最简单的那个一个文本文件放进项目里让 LLM 自己读自己执行。这个选择本身就是对简单优先原则的最好示范——用最少的机制解决今天的问题。而且文本文件有一个工具无法比拟的优势可以随时阅读、理解和修改没有任何黑盒。项目地址与资源官方资源GitHub: https://github.com/multica-ai/andrej-karpathy-skills原始 CLAUDE.md: 直接curl下载即可使用示例文档:EXAMPLES.md四原则的对比示例推荐阅读适用人群Claude Code / Cursor 日常用户希望减少 LLM 的过度工程化和不必要的代码改动团队工程效能负责人在团队 CLAUDE.md 中集成这套行为规范统一 AI 辅助编码的行为基准追求代码可审查性的开发者厌倦了 LLM 生成的超级 diff想要干净的、只包含请求变更的 PR总结与展望核心要点回顾来源直接提炼自 Karpathy 对 LLM 编码失效模式的一手观察有真实使用基础四条准则编码前先思考把隐性假设变成显性问题而不是悄悄选一个简单优先写解决今天问题的最少代码不预建灵活性外科手术式修改每行改动都能追溯到请求不做顺路重构目标驱动执行给成功标准不给操作步骤三种安装格式CLAUDE.md项目级/ Claude Code 插件全局/ Cursor 规则核心哲学LLM 最擅长循环直到达成目标——给目标不给步骤自我示范用最简单的方式一个文件解决问题自身就是简单优先原则的体现一句话评价andrej-karpathy-skills 做了一件看似微小但影响深远的事把怎么用好 LLM 写代码的工程智慧压缩进一个任何人都能读懂、放进任何项目的文本文件——而这个文件本身就是它所倡导的简单哲学的最好证明。欢迎来我的个人主页找到更多有用的知识和有趣的产品
一天一个开源项目（第108篇）：Andrej Karpathy Skills - 用一个 CLAUDE.md 文件修复 LLM 编码的四个顽疾
引言“LLMs excel at looping until they meet specific goals — so provide success criteria rather than imperative instructions.”这是一天一个开源项目系列的第108篇文章。今天带你了解的项目是andrej-karpathy-skills。这个项目非常特别它的核心不是一个工具、框架或库——就是一个 CLAUDE.md 文件。故事起点是 Andrej Karpathy 在大量使用 Claude Code 之后发的一个 X 帖子记录了他发现 LLM 在编码任务中反复出现的失效模式不问清楚就动手、把简单问题工程化成复杂方案、顺手改了不该改的代码……multica-ai 团队把这些观察提炼成了四条可操作的行为准则打包进一个 CLAUDE.md 文件——你把它放进项目Claude Code 就会改变行为方式。同时提供 Claude Code 插件和 Cursor 规则两种格式覆盖主流 AI 编码工具。这个项目很好地回答了一个常被忽视的问题与其教 LLM 具体做什么不如告诉它怎么思考。你将学到什么Karpathy 观察到的 LLM 编码四大失效模式是什么四条行为准则的具体内容与实际案例三种安装方式独立 CLAUDE.md / Claude Code 插件 / Cursor 规则为什么给出成功标准比给出操作步骤更有效如何验证这套准则是否真的在起作用前置知识使用过 Claude Code 或 Cursor 等 AI 编码工具有一定的日常开发经验能感受到 LLM 编码的痛点项目背景项目简介andrej-karpathy-skills 的核心是一份行为配置文件。它的设计哲学来自一个关键洞察LLM 编码的问题往往不是能力不够而是行为没有约束。模型有能力写简单的代码但没人告诉它不要写复杂的。模型有能力先问清楚需求但没有压力让它问。模型知道不该动无关的代码但顺便改一下的习惯很难克制。这份 CLAUDE.md 文件把这些约束显式化让每次对话都带着这些行为准则进入上下文。项目同时提供了三种分发格式适配不同的使用场景和工具链。作者/团队介绍维护方multica-aiMultica AI 团队灵感来源Andrej Karpathy 在 X 上分享的 LLM 编码使用笔记原始作者该 CLAUDE.md 内容最初由 forrestchang 整理multica-ai 将其扩展为插件生态关于 Andrej KarpathyOpenAI 联合创始人之一前特斯拉 AI 负责人现独立研究者以 nanoGPT、Neural Networks: Zero to Hero 等教学项目在 AI 社区广为人知。他对 AI 工具的实际使用反馈在业内有很强的参考价值。项目数据 核心文件:CLAUDE.md行为准则 Claude Code 插件 Cursor 规则 附带:EXAMPLES.md四原则的对比示例 License: MIT 仓库: multica-ai/andrej-karpathy-skills主要功能核心作用这份 CLAUDE.md 直接对抗 LLM 编码中最常见的四个失效模式LLM 编码常见失效 ├── 静默假设不问清楚直接动手 ├── 过度工程化把简单问题变复杂 ├── 扩大改动范围顺手改了不相关代码 └── 模糊执行缺乏可验证的完成标准 ↓ CLAUDE.md 注入四条行为准则 行为改变 ├── 编码前先思考Think Before Coding ├── 简单优先Simplicity First ├── 外科手术式修改Surgical Changes └── 目标驱动执行Goal-Driven Execution快速开始方式一Claude Code 插件推荐全局生效/plugin marketplaceaddforrestchang/andrej-karpathy-skills /plugininstallandrej-karpathy-skillskarpathy-skills安装后对所有项目生效无需在每个项目中单独配置。方式二项目级 CLAUDE.md只对当前项目生效cdyour-projectcurl-oCLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md如果项目中已有 CLAUDE.md可手动将内容合并进去。方式三Cursor 规则仓库中已包含.cursor/rules/karpathy-guidelines.mdc设置了alwaysApply: true。将该文件复制到你的项目中即可mkdir-p.cursor/rulescppath/to/karpathy-guidelines.mdc .cursor/rules/验证是否生效打开 Cursor → Settings → Rules查看规则是否出现在列表中。验证准则是否在起作用的信号实现前 Claude 会主动提问而不是直接开始写PR diff 里的改动更干净只涉及被请求的部分不再出现顺便优化了一下的代码变动四条准则详解准则一编码前先思考Think Before Coding针对的问题LLM 在遇到模糊需求时倾向于做出隐性假设并直接执行而不是把不确定性暴露出来。错误行为示例用户: 给我导出用户数据的功能 LLM: [直接开始写代码] → 假设导出 CSV假设所有字段假设同步下载 → 但用户实际需要的是后台任务 特定字段 JSON 格式正确行为准则要求先把不确定性表面化用户: 给我导出用户数据的功能 LLM: 在开始之前有几个问题需要确认 1. 范围导出所有用户还是按条件过滤 2. 格式CSV / JSON / Excel 3. 交付方式浏览器直接下载、后台任务发邮件还是 API 接口 4. 字段需要哪些字段是否包含敏感数据另一个典型案例——让搜索更快有三种完全不同的含义解释实际需求解决方案响应时间API 返回慢加索引、缓存、优化查询吞吐量并发量高水平扩展、队列体感速度用户觉得慢预加载、骨架屏、即时反馈三种解释需要完全不同的方案任何一个都不能默认。准则要求当存在多种合理解释时呈现所有解释让用户选择而不是悄悄选一个。在真正困惑时停下来说我不确定这里应该如何处理而不是硬撑下去。准则二简单优先Simplicity First针对的问题LLM 有强烈的过度工程化倾向在复杂性真正需要之前就引入抽象、框架和灵活性。错误行为示例——折扣计算# 用户要求实现一个简单的折扣计算# ❌ LLM 给出的方案10 倍代码量classDiscountStrategy(ABC):abstractmethoddefcalculate(self,price:float)-float:...classPercentageDiscount(DiscountStrategy):def__init__(self,config:DiscountConfig):...defcalculate(self,price:float)-float:...classDiscountCalculator:def__init__(self,strategy:DiscountStrategy):...defapply(self,cart:Cart)-float:...# 工厂类、配置类、注册器……# ✅ 实际需要的1 个函数defapply_discount(price:float,discount_pct:float)-float:returnprice*(1-discount_pct/100)另一个示例——“保存用户偏好设置”❌ LLM 实现了 - 带失效时间的缓存层 - 输入验证用户没要求 - 冲突合并逻辑用户没遇到这个问题 - 变更通知系统用户没提到 ✅ 实际需要的 - 把偏好写入数据库的一个函数准则给出的判断标准“一个 senior 工程师看到这段代码会说它过于复杂吗”如果 200 行代码可以写成 50 行就重写成 50 行。核心格言“Good code is code that solves today’s problem simply, not tomorrow’s problem prematurely.”过早引入的复杂性不只是浪费还会让代码更难理解、引入更多 bug哪怕它遵循了正确的设计模式。准则三外科手术式修改Surgical Changes针对的问题LLM 做顺路重构——修复一个 bug 时顺便改了引号风格、加了类型注释、重命名了变量、整理了导入顺序。这个行为看起来是好意但实际上有两个严重问题让 diff 变得难以审查reviewer 无法区分哪些改动是 bug 修复、哪些是顺便引入意外 regression每一行未经要求的改动都是潜在的风险点正确的做法# 原始代码有 bug同时有一些不完美之处defcalculate_total(items):total0foriteminitems:totalitem[price]# 单引号returntotal# 缺少类型注释# ❌ LLM 的全面改善defcalculate_total(items:list[dict])-float:# 加了类型注释Calculate total price of items.# 加了文档字符串total:float0.0# 改了变量类型foriteminitems:totalitem[price]# 改成双引号风格统一returntotal# ✅ 只修复 bug假设 bug 是 items 为空时的问题defcalculate_total(items):ifnotitems:# 只加了这一行return0total0foriteminitems:totalitem[price]# 保持原有风格不变returntotal准则的具体要求每一行改动都要能追溯到用户的请求匹配现有代码风格即使你更喜欢另一种不要改进路过的代码除非被明确要求只清理你的改动产生的无用导入/变量不要动原有的准则四目标驱动执行Goal-Driven Execution针对的问题LLM 在接到模糊任务时会给出看起来很全面但缺乏可验证性的计划。模糊计划的示例任务: 重构 auth 模块 ❌ 模糊计划: 1. 审查现有代码 2. 识别问题 3. 改进结构 4. 运行测试 → 没有任何一步有明确的完成标准准则要求把任务转化为可验证的目标任务: 修复登录 bug ✅ 目标驱动计划: 步骤 1: 写一个复现 bug 的失败测试 验证点: 测试确实在当前代码上失败 步骤 2: 实现修复 验证点: 刚才写的测试现在通过 步骤 3: 运行完整测试套件 验证点: 没有新的回归 → 每步都有明确的完成定义另一个示例任务: 重构 auth 模块 ✅ 具体化后: 1. 所有现有测试通过记录基线 2. 抽取 TokenService验证独立单元测试通过 3. 重构 AuthController 使用 TokenService验证集成测试通过 4. 所有原有测试仍然通过无回归Karpathy 的核心洞察LLM 最擅长的事是循环直到满足特定目标——因此提供成功标准比提供操作步骤更有效。命令式指令“先做 A然后做 B然后做 C”在出错时会让 LLM 不知道该怎么处理。声明式目标“这个测试要通过”、“这个接口要可调用”让 LLM 可以自主决定路径同时有清晰的完成标准。为什么是一个文件而不是一个工具这个项目的设计选择本身就值得深思。面对 LLM 编码的行为问题可以有很多种解决方案构建一个代理框架来约束行为开发后处理工具来检测和修正训练一个更好的模型andrej-karpathy-skills 选择的是最简单的那个一个文本文件放进项目里让 LLM 自己读自己执行。这个选择本身就是对简单优先原则的最好示范——用最少的机制解决今天的问题。而且文本文件有一个工具无法比拟的优势可以随时阅读、理解和修改没有任何黑盒。项目地址与资源官方资源GitHub: https://github.com/multica-ai/andrej-karpathy-skills原始 CLAUDE.md: 直接curl下载即可使用示例文档:EXAMPLES.md四原则的对比示例推荐阅读适用人群Claude Code / Cursor 日常用户希望减少 LLM 的过度工程化和不必要的代码改动团队工程效能负责人在团队 CLAUDE.md 中集成这套行为规范统一 AI 辅助编码的行为基准追求代码可审查性的开发者厌倦了 LLM 生成的超级 diff想要干净的、只包含请求变更的 PR总结与展望核心要点回顾来源直接提炼自 Karpathy 对 LLM 编码失效模式的一手观察有真实使用基础四条准则编码前先思考把隐性假设变成显性问题而不是悄悄选一个简单优先写解决今天问题的最少代码不预建灵活性外科手术式修改每行改动都能追溯到请求不做顺路重构目标驱动执行给成功标准不给操作步骤三种安装格式CLAUDE.md项目级/ Claude Code 插件全局/ Cursor 规则核心哲学LLM 最擅长循环直到达成目标——给目标不给步骤自我示范用最简单的方式一个文件解决问题自身就是简单优先原则的体现一句话评价andrej-karpathy-skills 做了一件看似微小但影响深远的事把怎么用好 LLM 写代码的工程智慧压缩进一个任何人都能读懂、放进任何项目的文本文件——而这个文件本身就是它所倡导的简单哲学的最好证明。欢迎来我的个人主页找到更多有用的知识和有趣的产品
