LLM之Coding：andrej-karpathy-skills的简介、安装和使用方法、案例应用之详细攻略
目录
andrej-karpathy-skills的安装和使用方法
[驱动式改 bug 过头](#驱动式改 bug 过头)
andrej-karpathy-skills的 简介
andrej-karpathy-skills项目本质上不是一个"应用程序"，而是一套面向 AI 编码助手的行为规范 / 提示约束包。仓库首页写明，它是 "A single CLAUDE.md file to improve Claude Code behavior"，也就是通过一个 CLAUDE.md 文件，帮助 Claude Code 在编程任务中减少常见错误。中文 README 也对应说明，它是"一个单一的 CLAUDE.md 文件，用于改善 Claude Code 的行为"。
它的设计灵感来自 Andrej Karpathy 对 LLM 编码问题的总结：模型容易替用户做错误假设、不会主动澄清、容易过度复杂化代码和 API、会删除或修改自己不完全理解的内容。仓库把这些问题当作起点，试图用四条原则把模型拉回到更稳健的编码方式。
从仓库内容看，它同时面向 Claude Code 和 Cursor 两类工具：前者通过安装 Claude Code 插件或直接合并 CLAUDE.md 使用，后者则通过仓库内置的 Cursor project rule 复用同样的指导原则。
仓库最后还总结了一点很关键的洞察：这些"过度复杂"的例子并不是一眼就错，它们很多都符合设计模式和最佳实践；问题不在于"模式本身"，而在于时机不对------复杂度被提前引入，导致代码更难理解、更容易出错、实现更慢、测试更难。相反，简单版本更容易理解、实现和测试，复杂度应当在真正需要时再添加。
Github地址 :https://github.com/multica-ai/andrej-karpathy-skills
1、特点
第一，它把复杂的编码规范压缩成了 四个非常聚焦的原则：Think Before Coding、Simplicity First、Surgical Changes、Goal-Driven Execution。README 和 CLAUDE.md 都强调，这四条原则分别对应错误假设、过度工程、无关修改和缺少验证这四类典型问题。
第二，它强调 编码前先思考、先澄清。仓库写得很直接：不要假设、不要隐藏困惑、要显式说明假设、在存在多种解释时不要默默选一种、必要时要提出异议、在不清楚时应停下来询问。这个特点的目标是减少"看似顺利推进、其实方向错了"的 LLM 行为。
第三，它强调 简洁优先。仓库明确反对为了"未来可能会用到"而提前加抽象、加配置、加错误处理、加新特性；如果 200 行能写成 50 行，就应该重写得更简单。它把"高级工程师会不会觉得太复杂"当作一个实用检验标准。
第四，它强调 精准修改。也就是说，AI 在修 bug 或加功能时，只应改动和用户请求直接相关的地方，不应顺手重构相邻代码、改注释、改格式、碰不相关的死代码。仓库甚至明确写到：每一行改动都应该能追溯到用户请求。
第五，它强调 目标驱动执行。项目把很多命令式任务改写成可验证目标，例如"加验证"要转成"先为无效输入写测试，再让测试通过"，"修 bug"要转成"先写出能复现 bug 的测试，再修复"，"重构 X"要转成"确保重构前后测试都通过"。这让模型不是只会"做事"，而是会围绕可验证标准循环推进。
第六，它还有一个很重要的取向：偏谨慎，不偏速度。CLAUDE.md 直接写明这些指南会向 caution 而不是 speed 倾斜，不过对于非常简单的任务仍然要用判断力，不需要每次都把流程做得很重。
andrej-karpathy-skills的安装和使用方法
1、安装
仓库给出了两条主要用法路线。第一条是 Claude Code 插件方式，也是 README 标注的推荐方式。步骤是先在 Claude Code 中添加 marketplace：/plugin marketplace add forrestchang/andrej-karpathy-skills，然后安装插件：/plugin install andrej-karpathy-skills@karpathy-skills。这样会把这些指南作为 Claude Code 插件安装到所有项目中。
第二条是 直接把 CLAUDE.md 合并到项目里。对于新项目，可以直接下载仓库里的 CLAUDE.md 到项目根目录；对于已有项目，则可以把这份内容追加到现有 CLAUDE.md 末尾。仓库给出的示例命令是通过 curl 从原始地址拉取文件并写入当前项目。
2、使用方法
项目还说明，这些指南可以与 项目特定指令 叠加使用。也就是说，你可以把通用的 Karpathy 风格规则和自己的业务规则合并在同一个 CLAUDE.md 中，例如再加上 TypeScript strict mode、API 测试要求、统一错误处理模式等项目级规范。
如果你使用的是 Cursor，仓库内已经提交了一个 Cursor project rule，因此打开这个项目时，同样的指导原则会自动生效。CURSOR.md 明确把这套规则与 Claude Code 的使用方式关联起来，说明它不是只对一种工具有效，而是可以跨编辑器复用。
andrej-karpathy-skills的案例应用
仓库的 EXAMPLES.md 给了非常具体的"正反对照"案例
隐藏假设
用户说"添加导出用户数据功能"，LLM 很容易直接假设要导出全部用户、固定文件位置、固定字段、固定格式；而正确方式是先把范围、格式、字段、数据量等问题问清楚，再决定实现路径。这个例子对应的就是 Think Before Coding。
多个解释并存时不要擅自决定
比如用户说"让搜索更快"，这可能是响应时间更快、吞吐更高，或者体感更快；仓库建议把不同含义拆开，告诉用户当前耗时情况，并让用户明确是哪一种"更快"。这说明该指南特别强调"先澄清，再编码"。
过度抽象
比如用户只要求"写一个折扣计算函数"，LLM 却可能先造出策略模式、配置对象、抽象基类等一大堆结构；而指南要求先写最小可用实现，只有在真正出现多折扣类型需求时再增加复杂度。这个例子对应 Simplicity First。
凭空加功能
例如用户只说"把用户偏好存进数据库"，LLM 却可能顺手加缓存、合并、验证、通知等一堆未被要求的能力；而仓库给出的正确示例是只做"更新数据库这一件事"，其余功能等需求出现时再加。
驱动式改 bug 过头
比如用户说"空邮箱会让验证器崩溃"，LLM 可能借机改写整个用户验证逻辑，连用户名校验、注释、文档都一起变掉；而指南要求只改空邮箱相关的几行，别动无关内容。这个例子对应 Surgical Changes。
风格漂移
比如用户只要求给上传函数加日志，LLM 却可能同时改类型标注、引号风格、返回值结构、异常处理方式；而仓库强调应该严格匹配原有风格，只补最必要的日志和极少量相关代码。
测试先行、先复现再修复
例如用户说"排序在重复分数时出问题"，正确流程不是立刻改排序逻辑，而是先写一个会复现问题的测试，再修复并确认测试稳定通过。这是 Goal-Driven Execution 的典型用法。
多步骤任务拆解并逐步验证
比如"给 API 加限流"，仓库建议先做基础内存限流，再抽 middleware，再加 Redis 后端，再加可配置限额；每一步都要给出明确验证方法，比如测试请求次数、检查不同端点、验证重启和多实例共享情况。