Claude Code 自定义规则插件完整指南：从装上 Karpathy 行为准则到写出你的第一条规则

Claude Code 自定义规则插件完整指南从装上 Karpathy 行为准则到写出你的第一条规则【免费下载链接】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 改代码时的惊喜折腾过——顺手重构了没让它碰的文件、给一个简单功能套上三层抽象——这篇教程会用 andrej-karpathy-skills 这个开源项目带你从零搭一个自定义规则插件。读完你不仅能把它装起来还能照着项目里的现成结构写出适合自己团队的规则文件。这个项目本身很轻它的核心就是用一个行为准则文件来约束 Claude Code 这类编码助手的做事方式灵感来自 Andrej Karpathy 对大模型写代码常见毛病的总结。规则不复杂但它把AI 爱犯的错一条条翻译成了可执行的约束。⚡️ 三分钟装好让 Claude Code 先守上规矩先让东西跑起来原理我们回头再拆。项目提供了两条安装路线按你的使用习惯选一条。装成 Claude Code 插件所有项目一次生效在 Claude Code 里依次输入两行命令先添加插件市场再安装/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skillskarpathy-skills装完后这套准则会变成你的全局技能之后打开任何项目都会自动带着这些约束。这是官方推荐的方式。放进单个项目一个 CLAUDE.md 搞定如果你只想在某个项目里生效可以把仓库克隆下来git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills然后把仓库里的CLAUDE.md复制到你的项目根目录即可。如果项目里已经有自己的CLAUDE.md把内容追加合并进去不要直接覆盖。Cursor 用户怎么接用 Cursor 的话把.cursor/rules/karpathy-guidelines.mdc复制到目标项目的.cursor/rules/目录没有就新建规则即自动生效在Settings → Rules里能看到karpathy-guidelines就说明接上了。项目里附带的CURSOR.md把这套流程写得更细可以对照着看。装好后先别急着写自定义规则。花两分钟读一遍项目里的CLAUDE.md你会发现全文其实只有四个原则每条都用几行要点写完——这正是稍后你要模仿的写法。它到底在约束 AI 什么换个角度读四个原则原文按原则分章这里我们按编码的生命周期重排一遍写之前、写新代码时、改老代码时、收尾时。这样你会发现规则其实就是在四个节点上各踩了一脚刹车。动手写之前把它脑内的假设逼出来大模型最常见的毛病是替你拍板需求模糊时它不问你自己默默选一种理解然后一路跑到底。这条原则要求它在实现之前先做四件事不确定就问、有多种理解就摆出来让你选、有简单方案就直说、真的看不懂就停下来指明困惑点。对应的正确行为长这样你让它加个用户数据导出功能它应该先问导出范围、文件格式、字段清单而不是直接假设导出全部用户到 json 文件然后开写。写新代码时只写够用的行数这条专治过度工程。它的口径很硬没要求的功能不加单次使用的代码不抽抽象没人要的灵活性不做不可能发生的场景不写错误处理。判断标准也给了你——一个资深工程师会不会说这段代码写复杂了会就重写。200 行能压到 50 行的直接重写。注意它打击的是时机而不是能力策略模式本身没错错在你只有一个折扣类型时就用上了。改老代码时像外科手术一样下刀这条约束的是 diff 的边界。规则要求不顺手改进相邻代码、注释和格式不重构没坏的东西风格跟着现有代码走——哪怕你有更喜欢的写法。发现无关的死代码可以提一句但别删。唯一要主动清理的是你自己的改动导致不再被使用的导入、变量和函数。自查口径同样干脆每一行改动都应该能直接追溯到你的需求。追溯不到的就是扩散。收尾时给成功标准让它自己闭环这是整个项目最有意思的一条。Karpathy 的观察是大模型特别擅长朝着明确目标循环所以别告诉它把验证加上而是给它为非法输入写测试然后让测试通过。模糊指令修好这个 bug会换来需要反复澄清的执行可验证的目标则能让 AI 独立跑完整个循环。多步任务则先列一个简短计划每步都带一个验证怎么检查。 实战从零写一个自定义规则插件规则生效的前提是你先知道它该管什么。下面这套流程每步都给你做什么 → 怎么做 → 怎么算过。定目标你的规则要管住哪个毛病先想清楚一个具体问题比如团队里接口命名风格混乱想统一成动词开头AI 总在你的项目里加没人要的配置项每次提交都混入格式化和顺手重构。检查标准你能用一句话说明装了这条规则后AI 的哪类行为会变。说不出来就还没想清楚。搭骨架照着 SKILL.md 的结构来打开项目里的skills/karpathy-guidelines/SKILL.md这就是一个最小可用的规则文件开头一段 frontmatter 元信息正文按主题分小节每节几句要点全文不过百行。你自己的规则文件照这个骨架写就行--- name: my-team-rules description: 团队代码规范写代码、改代码、重构时使用。 license: MIT --- # 团队规则 ## 命名 - API 路由一律动词开头create-user不写 user-create ## 提交 - 每次提交只包含当前任务相关的改动不夹带格式化frontmatter 里的description不是摆设它决定 AI 在什么场景下想起用这条规则写清什么时候用比写这文件是什么更有用。检查标准全文不超过一页每条规则都能对应一个具体的错误行为没有任何原则上尽量这类无法执行的措辞。落地放进你的 Claude Code两种接法和装官方规则时一样新项目把规则内容合并进CLAUDE.md多项目通用就按 SKILL.md 的方式放进技能目录。项目官方的规则也是这么可合并设计的CLAUDE.md和SKILL.md内容刻意保持一致就是方便你挑一份用。检查标准新开一个会话问 AI你现在的代码规范是什么它能复述出你的规则要点。验收怎么证明规则真的生效别用看起来变乖了当标准用两个可观察的信号验收看 diff让 AI 做一个小改动比如修一个空指针判断检查改动是否只落在该落的行上没有夹带格式化和顺手优化看提问时机给一个模糊需求把搜索做快一点看它在动手前是否先列出可能的理解让你选。检查标准diff 干净、澄清问题出现在实现之前而不是翻车之后规则就算活了。❓ 规则写废了四类高频坑自查规则越写越长AI 还会认真读吗不会。规则文件不是论文每条规则对应一个具体错误控制在一页以内。你写的规则本身也该遵守少即是多否则 AI 会在几十条约束里挑软柿子捏。规则和现有 CLAUDE.md 冲突了听谁的先合并、后生效。合并时手动对齐措辞别留两条打架的条款。改过规则后记得同步检查CLAUDE.md、Cursor 规则和 SKILL.md 这几份副本项目贡献指南里也特别强调了多份文件要保持一致。为什么小改动也被这套流程拖慢了这是官方自己写明的取舍这套规则偏向谨慎而不是速度。改个错别字、写个明显的一行函数别走完整流程用常识。规则的目标是压住非平凡任务上的高成本错误不是给所有操作加税。怎么判断规则在起作用而不是装了个摆设持续观察三个信号diff 里的无关改动变少了因为写复杂而返工的次数降下来了澄清问题从出错之后补救变成了动手之前确认。三个信号都朝着好的方向走说明你的自定义规则插件真的在干活。写在最后你的下一步回看一遍装好官方规则只要两行命令理解它等于理解四个节点各踩一脚刹车写自己的规则就是照着SKILL.md的骨架填上你团队的毛病。建议的动手顺序今天把插件装上跑一两个任务感受 diff 的变化本周挑一个你被 AI 反复得罪过的场景按目标 → 骨架 → 落地 → 验收写出你的第一条自定义规则。规则不需要一步到位像项目推崇的那样——够用就行后面再迭代。【免费下载链接】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），仅供参考